1. Introduction to the FAPI Read & Write OAuth Profile
Nat
Hi, I’m Nat Sakimura, the chairman of the OpenID Foundation and a research fellow at Nomura Research Institute.
I am honored to be invited here to talk about OpenID Connect and the potential collaboration with AGL, but before going into the main topics, let me introduce myself briefly.
Foundation
Chairman of the board
Research Fellow
OpenID® is a registered trademark of the OpenID Foundation.
*Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks.

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?

5. That creates specification to take care of medium to high risk API access security.
Closed circuit
Factory application
Basic choices
NOT OK
Bearer token Not OK
Financial API – Read & Write
e.g.,
Financial API – Read only
Value of the resource
Basic choices ok.
Social sharing
Low
Environment control level
High
Low
No need to satisfy all the security requirments by OAuth

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.

8. It has been adopted by Open Banking UK

9. 9 Major banks in UK went live on January, 2018
Australia adopting the same profile
(Source) Chris Mitchel, “Banking is now more open”, Identify 2017

10. It is also recommended by the Japanese Banker’s association
(source)

11. US FS-ISAC aligning their security requirements

12. … and major IAM vendors are implementing it

13. Submit to ISO/TC 68 and is a part of the forthcoming technical specification

14. We have issued two implementer’s drafts
High
e.g.,
Closed circuit
Factory application
Financial API – Read & Write
Financial API – Read only
Value of the resource
Basic choices ok.
Social sharing
Low
Environment control level
High
Low

15. Which are redirect approach
Part 1: Read Only Security Profile
Part 2: Read and Write Security Profile
Redirect
Approach
Decoupled
Approach
Embedded Approach

16. While RFC6749 is not complete with source, destination, and message authentication,
TLS Terminated UA
Sender
AuthN
Receiver
Message
AuthZ Req
Indirect
None
AuthZ Res
Token Req
Weak
Good
Token Res
TLS Protected
TLS Protected
Client AS
One of the problem of just using RFC6749 is the integrity protection of the authorization request and response.
OAuth relies heavily on TLS for its security, but TLS gets terminated in the User Agent (UA).
The exposes attack surface. In this table, I have …
You can see that there are problems with them. There is another perspective as well.
TLS Protected

17. Request Object Request object Hybrid Flow Good
FAPI Part 2 is complete with source, destination, and message authentication.
By using OpenID Connect’s Hybrid Flow and Request Object, you are pretty well covered.
Sender
AuthN
Receiver
Message
AuthZ Req
Request Object
Request object
AuthZ Res
Hybrid Flow
Token Req
Good
Token Res
By using OpenID Connect’s Hybrid Flow and Request Object, you are pretty well covered.
In fact, all these are written down as part of the Financial API Security Profile – the name says Financial, but there is not much financial in it as it only talks about the security. So, you might want to have a look at it.

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)

20. Crypto Requirements are tightened for interoperability and security
(source)

21. And now working on the decoupled approach …
CIBA (client initiated backchannel authentication) profile.
Redirect
Approach
Decoupled
Approach
Embedded Approach

22. Redirect Approach Decoupled Approach 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”?
Redirect
Approach
Decoupled
Approach
Embedded Approach

23. We have other works as well…
E.g. The OpenBanking OpenID Dynamic Client Registration Specification

24. Intent registration endpoint
… and perhaps
Intent registration endpoint
Pushing the intent, e.g., to send $1,000 to Bob’s account
Client
Server
Intent Registration EP
Intent ID
AuthZ Req w/Intent ID
Authorization EP
Redirect URI
AuthZ Response
Token EP

25. How can we tell that the implementation conforms to the specification?

26. See http://openid.net/certification/ for details
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 for details
OpenID Foundation provides the online test environment for the implementers to test their conformance.

27. By the way

28. New Name for WG?

29. After all, there is nothing specifically “Financial”

30. It is a general purpose High Security API protection protocol

31. Some of the candidates …
Fully Assured Protection Interoperable
Fair Assurance Protection Interface
Full Assurance Protection Interface
Full Assurance Profile Interface (FAPI) WG
Plus …

32. Introduction to OpenID Connect Self Issued Provider
Nat
Hi, I’m Nat Sakimura, the chairman of the OpenID Foundation and a research fellow at Nomura Research Institute.
I am honored to be invited here to talk about OpenID Connect and the potential collaboration with AGL, but before going into the main topics, let me introduce myself briefly.
Foundation
Chairman of the board
Research Fellow
OpenID® is a registered trademark of the OpenID Foundation.
*Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks.

33. Have you read the Chapter 7 of OpenID Connect?

35. It is an IdP on your local machine
I am the issuer of my “identity” therefor it will not be taken away
Sounds a lot like “Self Sovereign Identity”, is it not?
It does not need Blockchain, and does not leak information like current proposals that uses Blockchain.
Wire-protocol-wise, it is OpenID Connect with a little twist.
It can obviously use the platform supported Authenticator,
e.g. FIDO/WebAuthen supporting TEE through biometric unlocking.

36. Signed Claims Data Source Data Source Aggregated Claims
Self Issued IdP
Relying
Party
Typically
On your phone

37. Signed Claims Data Source Data Source Data Source Permission
Distributed Claims
Data Source
Data Source
Data Source
Signed Claims
Self Issued IdP
Permission
Relying
Party
Typically
On your phone

38. Self Issued Provider
Tap on it.
Social Logins