Hi Axel, I tried to respond inline below to some things but I'm guessing you mean PAR rather than RAR throughout? I admit to having had some trouble understanding on my first couple reads of this message.
On Sun, Feb 1, 2026 at 7:14 AM <[email protected]> wrote: > Hi, > > draft-ietf-oauth-rfc7523bis recommends strong typing of JWT but currently > none of the examples use "typ". > > I think that > https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#section-5 > > should update all examples in > "OAuth 2.0 Pushed Authorization Requests" [RFC9126 > <https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#RFC9126> > ] > > E.g.: > > eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrhTWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6sef5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-KdTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8WyeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJERWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6GQ > Uses > { > "kid": "k2bdc", > "alg": "RS256" > } > I think there should be the now recommended typ value. > Examples are only examples and not normative, but I think examples should > follow security recommendations. > The bis document https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc7523bis-05#name-client-authentication-jwt-e has a section with a full example that shows the decoded header and body in addition to the HTTP request while trying to explain the values shown. PAR/RFC9126 has two examples that somewhat incidentally include JWT client auth in them. One would have to decode the header to even see that typ isn't present. My personal opinion is that updating the PAR/RFC9126 examples in the bis doc would only clutter it up and make things harder to follow. > > Another topic, wouldn't it be better to have more types instead of one for > client authentication? > My intuition is that it would definitely not be better. Maybe I'm missing something but I'm having trouble seeing that there'd be any value in doing so, let alone better. > Something like rar_client_authn+jwt for rar, and ciba_client_authn+jwt for > CIBA and … Doesn't hurt because servers and clients are recommended to > adapt current implementations anyway, right? > It would make adapting implementations more cumbersome and error prone while needlessly bloating the media type registry and adding a number of logistical issues/questions about what documents (existing and hypothetical future) are responsible for defining and registering the associated type. >From my perspective it would hurt a lot while providing no benefit. > > Kind regards > Axel > > > *From: *Michael B. Jones <[email protected]> > *Date: *Saturday, 31. January 2026 at 23:05 > *To: *oauth-wg/draft-ietf-oauth-rfc7523bis < > [email protected]> > *Cc: *Nennker, Axel <[email protected]>, Author < > [email protected]> > *Subject: *Re: [oauth-wg/draft-ietf-oauth-rfc7523bis] tradeoffs between > using issuer and specific endpoint urls (PR #24) > > *@selfissued* commented on this pull request. > ------------------------------ > > In draft-ietf-oauth-rfc7523bis.xml > <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587> > : > > > + or its token endpoint URL. Using the specific token > > endpoint URL provides > + stronger endpoint binding and is RECOMMENDED when the > endpoint URL is > + configured from a trusted, out-of-band source. Using > the issuer identifier > + allows greater flexibility at the cost of reduced > endpoint-specific binding. > > As @PedramHD <https://github.com/PedramHD> wrote in his initial > description of the attack, "a malicious OP could specify token endpoints of > other OPs, thus, obtaining private key JWTs created by an RP that it could > use at those OPs." This is the core of what enables the attack: Attackers > can specify that the audience be the token endpoint of the legitimate site > being attacked. > > The use of endpoint URLs as audience values do not stop the attack. The > use of validated issuer URLs do. > > — > Reply to this email directly, view it on GitHub > <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AANEMB3OWYNI4YEH3RVCZHL4JURJPAVCNFSM6AAAAACRQSIOLGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMZTGY3TCNJRGQ> > . > You are receiving this because you authored the thread. > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _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 -- [email protected] To unsubscribe send an email to [email protected]
