The OpenID Foundation and the Open Identity Exchange co-hosted an Open Banking Workshop on Tuesday, January 30, 2018 in London. This presentation is an update on the Open Banking initiative that was presented by members of the Open Banking Implementation Entity (OBIE).
OpenID Foundation/Open Banking Workshop - Open Banking Update
1. Open ID Foundation / Open
Banking Workshop
30 Jan 2018
Chris Michael – Head of Technology OB
Gary Farrow – Head of Architecture OB
2. 2
Open ID Foundation Workshop
Session Agenda
1. An introduction to UK Open Banking
2. RTS challenge
3. Alternative authentication flows
4. Discussion
3. 3
Open ID Foundation Workshop
The Open Banking Implementation Entity (OBIE)
OBIE was set
up by the
CMA
in September
2016
A world leader
in the
implementation
of the Open
Banking
Remedies,
assisting in the
delivery of the
first APIs
A private body
whose
governance,
composition
and budget
was
determined by
the CMA
Funded by the
CMA 9 and
overseen by the
CMA, the
Financial
Conduct
Authority (FCA)
and Her
Majesty’s
Treasury
Tasked with delivering the Open Banking API standards and security framework
The CMA9 are the UK’s nine largest current account providers: AIBG, Bank of Ireland, Barclays, Danske,
HSBC, Lloyds Banking Group, Nationwide, RBS and Santander
4. 4
Open ID Foundation Workshop
The Open Banking Timeline
March
2017
Open Data
v1 API
standards
published
August 2017
Open Data v2
API standards
published
13 January 2018
PSD2 comes into effect
July 2017
Read / Write v1
API standards
published
October 2017
Open Banking
Directory
enrolment begins
January 2018
Open Banking go-live:
Secure access to
personal and business
current accounts
available to authorised
parties
OB Roadmap
5. 5
Open ID Foundation Workshop
API Standards
Open Data
• ATMs
• Branches
• Personal Current Accounts
• Business Current Accounts
• SME Lending
• SME Credit Cards
Closed (Read/Write) Data
• Account Info & Transactions
• Payment Initiation
Version 1 limited to:
• UK PCA and BCA accounts
• In GBP
• Single Immediate Payments
Security Profile
• Based on OAuth2
• And OIDC, specifically the
OIDF’s FAPI Profile
• TLS MA
• JWS
6. 6
Open ID Foundation Workshop
The Open Banking Directory
OB Directory
FCA / NCAs
Participants
(ASPSPs and TPPs)
Registration
Enrolment Validation
Identities
Software Statements
Digital Certificates
Self-Service
1
2 2
3
7. 7
Open ID Foundation Workshop
Customer Journey – Consent & Authorisation Model
STEP 1
Consent
STEP 2
Authentication
STEP 3
Account
Selection
STEP 4
Authorisation
• The Open Banking solu1on mandates a consent and authorisa.on model
• Steps 1, 2 and 4 must always be present
• The Domain (TPP or ASPSP) in which these ac1ons are undertaken may differ
• The order of the processing may change
Domain : TPP Domain : ASPSP Domain : TPP or ASPSP Domain : ASPSP
9. 9
Open ID Foundation Workshop
The RTS Challenge
Article 32.3
Account servicing payment service providers that have put in place a dedicated
interface shall ensure that this interface does not create obstacles to the provision
of payment initiation and account information services.
Such obstacles, may include, among others,
• preventing the use by payment service providers referred to in Article30(1) of the
credentials issued by account servicing payment service providers to their
customers,
• imposing redirection to the account servicing payment service provider's
authentication or other functions,
• requiring additional authorisations and registrations in addition to those provided
for in Articles 11, 14 and 15 of Directive2015/2366,
• or requiring additional checks of the consent given by payment service users to
providers of payment initiation and account information services.
11. 11
Open ID Foundation Workshop
Embedded
1. Consent to Payment Ini1a1on
2. Request Payment Ini1a1on
PSU
PISP
1st and 2nd SCA factors
captured by the PISP and
transmi>ed to the ASPSP
3. Authen1cate PSU
Key Concept
PSU submits SCA
factors to the PISP
applica7on which are
then transmi>ed to
the ASPSP
12. 12
Open ID Foundation Workshop
Decoupled
PISP
PSU 1. Consent to Payment Ini1a1on
2. Request Payment Ini1a1on
5. Authorise PI
Device 1
Device 2
4. Message to PSU
3. Setup a pending Authorisa1on
Key Concept
PSU completes the
authorisa7on step
i. on a different
device
ii. by opening a new
applica7on
22. 22
Interaction Sequencing
1 (a) The PSU requests a service, via the TPP, that
transacts on their bank account.
1. (b) The TPP system recognises this a protected
ASPSP service and requests an Authorisation via the
PSU’s browser [ User Agent ]
2. The PSU’s User Agent redirects the request to a
ASPSP Application [Authorisation Sever ] requesting an
Authorisation Grant of type Authorisation Code.
SCA then takes place, controlled by the ASPSP
application
If authentication is successful, the Authorisation Server
creates an Authorisation Code and returns this to the
TPP application via the PSU browser
3. The TPP application completes the Authorisation
Grant including the Authorisation Code + Client ID +
Client Credentials.
4. The ASPSP Authorisation Server validates the
Authorisation Grant and issues an Access Token.
5. The TPP makes the API request including the Access
Token.
API Call - Technical Overview
Third Party Application
[ OATH2 CLIENT ]
Strong Customer
Authentication Application
[ AUTHORISATION SERVER ]
API Server
[ RESOURCE SERVER ]
Client Device
[ USER AGENT ]
Client ID
Client Credential
1a
2
3 4
5 APIAccess
Token
Authorisation
Grant
Grant Type =
Auth Code
PSU
Access
Token
ASPSP
TPP
Auth Code +
Client ID +
Credential
Auth Code Authorisation
Request
1b
Redirection
API Call
