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"?"
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?
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?
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.
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"
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?"
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?