Thanks, Rifaat. See my comments below prefixed by “Mike2>”. From: Rifaat Shekh-Yusef <[email protected]> Sent: Monday, March 2, 2026 6:47 AM To: Michael Jones <[email protected]> Cc: oauth <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: 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. 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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
