Open Banking beyond PSD2 in the EU Torsten Lodderstedt - CTO,yes.com

1. Open Banking beyond PSD2 in
the EU
Torsten Lodderstedt
@tlodderstedt
yes®

2. Background
● Software Engineer (Ph.D in computer science) with strong interest in identity and security
● CTO at yes.com (open banking ecosystem)
● Before: quite some time in IT Consulting (public, banking, railway communication,
telecommunication), Consumer Identity Management at Deutsche Telekom
● Regular contributor to OAuth & OpenId
● Current focus: OAuth & OpenId for Open Banking & security-sensitive applications
● FAPI & eKYC & Identity Assurance WG, Editor of OAuth Security BCP, PAR & RAR & JARM

3. Open Banking prior PSD2
● Use Cases
○ Personal Finance Management (PFM)
○ Payment
○ Credit Rating
○ Identity Verification
● Technology
○ Screen Scraping, dedicated interfaces (e.g. HBCI/FinTS in Germany)
● Challenges
○ Screen Scraping is fragile, insecure, expensive
○ Interfaces not intended for web/app scenarios, credentials entered at the 3rd party
○ Liabilities unclear, security concerns, legal disputes

4. Payment Service Directive 2 (PSD2)
● EU Directive obliging any financial institution operating in the EU to provide
○ Access to Account Information (Accounts, Balances, Transactions) and
○ Payment Initiation
● to authorized third parties (TPPs) and
● to implement Strong Customer Authentication for any online access to
payment accounts
● Objectives: establish regulatory regime (liability), increase security, foster
innovation, reduce payments cost

5. ®
PSD2: 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
Within 18 months (until 14th of Sept. 2019)

6. PSD2: Status
● In transition phase, not fully operational from a customer’s perspective
● Lack of interoperability across financial institutions and member states
● Alignment among three major API initiatives under the Swift umbrella
○ OpenID Foundation/FAPI invited to contribute security profile

7. Beyond PSD2 (Scope)
● Different parties with different interests
● Merchants want better payment services (e.g. invoice, deferred, guaranteed)
● Regulator (EBA) wants EU-wide payment scheme based on current accounts
● Traditional TPPs want more data for identity verification, credit scoring &
payments risk assessment
Key Question: Willingness to Pay?
● Financial Institutions want a business case and leverage their tremendous
investments in the open banking infrastructure

8. Why is identity so important?
A digital society needs reliable digital
identities.
● eGovernment
● Access to Health Data
● Financial service (AML/CFT)
● Telecommunications
● Fraud prevention
● Risk mitigation

9. Bank Identity as a Service
● Financial Institutions verify and maintain identity data for every person
authorized for an bank account according to local anti-money laundering law
● This data is bound to online banking user accounts equipped with credentials
for multi factor authentication (SCA in the EU)
● User Account Lifecycle management in place
● Leveraging this assets as Identity Provider to 3rd parties is an opportunity to
provide new services to existing customers and to create a revenue stream
○ Authentication as a Service
○ High Level Identity Assurance
○ Further person-related data (e.g. credit score)

10. OpenID Connect
● Given most PSD2 APIs are based on OAuth, using OpenID to provide identity
services is the obvious choice
● Challenges with current state of the art
○ Lack of reach - not enough suitable claims sources
○ Lack of interoperability - e.g. data is interpreted based on implicit attestation
● OpenID Foundation has started WG to define OpenID Connect extension for
high-level Identity Assurance
● Suitable for all kinds of IDPs (governments, mobile operators, financial
institutions, …)

11. ®
OpenID Connect 4 Identity Assurance
● Current Draft:
https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
● Representation for verified claims and associated metadata & evidence
● Enables legal compliance for relevant use cases
● Adopted as Implementer’s Draft

12. ®
Explicit Attestation
● Trust framework the IDP complies with
● Time of verification
● Verifier: what party verified the user‘s identity
● Evidence: which evidence where used
● Verification Method: how were the evidence verified

13. ®
Verification Data Structure (Example)
German Anti-Money
Laundering Act
Physical In-Person
Proofing
External Verifier
on behalf of IDP
Proofing via ID
Card

14. ®
International
● Specification includes (growing number) of pre-defined
identifiers for
○ Trust frameworks, e.g. eIDAS, NIST 800-63A, Japanese &
German AML
○ Identity documents, e.g. ID Card, Passport, Driving Permit
○ Verification Methods, e.g. „Physical In-Person Proofing and
„Supervised remote In-Person Proofing“
● So far contributions from UK, US, CA, DE, and JP
● Looking for even broader group of participants!

15. ®
No Ambiguities
● Claims with attestation are represented in data
structure along with verification metadata
● Also allows to use existing OpenID Connect Claims
alongside verified claims in the same transaction

16. ®
Example
Standard OpenID Connect
Claims
verified_claims
integrated data
structure

17. ®
Privacy Preserving
● RP asks for individual Claims and Verification data elements
● Purpose of inquiry can be conveyed (per transaction or individual claim)

18. ®
Example Request
Required trust framework:
eIDAS Identity Assurance Level
„substantial“
Requested user
claims
evidence type and and verification
method
but not the evidence itself

19. ®
Versatile
● Representation can be used in a variety of channels (even beyond
OpenID Connect):
○ ID Token
○ User Info
○ Access Tokens
○ Token Introspection Responses

20. ®
Status
● Initial contribution based on implementation experience at yes.com
● Draft quickly evolved through international contributions
● Several implementations of the current draft in progress
● Set up dedicated working group for Identity Assurance
○ Please join!

21. Q&A!
Latest Drafts & Publications
OpenID Connect 4 Identity Assurance
https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
OAuth 2.0 Security Best Current Practice
https://tools.ietf.org/html/draft-ietf-oauth-security-topics
OAuth 2.0 Pushed Authorization Requests (PAR)
https://tools.ietf.org/html/draft-ietf-oauth-par
OAuth 2.0 Rich Authorization Requests (RAR)
https://tools.ietf.org/html/draft-lodderstedt-oauth-rar
JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
https://openid.net/specs/openid-financial-api-jarm-ID1.html
Cross-Browser Payment Initiation Attack
https://cutt.ly/cross-browser-payment-initation
Dr. Torsten Lodderstedt
CTO, yes.com
torsten@yes.com
@tlodderstedt
yes®
Talk to me about
- OpenID Connect 4 Identity Assurance
- OAuth Security Best Practices & FAPI
- The OAuth Security Workshop
- Other emerging OAuth & OpenID stuff
- Partnering with and working at yes.com