FAPI part 2 - request object for public clients (signing key?)

[Torsten Lodderstedt]

§5.2.3,#1 requires public clients to use "request" or "request_uri"

How is the client supposed to sign the request object?

[Nat Sakimura]

Good point. It needs more text around it. The premise is that to have the request object signed by the underlying TLS library using the key established for the Token Binding. Perhaps @ve7jtb can chime in and fill the void.

[Nat Sakimura]

Should remove public client from Part 2. This is not a blocking issue for the 2nd I-D.

[Nat Sakimura]

Related to #170. To be dealt with together.

[Nat Sakimura]

§5.2.3,#1 requires public clients to use "request" or "request_uri"

How is the client supposed to sign the request object?

[Dave Tonge]

We agreed to remove public client support from part 2. Here is a pull request:

https://bitbucket.org/openid/fapi/pull-requests/106/first-attempt-at-removing-public-client/diff

[Dave Tonge]

A few questions:

• PKCE, this has benefits beyond public clients, I think we need to look again on the conditions for requiring it - discussion about this here: https://bitbucket.org/openid/fapi/issues/173/mix-up-mitigation-defence-in-depth
• OAuth Token Binding - should we remove this? It was mainly there for public client support. While theoretically possible to use for confidential clients, it seems better to recommend MTLS.
• Formatting and numbering?

[Dave Tonge]

We discussed and agreed to remove the requirement for OAuth Token Binding. This is separate from the public client issue though, so I’ll open another issue for this.

[Dave Tonge]

We removed public client support, so this issue is no longer relevant