In principle we agree with the reasoning and resultant provisions. We are concerned about the potential for confusion in the current text between the words authentication and authorization.
Authentication is the provision of assurance in the identity of an entity [ISO/IEC 18014-2], authorization is the granting of rights [ISO 15782-1:2009] to access a resource or perform an action.
The RTS has requirements around the principles of this “strong customer authentication”, when it is required and the different factors that required for it to be “strong”. The implementation of this will vary between different ASPSPs - the use of authentication in this context is correct.
The RTS mentions “authentication codes” multiple times - however these codes would be better described as “authorization codes”. They have the following requirements:
- Can only be accepted once
- No authentication element can be derived from the code
- It is impossible to generate a new code based on knowledge of a previous code
- The code cannot be forged
- For payment transactions, the code should be specific to a payee and an amount
- Any change to the amount or payee shall result in a change of the code
These codes are therefore one-time use codes that authorize a payment from an end-user payment account to a specific payee. They should only be generated after the end-user has been authenticated (i.e. their identity verified) and they have authorized the specific transaction.
We therefore strongly suggest that the EBA consider adjusting the draft to refer to these codes as “authorization codes” or more preferably as “authorization tokens”. Code has a very generic meaning, whereas “token” has more meaning in this context - tokens often conveys a set of “claims”.
While we understand the intent of the clause we believe the current wording is ambiguous. For example, does this mean that a transaction initiated on a phone could not be completed on that phone? Or does it mean that if it is started in an app, the auth screen should be in another app? If the transaction was started in a browser, is it sufficient for the information to be shown in a new tab?
Yes we have a concern with the details of the exemption for “purely consultative services”. The exemption would force the user of an Account Information Service to re-authenticate and re-grant access to that Account Information Service for each of the PSPs they want to connect every month. This would add a lot of friction to services such as personal finance management tools.
The Authorization standard that we are recommending requires that tokens (granting access) have a specific expiry datetime. But we caution against a maximum validity of 1 month.
Frequent re-authentication won't increase security - but it more likely to increase end-user apathy to the process.
We suggest that customers should be able to revoke access at any time - either via the AIS provider or via the online interface provided by the ASPSP. Existing federated authorization networks already work in this manner; as does the UK direct debit system.
AIS providers themselves will have to meet certain security, compliance and legal certifications in order to gain access to this data. AIS providers will have a strong legally enforceable responsibility to only use this data in the way to which the customer has granted them consent.
We suggest the length of access is a context-dependant variable - that ASPSPs should be able to determine according to perceived risk.
We agree on the requirements for common and secure open standards of communication. However we are concerned that the only standard mentioned is ISO20022.
In the aim to achieve common and secure open standards of communication it is useful to identify 2 distinct parts of a standard that would fulfil the requirements of PSD2 and the RTS:
- Data schema and transport protocol
- Authorization framework
Having a common standard for both parts would be beneficial, but in the absence of that, it is a common standard for authorization that would help ensure interoperability. OAuth2 is the industry leading authorization standard and is well suited for allowing end-users to authorize third parties to access end-user data or perform actions on behalf of the end-user.
It was recommended by the UK Treasury commissioned Fingleton Report:
It was recommended (in conjunction with OpenID Connect) by the UK Open Banking Working Group Report
It is the most commonly used framework for banks that have already implemented APIs, e.g. BBVA, Fidor, Monzo, AXA, Capital One, Česká spořitelna, etc.
We strongly suggest that the EBA consider specifying (or making reference to) OAuth 2 as an Authorization standard. It fulfils many of the requirements of the RTS. A divergence of authorization frameworks would severely hinder innovation.
There is a working draft of an OAuth 2 profile with security levels geared towards Financial APIs by the OpenID Foundation’s Financial API Working Group
This draft is on track to be adopted as an international standard.
The OpenID Foundation Financial API Working Group was proposed by Nat Sakimura (Nomura), Tony Nadalin (Microsoft), and Cindy Barker (Intuit) and was formed in early 2016. Its main aim to create an open standard for financial APIs - based on a REST/JSON model and protected by OAuth.
The OpenID Foundation is a non-profit international standardization organization that promotes OpenID Connect and related standards. Its members are key authors for many of the IETF standards relating to OAuth 2 and OpenID Connect.
The working group holds weekly meetings with attendance from key individuals from software houses, banks and fintech firms. Further details, public mailing list and meeting minutes for the working group are available here: http://openid.net/wg/fapi/
We believe that the FAPI WG is well placed to provide expertise in regards to secure token-based authorization standards for financial APIs. The OpenID Foundation has a solid track record in developing international open standards.
We view the current ISO20022 standard as wholly inappropriate to be used. The standard was designed for a different use-case than the ones proposed by PSD2. It has been successfully implemented for SEPA transfers - but these are between ASPSPs - not between an AISP / PISP and a ASPSP.
We strongly advise against it for the following reasons:
- It contains message definitions - aimed at asynchronous message queue systems - this is reasonable for inter-bank communication, but the wrong technology for an AISP communicating with a ASPSP.
- Its message definitions are geared towards payments - the scope of data required by an AISP is not currently supported within the standard
- ISO20022 is not designed for the “authentication code” flows proposed by PSD2 and the RTS.
- The format is heavyweight and obtuse - it will hinder innovation, especially for newer AISP and PISP entrants
- The use-cases and user-flows described in PSD2 and the RTS strongly suggest the use of an authorization standard (e.g. OAuth 2) and synchronous Web APIs (e.g. REST or SOAP). While a web-api could be put in front of an ISO20022 message based system - there is no standard for this and so any supposed benefits of interoperability would be lost.
- PSD2 should enable a large amount of AIS and PIS providers - this much larger ecosystem is much better suited by RESTful web apis protected by OAuth 2. The combination of REST and OAuth2 is already being used by leading banks such as BBVA, challenger banks such as Monzo and in many other industries.
- We believe that the recommendation of “website certificates” being used for authentication of AIS, PIS and ASPSP providers would work better in an OAuth2 / REST solution than in a message based system.
We have no comment on the proposed frequency limit. However we are not sure how an ASPSP will differentiate between an “active request” and an automated request.
The OpenID Foundation Financial API Working Group is part of the The OpenID Foundation, a non-profit international standardization organization that promotes OpenID Connect and related standards.