Torsten Lodderstedt is the CTO of yes.com, an open banking ecosystem. He discusses open banking prior to PSD2, including challenges like screen scraping. PSD2 obliges financial institutions to provide access to account information and payment initiation to authorized third parties. Beyond PSD2, different parties have differing interests. Identity is important for digital society. Financial institutions can leverage verified identity data as an identity provider and authentication service. OpenID Connect can represent verified identity claims with metadata for legal compliance and international interoperability. This representation allows for privacy-preserving inquiries.

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