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.

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

6. ®
SCA Modes

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

10. ®
Authorization Information
in Financial APIs
ASPSPTPP
Authorization Information

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

12. ®
Authorization Information
{
"instructedAmount":{
"currency":"EUR",
"amount":"123.50"
},
"debtorAccount":{
"iban":"DE40100100103307118608"
},
"creditorName":"Merchant123",
"creditorAccount":{
"iban":"DE02100100109307118603"
},
"remittanceInformationUnstructured":"Ref Number Merchant"
}
Challenge:
More dynamic and complex than currently supported by OAuth through scopes

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