Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Finally there are also other kinds of banking services that can indirectly trigger payments and therefore, payment frauds. For example, contracts (e.g. saving contracts), that could be electronically signed by customers, can trigger money transfers and potentially fraud or theft.
In the coming years, end users’ preferred devices may not just be smartphones and could come from a large selection of connected objects, such as watches, glasses, cars, household appliances, etc. Existing dynamic authentication means such as hardware token or application on cards will also stay popular in many countries.
Today, the smartphone is the physical component that will probably be the preferred device for most end-users.
Smartphones provide a unique combination of benefits for both end-users and banks.
• A large deployment within customer bases
• A rich user experience, which may help to improve the information displayed and explained to customers
• A high security implementation using either Software Secure Element (SSE) or Hardware Secure Element (HSE). These components allow to securely generate and store sensitive data in a smartphone for strong customer authentication.
• An upgradable solution based on downloaded authentication software.
• A solution that may integrate a large range of authentication methods (knowledge and inherence methods)
• A solution that may integrate additional devices based on alternate communication channels like NFC or BLE (e.g. NFC keys or smart cards, passports, connected watches, etc.)
• Convenient and easy to understand user experience (e.g. voice recognition)
• Capacity to run in background for a transparent and continuous risk assessment and eventually authentication. This means that, for example, a mobile device could automatically detect the end-user’s behavior through, the way he walks, the way he types, or the places he stays.
We also consider that:
• When there is a limited risk on the transaction, the behavioral features can bring comfort for the user, bringing an additional risk assessment and ultimately avoiding having to ask the user for a knowledge factor.
• When the risk is medium or high, behavioral features can be used as a scoring element to mitigate other authentication means requirements.
• When the privacy dimension is respected, these methods can be considered (see answer to question 10)
Common criteria are being developed in Europe regarding biometrics and this work should be taken in consideration for the evaluation of biometrics authentication factors.
https://www.beat-eu.org/
The NIST is investigating the calculation of a score to assess biometrics authentication strength. http://www.nist.gov/nstic/NSTIC-strength-authentication-discussion-draft.pdf
A strong customer authentication implementation should address all customers with minimum limitation for online services.
TPP must provide alternative solutions with the same level of assurance and must be allowed to invoice according its cost model.
How the link is built
• As described in PSD2: what information is linked?
• How to create and secure the link?
• How to store the link?
How the link is used
• In which cases it is required to control the link?
• How to check whether the link is valid or broken?
• For how long this link could be checked?
• Who could have access to that link?
The specifications must not describe technical solutions but functional solutions, optionally with associated security levels.
• A graphical user interface in order to display authentication context (e.g. amount, date, merchant, payment means ….)
Support for a second authentication factor, such as a GUI to type a pin code and biometric sensors (fingerprint, camera, accelerometer …..).
• Cryptographic resources in order to securely exchange with an authentication platform
• Cryptographic resources in order to create a unique and non-reusable link between authentication and transaction
• Hardware or software secure elements to support cryptographic features and give devices the possession characteristic (actually the mobile must be specifically personalized for a given end-user)
• Tamper resistance for sensitive information in the mobile device.
HCE requirements specified by international schemes also address this kind of requirement.
The EBA should clarify if closed-loop payments are exempted, and give its definition of closed-loop.
The EBA should clarify which stakeholder is responsible for decision and application of exemptions: customer’s Bank, merchant, merchant’s bank, regulator, Scheme? For instance, the EBA should clarify what happens when merchants and issuers have different understandings of the exemptions, or transaction risk scoring.
The EBA should also clarify each player’s liabilities in case of frauds caused by exemptions for transactions that require strong authentication and for transactions that does not require strong authentication.
Smartphone using geolocation data can be used and the web browser geolocation API also.
Taking into account that the PSD2 states that PSPs must follow EU regulations on personal data, as stated in recital (94), that The EBA states, in Issue 51.A, that the question arises as to how to ensure the privacy of PSU data, and that The EU Global Data Protection Regulation will have over seeded the current EU regulation by the time the PSD2 comes into application, we underline the following points:
First, the RTS should make the distinction between the rights of the data subject (PSU in our case) and the data security. Vague terms such as ‘privacy of data’ should be avoided.
Second, privacy is more than data protection. The recently adopted European General Data Protection Regulation goes beyond data protection as a security measure and aim to promote the rights of data subjects. We believe that all authentication methods and fraud detection algorithms must be implemented in a manner which is fully supportive of the new regulation (data minimization, privacy by default, privacy by design). Hence, the RTS should guarantee customer control and transparency over the data and algorithms implemented.
Third, biometrics data processing should be done with additional considerations. All “inherence” elements (physiological and behavior) manipulate biometric data and are therefore considered sensitive personal data in the European General Data Protection Regulation. These will require specific assessment – Data Protection Impact Assessment. Therefore, the implementation of biometrics should be done under the strictest principles of balance of interest, with full user control and consent. Also, match on device should be the preferred method for biometrics authentication
So tamper resistance is one of the most important features to protect PSU.
Assurance level should be level 2 or 3
A complementary process could be an observation period in order to assess the level of security of a TPP. This period could be based on a duration or number of processed transactions without incidents.
The PSP must also be able to check easily (automatically) that the agreements are valid and are related to the requested services (TPP directory).
We believe that Account Numbers should be protected to limit attacks (phishing and identity thefts, for example). Therefore, storage of plain account number in various databases managed by PISP and AISP could create security risks. We suggest developing as much as possible possibility usage of token (such as encrypted account number).
A parallel can be drawn with the card industry which has introduced usage of tokens to manage in a secure manner specific cases such as mobile payment.
For point b, the TPP will have to self-identify. In this context, identification could be done with a license number given by local regulators or by the EBA through the general directory it will manage. Such license number could be the LEI or any other identifying number.
For point c, payees, in the PSD2 text, are included in the loop and not only the PIS/AIS/ASPSP are concerned by the common and open standards for communication.
For point d, there is a need for information concerning payment history, for audit tracking for instance. About account information communicated by ASPSPs, it would be important to indicate which data is mandatory or optional and which is sensitive and not in view of the future regulation of personal data protection. Indeed in the PSD2, we can read that IBANs and names are not sensitive.
For point f, the text is too restrictive in trying to define the ASPSP interface. Indeed, the ASPSP can use a distinct provider to avoid any internal IT development and a protocol converter for any communications with new PIS/AIS.
The timing for future implementation of API by ASPSP will be short; in consequence, a minimum set of practices commonly approved by the banking industry should be integrated.
Besides, the PSD2 mentions accounts which are accessible online; but online could be in cloud or through a connected object. Innovation can promote other protocols in the following years.
The usage of the OAuth 2.0 protocol and its authentication counterpart OpenId Connect is spreading on smartphone devices. Both protocols have an application scope which seems suitable to the context; they are designed as internet scale protocols and enable federated identity. Still, they have to be reviewed to investigate whether a specific profile needs to be created to accommodate the security context of the PSD2.
The PSP could be identified through a number of identification supplied by each local regulator and centralized by the EBA in its directory listing all the PIS and AIS. Nevertheless, services 7&8, identified in annex I of the PSD2, can be proposed by any others categories of PSP listed in article I (1). So identification is not only a PIS/AIS concern; the EBA register should also be available both per services and per categories of PSP.
Another protocol could be 3Skey (public and private) to encourage identification of stakeholders with protection of privacy.
Besides, if level of authentication are different for AIS and PIS, separate authentication should be done at connection (to access accounts) and then for payment initiation (to do a credit transfer between accounts).
In July 2014, the European Parliament and the EU Council passed the Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market" (eIDAS regulation) that repeals the Directive 1999/93/EC (Signature Directive).
The purpose of the eIDAS regulation is to constitute a basis for building trust in the European online environment.
This regulation covers different aspects of electronic transactions, such as:
• Electronic identification,
• Trust services,
• And electronic documents.
The e-IDAS Regulation seeks to enhance trust in electronic transactions in the internal market, by facilitating the cross-border use of online services, with particular attention to facilitating secure electronic identification and authentication since many online services require electronic identification, authentication and signature
Identification and Authentication following e-IDAS and PSD2
The e-IDAS Regulation underlines the difference between ‘Electronic identification’, which means “the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person” and Authentication, which means “an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed”;
It is important to note that identification is always before authentication. Authentication presupposes making a link between the identification data, which is already known to the provider, and the data that is used by the person to authenticate. The e-IDAS Regulation knows this link.
But if we analyze the PSD2, we can see that it has not used the word “Identification”, but includes two definitions for Authentication:
- 'Authentication', "a procedure which allows the payment service provider to verify the identity of a user of a specific payment instrument, including the use of its personalized security features or control of documents personal identity;
- "Strong client authentication": "a validation procedure for the identification of a person or entity based on the use of two or more elements belonging to the categories knowledge, possession and inherently which are independent in the sense that the compromise of one does not question the reliability of others, and is designed to protect the confidentiality of authentication data. "
The same word is used in the PSD2 with two different meanings.
If we compare the e-IDAS and the PSD 2, and if we do not consider the different words which are used, but only the needs, we can see that there is a need to verify an identity (Identification for the e-IDAS and Authentication for the PSD2) before being able to make Authentication, for the e-IDAS, and Strong Authentication, for the PSD2.
The e-IDAS Regulation defines meanwhile Identification levels and also Authentication levels.
The PSD2 regulation defines levels of Authentication (single and strong); this is not consistent either, since it is not the same operation.
However, in some cases, it will directly be an identification operation, not an authentication, to the extent that the provider does not know the person in advance.
It would be extremely unfortunate that this inconsistency remains because it is a source of legal ambiguity between the two regulations.
The e-IDAS regulation has a possible solution for facilitating strong customer authentication, protecting the confidentiality and the integrity of the users’ personalized security credentials.
Different Levels of confidence, different security levels
The e-IDAS Regulation describes different levels which permit to characterize the degree of confidence in electronic identification means in establishing the identity of a person, thus providing assurance that the person claiming a particular identity is in fact the person to which that identity was assigned.
The assurance level depends on the degree of confidence that the electronic identification means provide in claimed or asserted identity of a person taking into account processes (for example, identity proofing and verification, and authentication), management activities (for example, the entity issuing electronic identification means and the procedure to issue such means) and technical controls implemented.
Considering Authentication, the e-IDAS executive rule focuses on the threats associated with the use of the authentication mechanism and lists the requirements for each level of guarantee.
The controls are supposed to be proportionate to the risks at the given level.
For the Authentication Mechanism, below is a table which defines the requirements for each security level.
Low Authentication for the e-IDAS :
1. The diffusion of personal identification data is preceded by the reliable electronic verification of identification and its validity.
2. When personal identification data is stored in the authentication mechanism, the information is secured to ensure its protection against loss or compromise, including offline analysis.
3. The authentication mechanism implements security controls for the verification of the electronic identification means, so that it is highly unlikely that activities such as decryption attempts, listening, replay attack or communication manipulation by an attacker with a potential base attack may harm the enhanced authentication mechanisms.
Substantial Authentication: low/ substantial
1. The dissemination of personal identification data is preceded by the reliable verification of the electronic identification means and validity by a dynamic authentication.
2. The authentication mechanism implements security controls for verification of the electronic identification means, so it is highly unlikely that activities such as decryption attempts, listening, attack replay or manipulation of a communication by an attacker with a moderate attack potential could harm the authentication mechanisms .
High level, low/high:
The authentication mechanism is implementing security controls for verification of the electronic identification means, so it is highly unlikely that activities such as decryption attempts, listening, replay attack or manipulation a communication by an attacker with a high attack potential could harm the authentication mechanisms ."
The e-IDAS token specification, which is a contribution from the German and French IT security agencies BSI and ANSSI and is supported by European industry partners, allows the development of token-based and customized solutions for electronic identification, authentication and signatures that are directly interoperable, without the need of translation via proxies.
This specification provides a modular and homogeneous secured element API to protect the following functions:
• Authenticity,
• Integrity,
• Originality,
• Confidentiality and
• Privacy of the data stored on tokens for electronic identification, authentication and signatures (the eIDAS token).
Examples are the German ID card or the German Residence Permit.
The e-IDAS token specification covers all existing eService use cases, and opens the door to new applications. The technology is based on a direct mutual authentication between the eIDAS token and the service provider, and facilitates real end-to-end encryption. The approach is to build on the technology of machine readable travel documents and the corresponding infrastructures that are already in use in the European member states and includes enhancements and extended services.
There is a technical guideline which specifies the following protocols to protect personal data stored on electronic documents.
We can say that various technical definitions and descriptions of assurance levels exist, such as STORK and ISO 29115, which should be taken into account in establishing minimum technical requirements, standards and procedures for the low, substantial and high assurance levels within the meaning of this Regulation, while ensuring consistent application of this Regulation in particular with regards to assurance level high related to identity proofing for issuing qualified certificates.
The requirements established should be technology-neutral. It should be possible to achieve the necessary security requirements through different technologies.
Member States should encourage the private sector to voluntarily use electronic identification means under a notified scheme for identification purposes when needed for online services or electronic transactions. The possibility to use such electronic identification means would enable the private sector to rely on electronic identification and authentication already largely used in many Member States, at least for public services, and to make it easier for businesses, in order to facilitate the use of such electronic identification means across borders by the private sector. Additionally, the authentication possibility provided by any Member State should be available to private sector relying parties established outside of the territory of that Member State under the same conditions as applied to private sector relying parties established within that Member State. Consequently, with regard to private sector relying parties, the notifying Member State may define terms of access to the authentication means. Such terms of access may inform whether the authentication means related to the notified scheme is presently available to private sector relying parties
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
In a large risk and privacy analysis around online banking services, it must be considered that all sensitive information about customers must be protected by strong customers’ authentication even if there’s not direct and immediate link with a payment and the related fraud. Thus, customers’ information, that can lead to identity theft and then to fraud, should be protected by strong customer authentication.Finally there are also other kinds of banking services that can indirectly trigger payments and therefore, payment frauds. For example, contracts (e.g. saving contracts), that could be electronically signed by customers, can trigger money transfers and potentially fraud or theft.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
We consider that, in general, personal and preferred end-users’ devices will be the appropriate physical forms in order to get the possession factor. These devices will not be provided and, therefore, not fully controlled by the PSP so they will need a proven security to protect the PSU.In the coming years, end users’ preferred devices may not just be smartphones and could come from a large selection of connected objects, such as watches, glasses, cars, household appliances, etc. Existing dynamic authentication means such as hardware token or application on cards will also stay popular in many countries.
Today, the smartphone is the physical component that will probably be the preferred device for most end-users.
Smartphones provide a unique combination of benefits for both end-users and banks.
• A large deployment within customer bases
• A rich user experience, which may help to improve the information displayed and explained to customers
• A high security implementation using either Software Secure Element (SSE) or Hardware Secure Element (HSE). These components allow to securely generate and store sensitive data in a smartphone for strong customer authentication.
• An upgradable solution based on downloaded authentication software.
• A solution that may integrate a large range of authentication methods (knowledge and inherence methods)
• A solution that may integrate additional devices based on alternate communication channels like NFC or BLE (e.g. NFC keys or smart cards, passports, connected watches, etc.)
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Behavior-based characteristics are good complements to other authentication factors. Indeed, they bring some interesting features, such as:• Convenient and easy to understand user experience (e.g. voice recognition)
• Capacity to run in background for a transparent and continuous risk assessment and eventually authentication. This means that, for example, a mobile device could automatically detect the end-user’s behavior through, the way he walks, the way he types, or the places he stays.
We also consider that:
• When there is a limited risk on the transaction, the behavioral features can bring comfort for the user, bringing an additional risk assessment and ultimately avoiding having to ask the user for a knowledge factor.
• When the risk is medium or high, behavioral features can be used as a scoring element to mitigate other authentication means requirements.
• When the privacy dimension is respected, these methods can be considered (see answer to question 10)
Common criteria are being developed in Europe regarding biometrics and this work should be taken in consideration for the evaluation of biometrics authentication factors.
https://www.beat-eu.org/
The NIST is investigating the calculation of a score to assess biometrics authentication strength. http://www.nist.gov/nstic/NSTIC-strength-authentication-discussion-draft.pdf
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
General remark: The transposition into the local regulations of 28 countries could be a challenge to get the same technical, functional and regulatory levels of implementation. Understanding between local and central authorities should always lead to the same model of PSD2 transposition.A strong customer authentication implementation should address all customers with minimum limitation for online services.
TPP must provide alternative solutions with the same level of assurance and must be allowed to invoice according its cost model.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Dynamic linking should specifically explain the following:How the link is built
• As described in PSD2: what information is linked?
• How to create and secure the link?
• How to store the link?
How the link is used
• In which cases it is required to control the link?
• How to check whether the link is valid or broken?
• For how long this link could be checked?
• Who could have access to that link?
The specifications must not describe technical solutions but functional solutions, optionally with associated security levels.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
In our opinion, it would be a dedicated mobile application that would include:• A graphical user interface in order to display authentication context (e.g. amount, date, merchant, payment means ….)
Support for a second authentication factor, such as a GUI to type a pin code and biometric sensors (fingerprint, camera, accelerometer …..).
• Cryptographic resources in order to securely exchange with an authentication platform
• Cryptographic resources in order to create a unique and non-reusable link between authentication and transaction
• Hardware or software secure elements to support cryptographic features and give devices the possession characteristic (actually the mobile must be specifically personalized for a given end-user)
• Tamper resistance for sensitive information in the mobile device.
HCE requirements specified by international schemes also address this kind of requirement.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, it is helpful. Please note that additional comments can be found in our answer to question 8.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
The EBA should publish a list of these exemptions with detailed definitions (e.g.: what is definition of micro-donation?)The EBA should clarify if closed-loop payments are exempted, and give its definition of closed-loop.
The EBA should clarify which stakeholder is responsible for decision and application of exemptions: customer’s Bank, merchant, merchant’s bank, regulator, Scheme? For instance, the EBA should clarify what happens when merchants and issuers have different understandings of the exemptions, or transaction risk scoring.
The EBA should also clarify each player’s liabilities in case of frauds caused by exemptions for transactions that require strong authentication and for transactions that does not require strong authentication.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
The EBA should allow other criteria, that issuers already use for fraud detection, to improve or customize their transaction risk analysis.Smartphone using geolocation data can be used and the web browser geolocation API also.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
First, it is important to avoid unclear wording, such as adequate, take into account, minimize, safe use, etc. This type of broad words may lead to misinterpretation and mistranslation from one country to another.Taking into account that the PSD2 states that PSPs must follow EU regulations on personal data, as stated in recital (94), that The EBA states, in Issue 51.A, that the question arises as to how to ensure the privacy of PSU data, and that The EU Global Data Protection Regulation will have over seeded the current EU regulation by the time the PSD2 comes into application, we underline the following points:
First, the RTS should make the distinction between the rights of the data subject (PSU in our case) and the data security. Vague terms such as ‘privacy of data’ should be avoided.
Second, privacy is more than data protection. The recently adopted European General Data Protection Regulation goes beyond data protection as a security measure and aim to promote the rights of data subjects. We believe that all authentication methods and fraud detection algorithms must be implemented in a manner which is fully supportive of the new regulation (data minimization, privacy by default, privacy by design). Hence, the RTS should guarantee customer control and transparency over the data and algorithms implemented.
Third, biometrics data processing should be done with additional considerations. All “inherence” elements (physiological and behavior) manipulate biometric data and are therefore considered sensitive personal data in the European General Data Protection Regulation. These will require specific assessment – Data Protection Impact Assessment. Therefore, the implementation of biometrics should be done under the strictest principles of balance of interest, with full user control and consent. Also, match on device should be the preferred method for biometrics authentication
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Once an enrolment is securely done, the tamper resistance described in the discussion paper must also consider the way the personalized security credentials are stored in order to prevent against credential theft or copy.So tamper resistance is one of the most important features to protect PSU.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Local new digital identity platforms, as defined by the EIDAS regulation, could be good and simple solutions for a first approach of enrolment as they will be mature (e.g. ID card in Belgium, NEMID in Denmark).Assurance level should be level 2 or 3
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
A technical certification process with regular audit is absolutely necessary to ensure safety and confidence across the new ecosystem. Security will be limited by the weakest part of the transaction chain.A complementary process could be an observation period in order to assess the level of security of a TPP. This period could be based on a duration or number of processed transactions without incidents.
The PSP must also be able to check easily (automatically) that the agreements are valid and are related to the requested services (TPP directory).
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Article 4(32) of PSD2 states that “For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;”We believe that Account Numbers should be protected to limit attacks (phishing and identity thefts, for example). Therefore, storage of plain account number in various databases managed by PISP and AISP could create security risks. We suggest developing as much as possible possibility usage of token (such as encrypted account number).
A parallel can be drawn with the card industry which has introduced usage of tokens to manage in a secure manner specific cases such as mobile payment.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
For point a, it is necessary to conclude if the EBA has to define technical protocols for such standards (e.g. OAuth2 for authentication or REST/JSON web services for communication). It is also important to remember that there are 4 needs to cover: identification, authentication, notification, and information. So the notion of “common” includes also such services. Having clear technical standards could help to reduce market fragmentation.For point b, the TPP will have to self-identify. In this context, identification could be done with a license number given by local regulators or by the EBA through the general directory it will manage. Such license number could be the LEI or any other identifying number.
For point c, payees, in the PSD2 text, are included in the loop and not only the PIS/AIS/ASPSP are concerned by the common and open standards for communication.
For point d, there is a need for information concerning payment history, for audit tracking for instance. About account information communicated by ASPSPs, it would be important to indicate which data is mandatory or optional and which is sensitive and not in view of the future regulation of personal data protection. Indeed in the PSD2, we can read that IBANs and names are not sensitive.
For point f, the text is too restrictive in trying to define the ASPSP interface. Indeed, the ASPSP can use a distinct provider to avoid any internal IT development and a protocol converter for any communications with new PIS/AIS.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
We can imagine that protocol could be different for a PIS and for a AIS from a risk point of view. Indeed, a PIS will debit the account whereas the AIS will only consolidate banking information.The timing for future implementation of API by ASPSP will be short; in consequence, a minimum set of practices commonly approved by the banking industry should be integrated.
Besides, the PSD2 mentions accounts which are accessible online; but online could be in cloud or through a connected object. Innovation can promote other protocols in the following years.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
OAuth2 is the de facto framework used by Web players, in particular by big actors such Google, Facebook or Amazon.The usage of the OAuth 2.0 protocol and its authentication counterpart OpenId Connect is spreading on smartphone devices. Both protocols have an application scope which seems suitable to the context; they are designed as internet scale protocols and enable federated identity. Still, they have to be reviewed to investigate whether a specific profile needs to be created to accommodate the security context of the PSD2.
The PSP could be identified through a number of identification supplied by each local regulator and centralized by the EBA in its directory listing all the PIS and AIS. Nevertheless, services 7&8, identified in annex I of the PSD2, can be proposed by any others categories of PSP listed in article I (1). So identification is not only a PIS/AIS concern; the EBA register should also be available both per services and per categories of PSP.
Another protocol could be 3Skey (public and private) to encourage identification of stakeholders with protection of privacy.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
The user should be the decision maker concerning the credentials usage through a dashboard to adjust authorization for each type of services and associated ceilings.Besides, if level of authentication are different for AIS and PIS, separate authentication should be done at connection (to access accounts) and then for payment initiation (to do a credit transfer between accounts).
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
e-IDAS General frameworkIn July 2014, the European Parliament and the EU Council passed the Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market" (eIDAS regulation) that repeals the Directive 1999/93/EC (Signature Directive).
The purpose of the eIDAS regulation is to constitute a basis for building trust in the European online environment.
This regulation covers different aspects of electronic transactions, such as:
• Electronic identification,
• Trust services,
• And electronic documents.
The e-IDAS Regulation seeks to enhance trust in electronic transactions in the internal market, by facilitating the cross-border use of online services, with particular attention to facilitating secure electronic identification and authentication since many online services require electronic identification, authentication and signature
Identification and Authentication following e-IDAS and PSD2
The e-IDAS Regulation underlines the difference between ‘Electronic identification’, which means “the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person” and Authentication, which means “an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed”;
It is important to note that identification is always before authentication. Authentication presupposes making a link between the identification data, which is already known to the provider, and the data that is used by the person to authenticate. The e-IDAS Regulation knows this link.
But if we analyze the PSD2, we can see that it has not used the word “Identification”, but includes two definitions for Authentication:
- 'Authentication', "a procedure which allows the payment service provider to verify the identity of a user of a specific payment instrument, including the use of its personalized security features or control of documents personal identity;
- "Strong client authentication": "a validation procedure for the identification of a person or entity based on the use of two or more elements belonging to the categories knowledge, possession and inherently which are independent in the sense that the compromise of one does not question the reliability of others, and is designed to protect the confidentiality of authentication data. "
The same word is used in the PSD2 with two different meanings.
If we compare the e-IDAS and the PSD 2, and if we do not consider the different words which are used, but only the needs, we can see that there is a need to verify an identity (Identification for the e-IDAS and Authentication for the PSD2) before being able to make Authentication, for the e-IDAS, and Strong Authentication, for the PSD2.
The e-IDAS Regulation defines meanwhile Identification levels and also Authentication levels.
The PSD2 regulation defines levels of Authentication (single and strong); this is not consistent either, since it is not the same operation.
However, in some cases, it will directly be an identification operation, not an authentication, to the extent that the provider does not know the person in advance.
It would be extremely unfortunate that this inconsistency remains because it is a source of legal ambiguity between the two regulations.
The e-IDAS regulation has a possible solution for facilitating strong customer authentication, protecting the confidentiality and the integrity of the users’ personalized security credentials.
Different Levels of confidence, different security levels
The e-IDAS Regulation describes different levels which permit to characterize the degree of confidence in electronic identification means in establishing the identity of a person, thus providing assurance that the person claiming a particular identity is in fact the person to which that identity was assigned.
The assurance level depends on the degree of confidence that the electronic identification means provide in claimed or asserted identity of a person taking into account processes (for example, identity proofing and verification, and authentication), management activities (for example, the entity issuing electronic identification means and the procedure to issue such means) and technical controls implemented.
Considering Authentication, the e-IDAS executive rule focuses on the threats associated with the use of the authentication mechanism and lists the requirements for each level of guarantee.
The controls are supposed to be proportionate to the risks at the given level.
For the Authentication Mechanism, below is a table which defines the requirements for each security level.
Low Authentication for the e-IDAS :
1. The diffusion of personal identification data is preceded by the reliable electronic verification of identification and its validity.
2. When personal identification data is stored in the authentication mechanism, the information is secured to ensure its protection against loss or compromise, including offline analysis.
3. The authentication mechanism implements security controls for the verification of the electronic identification means, so that it is highly unlikely that activities such as decryption attempts, listening, replay attack or communication manipulation by an attacker with a potential base attack may harm the enhanced authentication mechanisms.
Substantial Authentication: low/ substantial
1. The dissemination of personal identification data is preceded by the reliable verification of the electronic identification means and validity by a dynamic authentication.
2. The authentication mechanism implements security controls for verification of the electronic identification means, so it is highly unlikely that activities such as decryption attempts, listening, attack replay or manipulation of a communication by an attacker with a moderate attack potential could harm the authentication mechanisms .
High level, low/high:
The authentication mechanism is implementing security controls for verification of the electronic identification means, so it is highly unlikely that activities such as decryption attempts, listening, replay attack or manipulation a communication by an attacker with a high attack potential could harm the authentication mechanisms ."
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
e-IDAS provide a comprehensive framework for forging e-signature and archiving necessary proofs to ensure legal value. It is not as such an authentication protocol and it doesn’t take into accounts use cases related to AIS and PIS.The e-IDAS token specification, which is a contribution from the German and French IT security agencies BSI and ANSSI and is supported by European industry partners, allows the development of token-based and customized solutions for electronic identification, authentication and signatures that are directly interoperable, without the need of translation via proxies.
This specification provides a modular and homogeneous secured element API to protect the following functions:
• Authenticity,
• Integrity,
• Originality,
• Confidentiality and
• Privacy of the data stored on tokens for electronic identification, authentication and signatures (the eIDAS token).
Examples are the German ID card or the German Residence Permit.
The e-IDAS token specification covers all existing eService use cases, and opens the door to new applications. The technology is based on a direct mutual authentication between the eIDAS token and the service provider, and facilitates real end-to-end encryption. The approach is to build on the technology of machine readable travel documents and the corresponding infrastructures that are already in use in the European member states and includes enhancements and extended services.
There is a technical guideline which specifies the following protocols to protect personal data stored on electronic documents.
We can say that various technical definitions and descriptions of assurance levels exist, such as STORK and ISO 29115, which should be taken into account in establishing minimum technical requirements, standards and procedures for the low, substantial and high assurance levels within the meaning of this Regulation, while ensuring consistent application of this Regulation in particular with regards to assurance level high related to identity proofing for issuing qualified certificates.
The requirements established should be technology-neutral. It should be possible to achieve the necessary security requirements through different technologies.
Member States should encourage the private sector to voluntarily use electronic identification means under a notified scheme for identification purposes when needed for online services or electronic transactions. The possibility to use such electronic identification means would enable the private sector to rely on electronic identification and authentication already largely used in many Member States, at least for public services, and to make it easier for businesses, in order to facilitate the use of such electronic identification means across borders by the private sector. Additionally, the authentication possibility provided by any Member State should be available to private sector relying parties established outside of the territory of that Member State under the same conditions as applied to private sector relying parties established within that Member State. Consequently, with regard to private sector relying parties, the notifying Member State may define terms of access to the authentication means. Such terms of access may inform whether the authentication means related to the notified scheme is presently available to private sector relying parties