openid foundation foundation financial api (fapi) wg

Nomura Research Institute

Nat SakimuraChairman of the Board, OpenID Foundation

Senior Researcher, Nomura Research Institute

#odf

Foundation Financial API WG

• OpenID® is a registered trademark of OpenID Foundation. • *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks.

June 2016

http://openid.net/wg/fapi/

© 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2

?Do you use Personal Finance Software?

What are the current problems?


When NRI started screen scraping in 2001, we thought it will be a temporally solution.

3

“There was OFX, and SAML was coming. SOAP was gaining momentum. We should be able to get out of scraping business in a few years time!”


WRONG!

4


After 15 years, we are still screen scraping.

5


The situation is changing though.

6


Fintech is gaining a lot of interest lately

（ SOURCE ） Google Trends


API is known to be one of the three main component of FinTech

8

Use cases for Identity Federation API in Financial sector

1. Account Opening (incl. KYC)2. Personal Asset Managment3. Payment, Sending Money4. Loan Application5. AI assisted portfolio management

(Source) Nikkei BP: Fintech Revolution P.4

(Source)Nikkei BP: FinTech Yearbook


I

JSON , XML + OAuth 2.0

INDUSTRY PUSH >US: FS-ISAC Durable Data API

9(Source) FS-ISAC FSDDA WG

OpenID Financial API


REGULATORY PUSH> EU Payment Service Directive 2 mandates API availability by the end of 2017.

10(SOURCE) ODI OBWG: The Open Banking Standard (2016)

JSON REST OAuth

OpenID Connect


Regulatory Pressures

Release 1 – to be completed within 12 months ▪ the launch of a tightly scoped Open

Banking API, enabling select, read-access, open data use cases.

Release 2 – to be completed by end of Q1 2017 ▪Third party read access to “midata”*

personal customer data (Read Only)Release 3 – to be completed by end of

Q1 2018 ▪Similar to R2 but has “midata” business

customer data sets (Read Only)Release 4 – to be completed by end of

Q1 2019 ▪Higher Risk – Full read & write access.

Timelines

11

* Minimum midata is a csv file.

(SOURCE) http://www.pcamidata.co.uk/445505-v2-PCA_midata_-_file_content_standard_-_March_2015-2.pdf


And the mere fact that we are here!

12http://www.open-data-finance.com/


Now is the time!

13


?but what API protection?

14

and what API request/response?


Solution Time!

15


OpenID Foundation Financial API WG (FAPI WG)

16


PurposeThe goal of FAPI is to provide JSON data schemas, REST APIs, and security & privacy recommendations and protocols to:

17

JSON REST OAuth

OpenID Connect

(SOURCE) ODI OBWG: The Open Banking Standard (2016)


Enableapplications to utilize the data stored in the financial account,

applications to interact with the financial account, andusers to control the security and privacy settings.

Both commercial and investment banking account as well as insurance, and credit card accounts are to be considered.

(Source) OpenID Foundation Financial API WG draft charter


So that we can finally get rid of password storing and screen scraping!

19

Enhanced Authentication Profile WGhttp://openid.net/wg/eap/


It will also help foster the FinTech companies.

20


Why OpenID Foundation?

• Authors of OAuth, JWT, JWS, OpenID Connect are all here.

Right People

• Loyalty Free, Mutual Non-Assert, so that everyone can use it freely.

Right IPR

• Free to join WGs. (Sponsors welcome)

• WTO TBT Compliant Process.

Right Structu

re21


Possible Approaches

22

JSON REST OAuth

OpenID ConnectBased on FS-ISAC DDAInternationalizeConvert to Swagger

Based on FS-ISAC DDAInternationalizeConvert to Swagger and HAL.


JSON REST OAuth

OpenID Connect

Locked down profile for interoperability. Holder of Key and out-of-band authorization for higher risk scenario (write). Privacy Considerations.


Challenges of OAuth (RFC 6749) in a typical scenario OAuth’s primary security assumption is that there are only 1

Authz Server per client: In case of Personal Financial Client, it will necessarily have multiple Authz Servers. Make sure to have adequate separation, e.g., having different

redirect endpoints for each server.

v.s.

C1O

C1RUA

A1Z

C2R

C2O

A2Z

1 Authz Server / client Model

C2R

C1O

C1R UA

A1Z

C2OA2Z

n Authz Server / client Model


Challenges of OAuth (RFC 6749) in a typical scenarioCommunication through UA are not authenticated and thus can be tainted, but often used without taint check.

Neither ‘code’ nor ‘state’ can be taken at its face value, but we do...

C1O

C1R

UA A1Z

TLS terminates here. Not authenticated (response_type, client_id, redirect_uri, scope, state)

Not authenticated(code, state)


Should we recommend using modified hybrid flow? Include ‘s_hash’ as well?

Security Level

Feature Set Remarks

Request Object w/Hybrid FLow

Authz Request protected

Hybrid Flow(confidential client)

Authz Response protected

Code Flow (confidential client)

Client authentication

Implicit Flow No client authenticationPlain OAuth Anonymous


?Is bearer token adequate? For “read only” access, probably yes. For “write” access, maybe not.

Token Binding? Mobile Apps security?

RFC7636 OAuth PKCE mandatory? MODRNA? AppAuth?


Once complete, consider submitting it to ISO/TC 68

28

ISO 20022 Financial Services - universal financial industry message scheme.Part 1: Overall Methodology and Format Specifications for

Inputs and Outputs to/from the ISO 20022 Repository Part 2: Roles and responsibilities of the registration bodiesPart

3: (TS) XML design rulesPart 5: (TS) Reverse engineering Part 6: Message Transport Characteristics


Join the group!

https://openid.net/wg/fapi/

29

openid foundation foundation financial api (fapi) wg

Technology