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. *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. > *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]
