Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Mike Jones <[e-mail]>]

The “Use Explicit Typing<https://www.rfc-editor.org/rfc/rfc8725.html#section-3.11>” section of the JWT BCP explicitly says: “Explicit typing is RECOMMENDED for new uses of JWTs.”  It does not recommend trying to retrofit “typ” values for existing JWT uses, as that would often cause breaking changes to working ecosystems.  The Request Object was defined by OpenID Connect in 2004, so this is very much an existing use – not a new use.  (The OAuth JAR draft, like several other previous OAuth drafts, is bringing existing OpenID Connect functionality into the OAuth world – intentionally doing so in such a way as to not break existing usages.)

I agree with Brian’s assessment that the cost/benefit of adding a “typ” field to the Request Object doesn’t have a reasonable cost/benefit ratio.

                                                          -- Mike

From: OAuth <[e-mail]> On Behalf Of Brian Campbell
Sent: Thursday, July 23, 2020 1:30 PM
To: [e-mail]
Cc: oauth <[e-mail]>
Subject: [EXTERNAL] Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

In hindsight, yeah, having explicit JWT typing everywhere would be nice.. But retrofitting would be a very major undertaking, which I don't think could reasonably be justified considering cost–benefit.

I can't speak directly for the Jwsreq authors but I suspect considerations around backward/forward compatibility with OIDC's JWT request and even existing implementations of the Jwsreq draft that has been in draft forever came into play.

On Wed, Jul 22, 2020 at 11:38 PM Dominick Baier <[e-mail]<mailto:[e-mail]>> wrote:
Even more. Jwsreq should have it. But the authors decided against it.

———
Dominick Baier


On 23. July 2020 at 07:38:04, Dominick Baier ([e-mail]<mailto:[e-mail]>) wrote:
Good point.. Thanks, Brian.

We should retrofit typs everywhere..in hindsight.

———
Dominick Baier


On 22. July 2020 at 23:55:20, Brian Campbell ([e-mail]<mailto:[e-mail]>) wrote:
Because it wouldn't actually prevent it in this case due to JWT assertion client authentication (a.k.a. private_key_jwt) having come about well before the JWT BCP and the established concept of using the 'typ' header to prevent cross-JWT confusion. Thus there's no validation rule regarding the 'typ' header defined in RFC 7523 for JWT client authentication. Explicitly typing the request object JWT doesn't do anything to prevent it from being used in the context of previously existing JWT applications like client auth.

On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier <[e-mail]<mailto:[e-mail]>> wrote:
Why not use a typ header as suggested by the JWT BCP?

———
Dominick Baier


On 22. July 2020 at 17:37:41, Brian Campbell (bcampbell=[e-mail]<mailto:bcampbell=[e-mail]>) wrote:
The TL;DR here is a somewhat tentative suggestion that a brief security consideration be added to https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/<https://datatracker..ietf.org/doc/draft-ietf-oauth-jwsreq/> that prohibits the inclusion of a 'sub' claim containing the client id value in the request object JWT so as to prevent the request object JWT (which is exposed to the user agent) from being erroneously accepted as a valid JWT for client authentication.

Some more details and the discussion that led to this here email can be found at https://github.com/oauthstuff/draft-oauth-par/issues/41

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.