Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
SPA agrees that generalizing the strong customer authentication (SCA) process minimizes the risk of customer impersonation. Furthermore, these requirements for SCA preserve the real freedom of choice of a particular payment instrument. However, the exemptions regime should be extended - Please refer to our answer to Q4.
Art 1.2 Reformulate as: « The authentication code shall be characterized by security features ensuring that : »
Rationale: this is a non exhaustive list that mixes security and non-security properties in an inconsistent and confusing way.
Art 1 3(b) refers to « incorrect » . The meaning of this term is unclear. Do you refer to failure to authenticate the customer whatever the reason?. At present in card F2F payment transactions, the CH is informed in real time if the entered PIN code was wrong. More clarification for management of knowledge-based authentication elements is needed.
As follows
In Art 1.2 (b) remove the last part of the requirement « for the same payer »
Art 2.2 (b). Replace the current requirement by: « The technical solution used to generate the authentication code shall guarantee that the data displayed to the customer (amount, payee) are identical to those used to generate the authentication code and to execute the payment. This could be achieved by e.g. is if the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction as well as an evaluated and certified device with a suitable security assurance level ».
Art 5.1 complete the last sentence by adding( : « as well as an authorized party being rejected ».
Art 3(d) HTTP over TLS should be mentioned as an example not a requirement ( technological neutrality principle)
Art 2.3 Implementation of Art 2.3 and 2.4 may be difficult if the data used to calculate the authentication code ( using dynamic linking) is different from the final amount to be paid. In this case we recommend to add an additional requirement stating that: « the data used during the dynamic linking shall be transmitted along with the payment amount in the authorization message ».
Some further clarification is required in the provisions of Article 6
Article 6 paragraph 1 refers to the the term « reliability » which is not appropriate, even if consistent with Article 4(30) of the PSD2 . Reliability is a term indicating the probability of good operation of a device at a given time «T » assuming that the device is functional at time « 0 », when the device is working in a pre-established physical environmental, not being hacked. Formaly speaking, the terms used in the definition of SCA proposed by SecurePay were more accurate: « …. The breach of one authenticator does not impact the level of security of the other authenticator .
Article 6 paragraph 3 refers to the fact that mobile devices and tablets shall « implement a separated trusted execution environment ». This point should be further clarified, especially considering that all mobile devices used to pay include some kind of « separated » execution environment. However these executions environments don’t feature the same security properties( e.g, a certified hardware tamper resistant device vs a software implementation).
Therefore the term « trusted execution environment » should be defined and how the « independence of elements » applies in that scenario. In particular if the term « separated » is equivalent to « independent from the security point of view ».
The statement « ..including but not limited to mobile phones and tablets » should be rewriten as « multipurpose devices, e.g. mobile devices and tablets ». This comment applies as well to others articles, where the references to specific devices should clearly indicate that they are just examples.
This neutrality could be better expressed with a requirement such as : the « dynamic linking » procedure should guarantee that the information used to generate the authentication code is the same than the payment information displayed to the payer (refer to Q1).
At the same time « independent or segregated » are ambiguous terms that should be defined. In the way it is expressed, the requirement seems to counter the risk of a man-in-the-middle attack in online payment contexts or to prevent relay attacks for contactless transactions
An example is a card generating a dynamic code which is displayed and then can either be entered manually for an e-commerce transaction or being transmitted from a mobile application.
Because a contactless card cannot be forged, a contactless transaction can only be executed with a legitimate card. However this card can be used to pay an amount under 50 Euros by anyone being in possession of the card.
A card generating a dynamic code, proves to the issuer that the payer is in possession of a legitimate card to pay. From the risk point of view, the situation is similar to the case of the contactless card, provided that the dynamic code is encrypted. Moreover, the issuer in that case can proceed to a risk management procedure that will provide additional evidence that the payer is likely the cardholder. Therefore from the security point of view it’s not justified that a contactless card may benefit from exemptions while a card using a dynamic code would not.
The amounts 10 Euros, 50 Euros, 100 and 150 Euros appear arbitrary and likely to be subject to frequent future changes. These thresholds should be regularly reviewed and adapted by the EBA.
Art 8.2 (a) to ( c ) vs Art 8.2(d) benefits the use of credit transfers for remote payments and discriminates other payment Binstruments, infringing the principle of « technological neutrality ».
Can the same PSC be bound with different payment instruments issued by the same PSP?
We suggest to add the term « sensitive data » Art 9 1.b « Sensitive Personalized Security Credentials »
Art 19.2 ( c ) Authentication codes may already be cryptographically protected. It seems as if Art 19 refers to security at the Transport Layer level protocol.
The technical constraints are twofold:
First is the fact that at present there are few ISO 20022-compliant implementations
Second: ISO 20022 is a collection of data elements and messages not a protocol meaning that by itself ISO 20022 doesn’t guarantee fully interoperability.
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”
SPA provides the industry with accurate figures on payment cards sales worldwide.
SPA is an active contributor in financial standards-setting organizations , including the ECSG, EMVCo, PCI , ISO TC68 and IUT-T Focus Group on Financial inclusion
and systematically participates in public consultations on draft regulatory texts having an impact on the retail payment industry.
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?
SPA supports the needs to protect the consumer at a time when a broad range of new technologies are available to pay.SPA agrees that generalizing the strong customer authentication (SCA) process minimizes the risk of customer impersonation. Furthermore, these requirements for SCA preserve the real freedom of choice of a particular payment instrument. However, the exemptions regime should be extended - Please refer to our answer to Q4.
Art 1.2 Reformulate as: « The authentication code shall be characterized by security features ensuring that : »
Rationale: this is a non exhaustive list that mixes security and non-security properties in an inconsistent and confusing way.
Art 1 3(b) refers to « incorrect » . The meaning of this term is unclear. Do you refer to failure to authenticate the customer whatever the reason?. At present in card F2F payment transactions, the CH is informed in real time if the entered PIN code was wrong. More clarification for management of knowledge-based authentication elements is needed.
As follows
In Art 1.2 (b) remove the last part of the requirement « for the same payer »
Art 2.2 (b). Replace the current requirement by: « The technical solution used to generate the authentication code shall guarantee that the data displayed to the customer (amount, payee) are identical to those used to generate the authentication code and to execute the payment. This could be achieved by e.g. is if the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction as well as an evaluated and certified device with a suitable security assurance level ».
Art 5.1 complete the last sentence by adding( : « as well as an authorized party being rejected ».
Art 3(d) HTTP over TLS should be mentioned as an example not a requirement ( technological neutrality principle)
Art 2.3 Implementation of Art 2.3 and 2.4 may be difficult if the data used to calculate the authentication code ( using dynamic linking) is different from the final amount to be paid. In this case we recommend to add an additional requirement stating that: « the data used during the dynamic linking shall be transmitted along with the payment amount in the authorization message ».
Some further clarification is required in the provisions of Article 6
Article 6 paragraph 1 refers to the the term « reliability » which is not appropriate, even if consistent with Article 4(30) of the PSD2 . Reliability is a term indicating the probability of good operation of a device at a given time «T » assuming that the device is functional at time « 0 », when the device is working in a pre-established physical environmental, not being hacked. Formaly speaking, the terms used in the definition of SCA proposed by SecurePay were more accurate: « …. The breach of one authenticator does not impact the level of security of the other authenticator .
Article 6 paragraph 3 refers to the fact that mobile devices and tablets shall « implement a separated trusted execution environment ». This point should be further clarified, especially considering that all mobile devices used to pay include some kind of « separated » execution environment. However these executions environments don’t feature the same security properties( e.g, a certified hardware tamper resistant device vs a software implementation).
Therefore the term « trusted execution environment » should be defined and how the « independence of elements » applies in that scenario. In particular if the term « separated » is equivalent to « independent from the security point of view ».
The statement « ..including but not limited to mobile phones and tablets » should be rewriten as « multipurpose devices, e.g. mobile devices and tablets ». This comment applies as well to others articles, where the references to specific devices should clearly indicate that they are just examples.
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.
It’s is unclear to what kind of neutrality Article 2.2 refers to. The same applies to the concept of « channel » (logical ? physical ?).This neutrality could be better expressed with a requirement such as : the « dynamic linking » procedure should guarantee that the information used to generate the authentication code is the same than the payment information displayed to the payer (refer to Q1).
At the same time « independent or segregated » are ambiguous terms that should be defined. In the way it is expressed, the requirement seems to counter the risk of a man-in-the-middle attack in online payment contexts or to prevent relay attacks for contactless transactions
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?
Article 5 properly refers to the need the « inherence element » guarantees a « sufficient low likehood » of an unauthorized party being authenticated as the legitimate enrolled user. This « sufficient low likehood » should be proven by the compliance of the inherence element with the performance requirements set forth by international standards.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?
The list of exemptions should be extended to an additional scenario, « enhanced authentication » for efficient fraud reducing technologies, having proven value in field .An example is a card generating a dynamic code which is displayed and then can either be entered manually for an e-commerce transaction or being transmitted from a mobile application.
Because a contactless card cannot be forged, a contactless transaction can only be executed with a legitimate card. However this card can be used to pay an amount under 50 Euros by anyone being in possession of the card.
A card generating a dynamic code, proves to the issuer that the payer is in possession of a legitimate card to pay. From the risk point of view, the situation is similar to the case of the contactless card, provided that the dynamic code is encrypted. Moreover, the issuer in that case can proceed to a risk management procedure that will provide additional evidence that the payer is likely the cardholder. Therefore from the security point of view it’s not justified that a contactless card may benefit from exemptions while a card using a dynamic code would not.
The amounts 10 Euros, 50 Euros, 100 and 150 Euros appear arbitrary and likely to be subject to frequent future changes. These thresholds should be regularly reviewed and adapted by the EBA.
Art 8.2 (a) to ( c ) vs Art 8.2(d) benefits the use of credit transfers for remote payments and discriminates other payment Binstruments, infringing the principle of « technological neutrality ».
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?
We don’t believe that the RTS should prevent a PSP to execute a SCA procedure even if the transaction falls under any of the exemptions set forth in Chapter 2.Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
The rationale for the protection of the confidentiality and the integrity of Personal Security Credentials (PSC) is correct, because according to Chapter 3, the security of the payment relies on the security of the PSC. With this regard, Chapter 3 includes provisions covering the overall operational life of the PSC and therefore can be considered as complete.Can the same PSC be bound with different payment instruments issued by the same PSP?
We suggest to add the term « sensitive data » Art 9 1.b « Sensitive Personalized Security Credentials »
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?
Art 17.1 as written excludes the current card-based EMV payment systems which only support unilateral authentication of the card.Art 19.2 ( c ) Authentication codes may already be cryptographically protected. It seems as if Art 19 refers to security at the Transport Layer level protocol.
Question 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?
ISO 20022 constitutes a step forwardThe technical constraints are twofold:
First is the fact that at present there are few ISO 20022-compliant implementations
Second: ISO 20022 is a collection of data elements and messages not a protocol meaning that by itself ISO 20022 doesn’t guarantee fully interoperability.
Question 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 ?
SPA 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”
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
SPA has not a particular position on this point.Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
The Smart Payment Association (SPA) is an organization composed of the 6 major card payment manufacturers: Austria Card, Gemalto, Giesecke&Devriendt, Incard, Morpho and Oberthur to collaborate in standardization activitiesPlease select which category best describes the services provided by you/your organisation
[Other"]"If you selected "Other", please provide details
SPA provides regularly with freely accessible white papers and paper positions in areas of interest for the retail payments industrySPA provides the industry with accurate figures on payment cards sales worldwide.
SPA is an active contributor in financial standards-setting organizations , including the ECSG, EMVCo, PCI , ISO TC68 and IUT-T Focus Group on Financial inclusion
and systematically participates in public consultations on draft regulatory texts having an impact on the retail payment industry.