The Payment Service Directive 2 (PSD2) is a huge leap forward for Open Banking as it obliges every financial institution operating in the European Union to provide APIs for Access to Account Information and Payment Initiation. The need for more then six thousand financial institutions to provide APIs caused a tremendous push forward for financial API design and accompanying authorization and authentication technologies. Based on the experiences gathered while supporting some of the PSD2 API initiatives in the context of OpenID Foundation’s FAPI working group, this talk will give an introduction to PSD2 and related technical standards, dig into some remarkable aspects of authorization for financial APIs and points out the potential impact on the future of OAuth.
Identiverse: PSD2, Open Banking, and Technical Interoperability
1. ®
PSD2, OPEN BANKING, AND
TECHNICAL INTEROPERABILITY
Dr. Torsten Lodderstedt, yes.com
@tlodderstedt
2. ®
What is PSD2 all about?
Any financial institution operating in the EU is required to
• provide the following services to trusted third parties (TPPs):
• Access to Account Information (Accounts, Balances, Transactions)
• Payment Initiation
• implement Strong Customer Authentication for any online
access to payment accounts
Objectives: Foster innovation, reduce payments cost, increase
security
Payment Services Directive 2
3. ®
The Big Picture
European Union 28 Member States
PSD2
RTS
Regulatory
Technical
Standards
Local Law
Technical Standards
STET, BG, UK OB, Polish API, …
Financial-Grade API WG
(profile & support)
About 6000 Financial
Institutions
4. ®
Commonalities
• Functional
• Account Information for debit and credit accounts
• SEPA* (Instant) Credit Transfer
• Technical
• HTTP(S)
• JSON
• Support for OAuth 2.0 (or sort of)
* Single Euro Payments Area
(=28 Member States of EU plus Iceland, Norway, Liechtenstein, Switzerland, Monaco, and San Marino)
5. ®
Differences
• Functional
• Regional specialties
(e.g. settlement systems, tax payments)
• Different scopes (e.g. partial payments, interests)
• Technical
• XML support
• Message Signing
• Payment initiation
• API Access Authorization (SCA* modes)
*Strong Customer Authentication
7. ®
Embedded Mode
• TPP has full UI control, forwards credentials to financial institution
• Trains users to enter credentials everywhere but regulatory compliant
• Not compliant with FIDO 2.0/webAuthn security model (different origins)
• Supported by: NextGenPSD2
User ASPSPTPP
Service usage
Dynamic 2nd Factor (out of band)
Credentials,
Authorization,
API access
Credentials
8. ®
Decoupled Mode
• TPP controls UI on „consuming“ device, SCA conducted out of band via banking app
• TPP does not process credentials but User IDs
• No SSO across TPPs
• „Facilitates“ session fixation kind of attacks
• Beneficial in Point of Sales and Kiosk scenarios
• Supported by: NextGenPSD2, UK Open Banking (planned), Polish API
User ASPSPTPP
Service usage
(Strong) Customer Authentication
Authorization,
API accessUser ID
9. ®
ASPSP
User TPP
Redirect Mode
• NextGenPSD2: proprietary, OAuth
• UK OB: OpenID Connect/ FAPI RW
• STET: proprietary + OAuth elements
• CZ: OAuth + proprietary PIS authz flow
• SK: OAuth + OpenID Connect
• PL: customized OAuth
Observations:
• Security issues with most home grown
and customized solutions
• Customization due to special authorization
requirements
Service usage
API accessAuthorization
11. ®
Requirements from RTS on SCA
• Consent: customer consent is required, either for individual
requests or as mandate for designated payment accounts
and associated payment transactions
• Dynamic Linking: payment initation requests must must be
bound to amount and payee as approved by the customer
13. ®
(Selected) Solutions in the PSD2 Wild
• external resource (payment or consent),
reference in (dynamic) scope value, e.g., pis:12345678 (NextGenPSD2)
• external resource,
reference in consent_id claim in claims parameter in signed request
object
(UK OB)
• static scope values + JSON-based scope_details request parameter,
OAuth authorization request as HTTP POST to AS, which returns
transaction redirect URL (PL)
Have a look at: https://cutt.ly/oauth-transaction-authorization
14. ®
Identity Standards for Open Banking
• OAuth 2.0 Security Best Current Practice
• Mutual TLS for OAuth 2.0
• FAPI Profile including conformance tests
• NEW: JWT-protected Authorization Response Mode (JARM)
• NEW: Client Initiated Backchannel Authentication Profile (CIBA)
• NEW: Pushed Request Object
• UPCOMING: rich authorization requests aka „structured scopes“
15. ®
Q&A!
Latest Drafts & Publications
OAuth 2.0 Security Best Current Practice
https://tools.ietf.org/html/draft-ietf-oauth-security-topics
OpenID Connect 4 Identity Assurance
https://openid.net/specs/openid-connect-4-identity-assurance.html
Transaction Authorization or why we need to re-think OAuth scopes
https://cutt.ly/oauth-transaction-authorization
JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
https://openid.net/specs/openid-financial-api-jarm-ID1.html
Financial-grade API: Pushed Request Object
https://cutt.ly/pushed_request_object
yes®
Talk to me about
- OAuth & OpenID in financial services
and electronic signing
- OAuth Security
- Other emerging OAuth & OpenID stuff
- Working at yes.com
Editor's Notes
…
SCA –> 2FA with tight binding to certain transaction
…
Should be easy, shouldn’t it? Define an API and utilize OAuth for access authorization.
Well, it turned out that “traditional OAuth” couldn’t fulfil the requirements regarding security and authorization. You will learn in the course of this talk what that means and how solutions look like.
And there is another reason why I’m so fascinated by PSD2 … it’s just impressive!
As a directive of the EU, it is binding for all 28 member states and every of those member states has to implement it within ist local law, several member states also developed their own technical standards. And those technical standards have been implemented by all finanical institutions operating in the EU.
What do you think? How many finanical institiutions are affected?
It‘s about 6000 – and the jpb needs to be done within a 18 months time frame!
I think it‘s fair to say this will create the world‘s biggest API ecosystem. And I had the plausure to be involved along with OpenID Foundations FAPI WG as we were supporting some of the technical standardization initiatives.
Differences, commonalities, what we can learn for other industries and the future evolution of oauth
Not that much …
The functional scope is centered around account information for credit and debit transfer and there is at least support for the two SEPA variants of credit transfer. I would like to point out; That does not mean the API is the same.
From a technical standpoint, well yeah, everything is based on HTTPS and (mostly) JSON
But when it comes to the authorization piece there is not so much commonalities beside that fact most standards support use of oauth to certain degree – I will dig into some reasons for this later on
… Interoperability? Not in the short term …
API Access Authorization
- it‘s quite amazing to learn the different ways to perform SCA
Let‘s take a look into this aspect
On a conceptual level, one can distinguished three SCA modes can be: embedded, decoupled and redirect (which also encompasses Oauth & OpenID)
That‘s what everybody including me expected to see as the authorization protocol
Redirect to ASPSP, 2FA, consent, redirect back
BUT … no one uses plain Oauth with static scope values as we know it from the past – some even don‘t use oauth at all
What we have seen are ..