Your shepherd comments are applied in
https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/25, Rifaat.
Please review.
Thanks,
-- Mike
From: Michael Jones
Sent: Sunday, March 1, 2026 7:40 PM
To: 'Rifaat Shekh-Yusef' <[email protected]>; oauth <[email protected]>
Subject: RE: [OAUTH-WG] Shepherd Review - Updates to JWT Client Authentication
and Assertion-Based Authorization Grants
Thanks for your review, Rifaat. Replies inline prefixed by "Mike>".
From: Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>>
Sent: Monday, February 23, 2026 11:32 AM
To: oauth <[email protected]<mailto:[email protected]>>
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
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
