Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Enrolment of PSUs into recurrent payment solutions and mobile applications with in-app payments have been experienced.
Tokens as a notion can be technology agnostic and facilitate description and understanding of new methods to combine authentication factors into a Token. Tokens are possessed by the User and controlled by one or more of the traditional authentication factors. By this way it will facilitate specifying and qualifying different characteristics of security solutions instead of just claiming the use of a two factor solution.
Specific realization of different kinds of Tokens is also contained in the above referenced NIST Guideline.
The Tokenization has the ability to protect, to limit use for specific ac-ceptance domains, can be unlinked for the ‘private data’ (the account no), can be seen as a ‘pseudonymisation’ of the personal data, as recommended in the EU General Data Protection Regulation approved on the 15. December 2015. (http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm) – on top of this tokens may be revoked by the PSU with the appropriate system setup.
EMVCo has made significant work in adaptation of tokenisation and proved its benefits for card payments.[ref:EMVCo Payment Tokenisation Specification Technical Framework version 1.0, March 2014]
Nets has experience with collection and analysis of behaviour-based characteristics through deployment of so called “Behavioural Biometrics” in the Norwegian BankID solution. Experience show that though this type of authentication may show significant results for advanced, context based scenarios, the results for transaction types like simple authentication or transaction authorisation is not convincing. The significance of the confidence provided from the “Behavioural Biometrics” analysis is not satisfactory enough to replace one factor in a two-factor solution.
However inherence elements or behaviour-based characteristics data have a role to play as they are more difficult to exploit with phishing attacks, comparing to other SCA elements like “something you know” .
Currently behaviour-based characteristics analysis might not be mature enough to stand alone as SCA in all situations in relation to
Article 97(1) A. But could very much be used in low risk, low value Card payment transaction Article 97(1) B, and be an future important factor in inherence elements.
It is very hard to achieve independence of the authentication elements whenever it comes to a compromised mobile platform. Nets will not recommend EBA to make security requirements which specifies “independency of the authentication elements” which we find not to be achievable on a single execution environment. A better approach is to include the notion of a Token as proposed above and specify different assurance level according the strength of this Token.
Nets will recommend EBA to define the different threats which the system should protect against and establish an Assurance Level Matrix based on the same concept as NIST or eIDAS [STORK D2.3 Quality Authenticator Scheme. In this case a single device situation is reflected as a lower assurance level.
Deciding on mandatory minimum requirements where information from all parties are required will mean that one part can obstruct innovation and security in payments
As a complement to the criteria identified in paragraph 45 subsection b) we believe that as part of the information about the customer device used it should also include details on the SDK Application used (or similar information), to verify whether there has been updates or transfer of applications to new devices.
Today’s market and customer behavior is resulting in device replacement (and consequently transfer of applications) with a very high frequency, especially for those consumers who is most active in using new and emerging technologies.
Costumer convenience, new market opportunities combined with rapidly emerging new technologies is, together with increasing efforts to move cash into electronic payments, is also driving the market players into a very high frequency of application updates.
As both updates and transfer of applications (re-installation of known application) can be considered high risk, Nets sees it relevant to include in the risk evaluation.
Additional complement criteria to subsection a) we believe that, when available, the routing and switching information should be used as well.
The payment processor will always know who has delivered the transaction to the payment system, and in order to establish reliability it could be meaningful to have the payment processor be a part of the risk assessment, which could be in form of a risk marking, like the way that such a marking is used in the current 3D secure processing.
Comment on 52. i.:
Include credential renewal and - revocation/ destruction.
The clarification specified in 51. E is very important:
National eID solutions in the Nordic area are used for much more than payments
In the Nordic countries Norway and Denmark a common e-ID solution is used for both e-banking and e-Government transactions.(NemID in Denmark and BankID in Norway) It is therefore important that the RTS supporting the financial area does not impose conflicts to the eIDAS regulation supporting the e-Governmental area because the e-ID solution in the Nordic must embrace both areas to provide the efficiency gains and consumer convenience. This cross sector use of eID solutions in practice means that the same eID solutions are both used for payments and as well as e-signing of for example an application for a divorce or sign-off of a parent ship to kids, registering move of national register address, signing mortgage bonds or signing of property deeds. Consequently, the impact of any security breach related to PSC can have significant consequences for the PSU although the impact may be non-financial it may compromise privacy.
The protection of PSC for these eID solutions is crucial for the end-user’s trust in the solution in the countries using common eID solutions. Therefore, exposure of the PSC to third parties should not be allowed when the PSC is utilised for common eID solutions.
The use of the open standard OAuth 2.0 Authentication Framework can provide third parties with an alternative protocol using tokens which prevent disclosure of the end-user PSC for the eID solutions to third parties. Nets has explained about an example of alternatives as OAuth 2.0 in its answer to question 2.
This is also in alignment with the recommendations made by ECB as described in ECB: Recommendations for “payment account access” services, January 2013.
An alternative is to limit financial and data protection risks for solutions which decide to not to comply with complicated and expensive certification or evaluation.
In Nets’ view, the segment between the PSU and the third party is ex-posed to most risks as the PSU – being a non-professional - often have few or no means to confirm the identity of the third party. In this segment the risk of phishing is highest and the consequence for the PSU could be financial loss but also non-financial. The trust balance is not even here. The PSU is supposed to identify himself but the third party is not required to identify himself towards the PSU. The PSU may think he is enrolling with the correct third party but it could be an impersonator.
Please refer to Nets answer to Question 10 for more information on common eID solutions and consequences of a security breach.
Comments to 63 b: Yes, it will be helpful to specify the quality of how the PIS/AIS identifies themselves to ASPSP., because an IP-address of the AIS/PIS is evidently neither sufficient or trustworthy.
Comments to 63c: The central part here is that the PSC of the PSU is never disclosed to the PIS/AIS. Only in the circumstances that the PIS/AIS itself act as a trusted issuer of the PSC or if PIS/AIS is issued its own PSCs.
No comments to 63d.
Comments to 63e.: A framework which has been defined by NIST 800-63-2 and ISO 29115 on Electronic Authentication and which uses different assurance levels in accordance with the perceived risk acceptance could be helpful.
No comments to 63f.
Nets and its peers in the payments industry have engaged in making new industry standards for the purpose of AIS/PIS via the CAPS Framework Work Group. Nets see industry standards as CAPS Framework as a prerequisite to make PIS and AIS create the expected innovation in the payments market. [For more information on CAPS Framework see http://www.nets.eu/Documents/White%20Paper%20on%20CAPS%20for%20PSD2.pdf]
1) Instead of using the resource owner's credentials to access protected resources, the client(AIS/PIS) obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes.
2) Access tokens are issued to third-party clients (AIS/PIS) by an authorization server with the approval of the resource owner.
3) The client (AIS/PIS) uses the access token to access the protected resources hosted by the resource server
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.
Yes, changes to any basic information in a bank related to a customer e.g. phone number, post address and e-mail address which can affect implemented security procedures and lead to impersonation and fraud are such other examples. Fraudulent re-issuing of PSC to a fraudulent address is another example.Enrolment of PSUs into recurrent payment solutions and mobile applications with in-app payments have been experienced.
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?
EBA should consider introducing the notion of a Token as specified by NIST Special Publication 800-63-2 Electronic Authentication Guideline which provides certain conceptual security qualities. The publication also provides practical examples of realisation of Tokens.Tokens as a notion can be technology agnostic and facilitate description and understanding of new methods to combine authentication factors into a Token. Tokens are possessed by the User and controlled by one or more of the traditional authentication factors. By this way it will facilitate specifying and qualifying different characteristics of security solutions instead of just claiming the use of a two factor solution.
Specific realization of different kinds of Tokens is also contained in the above referenced NIST Guideline.
The Tokenization has the ability to protect, to limit use for specific ac-ceptance domains, can be unlinked for the ‘private data’ (the account no), can be seen as a ‘pseudonymisation’ of the personal data, as recommended in the EU General Data Protection Regulation approved on the 15. December 2015. (http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm) – on top of this tokens may be revoked by the PSU with the appropriate system setup.
EMVCo has made significant work in adaptation of tokenisation and proved its benefits for card payments.[ref:EMVCo Payment Tokenisation Specification Technical Framework version 1.0, March 2014]
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?
Nets does not perceive “inherence” elements as strong customer authentication. But the notion of a token will be helpful in this context as Nets has proposed in its answer to question 2.Nets has experience with collection and analysis of behaviour-based characteristics through deployment of so called “Behavioural Biometrics” in the Norwegian BankID solution. Experience show that though this type of authentication may show significant results for advanced, context based scenarios, the results for transaction types like simple authentication or transaction authorisation is not convincing. The significance of the confidence provided from the “Behavioural Biometrics” analysis is not satisfactory enough to replace one factor in a two-factor solution.
However inherence elements or behaviour-based characteristics data have a role to play as they are more difficult to exploit with phishing attacks, comparing to other SCA elements like “something you know” .
Currently behaviour-based characteristics analysis might not be mature enough to stand alone as SCA in all situations in relation to
Article 97(1) A. But could very much be used in low risk, low value Card payment transaction Article 97(1) B, and be an future important factor in inherence elements.
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)?
The first challenge is to detect occurrence of a single execution platform which may compromise independence of authentication ele-ments.It is very hard to achieve independence of the authentication elements whenever it comes to a compromised mobile platform. Nets will not recommend EBA to make security requirements which specifies “independency of the authentication elements” which we find not to be achievable on a single execution environment. A better approach is to include the notion of a Token as proposed above and specify different assurance level according the strength of this Token.
Nets will recommend EBA to define the different threats which the system should protect against and establish an Assurance Level Matrix based on the same concept as NIST or eIDAS [STORK D2.3 Quality Authenticator Scheme. In this case a single device situation is reflected as a lower assurance level.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Nets has no comments6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
To be able to fulfil both independence and dynamic linking two different channels and processing devices must be in use. Despite Nets sceptic view on independence on independence for mobile devices, Nets has a satisfactory solution. In the Norwegian market Nets has deployed BankID on SIM, where the transaction authentication and signing is done in the SIM-card of a mobile device using SIM-toolkit application and end users private key protected in SIM. The client for authentication and signing is deployed in the SIM and triggered by an STK-message from the mobile operator. The client is capable of displaying the context of the transaction, ie amount, merchant or account number. On the other side the initial trigger of the transaction can be made from the mobile device’s browser displaying the payment context, thus enabling both parties to verify the authenticity and the integrity of the transaction. Both the merchant and the mobile operator are connected via a common infrastructure.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The clarifications are useful as a guideline, however we believe the explicit use of transaction risk analysis (42.D) requires further clarifications on who decides exemption conditions are meet and any liability switching. The transaction risk analysis is complicated by three matters: 1)a distinction between what is available for the Payer and the Payer’s PSP and what is available to the Payee and the Payee’s PSP eg the IP address of device used is available to the Payer and Payer’s PSP. 2) Secondly an understanding that information exchanged between the Payer and Payee can include elements that could be considered sensitive and covered by data protection eg Payer’s IP address during purchase. 3) Thirdly that best practice of use as in cards should be maintained by independent certification companies to ensure continual development in security practice and minimum standards similar to PCI DSS and ISO standards.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Nets has no comments.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?
Most important is the understanding of which information is available to Payer and Payer’s PSP as opposed to what is available to Payee and Payee’ PSP.Deciding on mandatory minimum requirements where information from all parties are required will mean that one part can obstruct innovation and security in payments
As a complement to the criteria identified in paragraph 45 subsection b) we believe that as part of the information about the customer device used it should also include details on the SDK Application used (or similar information), to verify whether there has been updates or transfer of applications to new devices.
Today’s market and customer behavior is resulting in device replacement (and consequently transfer of applications) with a very high frequency, especially for those consumers who is most active in using new and emerging technologies.
Costumer convenience, new market opportunities combined with rapidly emerging new technologies is, together with increasing efforts to move cash into electronic payments, is also driving the market players into a very high frequency of application updates.
As both updates and transfer of applications (re-installation of known application) can be considered high risk, Nets sees it relevant to include in the risk evaluation.
Additional complement criteria to subsection a) we believe that, when available, the routing and switching information should be used as well.
The payment processor will always know who has delivered the transaction to the payment system, and in order to establish reliability it could be meaningful to have the payment processor be a part of the risk assessment, which could be in form of a risk marking, like the way that such a marking is used in the current 3D secure processing.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes they are clear, however distinction between high impact services vs low impact needs to be made, e.g. using a payment app that applies low value / low risk methods should be approached differently than requirements to reissue cards, open bank accounts etc. High impact use cases should not be negatively impacted by needs from low impact uses cases.Comment on 52. i.:
Include credential renewal and - revocation/ destruction.
The clarification specified in 51. E is very important:
National eID solutions in the Nordic area are used for much more than payments
In the Nordic countries Norway and Denmark a common e-ID solution is used for both e-banking and e-Government transactions.(NemID in Denmark and BankID in Norway) It is therefore important that the RTS supporting the financial area does not impose conflicts to the eIDAS regulation supporting the e-Governmental area because the e-ID solution in the Nordic must embrace both areas to provide the efficiency gains and consumer convenience. This cross sector use of eID solutions in practice means that the same eID solutions are both used for payments and as well as e-signing of for example an application for a divorce or sign-off of a parent ship to kids, registering move of national register address, signing mortgage bonds or signing of property deeds. Consequently, the impact of any security breach related to PSC can have significant consequences for the PSU although the impact may be non-financial it may compromise privacy.
The protection of PSC for these eID solutions is crucial for the end-user’s trust in the solution in the countries using common eID solutions. Therefore, exposure of the PSC to third parties should not be allowed when the PSC is utilised for common eID solutions.
The use of the open standard OAuth 2.0 Authentication Framework can provide third parties with an alternative protocol using tokens which prevent disclosure of the end-user PSC for the eID solutions to third parties. Nets has explained about an example of alternatives as OAuth 2.0 in its answer to question 2.
This is also in alignment with the recommendations made by ECB as described in ECB: Recommendations for “payment account access” services, January 2013.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Nets has identified delayed revocation/destruction of credentials as a risk in regard to protecting PSCs.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?
Nets has no comments13. 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?
Unfortunately Nets cannot point to alternatives to certification or third party evaluation even though Nets is opposed to using strong formal certification - and authentication schemes for the entire enrolment as this drives cost and significantly limit innovation and market adoption.An alternative is to limit financial and data protection risks for solutions which decide to not to comply with complicated and expensive certification or evaluation.
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?
In Nets’ opinion enrolment is one of the most critical parts of the credential life-cycle. It is here the foundation of the quality of the authentication system is created. However, it is a rare event compared to the normal operation when users initiates/authorize payments, which occur on a daily basis.In Nets’ view, the segment between the PSU and the third party is ex-posed to most risks as the PSU – being a non-professional - often have few or no means to confirm the identity of the third party. In this segment the risk of phishing is highest and the consequence for the PSU could be financial loss but also non-financial. The trust balance is not even here. The PSU is supposed to identify himself but the third party is not required to identify himself towards the PSU. The PSU may think he is enrolling with the correct third party but it could be an impersonator.
Please refer to Nets answer to Question 10 for more information on common eID solutions and consequences of a security breach.
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?
Comments to 63 a.: It is very difficult to define the notion “common and open” in more detail, because there are plenty of organisations in the field which claims to develop common and open standards. Either keep the notion open or EBA should recommend specific standards to be used. However, this could also lead to over regulations if EBA is going into very specific detail.Comments to 63 b: Yes, it will be helpful to specify the quality of how the PIS/AIS identifies themselves to ASPSP., because an IP-address of the AIS/PIS is evidently neither sufficient or trustworthy.
Comments to 63c: The central part here is that the PSC of the PSU is never disclosed to the PIS/AIS. Only in the circumstances that the PIS/AIS itself act as a trusted issuer of the PSC or if PIS/AIS is issued its own PSCs.
No comments to 63d.
Comments to 63e.: A framework which has been defined by NIST 800-63-2 and ISO 29115 on Electronic Authentication and which uses different assurance levels in accordance with the perceived risk acceptance could be helpful.
No comments to 63f.
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?
EBA may consider this approach: On security matters direct to some general security guidelines as proposed above, but on the interoperability area the standards should be developed and maintained by the industry as these interoperability standards have to be very specific - otherwise, the free and open competition will not occur.Nets and its peers in the payments industry have engaged in making new industry standards for the purpose of AIS/PIS via the CAPS Framework Work Group. Nets see industry standards as CAPS Framework as a prerequisite to make PIS and AIS create the expected innovation in the payments market. [For more information on CAPS Framework see http://www.nets.eu/Documents/White%20Paper%20on%20CAPS%20for%20PSD2.pdf]
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?
Nets recommends EBA to include OAuth 2.0 Authentication Framework into the RTS. The objectives of OAuth 2.0 is:1) Instead of using the resource owner's credentials to access protected resources, the client(AIS/PIS) obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes.
2) Access tokens are issued to third-party clients (AIS/PIS) by an authorization server with the approval of the resource owner.
3) The client (AIS/PIS) uses the access token to access the protected resources hosted by the resource server