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 <oauth-boun...@ietf.org> On Behalf Of Brian Campbell
Sent: Thursday, July 23, 2020 1:30 PM
To: dba...@leastprivilege.com
Cc: oauth <oauth@ietf.org>
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
<dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> 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
(dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>) wrote:
Good point.. Thanks, Brian.
We should retrofit typs everywhere..in hindsight.
———
Dominick Baier
On 22. July 2020 at 23:55:20, Brian Campbell
(bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>) 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
<dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> 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=40pingidentity....@dmarc.ietf.org<mailto:bcampbell=40pingidentity....@dmarc.ietf.org>)
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
OAuth@ietf.org<mailto:OAuth@ietf.org>
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
