Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
No we need to distinguish between authentication and authorization :
- For authentication purposes we do not agree, the generated code is always accepted only once :
a. For classic web application usually generated something called sessionID (jsessionID, JWT…)
b. For new REST API/Mobile application based on Oauth protocol is generated access code / refresh token which is valid until token expire and/or refresh token expire.
- For authentication purposes we agree , the generated code is accepted only one by PSP
Please provide clear distinguish between authentication code (access code) and authorization code. More elaborate is needed
Article 1 (3) -> For Online Fraud we also need to distinguish between authentication and authorization.
Our question:
Can be as result of authentication procedure e.g. some sort of session ID like: JSESSIONID or Oauth access code / refresh token ?
Can we use two-step SCA procedure , when in case of second step it is clear that first step/element is correct. Is this approach inline with Article 1 (3,b)?
Who will define certified auditors?
What can we understand as only once when user is entering PIN on mobile application?
Can we apply as definition for sensitive payment data one that was introduced in EBA document on Security of Internet payments"?"
However the concept of independence is OK when we are talking about authorization code (not authentication code).
Our question:
Please provide more clarification what is a channel.
How to show client total amount and each several payee if the batch contains 100ths transaction e.g. big corporates? In relation to Article 2, Point 1, a)?
Please elaborate considered collectively?
We agree that behavioral data cannot be seen as standalone independent element. However we are planning to use them during both authentication and authorization procedure as additional data. With this data (mouse clicking, speed of writing, using of online services ) we can very precisely estimate that behind is correct user and based on this output we can decide (risk based approach) whether we require second factor or not to support user seamless experience (adaptive authentication / authorization).
Our question:
Did you consider sending SMS as possession element of SCA if there are some know flaws in SMS protocol?
Is access to the transaction history considered as sensitive payment data?
Risk based approach is the KEY FACTOR.
Article 8, 1, a, ii -> one month period shall be replace by RISK BASED approach.
Our question:
How to apply these principles stated in Article 12, b when onboarding new client via online channel (client is opening account online, not at branch)?
Is Article 9, 1 c, applied also to end user devices?
What is meaning in Article 15, c -> public repositories" -> certificates CRL?"
Article 17
Yes we agree. However clarification is needed how new certificates attribute will looks like. Each certificate per role (pips/ais/..) or one certificate with multiple roles?
Also mutual authentication is not must for OAuth, we can use as today one-way TLS.
Bilateral identification is mutual authentication, alias two-way TLS?
Article 18
NO comments
Article 19
We are of opinion that EBA will set some recommended protocols e.g.:
- JSON/REST (nowadays widely used in API , mobile applications and JS frameworks) as opposite to XML
- OAuth for authorization/authentication
- etc
ISO 20022 XML can be very resource consuming e.g. when nested
Also testing interfaces are not always available due to fact that they are using for development of next releases.
Article 19, point 6 -> Testing environments shall be excluded from the statements same level of SLA.
Article 20 -> will be another RTS regarding eIDAS registration, crl a procedures issued?
Our question:
How we will communicate with PISP/AIS regarding resolving client's claims? Will be introduced some central body?
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 (1)No we need to distinguish between authentication and authorization :
- For authentication purposes we do not agree, the generated code is always accepted only once :
a. For classic web application usually generated something called sessionID (jsessionID, JWT…)
b. For new REST API/Mobile application based on Oauth protocol is generated access code / refresh token which is valid until token expire and/or refresh token expire.
- For authentication purposes we agree , the generated code is accepted only one by PSP
Please provide clear distinguish between authentication code (access code) and authorization code. More elaborate is needed
Article 1 (3) -> For Online Fraud we also need to distinguish between authentication and authorization.
Our question:
Can be as result of authentication procedure e.g. some sort of session ID like: JSESSIONID or Oauth access code / refresh token ?
Can we use two-step SCA procedure , when in case of second step it is clear that first step/element is correct. Is this approach inline with Article 1 (3,b)?
Who will define certified auditors?
What can we understand as only once when user is entering PIN on mobile application?
Can we apply as definition for sensitive payment data one that was introduced in EBA document on Security of Internet payments"?"
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.
We are of opinion that Article 2 (1,2,3,4) is about authorization and not authentication. Please update it to use correct wording otherwise it is confusing. Authentication and Authorization are two different things. There is a difference between authentication code (access code) and authorization code.However the concept of independence is OK when we are talking about authorization code (not authentication code).
Our question:
Please provide more clarification what is a channel.
How to show client total amount and each several payee if the batch contains 100ths transaction e.g. big corporates? In relation to Article 2, Point 1, a)?
Please elaborate considered collectively?
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?
Answer:We agree that behavioral data cannot be seen as standalone independent element. However we are planning to use them during both authentication and authorization procedure as additional data. With this data (mouse clicking, speed of writing, using of online services ) we can very precisely estimate that behind is correct user and based on this output we can decide (risk based approach) whether we require second factor or not to support user seamless experience (adaptive authentication / authorization).
Our question:
Did you consider sending SMS as possession element of SCA if there are some know flaws in SMS protocol?
Is access to the transaction history considered as sensitive payment data?
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?
List of exemptions as state is OK, however EBA shall put more flexibility to ASPSPs to define their own exemptions based on client's risk profile.Risk based approach is the KEY FACTOR.
Article 8, 1, a, ii -> one month period shall be replace by RISK BASED approach.
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?
Yes, we have concerns that whit this exact list we are unable to bring our client seamless user experience. We would like to use adaptive authentication/authorization" approach"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?
In general yes we agree, however how to apply these principles stated in Article 12, b when onboarding new client via online channel (client is opening account online, not at branch)?Our question:
How to apply these principles stated in Article 12, b when onboarding new client via online channel (client is opening account online, not at branch)?
Is Article 9, 1 c, applied also to end user devices?
What is meaning in Article 15, c -> public repositories" -> certificates CRL?"
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?
We agree partially. The whole requirement is very high level describe to see technical implications for integration.Article 17
Yes we agree. However clarification is needed how new certificates attribute will looks like. Each certificate per role (pips/ais/..) or one certificate with multiple roles?
Also mutual authentication is not must for OAuth, we can use as today one-way TLS.
Bilateral identification is mutual authentication, alias two-way TLS?
Article 18
NO comments
Article 19
We are of opinion that EBA will set some recommended protocols e.g.:
- JSON/REST (nowadays widely used in API , mobile applications and JS frameworks) as opposite to XML
- OAuth for authorization/authentication
- etc
ISO 20022 XML can be very resource consuming e.g. when nested
Also testing interfaces are not always available due to fact that they are using for development of next releases.
Article 19, point 6 -> Testing environments shall be excluded from the statements same level of SLA.
Article 20 -> will be another RTS regarding eIDAS registration, crl a procedures issued?
Our question:
How we will communicate with PISP/AIS regarding resolving client's claims? Will be introduced some central body?