On Fri, Apr 10, 2026 at 11:00 AM Rich Salz via Datatracker <[email protected]> wrote:
> Document: draft-ietf-oauth-rfc7523bis > Title: Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and > Assertion-Based Authorization Grants Reviewer: Rich Salz Review result: Has > Issues > > This is the Security Directorate review for draft-ietf-oauth-rfc7523bis. > The > authors know what this kind of thing is. The Security ADs should treat > this as > any other last-call comments. > > Not surprisingly, I found the document pretty clear. I had to read a bunch > of > OAUTH RFCs to catch the context; as I'm mostly ignorant about it.. > I am truly sorry you had to do that Rich. But thanks nonetheless for the review. > > The only issue I found was that there discussion of backward compatibility > other than Section 3, where it's kinda weakly stated. The identifier isn't > changing, so at least a statement that it is backward compatible would be > helpful I think. What is and isn't backward On Fri, Apr 10, 2026 at 11:00 AM Rich Salz via Datatracker <[email protected]> wrote: > Document: draft-ietf-oauth-rfc7523bis > Title: Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and > Assertion-Based Authorization Grants Reviewer: Rich Salz Review result: Has > Issues > > This is the Security Directorate review for draft-ietf-oauth-rfc7523bis. > The > authors know what this kind of thing is. The Security ADs should treat > this as > any other last-call comments. > > Not surprisingly, I found the document pretty clear. I had to read a bunch > of > OAUTH RFCs to catch the context; as I'm mostly ignorant about it.. > I am truly sorry you had to do that Rich. But thanks nonetheless for the review. > > The only issue I found was that there discussion of backward compatibility > other than Section 3, where it's kinda weakly stated. The identifier isn't > changing, so at least a statement that it is backward compatible would be > helpful I think. What is and isn't backward compatible here is a little subtle. A sender doing the new thing will be accepted by a receiver doing the old thing and by a receiver doing the new thing, so that's fully backward compatible. But some variations of the sender doing the old thing would be rejected by a receiver strictly doing the new thing, so that's the not entirely backward compatible part that might need some migration consideration. I'll make an effort to improve treatment of the subject in the draft. If, after reading that rambling explanation from me, you have thoughts about where or how in the draft to make such improvements though, I'd be happy to hear suggestions. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
