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 <[email protected]> wrote: > 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]> > wrote: > > Thanks for your review, Rifaat. Replies inline prefixed by “Mike>”. > > > > *From:* Rifaat Shekh-Yusef <[email protected]> > *Sent:* Monday, February 23, 2026 11:32 AM > *To:* oauth <[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]
