Introduction to the FAPI Read & Write OAuth Profile 2018-05-15 Nat Sakimura(@_nat_en) 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.

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.

Which OAuth?

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

That can serve all financial transactions including PSD2, but not limited to.

FAPI Security Profile is a general purpose higher security API protection mechanism based on OAuth framework.

It has been adopted by Open Banking UK

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

It is also recommended by the Japanese Banker’s association (source) https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf

US FS-ISAC aligning their security requirements

… and major IAM vendors are implementing it

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

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

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

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

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.

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

These are in the form of check lists. (source) https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

Crypto Requirements are tightened for interoperability and security (source) https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

And now working on the decoupled approach … CIBA (client initiated backchannel authentication) profile. https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md Redirect Approach Decoupled Approach Embedded Approach

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

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

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

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

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

By the way

New Name for WG?

After all, there is nothing specifically “Financial”

It is a general purpose High Security API protection protocol

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

Introduction to OpenID Connect Self Issued Provider 2018-05-15 Nat Sakimura(@_nat_en) 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.

Have you read the Chapter 7 of OpenID Connect?

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.

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

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

Self Issued Provider Tap on it. Social Logins