Thanks Éric for the No Objection ballot and comments. I've attempted to provide a bit more color inline below. Accordingly, PR https://github.com/oauth-wg/oauth-identity-chaining/pull/194 proposes to use 2119 keywords just a little less when not needed or not appropriate.
On Tue, Jun 2, 2026 at 2:32 PM Éric Vyncke via Datatracker <[email protected]> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-oauth-identity-chaining-14: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work done in this document. I regret that the shepherd's > write-up does not have real justifications for the intended publication > status > or for the number of authors. > Near the end of April I advocated for adding Aaron Parecki to the author list (see https://github.com/oauth-wg/oauth-identity-chaining/pull/184), which IMHO was a long overdue acknowledgment of his contributions directly to the document as well as his arguably more impactful indirect contribution of raising its profile through the closely related work on https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ and advocacy thereof. I confirmed Aaron's addition to the draft with the responsible AD, at least one of the WG chairs, and the document shepherd. I did not broach the idea of removing any of the existing authors because, well, that can be a very fraught topic. I only wanted to raise up and demonstrate appreciation for substantial contributions, not spotlight the lack thereof from others or seek to evict anyone from the document. Aaron also assured me that he would be responsive throughout the AUTH48 process. https://github.com/oauth-wg/oauth-identity-chaining/issues/175 has a bit more on the rationale of the intended publication status. > > In section 2.5, should this rather be a "MUST" in `Authorization Servers > SHOULD > verify that the requested scopes are not higher privileged than the scopes > of > the presented subject_token` ? If "SHOULD" is kept, then please provide the > additional guidance per > > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ I feel like the text around it does an okay job of describing things and the condition isn't easily testable anyway. I'm going to opt for simply avoiding 2119 keywords here. > > > The same issue in section 5.4, i.e., why not a "MUST NOT" in `The > authorization > server in trust domain B SHOULD NOT issue refresh tokens ` ? > The entirety of 5.4 after that sentence is text providing additional guidance and rationale about it. > > The same IESG statement also considers that BCP14 terms should not be used > in > appendix. Yeah, thanks for the reminder, I'll remove those. -- _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]
