Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

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?

Article 1-3(c) should NOT apply to devices which have been previously registered with the ASPSP and which have not been compromised. Otherwise, you are allowing an attacker to lock me out of my account. Furthermore, since any well designed system would use strong cryptography, there is absolutely no benefit to lock someone out of an account for more than 1 second because there are so many combinations, a hacker could never breach the account. The simplest way to address this is that, if all authentication uses high entropy digital signatures for authentication, Chapter 1, Article 1, pgf 3(c) should not apply.

In article 2, you should clarify that the amount approved could be a maximum amount and that if the payee elects to capture a lesser amount, that should NOT require an additional authorization. For example, if I order 10 items at Amazon, I should only have to authorize the total amount of the transaction ONCE, and Amazon can capture funds several times so long as the total sum of all captured amounts are less than or equal to the approved amount. This might be the case if Amazon ships in several drop shipments instead of a single shipment.

Also, two questions arise that would be nice to clarify:

1) For 2FA, if push notifications to a mobile phone requesting approval is used, and the phone is locked, will unlocking the phone and tap approve" suffice to meet the 2FA requirements (possession of the phone and unlock code)? Or must the phone be unlocked and then again 2 factor authenticated?

2) If an ASPSP interacts DIRECTLY with a merchant so that the ASPSP is the same as the PSP, does SCA still apply?"

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.

No, we STRONGLY disagree about channel separation if the dynamic linking is accomplished using digital signatures in which the amount and payee are signed by multiple private keys of the payer. In that case, use of different channels is unwarranted and leads to unnecessarly poor user experience. For example, I can have extremely secure 3 factor auth on a single mobile device using 3 digital signatures which provides BOTH multi-factor auth AND non-repudiation.

Your restriction would eliminate my ability to make secure purchases on my mobile phone. To meet your requirements, I would have to carry around a laptop with my phone. Or if SMS is considered a different “channel” then that would force us to use an insecure method.

Furthermore, this is forcing a code to be “displayed”. Token uses digital signatures to sign the transaction. The transaction is displayed to the user, but NOT the dynamic code itself (the digital signature) since this would look like random text to a user. Using digital signatures is the safest way to create unique codes that can be used to prove the user approved the transaction.

Our suggestion is that you encourage the use of digital signatures for authorization by exempting authorization codes done using digital signatures from both the “out of band” transmission requirements and the display requirement. It is nonsensical to display a digital signature to a user.

Modern, secure authentication systems should never use authentication codes because these codes require the use of shared secrets in order to authenticate the result by the relying party. Anytime you have shared secrets, you run the risk of a MASS BREACH at the relying party (the holder of the shared secrets used for code validation) and you also forfeit any non-repudiation ability as well.

By forcing the use of displayable authentication codes instead of digital signatures, you are creating a large security hole. An objective of PSD2 is to move the ball forward on security, not mandate the use of old fashioned, insecure methods.

Authentication codes prove nothing. What we want is unambiguous proof that the buyer actually approved the transaction. The best way to do that, by far, is through digital signatures of the payee and amount done with private keys that never leave the buyer’s device. The regulations should strongly encourage this method.

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?

No

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?

No. Everyone we’ve talked to says the 10/100 euro limit is ridiculously low. If you must set a hard limit, then start high and allow member states to lower it.

The ASPSP should be able to both enforce the PSP to do SCA anytime the ASPSP has good reason to believe there is fraud, and also to waive SCA anytime it believes the transaction is safe. This is reasonable because the ASPSP would bear the liability if it set the threshold too high.

It would be reasonable for the EBA to force SCA for very high dollar purchases, e.g., 1000 EUR or more. But below that, we believe that the ASPSP should be able to determine when a PSP is required to use SCA. The ASPSP will set the limit based on history of the PSU, the device, the payee, and the amount.

Because the ASPSP is liable for the loss in such a case, the ASPSP should be free to trade-off losses for lowering the friction of the transaction. Only in the event that there is a consistently unacceptably high level of fraud losses, should the ASPSP be forced by the regulator to lower the limits for SCA.

This provides strong incentive for the ASPSP to develop low friction ways to control fraud which benefits all parties.

The short answer is, let the free market work to reduce fraud at minimal friction and only enforce strict dollar limits on a particular ASPSP, if the ASPSP fails to keep fraud losses under a certain threshold. The ASPSP should report fraud losses to the regulator.

Such techniques (specifying the target fraud loss before sanctions are imposed) have been used with great success in the card business. If your chargeback % is above a certain threshold, a merchant may lose their merchant ID. This allows each merchant a wide range of options to control fraud losses.

The 10 / 100 euro strict thresholds are much too strict of a requirement to achieve the goal. The EBA has not referenced any studies in support of those threshold numbers.

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?

It includes the “established relationship” exemption, which is good. But 10/100 hard limits are way too strict. If you must set absolutely hard limits, set them at 1000 EUROs, and give the ASPSP the ability to set the threshold to achieve a fraud threshold set by the regulator in that member state. That way, friction is minimized while keeping fraud under control and encourage innovation in reducing fraud that does not impact the purchase completion rate.

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?

It’s OK, but the EBA should strongly encourage the use of public key cryptography to authenticate to the PISP, relieving the PISP of storing any secrets at all. Anytime a 3rd Party stores secrets, even if encrypted, there is the risk of mass breaches.

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?

There are pros and cons with standards. For example, Oauth2 is a standard, but as correctly pointed out in wikipedia, “The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.”

The use of standards should be encouraged, but where there is a protocol that is clearly documented, demonstrably superior to official standards and adopted by several ASPSPs and thus a “de-facto standard”, those technologies should be allowed. It is critical for the development of better security protocols that such technologies can be deployed by ASPSPs without being official standards.

Our recommendation is that the EBA encourages standards, but doesn’t strictly require them.

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 20222 was designed for communication of payment instructions, not for authentication and authorization.

For example, Token’s system uses advanced digital cryptography using Ed25519. There is no provision in ISO 20022 for the communication and verification of such digital signatures.

It would be better to strongly encourage the use of standards like ISO 20022, but not require them. This gives member states the ability to tighten up this requirement IF NECESSARY to move the industry forward.

By requiring ISO 20022, you’d be excluding solutions that can offer greater simplicity to all parties. That would be a barrier to widespread adoption. For large enterprises and ERP systems, ISO 20022 makes perfect sense. But for smaller organizations, a lightweight JSON protocol that gets wide adoption would be a vastly superior solution for all parties.

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 ?

Yes, but if there are no such providers available as noted in #74, a fallback to Option 2 should be allowed. When providers become available, there should be at least 6 months allowed for the switchover.

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.

Token believes the upper limit should be defined by each ASPSP. For example, if the ASPSP charges for each information request, the ASPSP might WANT to set the limit to be very high and/or adjust it dynamically as required. This benefits all parties. Establishing that each ASPSP shall have a lower limit that it must support is reasonable. In this case, if an AISP has 12 users at a bank, it would be limited to 24 requests a day unless the bank chooses to allow more frequent access. This limit would be easy for a AISP to discover by making more than 2 API requests per day and seeing what happens or by making an API call to discover the limit.

Please select which category best describes you and/or your organisation

[Other "]"

If you selected "Other", please provide details

Software provider

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

software services

Name of organisation

Token