Usage of dpop_jkt

[paulbastian]

Do we have benefits of enforcing https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-code-binding- ?

[Sakurann]

could you please elaborate more?

[TimoGlastra]

Binding the DPoP key already during the authorization request (PAR in case of HAIP) enabled end-to-end binding of the authorization flow. Because the key the access token will be bound to is already provided in the PAR endpoint.

To me it makes sense to make this a requirement.

[jogu]

There was some discussion of the benefits of this mechanism here: https://bitbucket.org/openid/fapi/issues/503/dpop-par-and-authorization-code-binding#comment-63863178 - FAPI2 eventually decided not to mandate clients to use it as the benefits didn't seem that high.

This did cause interoperability issues in the latest interop - at least one implementer rejected PAR requests that didn't have a DPoP proof, and at least one implementer was not sending such a proof. I think we need to address it in 1.0 as the text around DPoP is currently not very explicit. At least we should make it clear whether or not wallets are required to use this mechanism or not.

[Sakurann]

WG discussion

• currently leaning towards being silent about it.
• if we mandate this feature, can we omit PKCE entirely? - needs more thought @bc-pi @danielfett @paulbastian

[jogu]

• if we mandate this feature, can we omit PKCE entirely? - needs more thought @bc-pi @danielfett @paulbastian

I think PKCE could only be omitted if the key supplied in the dpop_jkt was unique to the session. In practice that's almost true as each wallet instance is presumably using a separate key, but I don't know if "almost" is good enough and it would definitely make me nervous to remove the requirement for PKCE.

[jogu]

Discussed on today's EU WG call:

There was a question about why this was added to the dpop spec - Pieter Kasselman provided a good write up of that but the TL;DR is mostly "for public clients". I also asked Gemini what attack it prevented and it said this:

It further clarified that this attack wasn't possible in the same way when using client authentication (in particular Gemini seemed to think about private_key_jwt).

There isn't a clear attack that's prevented by this. FAPI looked at it and decided not to require it, and it wasn't necessary to prevent any of the attacks outlined in the FAPI attacker model. so consensus was HAIP should stay silent (meaning the situation is as per the DPoP RFC - this mechanism would be mandatory to implement for the Credential Issuer's AS, and optional for Wallets). Hence marking this as 'pending-close'. If anyone strongly feels we should do something please comment in the next 7 days.

[jogu]

I've thought further about this since the WG call; if we assume the same attack model as Pieter outlines above (where the PKCE verifier has somehow being leaked) then I think the binding the authorization code to the wallet instance as suggested in oauth-wg/draft-ietf-oauth-attestation-based-client-auth#114 also helps.

[jogu]

closing as per previous 2 comments