[OAUTH-WG] Re: Shepherd Review - Updates to JWT Client Authentication and Assertion-Based Authorization Grants

[Rifaat Shekh-Yusef <[e-mail]>]

Thanks Mike!

After re-reading the "strong typing" issue with the highlighted sentence, I
think I now understand what you are saying, and I am fine with keeping the
text as is.

Please, publish a new version with the latest changes, and I will try to
complete the shepherd write up later this week.

Regards,
 Rifaat


On Mon, Mar 2, 2026 at 11:58 AM Michael Jones <[e-mail]>
wrote:

> Thanks, Rifaat.  See my comments below prefixed by “Mike2>”.
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Monday, March 2, 2026 6:47 AM
> *To:* Michael Jones <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *Subject:* Re: [OAUTH-WG] Shepherd Review - Updates to JWT Client
> Authentication and Assertion-Based Authorization Grants
>
>
>
> See my comments below.
>
>
>
>
>
> On Sun, Mar 1, 2026 at 10:40 PM Michael Jones <[e-mail]>
> wrote:
>
> Thanks for your review, Rifaat.  Replies inline prefixed by “Mike>”.
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Monday, February 23, 2026 11:32 AM
> *To:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] Shepherd Review - Updates to JWT Client
> Authentication and Assertion-Based Authorization Grants
>
>
>
> Hi,
>
>
>
> As the shepherd for this document, I have reviewed version 05 of the draft
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-05.html
>
>
>
> and I have the following comments/questions:
>
>
> *Section 3*
>
> It is RECOMMENDED that SAML Bearer Assertions not be used for client
> authentication.
>
>
> Should the RECOMMENDED be a MUST? If not, can you add some text to explain
> when SAML Bearer Assertions could still be used?
>
> Mike> How about we change it to say:
>
> It is RECOMMENDED that SAML Bearer Assertions not be used for client
> authentication for any new applications.  (The authors are not actually
> aware of any applications using this feature of RFC 7522.)  Should any
> applications already be doing this in the manner described in RFC 7522, it
> is left to the discretion of their implementers and deployers whether to
> migrate away from this feature and/or potentially tighten the audience
> values used in a manner parallel to the changes being made in RFC 7523.
>
>
>
> If you want new applications to *not* use SAML Bearer Assertions, then I
> think RECOMMENDED should be a MUST; otherwise, you need to explain
> when SAML Bearer Assertions can still be used.
>
>
>
> Mike2> OK –
> https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/25 updated
> to use MUST NOT.  Please review.
>
> *Section 5, *Second paragraph,
>
> “The paragraph describing the audience value in Section 2”
>
>
> You might want to explicitly state which paragraph this is referring to.
>
> Mike> How about we change it to say:
>
> The last paragraph of Section 2 of [RFC9126] , which describes the
> audience value, is replaced by:
>
>
>
> Yep
>
>
>
>
> *Section 5, *Last paragraph,
>
> “Client authentication JWTs SHOULD be explicitly…”
>
>
> Can you elaborate on what this is a “SHOULD” to make it clear to the
> implementer?
>
> Mike> The previous paragraph, beginning “The introduction of strong typing
> for JWTs” already gives ample reasons why this should be done but is not
> required.  I don’t believe any additional text is needed in this case.
>
> If I understood the previous paragraph, it implies that you can still not
> use strong typing for backwards compatibility reasons.
>
> If this is the reason for the RECOMMENDED and SHOULD in this section, then
> it would be great if you can be explicit about it.
>
>
>
> Mike2> That same paragraph already contains the rationale for why this is
> RECOMMENDED:
>
> “Since strong typing alone does not prevent the attacks described in [
> private_key_jwt.Disclosure
> <https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#private_key_jwt.Disclosure>
> ] and [Audience.Injection
> <https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#Audience.Injection>],
> the use of explicit typing is RECOMMENDED for clients, enabling them to
> signal their intention of sending a JWT conforming to the requirements
> herein.  *This approach balances security signaling with practical
> deployment considerations, avoiding disruption to client deployments that
> already conform to the tightened audience requirements but have not yet
> adopted explicit typing.*”
>
>
>
> Mike2> Explicit typing can be relied on for new deployments, since new
> clients will follow the recommendation.  Let us know if there is a specific
> additional wording change that you recommend.
>
> *Section 8.2*
>
> It seems to me that the following references should be moved to the
> Normative References section:
> IANA.MediaTypes, IANA.OAuthParameters, OpenID.Core, RFC2046, and RFC6838
>
> I agree with you about OpenID.Core because implementers need to use
> normative definitions contained in it.  The other references are only used
> to inform the IANA registrations – not implementers, and so need not be
> normative.  It’s not customary to make such references normative.  (Of
> course, if the IESG disagrees, we can always do this later.)
>
>
>
> Yeah, this makes sense to me.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
> Regards,
>  Rifaat
>
>
>
> I will create a PR applying these proposed changes later this evening.
>
>
>
>                                                                 Thanks
> again,
>
>                                                                 -- Mike
>
>
>
>