Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Below are aspects that EBA can improve and correct in its final wording.
Definition of authentication code
The RTS currently describes ‘authentication code’ as either being an OTP or digital signature, which appears to restrict technological-neutrality, innovation and even currently available options because secure tokens are for example currently not considered in EBA’s description. This would exclude very good solutions because the requirements mention technologies instead of outcomes.
GSMA suggests therefore that the EBA requires authentication codes in such a way that it should be possible to use a range of solutions including OTP, digital signatures and secure tokens that can be signed by both the authentication provider and the PSP depending on the situation.
Within the context of ‘authentication code’, the EBA is also considering ‘keys stored in the authentication elements’. EBA instead should explicitly ensure more flexibility in the description of authentication codes and allow both public and private keys that can be stored in either an authentication system or a device.
EBA’s current approach would inadvertently block innovation and future industry developments. For example, the mobile operator solution uses keys that are not linked to the user and stored on the mobile device. This should be possible to avoid hindering a large area of innovation in the field of SCA.
Art. 1 section 2 of the RTS could also be clarified, because subsection (b) is a special case of (c) where the forging is based on the knowledge of “authentication codes generated for the same payer”.
Based on the above explanation, GSMA suggests following changes:
EBA current wording:
RTS Art. 1 (1) :
…the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time the payer, making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
RTS Art. 1 (2): The authentication code shall be characterised by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time, ensuring that:
a) No information on any of the elements of strong customer authentication categorised as knowledge, possession and inherence can be derived from the disclosure of the authentication code;
b) It is not possible to generate a new authentication code based on the knowledge of another authentication code generated for the same payer
c) The authentication code cannot be forged.
Suggested new wording:
RTS Art. 1 (1) :
…the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time the payer, making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
RTS Art. 1 (2): The authentication code shall be characterised by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time, ensuring that:
a) No information on any of the elements of strong customer authentication categorised as knowledge, possession and inherence can be derived from the disclosure of the authentication code;
b) It is not possible to generate a new authentication code based on the knowledge of another authentication code generated for the same payer
b)The authentication code cannot be forged
including but not limited to forging new authentication codes based on the knowledge of another authentication code generated for the same payer;”
c) Is independently verifiable
d) Generated based on payment security credentials and the amount of the transaction
Definition and use of digital signatures
The EBA mentions digital signatures without defining them. GSMA suggests to define signatures similarly as in eIDAS. It is of utmost importance that different types of signatures are allowed such as secure tokens provided by authentication providers with keys securely stored in the cloud or in authentication providers’ servers.
Mandating the PSP to digitally sign the software used to authenticate a transaction would be impractical in the case where the PSP outsources the authentication to a service provider. Furthermore, mandating the use of digital signatures for the end to end process would default all transactions to LoA4 and its requisite infrastructure. This may rule out customers in markets that deploy a SIM based solution (applet) without NFC SIMs.
EBA should refrain from mandating digital signatures at the highest possible assurance level (LoA4)
The requirement of a digital signature in the context of the RTS is too specific and also requiring highest technical security level possible – Level of Assurance 4 (LoA4). This is too restrictive and will restrict technologies unnecessarily without the benefit of necessarily creating more security for the authentication processes in its entirety. A more proportionate and technologically neutral requirement would be to allow for symmetric keys as well.
EBA should demand overall security of the strong customer authentication procedure and not determine limiting technological choices such as digital signatures.
Mobile Connect uses the standard Level of Assurance (LoA) definitions from ISO 29115 for authentication: a global standards-based approach to authentication security. LoA 3 is a high-security two-factor authentication solution and is comparable to European eIDAS directive defined security level “substantial”.
Within the Mobile Connect framework, LoA 3 service is typically achieved using a SIM applet with security credentials placed on the user’s mobile phone SIM secure element, together with strong encryption for messages to and from the SIM. GSMA believes that for payments conducted under the PSD2, LoA3 is sufficiently secure. Further, we consider that business processes and dynamic mobile network data solutions are more effective ways to increase security and fraud resistance than the addition of a secure encryption algorithm
Based on the above explanation, GSMA suggests following description of the authentication code:
Exact reference in the EBA consultation document par. 24 page 11 (GSMA addition in bold):
The authentication code can be either a single piece of data that is being input by the payer on the interface of the relevant PSP or can be generated from several pieces of data, such as one-time password that is being input by the payer on the interface of the relevant PSP, the amount, and the payee of the transaction. Alternatively, the authentication code can take the form of different types signatures, such as signatures provided by authentication providers, digital signatures of such data using keys stored in the authentication elements, in the cloud or in the authentication provider’s server.
EBA’s reasoning on the compatibility between public e-identity schemes under the e-IDAS regulation framework and the RTS may imply that only e-identity schemes using digital signatures (LoA4) comply with these RTS. This would be very limiting for the choice of technology whilst also not necessarily adding more security, because it focuses on technical components instead on overall security for the system.
Based on the above explanation, GSMA suggests following changes:
Exact reference in the EBA consultation document par. 34, page 12:
… the proposed draft RTS do not prevent the possibility to adopt strong customer authentication procedures based on the services of a public e-identity scheme under the e-IDAS regulation framework, as long as these public e-identity schemes comply with the draft RTS.
Suggested new wording:
… the proposed draft RTS do not prevent the possibility to adopt strong customer authentication procedures based on the services of a public e-identity scheme under the e-IDAS regulation framework, as long as these public e-identity schemes comply with the draft RTS.
Independence: differentiated view of the mobile device is necessary
For mobile payments, the same level of independence, with beneficial impact on security as requested in the EBA text, can be achieved also by ensuring that the consumption and the authentication channel are two independent channels:
During the authentication process independence is created by out-of-band authentication, whereby the consumption channel and the authentication channel are separate. The user uses the consumption channel (i.e. banking app) for the payment service. During the interaction of the user with the PSP, the SIM applet or smart phone app is the authenticator and uses the authentication channel. Whilst this is on the same device, these are always separate channels.
This should be clearly stated in the EBA text.
GSMA would also like to repeat the differentiated view of the mobile device already presented in the previous consultation on EBA’s discussion paper, because it is crucial for understanding independence. See below.
Differentiated view of the mobile device
The mobile phone is a combination of following elements: 1) mobile device + 2) mobile business processes + 3) mobile network. They all function independently and the device can be reached even if the consumer has lost the device. With all three of these elements being linked in the mobile phone and actively used, the mobile phone is very secure possession element for payment service users:
1) The mobile device
The mobile device is controlled by the consumer whereas SIM security and SIM business processes are always owned by the operator. The element that disappears when a phone is lost/stolen is the device itself. The consumer loses the ability to use the device. Even when the device has been lost or stolen, the MNO will be able to access the device / SIM whenever it is active and attached to the network and therefore usable for Mobile Connect authentication purposes (if the SIM is inactive or not attached it won’t be usable for Mobile Connect authentication purposes.)
On a more detailed level – the mobile device can also be used as three subsets of possession elements.
2) The business process
This business process is the mobile operator’s ability to interact with the handset, i.e. communicate with the SIM and disable it. Business processes still function and have access to the lost/stolen device and can disable the use of the device after it has been reported lost/stolen. These interactions between device and network ensure security, because risk situations can be dealt with appropriately. The loss of a mobile phone is usually much more quickly noticed by the consumer than the loss of a wallet. And the consumer has an immediate interest to contact the operator to lock the use of the mobile phone and Mobile Connect remotely over the air with the SIM provisioning process. Not only can the device be disabled, but also additional knowledge such as the location of the device is available independently of the device and customer. The operator can also restore the payment capability remotely, if and when appropriate.
3) The mobile network
The mobile network is interlinking the following elements: mobile phone, SIM and the phone number (MSISDN). This association is stored very securely in the mobile network, which is not penetrable from the outside. This means that whenever a mobile device attaches to a network (i.e. consumer switches phone on), the network is aware of the interlinking of phone + SIM + phone number. If the device is suddenly used with a different SIM, the network knows immediately that this is a new association and can take immediate action, if this is interpreted as fraud (i.e. block the Mobile Connect account, mark the phone as stolen, etc.). If a phone is marked as stolen by one mobile operator, this is known to mobile operators around the world. The mobile industry has a tried and tested processes for this.
Furthermore, the fundamental independence between the mobile device (something the consumer has) and the PIN (something the consumer knows) remains intact even when the mobile device is lost or stolen.
For example with Mobile Connect, the phone with the hardware secure element notices when the SIM has been exchanged. If necessary, the phone can be disabled over the air independently of the SIM.
Based on above explanations GSMA suggests following changes to the EBA’s reasoning and wording of the RTS:
Exact EBA reference in consultation document par. 26, page 11 (GSMA addition in bold):
To that end, the channel, device or mobile application where the information about the amount and the payee of the transaction is displayed should be independent or segregated from the channel, device or mobile application used for initiating the payment. This can be done, for example, via an independent channel to prevent any manipulation of the transaction details through the initiation process of the payment transaction
EBA current wording: RTS recital 4)
It is necessary to define the security features of the elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) for the application of strong customer authentication, as well as requirements ensuring that these elements are independent so that the breach of one does not compromise the reliability of the others, in particular when any of these elements is used through a multi-purpose device.
Suggested new wording:
It is necessary to define the security features of the elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) for the application of strong customer authentication, as well as requirements ensuring that these elements are independent so that the breach of one does not compromise the reliability of the others, in particular when any of these elements is used through a multi-purpose device. Various elements can be used to achieve independence: device, business processes, data, authentication and payment channel (out-of-band authentication).
Independently of the above question from the EBA, GSMA would like to summarise the most important points to get right in these RTS from the point of view of the mobile industry:
In order to prevent foreclosure of this market to the detriment of consumers and industry, the following considerations are absolutely critical for EBA to clearly set out in the final version of the RTS.
1) The possibility to outsource the authentication process: It is of great importance that EBA ensures the possibility of outsourcing the authentication service to e.g. MNOs as set out in Art. 12. We urge EBA to keep the current wording of art. 12 a). However, some subsections are impractical and need to be adjusted for the outsourcing provisions to work in practice: For example, the current text in Art. 13 (b) mandates the PSP to digitally sign the software used to authenticate a transaction. This is impractical in an outsourcing context in which it is likely to be the authentication provider who has to sign the authentication software.
2) Mandating LoA4 through the back door: GSMA believes that for payments conducted under the PSD2, LoA3 is sufficiently secure. In fact, the use of additional security features, such as mobile operator business processes and dynamic mobile network data, may be more effective in increasing overall security and fraud resistance than by the addition of PKI, because using secure encryption algorithm in LoA3 enhances the security to a greater level. While the industry is likely to evolve to digital signatures over time, mandating the use of digital signatures for the end to end process would default all transactions to LoA4 and its requisite infrastructure. Introducing this standardwill inevitably have a negative effect on customers in markets that deploy a SIM based solution (applet) without NFC SIMs. Also, LoA4 is not necessarily translating into best security because it focuses on technical components instead on overall security for the system. LoA4 is more about a non-repudiation use case through digital signature than a security improvement over LoA3. LoA3 with operator assets such as (business processes, always connected to the device through the SIM relationship and network data) can provide equal if not even higher security than LoA4. The difference between electronic signature, advanced electronic signature and qualified electronic signature are defined by eIDAS. It would be good to ensure consistency with the eIDAS definitions. In addition, advanced electronic signatures can be delivered with or without a PKI infrastructure, i.e. PKI is only one technology option. RTS should refrain from pushing one specific technology and from mandating the highest level of assurance. The best way forward here is to start similar to eIDAS regulation with a minimum requirement of LoA3 according to ISO 29115 and over time move to LoA4 using additional security features as the industry develops.
3) Independence of the authentication element.
Independence of authentication factors (possession, knowledge, inherence) should be complemented and protected with required independence of payment service security components and separated communication channels, to protect the integrity of the transaction and to avoid scalability of attacks.
a) Independence of service security components: within the mobile device there are separate and independent security domains (i.e. the device and the SIM) in addition to application software domains. At least two separate security domains should be used to achieve independence of service security components.
b) Independence of communication channels:the channels for payment service consumption and authentication should be separate (i.e. if payment is initiated over fixed or mobile data channel then authentication should happen over other separate communication channel (e.g. SMS))
c) Certification. The current draft RTS requirements on certification would be so heavy-wielded and costly that they would act as an entry barrier for new, innovative and more secure solutions. Mobile industry and secure authentication are both dynamic, fast developing domains. Within the mobile industry new phone models, SIMs, software and applications are continuously introduced. Secure authentication is advancing fast through innovations in authenticators (e.g. biometrics) and new data sources that improve security (e.g. device parameters and mobile network signals). Therefore, certification requirements, if mandatory, should be limited to high-level certification of solution architecture and security principles and not mandate certification of each new mobile phone model, SIM and software improvement combination. The risk of overextending certification requirement is an endless certification loop and prohibitive certification costs hindering progress and security improvements.
Any certification requirement in these RTS needs to be assessed with regard to:
• Are all market players benefiting from certification requirements or only incumbent industry?
• Are the certification requirements enabling the industry to respond to new fraud and security threats in a dynamic, rapid and efficient way?
Please contact us if you require information on certification in the context of mobile devices.
d) Privacy. Privacy of consumers is fundamental to achieving the objectives of these RTS and fundamental for earning the justified trust of consumers. In order to protect consumers’ privacy, the SCA solution should use proper mechanisms such as encryption and PCR (Pseudonymous Customer Reference). EBA should be more explicit and demanding in its RTS in relation to the principle of privacy .
Also for clarity, we often refer to Mobile Connect in our answers to EBA's question. Here is a short reminder of what Mobile Connect is.
Mobile Connect
What is it?
Mobile Connect is a global open standard supported by GSMA that enables consumers to authenticate themselves, authorise transactions and share their data via the mobile when accessing websites, payment accounts or when initiating payments.
How does it work?
The mobile phone is used as ‘something I have’, a PIN is used as ‘something I know’ . Security of the mobile device is ensured via the mobile network in a two-way communication and business process that disables transactions when the phone is lost/stolen, in case of SIM swaps or other unusual transactions that are flagged as potential fraud. Available security assurance levels are the same as with eIDAS regulation (LoA 2-4). The mobile phone is used as a mechanism through which the user can authenticate and claim a right to whatever service or transaction they are accessing or approving. This is similar to the TANs used in banking and issued to individual users to use as tokens to prove their right to access a service. As the phone is ubiquitous and always with the user, it can be used as a replacement for these TANs. The service is delivered to digital service providers as an industry standard API (Open ID Connect) that is rapidly becoming industry standard.
What are the benefits of Mobile Connect for Payment Service Users (PSUs) and Payment Service Providers (PSPs)?
- Convenience: the customer experience is simple and consistent. The consumer has one PIN that is used for one log-in to Mobile Connect. There is no need to remember/use further passwords or user names for other websites. Therefore there is no password to steal. Only having to deal with one password improves user experience and reduces friction for the consumer. No other hardware device is necessary, so the consumer has the comfort of using own device that is always available. During the log-in process Mobile Connect will interact with the device and generate a pop up and the user provides the PIN.
- Security: once the user has logged-in to Mobile Connect, only an anonymised token is shared with the service provider. The token represents that everything is ok. No token is shared if there is a problem. Each token is specific to a service provider, i.e. different service providers get a different token for the same user. This means that the service provider doesn’t know who the consumer is and service providers can’t track a customer based on a token. Mobile Connect works with the Open ID standard; i.e. all interactions are encrypted and the token is signed (inherent security).
- Privacy and complete user control: whilst service providers can authenticate users, they can only share data with the permission of users. The operator confirms credentials by sending the token to the service provider. The user is in control over his data as he gives consent (or not) to the service provider to share more attributes about him. Both operators and service providers agree on GSMA privacy principles (see Annex I) whereby no user data is shared without user permission.
- Global availability and interoperability: Mobile Connect is globally available to all consumers and service providers and therefore ensuring consistency, reach and interoperability. The same user experience will apply whatever the payment service provider. Mobile Connect works with all mobile network providers globally and on all devices worldwide independently of the operating system. Within the European Union alone, Mobile Connect is already supported by major mobile network groups such as Orange, Telefonica, Vodafone, TIM (Telecom Italia Mobile), Telenor and Telia Company to name a few .
Why is Mobile Connect relevant?
Mobile Connect is a mobile solution for authentication that is standardised, secure and globally available. It is extensible in that other data factors such as inherence (something the consumer is) can be added as necessary to enhance transaction authorisation.
In addition to this it is of utmost importance for the EBA to ensure that the PSP and the authentication provider can be two separate entities. Innovation of authentication services will thrive if they can be offered independently from the payment service provider. The RTS provisions have to allow for the outsourcing scenario and not prescribe details such as that the PSP has to sign the authentication software, which cannot be complied to in an outsourcing set-up.
Each payment service provider should have the opportunity to use the mobile device as a possession element as long as it is used in an appropriate manner that mitigates the inherent risks.
The RTS should work closer with the privacy principle. The user’s privacy information should only be transferred to parties who need to know this data. If possible the confidentiality of the user’s private information should protected by encrypting it so that only the intended recipient can decrypt the data. The payment processes that minimise sharing of user’s privacy information should be preferred. For example in art. 13 b) the PSP can collect lots of data. This could be a problem when considering that only essential data should be collected that is necessary to perform this activity.
Definition of TEE
EBA’s description in the context of the RTS is too specific, not technologically neutral and it excludes technologies that are perfectly fine, especially in the early phases of PSD2 implementation. Therefore, we suggest to clarify that TEE is referred to as a concept instead of a specific technology.
EBA current wording: Art. 6 (3)a
For the purposes of par. 2, the mitigating measures shall include, but not be limited to:
a) the implementation of separated trusted execution environments inside the multi-purpose device.
Suggested new wording:
For the purposes of par. 2, the mitigating measures shall include, but not be limited to:
a) the implementation of separated trusted execution environments inside the multi-purpose device.in a way that trust and security is maintained.
Certification
Certification requires careful consideration as it easily acts as an impediment to innovation. As such, any certification requirements need to be flexible and light-touch to achieve the objectives of the RTS. For example, in order for certification to be effective in ensuring high security and in avoiding systemic risks the RTS should require mandatory certification for architecture security and business processes only rather than certifying each technological part or independent technical elements. For mobile devices there are many elements and it takes a long time to certify. In cases where the user changes their device certification is not possible.
Also in the mobile context responding to security threats by certification is a very slow and impractical way. Once the mobile device is in in the hands of the user, it cannot be tested or evaluated by independent auditors. For this reason, certification canonly be conducted during the set-up process.
A good example of certification is ISO certification, which doesn’t focus on implementation.
GSMA believes that a responsive standard towards evolution of fraud is more effective than certification.
Even with certification requirements in place there is neither a shift in liability nor in the risk of tampering and unauthorised access. Therefore, new technical requirements should be reflected in guidelines. In an environment where all elements/components are already certified today GSMA believes that this could be a quicker and more effective response than certification. GSMA therefore does not see any need for certification to solve the problem of fraud.
Potential risk and challenges outweigh the benefits of certification
GSMA foresees significant challenges and risks in relation to certification:
• Risk of slowing down the development and adoption of new payment services solutions - Identity management and authentication solutions are undergoing very rapid development. The introduction of mandatory external certification of technical components or devices hosting payment solutions may lead to slower development and improvements in security. Depending on the solution, certification might not be the most efficient way of improving the security, especially if this leads to slow adoption of new, improved online payment solutions and authentication processes. Given the pace of development in the mobile sector there would be an inevitable backlog of certifications that would restrict the ability of users to start using latest technology as it becomes available.
• Risk of unreasonable costs – Certification processes are undertaken by specific test labs, which is both time consuming and costly. Hence the introduction of certification may be a barrier to entry to the market. This could lead to only specific solutions being available, which would risk customer acceptance and growth and put at risk the benefits of a single and efficient market for payment services. Furthermore, there is limited or no business purpose for the cost and effort in mandatory certification because the certification does not change the legal responsibilities or liabilities of the solution provider.
• Risk of increased complexity - There are a number of actors, components, integration points and systems involved (provided by different entities) in the architecture of the online payment service solution, hence the complexity of the certification would be much higher.
• Risk of distorting the balance of technology neutrality - Mandatory external certification might jeopardise technology neutrality, since well-established (old-fashioned) technologies are easier to certify than the new break-through technologies that require iterative improvements. This is especially relevant for modern mobile-based authentication solutions, which are challenging to certify, as any new development in hardware or software and/or new combination of them, would need to be re-certified. The world of online payment services develops rapidly, especially in the area of mobile use. There is a real danger of applying an old set of thinking to a new rapidly developing area. Making this mandatory without proper consultation is unlikely to produce a positive result for governments, businesses or citizens but creates unnecessary bureaucracy. The responsibilities and liabilities of the certifying authority would also have to be defined and acceptable to all member states.
EBA current wording: Recital 5)
… the strong customer authentication procedure should be periodically tested by certified auditors.
Suggested new wording:
… the strong customer authentication procedure should be periodically tested by certified auditors.
A risk management process should be established to mitigate risks of fraud and misuse of the strong customer authentication procedure. This process should be periodically checked by independent auditors.
Explicit certification should be replaced by guidelines. What should be periodically certified is the risk-management process, the authentication procedure and authentication architecture.
This way the negative and positive effects of certification can be optimised:
EBA current wording: Recital 7)
Given the constant evolution of online frauds, it is necessary that these measures are documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. Such review should be made available to competent authorities upon their request in order to allow them to ensure enforcement of these requirements.
Suggested new wording:
Given the constant evolution of online frauds, it is necessary that these risk management process measures are is documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. Such review should be made available to competent authorities upon their request in order to allow them to ensure enforcement of these requirements.
EBA current wording: Art. 7 (1):
The overall security of the strong customer authentication procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the relevant audit framework of the PSP.
GSMA suggests new wording:
The overall security of the strong customer authentication procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors in the phase of set-up of the authentication element in the device and the security element and the business processes must ensure that all the risks are mitigated when the devices are with the consumer. The periodicity of these audits shall be defined according to the relevant audit framework of the PSP.
In order for the authentication procedure to be outsourced, the PSP credential and authentication credential need to be separated out. The most efficient way of certification would be to certify the authentication procedure. To ensure this GSMA suggests following modification of art. 16 (1):
EBA current wording: Art. 16 (1)
The overall security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials as referred to in articles 9-15, shall be documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the applicable audit framework of the PSPs.
Suggested new wording:
The overall authentication procedure security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials as referred to in articles 9-15, shall be documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the applicable audit framework of the PSPs.
Independence is created by out-of-band authentication, whereby the consumption channel and the authentication channel are separate. The user uses the consumption channel (i.e. banking app) for the payment service. During the interaction of the user with the PSP, the PSP, the SIM applet or smart phone app is the authenticator and uses the authentication channel. Whilst this is on the same device, these are always separate channels on the same device. Any security attack would need to access both the authentication device and the payment channel at the same time (authentication and payment), which adds practical barriers to a security attack and makes it less scalable.
Dynamic linking is ensured by a very convenient and secure way for the consumer whereby the user is not actively involved: at the point of authentication of the consumer a secure signed token is passed to the PSP. The PSP validates the signature and then the PSC and amount of transaction. A different token is used for each transaction.
Difference between PSP and authentication provider
It is of great importance that EBA ensures the possibility of outsourcing the authentication process to e.g. MNOs as set out in art. 12.
Art. 12 a) is a very important article that ensures that authentication providers can offer their services, which ultimately remain under the responsibility of the PSP. GSMA urges the EBA to keep this article as is or in such a way that it remains absolutely clear that the PSP can outsource authentication activities to service providers whilst ensuring that the overall authentication procedure is secure. It is the PSPs responsibility to manage the association between authentication offered by service providers and the payment transaction.
However, for art. 12 to work in practice the possibility for outsourcing the authentication activity needs to be ensured also in subsequent articles such as 13 (b).
The current text in art. 13 (b) mandates the PSP to digitally sign the software used to authenticate a transaction. This is impractical in situations whereby the authentication activity is outsourced to a service provider, because the authentication provider needs to sign the authentication software. However, also mandating digital signatures if they are defined as PKI solutions would unnecessary restrict currently available authentication solutions such as the Mobile Connect authentication mechanism (using either applet or native client) whereby the authentication provider signs the authentication software.
If not corrected art. 13b) is at risk to create unnecessary limitations to use cases and innovation, because it blurs the line between the authentication provider and PSP in such a way that the requirement of this article won’t match with the reality of activities and responsibilities of the different players.
Based in this reasoning GSMA suggests following wording:
EBA current wording: Art. 13 a)
Effective and secure delivery mechanisms ensuring that the PSCs, authentication devices and software are delivered to the legitimate payment services user associated with the credentials, the authentication devices and the software provided by the PSP.
Suggested new wording:
PSP shall ensure effective and secure delivery mechanisms ensuring that the PSCs, authentication devices and software are delivered to the legitimate payment services user associated with the credentials, the authentication devices and the software provided by the PSP.
The provision of art. 13 b) is technically too specific and focuses on one specific technology, which precludes other equivalent solutions. EBA should only state the requirement in this article and leave it to the market how this requirement is achieved technologically. GSMA suggests following change in wording:
EBA current wording: Art. 13 b)
Mechanisms ensuring that the authentication software delivered to the payment services user via the internet has been digitally signed by the PSP.
Suggested new wording:
Mechanisms ensuring the integrity of that the authentication software delivered to the payment services user. via the internet has been digitally signed by the PSP.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
GSMA agrees to a certain extent with EBA’s requirements provided that the principles of technological-neutrality and proportionality are observed, which is not always obvious from the current RTS.Below are aspects that EBA can improve and correct in its final wording.
Definition of authentication code
The RTS currently describes ‘authentication code’ as either being an OTP or digital signature, which appears to restrict technological-neutrality, innovation and even currently available options because secure tokens are for example currently not considered in EBA’s description. This would exclude very good solutions because the requirements mention technologies instead of outcomes.
GSMA suggests therefore that the EBA requires authentication codes in such a way that it should be possible to use a range of solutions including OTP, digital signatures and secure tokens that can be signed by both the authentication provider and the PSP depending on the situation.
Within the context of ‘authentication code’, the EBA is also considering ‘keys stored in the authentication elements’. EBA instead should explicitly ensure more flexibility in the description of authentication codes and allow both public and private keys that can be stored in either an authentication system or a device.
EBA’s current approach would inadvertently block innovation and future industry developments. For example, the mobile operator solution uses keys that are not linked to the user and stored on the mobile device. This should be possible to avoid hindering a large area of innovation in the field of SCA.
Art. 1 section 2 of the RTS could also be clarified, because subsection (b) is a special case of (c) where the forging is based on the knowledge of “authentication codes generated for the same payer”.
Based on the above explanation, GSMA suggests following changes:
EBA current wording:
RTS Art. 1 (1) :
…the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time the payer, making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
RTS Art. 1 (2): The authentication code shall be characterised by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time, ensuring that:
a) No information on any of the elements of strong customer authentication categorised as knowledge, possession and inherence can be derived from the disclosure of the authentication code;
b) It is not possible to generate a new authentication code based on the knowledge of another authentication code generated for the same payer
c) The authentication code cannot be forged.
Suggested new wording:
RTS Art. 1 (1) :
…the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time the payer, making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
RTS Art. 1 (2): The authentication code shall be characterised by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time, ensuring that:
a) No information on any of the elements of strong customer authentication categorised as knowledge, possession and inherence can be derived from the disclosure of the authentication code;
b) It is not possible to generate a new authentication code based on the knowledge of another authentication code generated for the same payer
b)The authentication code cannot be forged
including but not limited to forging new authentication codes based on the knowledge of another authentication code generated for the same payer;”
c) Is independently verifiable
d) Generated based on payment security credentials and the amount of the transaction
Definition and use of digital signatures
The EBA mentions digital signatures without defining them. GSMA suggests to define signatures similarly as in eIDAS. It is of utmost importance that different types of signatures are allowed such as secure tokens provided by authentication providers with keys securely stored in the cloud or in authentication providers’ servers.
Mandating the PSP to digitally sign the software used to authenticate a transaction would be impractical in the case where the PSP outsources the authentication to a service provider. Furthermore, mandating the use of digital signatures for the end to end process would default all transactions to LoA4 and its requisite infrastructure. This may rule out customers in markets that deploy a SIM based solution (applet) without NFC SIMs.
EBA should refrain from mandating digital signatures at the highest possible assurance level (LoA4)
The requirement of a digital signature in the context of the RTS is too specific and also requiring highest technical security level possible – Level of Assurance 4 (LoA4). This is too restrictive and will restrict technologies unnecessarily without the benefit of necessarily creating more security for the authentication processes in its entirety. A more proportionate and technologically neutral requirement would be to allow for symmetric keys as well.
EBA should demand overall security of the strong customer authentication procedure and not determine limiting technological choices such as digital signatures.
Mobile Connect uses the standard Level of Assurance (LoA) definitions from ISO 29115 for authentication: a global standards-based approach to authentication security. LoA 3 is a high-security two-factor authentication solution and is comparable to European eIDAS directive defined security level “substantial”.
Within the Mobile Connect framework, LoA 3 service is typically achieved using a SIM applet with security credentials placed on the user’s mobile phone SIM secure element, together with strong encryption for messages to and from the SIM. GSMA believes that for payments conducted under the PSD2, LoA3 is sufficiently secure. Further, we consider that business processes and dynamic mobile network data solutions are more effective ways to increase security and fraud resistance than the addition of a secure encryption algorithm
Based on the above explanation, GSMA suggests following description of the authentication code:
Exact reference in the EBA consultation document par. 24 page 11 (GSMA addition in bold):
The authentication code can be either a single piece of data that is being input by the payer on the interface of the relevant PSP or can be generated from several pieces of data, such as one-time password that is being input by the payer on the interface of the relevant PSP, the amount, and the payee of the transaction. Alternatively, the authentication code can take the form of different types signatures, such as signatures provided by authentication providers, digital signatures of such data using keys stored in the authentication elements, in the cloud or in the authentication provider’s server.
EBA’s reasoning on the compatibility between public e-identity schemes under the e-IDAS regulation framework and the RTS may imply that only e-identity schemes using digital signatures (LoA4) comply with these RTS. This would be very limiting for the choice of technology whilst also not necessarily adding more security, because it focuses on technical components instead on overall security for the system.
Based on the above explanation, GSMA suggests following changes:
Exact reference in the EBA consultation document par. 34, page 12:
… the proposed draft RTS do not prevent the possibility to adopt strong customer authentication procedures based on the services of a public e-identity scheme under the e-IDAS regulation framework, as long as these public e-identity schemes comply with the draft RTS.
Suggested new wording:
… the proposed draft RTS do not prevent the possibility to adopt strong customer authentication procedures based on the services of a public e-identity scheme under the e-IDAS regulation framework, as long as these public e-identity schemes comply with the draft RTS.
Independence: differentiated view of the mobile device is necessary
For mobile payments, the same level of independence, with beneficial impact on security as requested in the EBA text, can be achieved also by ensuring that the consumption and the authentication channel are two independent channels:
During the authentication process independence is created by out-of-band authentication, whereby the consumption channel and the authentication channel are separate. The user uses the consumption channel (i.e. banking app) for the payment service. During the interaction of the user with the PSP, the SIM applet or smart phone app is the authenticator and uses the authentication channel. Whilst this is on the same device, these are always separate channels.
This should be clearly stated in the EBA text.
GSMA would also like to repeat the differentiated view of the mobile device already presented in the previous consultation on EBA’s discussion paper, because it is crucial for understanding independence. See below.
Differentiated view of the mobile device
The mobile phone is a combination of following elements: 1) mobile device + 2) mobile business processes + 3) mobile network. They all function independently and the device can be reached even if the consumer has lost the device. With all three of these elements being linked in the mobile phone and actively used, the mobile phone is very secure possession element for payment service users:
1) The mobile device
The mobile device is controlled by the consumer whereas SIM security and SIM business processes are always owned by the operator. The element that disappears when a phone is lost/stolen is the device itself. The consumer loses the ability to use the device. Even when the device has been lost or stolen, the MNO will be able to access the device / SIM whenever it is active and attached to the network and therefore usable for Mobile Connect authentication purposes (if the SIM is inactive or not attached it won’t be usable for Mobile Connect authentication purposes.)
On a more detailed level – the mobile device can also be used as three subsets of possession elements.
2) The business process
This business process is the mobile operator’s ability to interact with the handset, i.e. communicate with the SIM and disable it. Business processes still function and have access to the lost/stolen device and can disable the use of the device after it has been reported lost/stolen. These interactions between device and network ensure security, because risk situations can be dealt with appropriately. The loss of a mobile phone is usually much more quickly noticed by the consumer than the loss of a wallet. And the consumer has an immediate interest to contact the operator to lock the use of the mobile phone and Mobile Connect remotely over the air with the SIM provisioning process. Not only can the device be disabled, but also additional knowledge such as the location of the device is available independently of the device and customer. The operator can also restore the payment capability remotely, if and when appropriate.
3) The mobile network
The mobile network is interlinking the following elements: mobile phone, SIM and the phone number (MSISDN). This association is stored very securely in the mobile network, which is not penetrable from the outside. This means that whenever a mobile device attaches to a network (i.e. consumer switches phone on), the network is aware of the interlinking of phone + SIM + phone number. If the device is suddenly used with a different SIM, the network knows immediately that this is a new association and can take immediate action, if this is interpreted as fraud (i.e. block the Mobile Connect account, mark the phone as stolen, etc.). If a phone is marked as stolen by one mobile operator, this is known to mobile operators around the world. The mobile industry has a tried and tested processes for this.
Furthermore, the fundamental independence between the mobile device (something the consumer has) and the PIN (something the consumer knows) remains intact even when the mobile device is lost or stolen.
For example with Mobile Connect, the phone with the hardware secure element notices when the SIM has been exchanged. If necessary, the phone can be disabled over the air independently of the SIM.
Based on above explanations GSMA suggests following changes to the EBA’s reasoning and wording of the RTS:
Exact EBA reference in consultation document par. 26, page 11 (GSMA addition in bold):
To that end, the channel, device or mobile application where the information about the amount and the payee of the transaction is displayed should be independent or segregated from the channel, device or mobile application used for initiating the payment. This can be done, for example, via an independent channel to prevent any manipulation of the transaction details through the initiation process of the payment transaction
EBA current wording: RTS recital 4)
It is necessary to define the security features of the elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) for the application of strong customer authentication, as well as requirements ensuring that these elements are independent so that the breach of one does not compromise the reliability of the others, in particular when any of these elements is used through a multi-purpose device.
Suggested new wording:
It is necessary to define the security features of the elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) for the application of strong customer authentication, as well as requirements ensuring that these elements are independent so that the breach of one does not compromise the reliability of the others, in particular when any of these elements is used through a multi-purpose device. Various elements can be used to achieve independence: device, business processes, data, authentication and payment channel (out-of-band authentication).
Independently of the above question from the EBA, GSMA would like to summarise the most important points to get right in these RTS from the point of view of the mobile industry:
In order to prevent foreclosure of this market to the detriment of consumers and industry, the following considerations are absolutely critical for EBA to clearly set out in the final version of the RTS.
1) The possibility to outsource the authentication process: It is of great importance that EBA ensures the possibility of outsourcing the authentication service to e.g. MNOs as set out in Art. 12. We urge EBA to keep the current wording of art. 12 a). However, some subsections are impractical and need to be adjusted for the outsourcing provisions to work in practice: For example, the current text in Art. 13 (b) mandates the PSP to digitally sign the software used to authenticate a transaction. This is impractical in an outsourcing context in which it is likely to be the authentication provider who has to sign the authentication software.
2) Mandating LoA4 through the back door: GSMA believes that for payments conducted under the PSD2, LoA3 is sufficiently secure. In fact, the use of additional security features, such as mobile operator business processes and dynamic mobile network data, may be more effective in increasing overall security and fraud resistance than by the addition of PKI, because using secure encryption algorithm in LoA3 enhances the security to a greater level. While the industry is likely to evolve to digital signatures over time, mandating the use of digital signatures for the end to end process would default all transactions to LoA4 and its requisite infrastructure. Introducing this standardwill inevitably have a negative effect on customers in markets that deploy a SIM based solution (applet) without NFC SIMs. Also, LoA4 is not necessarily translating into best security because it focuses on technical components instead on overall security for the system. LoA4 is more about a non-repudiation use case through digital signature than a security improvement over LoA3. LoA3 with operator assets such as (business processes, always connected to the device through the SIM relationship and network data) can provide equal if not even higher security than LoA4. The difference between electronic signature, advanced electronic signature and qualified electronic signature are defined by eIDAS. It would be good to ensure consistency with the eIDAS definitions. In addition, advanced electronic signatures can be delivered with or without a PKI infrastructure, i.e. PKI is only one technology option. RTS should refrain from pushing one specific technology and from mandating the highest level of assurance. The best way forward here is to start similar to eIDAS regulation with a minimum requirement of LoA3 according to ISO 29115 and over time move to LoA4 using additional security features as the industry develops.
3) Independence of the authentication element.
Independence of authentication factors (possession, knowledge, inherence) should be complemented and protected with required independence of payment service security components and separated communication channels, to protect the integrity of the transaction and to avoid scalability of attacks.
a) Independence of service security components: within the mobile device there are separate and independent security domains (i.e. the device and the SIM) in addition to application software domains. At least two separate security domains should be used to achieve independence of service security components.
b) Independence of communication channels:the channels for payment service consumption and authentication should be separate (i.e. if payment is initiated over fixed or mobile data channel then authentication should happen over other separate communication channel (e.g. SMS))
c) Certification. The current draft RTS requirements on certification would be so heavy-wielded and costly that they would act as an entry barrier for new, innovative and more secure solutions. Mobile industry and secure authentication are both dynamic, fast developing domains. Within the mobile industry new phone models, SIMs, software and applications are continuously introduced. Secure authentication is advancing fast through innovations in authenticators (e.g. biometrics) and new data sources that improve security (e.g. device parameters and mobile network signals). Therefore, certification requirements, if mandatory, should be limited to high-level certification of solution architecture and security principles and not mandate certification of each new mobile phone model, SIM and software improvement combination. The risk of overextending certification requirement is an endless certification loop and prohibitive certification costs hindering progress and security improvements.
Any certification requirement in these RTS needs to be assessed with regard to:
• Are all market players benefiting from certification requirements or only incumbent industry?
• Are the certification requirements enabling the industry to respond to new fraud and security threats in a dynamic, rapid and efficient way?
Please contact us if you require information on certification in the context of mobile devices.
d) Privacy. Privacy of consumers is fundamental to achieving the objectives of these RTS and fundamental for earning the justified trust of consumers. In order to protect consumers’ privacy, the SCA solution should use proper mechanisms such as encryption and PCR (Pseudonymous Customer Reference). EBA should be more explicit and demanding in its RTS in relation to the principle of privacy .
Also for clarity, we often refer to Mobile Connect in our answers to EBA's question. Here is a short reminder of what Mobile Connect is.
Mobile Connect
What is it?
Mobile Connect is a global open standard supported by GSMA that enables consumers to authenticate themselves, authorise transactions and share their data via the mobile when accessing websites, payment accounts or when initiating payments.
How does it work?
The mobile phone is used as ‘something I have’, a PIN is used as ‘something I know’ . Security of the mobile device is ensured via the mobile network in a two-way communication and business process that disables transactions when the phone is lost/stolen, in case of SIM swaps or other unusual transactions that are flagged as potential fraud. Available security assurance levels are the same as with eIDAS regulation (LoA 2-4). The mobile phone is used as a mechanism through which the user can authenticate and claim a right to whatever service or transaction they are accessing or approving. This is similar to the TANs used in banking and issued to individual users to use as tokens to prove their right to access a service. As the phone is ubiquitous and always with the user, it can be used as a replacement for these TANs. The service is delivered to digital service providers as an industry standard API (Open ID Connect) that is rapidly becoming industry standard.
What are the benefits of Mobile Connect for Payment Service Users (PSUs) and Payment Service Providers (PSPs)?
- Convenience: the customer experience is simple and consistent. The consumer has one PIN that is used for one log-in to Mobile Connect. There is no need to remember/use further passwords or user names for other websites. Therefore there is no password to steal. Only having to deal with one password improves user experience and reduces friction for the consumer. No other hardware device is necessary, so the consumer has the comfort of using own device that is always available. During the log-in process Mobile Connect will interact with the device and generate a pop up and the user provides the PIN.
- Security: once the user has logged-in to Mobile Connect, only an anonymised token is shared with the service provider. The token represents that everything is ok. No token is shared if there is a problem. Each token is specific to a service provider, i.e. different service providers get a different token for the same user. This means that the service provider doesn’t know who the consumer is and service providers can’t track a customer based on a token. Mobile Connect works with the Open ID standard; i.e. all interactions are encrypted and the token is signed (inherent security).
- Privacy and complete user control: whilst service providers can authenticate users, they can only share data with the permission of users. The operator confirms credentials by sending the token to the service provider. The user is in control over his data as he gives consent (or not) to the service provider to share more attributes about him. Both operators and service providers agree on GSMA privacy principles (see Annex I) whereby no user data is shared without user permission.
- Global availability and interoperability: Mobile Connect is globally available to all consumers and service providers and therefore ensuring consistency, reach and interoperability. The same user experience will apply whatever the payment service provider. Mobile Connect works with all mobile network providers globally and on all devices worldwide independently of the operating system. Within the European Union alone, Mobile Connect is already supported by major mobile network groups such as Orange, Telefonica, Vodafone, TIM (Telecom Italia Mobile), Telenor and Telia Company to name a few .
Why is Mobile Connect relevant?
Mobile Connect is a mobile solution for authentication that is standardised, secure and globally available. It is extensible in that other data factors such as inherence (something the consumer is) can be added as necessary to enhance transaction authorisation.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
As explained under Q 1, a differentiated view of the mobile phone as a possession element is necessary.In addition to this it is of utmost importance for the EBA to ensure that the PSP and the authentication provider can be two separate entities. Innovation of authentication services will thrive if they can be offered independently from the payment service provider. The RTS provisions have to allow for the outsourcing scenario and not prescribe details such as that the PSP has to sign the authentication software, which cannot be complied to in an outsourcing set-up.
Each payment service provider should have the opportunity to use the mobile device as a possession element as long as it is used in an appropriate manner that mitigates the inherent risks.
The RTS should work closer with the privacy principle. The user’s privacy information should only be transferred to parties who need to know this data. If possible the confidentiality of the user’s private information should protected by encrypting it so that only the intended recipient can decrypt the data. The payment processes that minimise sharing of user’s privacy information should be preferred. For example in art. 13 b) the PSP can collect lots of data. This could be a problem when considering that only essential data should be collected that is necessary to perform this activity.
Definition of TEE
EBA’s description in the context of the RTS is too specific, not technologically neutral and it excludes technologies that are perfectly fine, especially in the early phases of PSD2 implementation. Therefore, we suggest to clarify that TEE is referred to as a concept instead of a specific technology.
EBA current wording: Art. 6 (3)a
For the purposes of par. 2, the mitigating measures shall include, but not be limited to:
a) the implementation of separated trusted execution environments inside the multi-purpose device.
Suggested new wording:
For the purposes of par. 2, the mitigating measures shall include, but not be limited to:
a) the implementation of separated trusted execution environments inside the multi-purpose device.in a way that trust and security is maintained.
Certification
Certification requires careful consideration as it easily acts as an impediment to innovation. As such, any certification requirements need to be flexible and light-touch to achieve the objectives of the RTS. For example, in order for certification to be effective in ensuring high security and in avoiding systemic risks the RTS should require mandatory certification for architecture security and business processes only rather than certifying each technological part or independent technical elements. For mobile devices there are many elements and it takes a long time to certify. In cases where the user changes their device certification is not possible.
Also in the mobile context responding to security threats by certification is a very slow and impractical way. Once the mobile device is in in the hands of the user, it cannot be tested or evaluated by independent auditors. For this reason, certification canonly be conducted during the set-up process.
A good example of certification is ISO certification, which doesn’t focus on implementation.
GSMA believes that a responsive standard towards evolution of fraud is more effective than certification.
Even with certification requirements in place there is neither a shift in liability nor in the risk of tampering and unauthorised access. Therefore, new technical requirements should be reflected in guidelines. In an environment where all elements/components are already certified today GSMA believes that this could be a quicker and more effective response than certification. GSMA therefore does not see any need for certification to solve the problem of fraud.
Potential risk and challenges outweigh the benefits of certification
GSMA foresees significant challenges and risks in relation to certification:
• Risk of slowing down the development and adoption of new payment services solutions - Identity management and authentication solutions are undergoing very rapid development. The introduction of mandatory external certification of technical components or devices hosting payment solutions may lead to slower development and improvements in security. Depending on the solution, certification might not be the most efficient way of improving the security, especially if this leads to slow adoption of new, improved online payment solutions and authentication processes. Given the pace of development in the mobile sector there would be an inevitable backlog of certifications that would restrict the ability of users to start using latest technology as it becomes available.
• Risk of unreasonable costs – Certification processes are undertaken by specific test labs, which is both time consuming and costly. Hence the introduction of certification may be a barrier to entry to the market. This could lead to only specific solutions being available, which would risk customer acceptance and growth and put at risk the benefits of a single and efficient market for payment services. Furthermore, there is limited or no business purpose for the cost and effort in mandatory certification because the certification does not change the legal responsibilities or liabilities of the solution provider.
• Risk of increased complexity - There are a number of actors, components, integration points and systems involved (provided by different entities) in the architecture of the online payment service solution, hence the complexity of the certification would be much higher.
• Risk of distorting the balance of technology neutrality - Mandatory external certification might jeopardise technology neutrality, since well-established (old-fashioned) technologies are easier to certify than the new break-through technologies that require iterative improvements. This is especially relevant for modern mobile-based authentication solutions, which are challenging to certify, as any new development in hardware or software and/or new combination of them, would need to be re-certified. The world of online payment services develops rapidly, especially in the area of mobile use. There is a real danger of applying an old set of thinking to a new rapidly developing area. Making this mandatory without proper consultation is unlikely to produce a positive result for governments, businesses or citizens but creates unnecessary bureaucracy. The responsibilities and liabilities of the certifying authority would also have to be defined and acceptable to all member states.
EBA current wording: Recital 5)
… the strong customer authentication procedure should be periodically tested by certified auditors.
Suggested new wording:
… the strong customer authentication procedure should be periodically tested by certified auditors.
A risk management process should be established to mitigate risks of fraud and misuse of the strong customer authentication procedure. This process should be periodically checked by independent auditors.
Explicit certification should be replaced by guidelines. What should be periodically certified is the risk-management process, the authentication procedure and authentication architecture.
This way the negative and positive effects of certification can be optimised:
EBA current wording: Recital 7)
Given the constant evolution of online frauds, it is necessary that these measures are documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. Such review should be made available to competent authorities upon their request in order to allow them to ensure enforcement of these requirements.
Suggested new wording:
Given the constant evolution of online frauds, it is necessary that these risk management process measures are is documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. Such review should be made available to competent authorities upon their request in order to allow them to ensure enforcement of these requirements.
EBA current wording: Art. 7 (1):
The overall security of the strong customer authentication procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the relevant audit framework of the PSP.
GSMA suggests new wording:
The overall security of the strong customer authentication procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors in the phase of set-up of the authentication element in the device and the security element and the business processes must ensure that all the risks are mitigated when the devices are with the consumer. The periodicity of these audits shall be defined according to the relevant audit framework of the PSP.
In order for the authentication procedure to be outsourced, the PSP credential and authentication credential need to be separated out. The most efficient way of certification would be to certify the authentication procedure. To ensure this GSMA suggests following modification of art. 16 (1):
EBA current wording: Art. 16 (1)
The overall security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials as referred to in articles 9-15, shall be documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the applicable audit framework of the PSPs.
Suggested new wording:
The overall authentication procedure security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials as referred to in articles 9-15, shall be documented, periodically tested, evaluated and audited by internal or external independent and certified auditors. The periodicity of these audits shall be defined according to the applicable audit framework of the PSPs.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
GSMA would like to point out that the exemptions defined in the PSD2 and the exemptions suggested by the EBA are asymmetric in treating the mobile phone and credit cards differently. This doesn’t make sense, in particular considering the situation where a contactless credit card payment is made with the mobile device. Therefore, GSMA would suggest to keep the 50Euro threshold of the exemption determined in the PSD2 also for the RTS.Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
The mobile industry’s solution called Mobile Connect allows users to use their mobile phone for easy and secure customer authentication when accessing payment accounts, initiating and authorising payments via the mobile device.Independence is created by out-of-band authentication, whereby the consumption channel and the authentication channel are separate. The user uses the consumption channel (i.e. banking app) for the payment service. During the interaction of the user with the PSP, the PSP, the SIM applet or smart phone app is the authenticator and uses the authentication channel. Whilst this is on the same device, these are always separate channels on the same device. Any security attack would need to access both the authentication device and the payment channel at the same time (authentication and payment), which adds practical barriers to a security attack and makes it less scalable.
Dynamic linking is ensured by a very convenient and secure way for the consumer whereby the user is not actively involved: at the point of authentication of the consumer a secure signed token is passed to the PSP. The PSP validates the signature and then the PSC and amount of transaction. A different token is used for each transaction.
Difference between PSP and authentication provider
It is of great importance that EBA ensures the possibility of outsourcing the authentication process to e.g. MNOs as set out in art. 12.
Art. 12 a) is a very important article that ensures that authentication providers can offer their services, which ultimately remain under the responsibility of the PSP. GSMA urges the EBA to keep this article as is or in such a way that it remains absolutely clear that the PSP can outsource authentication activities to service providers whilst ensuring that the overall authentication procedure is secure. It is the PSPs responsibility to manage the association between authentication offered by service providers and the payment transaction.
However, for art. 12 to work in practice the possibility for outsourcing the authentication activity needs to be ensured also in subsequent articles such as 13 (b).
The current text in art. 13 (b) mandates the PSP to digitally sign the software used to authenticate a transaction. This is impractical in situations whereby the authentication activity is outsourced to a service provider, because the authentication provider needs to sign the authentication software. However, also mandating digital signatures if they are defined as PKI solutions would unnecessary restrict currently available authentication solutions such as the Mobile Connect authentication mechanism (using either applet or native client) whereby the authentication provider signs the authentication software.
If not corrected art. 13b) is at risk to create unnecessary limitations to use cases and innovation, because it blurs the line between the authentication provider and PSP in such a way that the requirement of this article won’t match with the reality of activities and responsibilities of the different players.
Based in this reasoning GSMA suggests following wording:
EBA current wording: Art. 13 a)
Effective and secure delivery mechanisms ensuring that the PSCs, authentication devices and software are delivered to the legitimate payment services user associated with the credentials, the authentication devices and the software provided by the PSP.
Suggested new wording:
PSP shall ensure effective and secure delivery mechanisms ensuring that the PSCs, authentication devices and software are delivered to the legitimate payment services user associated with the credentials, the authentication devices and the software provided by the PSP.
The provision of art. 13 b) is technically too specific and focuses on one specific technology, which precludes other equivalent solutions. EBA should only state the requirement in this article and leave it to the market how this requirement is achieved technologically. GSMA suggests following change in wording:
EBA current wording: Art. 13 b)
Mechanisms ensuring that the authentication software delivered to the payment services user via the internet has been digitally signed by the PSP.
Suggested new wording:
Mechanisms ensuring the integrity of that the authentication software delivered to the payment services user. via the internet has been digitally signed by the PSP.