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

[Michael Jones <[e-mail]>]

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.

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:


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.

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.)


Regards,
 Rifaat

I will create a PR applying these proposed changes later this evening.

                                                                Thanks again,
                                                                -- Mike