FAPI1 Part1: not clear as to which auth flows are supported

[Kosuke Koiwai]

In Issue #11, Nat says “PKCE or Hybrid Flow is mandated in Part 1,“ but I couldn’t read it from the spec.

Does “shall support PCKE” means “shall not use implicit flow?”

Part2 has been already covered in Issue #72.

5.2.3.  Public client

1. shall support RFC7636;
2. shall use S256 as the code challenge method for the RFC7636;

‌

‌

[Joseph Heenan]

Hi Kosuke,

I agree that this should be clearer.

I presume the question probably arose in the context of your upcoming presentation, so it might be helpful to add some more context.

Firstly I’d say that https://openid.net/specs/openid-financial-api-part-1-1_0-final.html has not been widely deployed - I’m not currently aware of any ecosystem that has chosen to use it. Everyone (e.g. UK/Brazil/Australia Openbanking etc) seems to be using part 2, even for read-only access.

We also ( https://bitbucket.org/openid/fapi/src/master/Financial_API_Implementation_And_Deployment_Advice.md#markdown-header-511-introduction ) encourage the use of confidential clients in many of the situations where public clients were traditionally used. (The section could probably do with an update, since it was written I believe someone (fairly sure it was Vittorio Bertocci or Aaron Parecki) has done a great diagram that shows potential different deployment methods that we could reference (though I can’t seem to find it…), and we should also reference using the JS Web Crypto API for SPAs.

[Kosuke Koiwai]

Thanks Joseph,

I guess Part 1 may be usable for simpler ekyc use cases where RPs may not want to implement signed requests. PKCE and signed id_token/userinfo may be enough for such use cases.

I agree that confidential clients should be used for high-risk transactions, while I think we should also give advice for how to manage login and sessions for browsers and native apps.

[Joseph Heenan]

I agree that confidential clients should be used for high-risk transactions, while I think we should also give advice for how to manage login and sessions for browsers and native apps.

Just to be clear on this point - browsers and native apps (even those without backends) can be confidential clients and we do give (rather obtuse) advice on how to do that in 5.1.3 - i.e. using dynamic client registration to register keys for each instance of the app.

As you say, there may be some less risky use cases where this is not required, but in general I’d say that I’m not sure which eKYC use cases would be suitable to use with public clients - without the guarantee that the response is for the intended user, I’m not sure when an assured identity is useful, and https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md does not support public clients at all.

[Nat Sakimura]

Although it introduces “shall” it was mandated on the client-side already so it is to make it clearer.

[Nat Sakimura]

The intent of requiring PKCE is to disallow clients from getting access tokens without PKCE protection. So, the only allowed response type would be code and code id_token

[Dave Tonge]

Merged in fapi1_errata_458b (pull request #430)

fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - allow 'code' or 'code id_token' only

• Merged openid/fapi:master into edmundjay/fapi1:fapi1_errata_458b

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Joseph Heenan Approved-by: Kosuke Koiwai

→ <<cset d49e643f0457>>

[Dave Tonge]

Merged in fapi1_errata_458b (pull request #430)

fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - allow 'code' or 'code id_token' only

• Merged openid/fapi:master into edmundjay/fapi1:fapi1_errata_458b

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Joseph Heenan Approved-by: Kosuke Koiwai

→ <<cset d49e643f0457>>

[Dave Tonge]

Merged in fapi1_errata_458b (pull request #430)

fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported

• fixes #458 - allow 'code' or 'code id_token' only

• Merged openid/fapi:master into edmundjay/fapi1:fapi1_errata_458b

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Joseph Heenan Approved-by: Kosuke Koiwai

→ <<cset d49e643f0457>>