Introduction to the FAPI Read & Write OAuth Profile · OAuth is a framework –needs to be profiled This framework was designed with the clear expectation that future work will define

Nomura Research Institute

Nat Sakimura(@_nat_en)

Introduction to

the FAPI Read & Write OAuth Profile

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

2018-05-15

Foundation

Research FellowChairman of the board

© 2017 by Nat Sakimura. CC-BY-SA.

Copyright © 2016 Nat Sakimura. All Rights Reserved.

2

OAuth is a framework – needs to be profiled

This framework was designed with the clear expectation that future work will

define prescriptive profiles and extensions necessary to achieve full web-scale

interoperability.“



3

Which OAuth?



44



5

That creates specification to take care of medium to high risk API access security.

5

Va

lue

of

the

re

so

urc

e

Environment control levelHigh Low

High

Low

Social sharing

Closed circuit

Factory

application

Financial API

– Read & Writee.g.,

Basic choices ok.

Bearer token Not

OK

Basic choices

NOT OK

No need to satisfy all the security

requirments by OAuth

Financial API

– Read only



6

That can serve all financial transactions

including PSD2,

but not limited to.



7

FAPI Security Profile is a general purpose higher

security API protection mechanism based on

OAuth framework.

7



8

It has been adopted by Open Banking UK

8



9

9 Major banks in UK went live on January, 2018

(Source) Chris Mitchel, “Banking is now more open”, Identify 2017

Australia adopting the same profile



10

It is also recommended by the Japanese Banker’s association

10

(source) https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf

https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf



11

US FS-ISAC aligning their security

requirements

11



12

… and major IAM vendors are

implementing it

12



13

Submit to ISO/TC 68 and is a part of the

forthcoming technical specification

13



14

We have issued two implementer’s draftsVa

lue

of

the

re

so

urc

e

Environment control levelHigh Low

High

Low

Social sharing

Closed circuit

Factory

application

Financial API

– Read & Write

e.g.,

Basic choices ok.

Financial API

– Read only



15

Which are redirect approach

Part 1: Read Only Security Profile

Part 2: Read and Write Security Profile

15

Redirect

Approach

Decoupled

Approach

Embedded

Approach



16

While RFC6749 is not complete with source, destination, and message authentication,

UA

Client ASTLS Protected

TLS Protected TLS Protected

TLS Terminated

Sender

AuthN

Receiver

AuthN

Message

AuthN

AuthZ

Req

Indirect None None

AuthZ

Res

None None None

Token

Req

Weak Good Good

Token

Res

Good Good Good



17

By using OpenID Connect’s Hybrid Flow and Request Object, you are pretty well covered.

FAPI Part 2 is complete with source, destination, and message authentication.

17

Sender

AuthN

Receiver

AuthN

Message

AuthN

AuthZ Req Request Object Request Object Request object

AuthZ Res Hybrid Flow Hybrid Flow Hybrid Flow

Token Req Good Good Good

Token Res Good Good Good



18

Tokens are Sender Constrained instead of being bearer

Security

Levels

Token Types Notes

Sender Constrained

Token

Only the entity that was issued

can used the token.

Bearer Token Stolen tokens can also be used



19

These are in the form of check lists.

(source) https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?at=master&fileviewer=file-view-default#markdown-header-85-tls-considerations

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?at=master&fileviewer=file-view-default#markdown-header-85-tls-considerations

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md



20

Crypto Requirements are tightened for interoperability and security

(source) https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md



21

And now working on the decoupled approach …

CIBA (client initiated backchannel

authentication) profile.

21

Redirect

Approach

Decoupled

Approach

Embedded

Approach

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md



22

Embedded Approach

Giving bearer credentials to a third party is a bad idea.

GDPR explicit consent for third party data transfer?

What would be the liability implications?

Perhaps per app “password”?

22

Redirect

Approach

Decoupled

Approach

Embedded

Approach



23

We have other works as well…

E.g. The OpenBanking OpenID Dynamic Client Registration Specification

23



24

… and perhaps

Intent registration endpoint

24

Intent Registration EP

Authorization EP

Token EP

ServerPushing the intent,

e.g., to send $1,000 to

Bob’s account

Intent ID

AuthZ Req w/Intent ID

AuthZ ResponseRedirect URI

Client



25

How can we tell that the implementation

conforms to the specification?

25



26

OpenID Foundation provides the online test environment for the implementers to test their conformance.

26

Once it passes the test, the implementer can self-certify and publish.

•That gets the implementers under the premise of the article 5 of the FTC Act.

•The log will be openly available so others can also find out false claims.

See http://openid.net/certification/for details

http://openid.net/certification/



2727



28

New Name for WG?

28



29

After all, there is nothing specifically

“Financial”

29



30

It is a general purpose High Security API

protection protocol

30



31

Some of the candidates …

Fully Assured Protection Interoperable

Fair Assurance Protection Interface

Full Assurance Protection Interface

Full Assurance Profile Interface (FAPI) WG

Plus …

31

Documents

Introduction to the FAPI Read & Write OAuth Profile · OAuth is a framework –needs to be profiled This framework was designed with the clear expectation that future work will define