Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
The Agency for Digitisation is an agency under the Ministry of Finance and was established in 2011 to support digitisation of the public sector and egovernment. The Agency is in charge of the digitisation of Denmark and is responsible for the implementation of the government's digital ambitions in the public sector.
The Agency for Digitisation is responsible for the OCES standard and for the national eID, called NemID.
Background
In Denmark, we have a single national eID solution called “NemID” which is the Danish public digital signature based on the national public standard for certificates for public services (OCES standard). OCES is the Danish designation for Public Certificates for Electronic Services (Offentlige Certifikater til Elektronisk Service"). OCES digital signatures are advanced electronic signatures under the notion of the eSignature directive. They are software-based with enforced password-protection, in order to ensure “sole control”.
The OCES standard is closely linked to the Danish Central Personal identification number. The personal identification number is a unique identification number for Danish citizens. The personal numbers of all Danish citizens are stored in the CPR-register (a national central register containing information of name, address and register number of all Danish citizens). The legal framework for the use of the personal identification numbers and other information of the CPR-register is laid down in the Act on the Civil Registration System .
Conclusion
The Danish eID (NemID) is used for both authentication of the user and signing legally binding documents and contracts. Furthermore, the Danish eID credentials are used by both public and private sector i.e. for accessing public services and private banking. Taking into account the wide range of services available for the Danish population using NemID, it is of utmost importance that the credentials are kept secure and in full control of the user, so that they are not put at risk through man-in-the-middle-like services. Since NemID functions as a federated identity scheme the danish service providers both public and private, never receive any knowledge of the credentials applied using NemID which means the credentials are never at risk of getting compromised at the Service Providers’ end. This is ensured technically by an end to end encryption architecture where only the user and the Identity Provider, IdP, takes part in the credential verification protocol and where the Service Provider rely on receiving a SAML token proving that the user has been authenticated by the IdP.
Moreover the NemID-users have obligations via an end user agreement with the IdP which includes requirements not to disclose credentials to anybody. The reason for this, is the fact that disclosure of credentials to third parties may affect not only the information held by one Service Provider, but the entire selection of services, including healthcare information, tax information, union membership etc. In addition the user can enter into legally binding contracts using NemID. In Denmark a NemID user’s disclosure of credentials to other parties such as a third party payment service will violate the end user agreement and thus result in revocation of the NemID according to the Danish national standard.
There is a general issue related to the protection of the users' personalised security credentials if the ASPSP, i.e. banks do not issue and manage the credentials of the users directly but rely on federated identities from a third party IdP, e.g. an electronic identification scheme according to eIDAS article 3. While the ASPSP, i.e. banks do not know nor handle user credentials but expect a token from the third party IdP, it would be irrelevant and unnecessarily insecure to introduce and endorse a middle-man to receive and manage these credentials. In Denmark we have put in significant awareness efforts exactly to avoid our citizens disclosing their credentials to third party service providers.
Endorsing such disclosure for certain third party service providers such as payment services will risk breaking the attained level of good practice. We foresee a difficult and unwanted situation if services are introduced where the usage of such rely on disclosing personalised security credentials to a third party such as a third party payment service. In fact our entire security model is based on not having to disclose personal credentials to any party at all. Any change to that would be seen as a step back and we suggest that EBA defines technical standards which handle credentials in a way that doesn’t reduce the existing built-in confidentiality of the user’s security credentials between the user and the IdP or trust service provider.
In such eID systems at large, the ASPSP will normally never request the users credentials but will rely on a security token sent from the IdP. The IdP may act as trusted party to other entities than the ASPSP. For security reasons in many cases even the IdP may not know the users credentials, but may have the ability to verify them through challenge-response protocols. We would like to ensure that any third-party service providers must implement a security model based on these principles.
Additionally, requirements in identity schemes in article 8 of eIDAS and the corresponding "COMMISSION IMPLEMENTING REGULATION (EU) 2015/1502 of 8 September 2015" may contradict the disclosure of credentials to PIS or AIS. See paragraph 2.2.1, 2.3.1 and 2.4.6 of the implementing regulation 2015/1502.
At some point, Denmark expects to notify our national eID scheme in accordance with the implementing regulation of the eIDAS regulation on either assurance level substantial or high. With regard to the abovementioned use of credentials for both public and private sector services we are not welcoming banking regulations putting our national eID architecture at risk.
It is suggested that EBA define technical standards for PSD2 which address the use of federated identity schemes and signing trust service providers without compromising the built-in confidentiality of the user’s security credentials between the user and the IdP or trust service provider."
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.
N/A2. 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?
N/A3. 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?
N/A4. 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)?
N/A5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
N/A6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
N/A7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
N/A8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
N/A9. 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?
N/A10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
N/A11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
IntroductionThe Agency for Digitisation is an agency under the Ministry of Finance and was established in 2011 to support digitisation of the public sector and egovernment. The Agency is in charge of the digitisation of Denmark and is responsible for the implementation of the government's digital ambitions in the public sector.
The Agency for Digitisation is responsible for the OCES standard and for the national eID, called NemID.
Background
In Denmark, we have a single national eID solution called “NemID” which is the Danish public digital signature based on the national public standard for certificates for public services (OCES standard). OCES is the Danish designation for Public Certificates for Electronic Services (Offentlige Certifikater til Elektronisk Service"). OCES digital signatures are advanced electronic signatures under the notion of the eSignature directive. They are software-based with enforced password-protection, in order to ensure “sole control”.
The OCES standard is closely linked to the Danish Central Personal identification number. The personal identification number is a unique identification number for Danish citizens. The personal numbers of all Danish citizens are stored in the CPR-register (a national central register containing information of name, address and register number of all Danish citizens). The legal framework for the use of the personal identification numbers and other information of the CPR-register is laid down in the Act on the Civil Registration System .
Conclusion
The Danish eID (NemID) is used for both authentication of the user and signing legally binding documents and contracts. Furthermore, the Danish eID credentials are used by both public and private sector i.e. for accessing public services and private banking. Taking into account the wide range of services available for the Danish population using NemID, it is of utmost importance that the credentials are kept secure and in full control of the user, so that they are not put at risk through man-in-the-middle-like services. Since NemID functions as a federated identity scheme the danish service providers both public and private, never receive any knowledge of the credentials applied using NemID which means the credentials are never at risk of getting compromised at the Service Providers’ end. This is ensured technically by an end to end encryption architecture where only the user and the Identity Provider, IdP, takes part in the credential verification protocol and where the Service Provider rely on receiving a SAML token proving that the user has been authenticated by the IdP.
Moreover the NemID-users have obligations via an end user agreement with the IdP which includes requirements not to disclose credentials to anybody. The reason for this, is the fact that disclosure of credentials to third parties may affect not only the information held by one Service Provider, but the entire selection of services, including healthcare information, tax information, union membership etc. In addition the user can enter into legally binding contracts using NemID. In Denmark a NemID user’s disclosure of credentials to other parties such as a third party payment service will violate the end user agreement and thus result in revocation of the NemID according to the Danish national standard.
There is a general issue related to the protection of the users' personalised security credentials if the ASPSP, i.e. banks do not issue and manage the credentials of the users directly but rely on federated identities from a third party IdP, e.g. an electronic identification scheme according to eIDAS article 3. While the ASPSP, i.e. banks do not know nor handle user credentials but expect a token from the third party IdP, it would be irrelevant and unnecessarily insecure to introduce and endorse a middle-man to receive and manage these credentials. In Denmark we have put in significant awareness efforts exactly to avoid our citizens disclosing their credentials to third party service providers.
Endorsing such disclosure for certain third party service providers such as payment services will risk breaking the attained level of good practice. We foresee a difficult and unwanted situation if services are introduced where the usage of such rely on disclosing personalised security credentials to a third party such as a third party payment service. In fact our entire security model is based on not having to disclose personal credentials to any party at all. Any change to that would be seen as a step back and we suggest that EBA defines technical standards which handle credentials in a way that doesn’t reduce the existing built-in confidentiality of the user’s security credentials between the user and the IdP or trust service provider.
In such eID systems at large, the ASPSP will normally never request the users credentials but will rely on a security token sent from the IdP. The IdP may act as trusted party to other entities than the ASPSP. For security reasons in many cases even the IdP may not know the users credentials, but may have the ability to verify them through challenge-response protocols. We would like to ensure that any third-party service providers must implement a security model based on these principles.
Additionally, requirements in identity schemes in article 8 of eIDAS and the corresponding "COMMISSION IMPLEMENTING REGULATION (EU) 2015/1502 of 8 September 2015" may contradict the disclosure of credentials to PIS or AIS. See paragraph 2.2.1, 2.3.1 and 2.4.6 of the implementing regulation 2015/1502.
At some point, Denmark expects to notify our national eID scheme in accordance with the implementing regulation of the eIDAS regulation on either assurance level substantial or high. With regard to the abovementioned use of credentials for both public and private sector services we are not welcoming banking regulations putting our national eID architecture at risk.
It is suggested that EBA define technical standards for PSD2 which address the use of federated identity schemes and signing trust service providers without compromising the built-in confidentiality of the user’s security credentials between the user and the IdP or trust service provider."