Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Specific Comments:
Comment 1:
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. (DP Resoning 34)
According to Eurosmart, the implementations of eIDAS, PSD-2 and the EU Data Privacy regulation (as well as the NIS Directive on cyber security) have to be aligned, because products have to comply to them all. The underlying RTS (as well as the Implementing acts for eIDAS) have to take care of this (and not each product for its own). Therefore the resoning 34 should be changed according to a respective recommendation.
Comment 2:
The usage of the term “shall” and “should “as well as the requirements of authentication seem not to be constantly used within the resoning and the articles.
According to DP Reasoning 28/29: With regards to the definition of authentication elements categorised as knowledge, possession and inherence in in order to ensure technology neutrality and allow for the development of user-friendly, accessible and innovative means of payment, the EBA is of the view that there is no need to further define these authentication elements.
Yet according to (DP Reasoning 22) and Article 1.2 the strong customer authentication procedure shall include mechanisms to prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. Thereby the requirements of tamper resistant devices (DP Reasoning 25) as well as security and privacy features according DP Reasoning 26 should apply.
Eurosmart, is in favour to change the “should” to “shall“ in DP 25 as well as in compliance to 6.3.(a), (which actually sets strong requirement to authentication elements) because we do not envision, non tamper resistant devices“ with the property described in DP Reasoning 22 and DP Reasoning 26.
Tamper resistant shall meet all of the following requirements:
1) have mechanisms to protect the execution and integrity of its embedded software;
2) have mechanisms to protect the integrity of the user data stored within;
3) have mechanism to to ensure controlled execution and data integrity when oprating outside its specified operating conditions;
4) have mechanisms to protect against physical tampering and micro-manipulation;
5) The strength of all of these mechanisms must have been evaluated and certified in a (Common Criteria based) security certification.
For ensuring interoperability and ease the burden of implementation and security evaluation suitable standardized authentication protocols and privacy mechanisms should be referenced, see e.g. regarding the management and operation of tamper resistant devices the current Privacy Standard ISO/IEC CD 19286 or the European Industry Standard EN 419212 (former EN14890). Therefore we would be in favour to reference suitable standards in the RTS.
Comment 3:
According to Article 1.2 “The authentication code shall be characterized by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time”.
Eurosmart is in favour to change the above sentence in:
“The authentication code shall be characterized by security features including, but not limited to protocols, algorithm, length, information entropy, expiration time (and effective time, the latter, if a current date can be validated)”.
Reason: The term protocols are missing including referenced algorithms and data objects. (The expiration date can only validated, if certain measures on behalf of the ICCS or IFDS are provided, see e.g. the EAC Protocol in EN 419 212 or TR 03110-3.)
Comment 4:
According to Article 1. Article 1.2.(b), the term “generated for the same payer” should be deleted given that an authentication code should not be derivable from a previous one independent of the payer.
“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be logically independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”
Addition in Article 6.3 a) the term “logical” is to be added in the underlying sentence.
a) The implementation of logical separated trusted execution environments inside the multi- purpose device;
Thereby the definition of Trusted Execution Environment is to be provided (according to Global Platform or more generic?).
Reason:
The article should address the issue of logical independence" of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device, if this device provides respective security means, e.g. by certification."
Together with the referred generic privacy requirement, the qualified trust services, especially the seal services, are described very explicitly in the eIDAS regulation fulfilling data originality and data integrity to be applied for legal persons as e.g. AIS, PIS and ASPSDs. The gain of this new concept is that qualified seals are accepted as such European–wide and cannot be interpreted differently as it was the case with qualified signatures before, as substitute for “handwritten signatures”.
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?
In principle Eurosmart agrees, but would ask for harmonizing the definitions and arguments of the resoning with the ones provided in the articles, see Comment 2 and for the definition of “Strong customer authentication” in a generic and payment transaction specific way.Specific Comments:
Comment 1:
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. (DP Resoning 34)
According to Eurosmart, the implementations of eIDAS, PSD-2 and the EU Data Privacy regulation (as well as the NIS Directive on cyber security) have to be aligned, because products have to comply to them all. The underlying RTS (as well as the Implementing acts for eIDAS) have to take care of this (and not each product for its own). Therefore the resoning 34 should be changed according to a respective recommendation.
Comment 2:
The usage of the term “shall” and “should “as well as the requirements of authentication seem not to be constantly used within the resoning and the articles.
According to DP Reasoning 28/29: With regards to the definition of authentication elements categorised as knowledge, possession and inherence in in order to ensure technology neutrality and allow for the development of user-friendly, accessible and innovative means of payment, the EBA is of the view that there is no need to further define these authentication elements.
Yet according to (DP Reasoning 22) and Article 1.2 the strong customer authentication procedure shall include mechanisms to prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. Thereby the requirements of tamper resistant devices (DP Reasoning 25) as well as security and privacy features according DP Reasoning 26 should apply.
Eurosmart, is in favour to change the “should” to “shall“ in DP 25 as well as in compliance to 6.3.(a), (which actually sets strong requirement to authentication elements) because we do not envision, non tamper resistant devices“ with the property described in DP Reasoning 22 and DP Reasoning 26.
Tamper resistant shall meet all of the following requirements:
1) have mechanisms to protect the execution and integrity of its embedded software;
2) have mechanisms to protect the integrity of the user data stored within;
3) have mechanism to to ensure controlled execution and data integrity when oprating outside its specified operating conditions;
4) have mechanisms to protect against physical tampering and micro-manipulation;
5) The strength of all of these mechanisms must have been evaluated and certified in a (Common Criteria based) security certification.
For ensuring interoperability and ease the burden of implementation and security evaluation suitable standardized authentication protocols and privacy mechanisms should be referenced, see e.g. regarding the management and operation of tamper resistant devices the current Privacy Standard ISO/IEC CD 19286 or the European Industry Standard EN 419212 (former EN14890). Therefore we would be in favour to reference suitable standards in the RTS.
Comment 3:
According to Article 1.2 “The authentication code shall be characterized by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time”.
Eurosmart is in favour to change the above sentence in:
“The authentication code shall be characterized by security features including, but not limited to protocols, algorithm, length, information entropy, expiration time (and effective time, the latter, if a current date can be validated)”.
Reason: The term protocols are missing including referenced algorithms and data objects. (The expiration date can only validated, if certain measures on behalf of the ICCS or IFDS are provided, see e.g. the EAC Protocol in EN 419 212 or TR 03110-3.)
Comment 4:
According to Article 1. Article 1.2.(b), the term “generated for the same payer” should be deleted given that an authentication code should not be derivable from a previous one independent of the payer.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
According to Article 97(2) of the EU Directive, strong customer authentication includes elements which dynamically link the transaction to a specific amount and a specific payee. The additional condition of that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, is to be changed accordingly:“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be logically independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”
Addition in Article 6.3 a) the term “logical” is to be added in the underlying sentence.
a) The implementation of logical separated trusted execution environments inside the multi- purpose device;
Thereby the definition of Trusted Execution Environment is to be provided (according to Global Platform or more generic?).
Reason:
The article should address the issue of logical independence" of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device, if this device provides respective security means, e.g. by certification."
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?
Eurosmart agrees, but would include in Article 3 and 4 besides algorithm the use of suitable cryptographic (proven) standardized protocols which uses respective asymmetric or symmetric algorithms with keys providing state of the art key length (according to algorithm catalogues e.g. BSI, ANSSI, ENISA, ETSI) and include in particular anti-cloning features to offer resistance against the risks of forging and cloning of the elements.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?
Eurosmart and Smart Payment Association (SPA) have aligned their answers and thereby Eurosmart fully supports SPA argumentation regarding this question.Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Eurosmart and Smart Payment Association (SPA) have aligned their answers and thereby Eurosmart fully supports SPA argumentation regarding this question.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?
Eurosmart agrees on the need if confidentiality and the integrity of the payment service users’ personalised security credentials and fully agrees with the proposal in Chapter as for instance article 9.1.c): Secret cryptographic material related to the encryption of the credentials is stored in secure and tamper resistant devices and environments.Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
NAQuestion 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
NAQuestion 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
Eurosmart agrees that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices with a respective capability (such as computers, tablets and mobile phones), but would as well emphasise the need of respective E2E device authentication protocols regarding eID management and remote administration regarding for tamper resistant devices in charge of all sensitive keys as encipherment keys and keys ensuring the integrity (authenticity).Together with the referred generic privacy requirement, the qualified trust services, especially the seal services, are described very explicitly in the eIDAS regulation fulfilling data originality and data integrity to be applied for legal persons as e.g. AIS, PIS and ASPSDs. The gain of this new concept is that qualified seals are accepted as such European–wide and cannot be interpreted differently as it was the case with qualified signatures before, as substitute for “handwritten signatures”.