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?

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

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!”

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

WRONG!

4

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

After 15 years, we are still screen scraping.

5

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

The situation is changing though.

6

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

Fintech is gaining a lot of interest lately

（ SOURCE ） Google Trends

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

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

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

I

JSON , XML + OAuth 2.0

INDUSTRY PUSH >US: FS-ISAC Durable Data API

9(Source) FS-ISAC FSDDA WG

OpenID Financial API

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

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

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

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

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

And the mere fact that we are here!

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

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

Now is the time!

13

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

?but what API protection?

14

and what API request/response?

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

Solution Time!

15

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

OpenID Foundation Financial API WG (FAPI WG)

16

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

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)

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

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

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

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

19

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

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

It will also help foster the FinTech companies.

20

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

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

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

Possible Approaches

22

JSON REST OAuth

OpenID ConnectBased on FS-ISAC DDAInternationalizeConvert to Swagger

Based on FS-ISAC DDAInternationalizeConvert to Swagger and HAL.

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

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.

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

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

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

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)

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

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

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

?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?

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

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

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

Join the group!

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

29