On Sat, Apr 25, 2026 at 9:31 AM Deb Cooley <[email protected]> wrote:
> These all look good to me. I'm going to submit it to IETF Last Call. > > Adding Aaron as an author is fine as well. I will need Rifaat to update > the shepherd review to provide at least a little bit of rationale for 6 > authors. > Done Regards, Rifaat > > Other comments/confessions? in line with [DC] > > Deb > > On Fri, Apr 24, 2026 at 12:11 PM Brian Campbell < > [email protected]> wrote: > >> Thank you for the review and it's now my turn to apologize for the delay >> (can I blame IETF 125 at this point? probably not...). Some specific >> responses are inline below but I don't think you'll find anything >> surprising or controversial. This issue >> https://github.com/oauth-wg/oauth-identity-chaining/issues/182 and this >> PR https://github.com/oauth-wg/oauth-identity-chaining/pull/183 kinda >> show our work here and the responses below are taken from the issue and >> specific commits mentioned are part of that PR. A new draft incorporating >> all this will be forthcoming soon. >> >> >> On Wed, Apr 8, 2026 at 6:57 AM Deb Cooley <[email protected]> wrote: >> >>> Thank you for your work on this specification, here are my comments on >>> this draft. Apologies for the delay (IETF 125 and recovery from the same >>> takes time). I don't think any of these comments are especially difficult, >>> most are process related: >>> >>> Deb >>> Sec AD >>> >>> --------------------------------------- >>> General: Consider using *.*.example.org for example domains (currently >>> this draft uses as.*.org). See: >>> https://authors.ietf.org/example-addresses for more information. >>> >> >> Yup, will do in 3c777e3 >> <https://github.com/oauth-wg/oauth-identity-chaining/commit/3c777e33338d8f559bec358d5008bad801ec3d7c> >> and 886cbc6 >> <https://github.com/oauth-wg/oauth-identity-chaining/commit/886cbc6f71b34dffa41064f9ef9f14aef2eb84e4> >> > [DC] certainly the change results in a 'non-routable' domain, but consider > adding '.org' to the end. This can wait for later, and possibly for > someone else commenting on it. > >> >> >> >>> Long line: Line 416, is 75 characters long, according to idnits >>> (experimental). I did not go looking for this (which is why I've put it up >>> front). >>> >> >> will split the 1 instance of too long line >> <https://github.com/oauth-wg/oauth-identity-chaining/pull/183/changes/1f32fc4af6b5efb85aca27e82183cc4301b3dcee> >> >> >> >>> Section 2.1, Appendix B: Using steps (A), (B), (C) could be confusing >>> in light of the pre-existing domain enumerations of Domain A, Domain B. >>> I'd suggest using some other enumeration for the steps, maybe (1), (2), (3) >>> to disambiguate. >>> >> >> Makes good sense 7a90229 >> <https://github.com/oauth-wg/oauth-identity-chaining/commit/7a90229772175b040c487982637cb0b94cc32661> >> >> >> Section 2.2: Since this 'MAY' does not enable/disable interoperability >>> (the goal of BCP 14), consider changing it to 'may' or even 'could'. >>> >> >> Happy to do that one cf9e53f >> <https://github.com/oauth-wg/oauth-identity-chaining/commit/cf9e53fa063e7814ceccf7622947d138244221a4> >> >> >> >>> Section 2.3, bullet 1: 'MUST deny' or 'MUST NOT approve'? Which will >>> be more obvious to the implementer? >>> >> >> In bullet 1 or 2.3[.2?], deny seems more obvious to me and I was an >> implementer at one point long ago in this so called career. >> >> [DC] this is fine. > >> >> >>> >>> Section 2.4.3: There is an assumption here that the previous >>> rules/steps/checks have been validated without error. Perhaps consider >>> adding a phrase like, 'When the authorization grant has been validated, >>> the....' >>> >> >> Yup, added When the authorization grant has been validated, the... >> <https://github.com/oauth-wg/oauth-identity-chaining/pull/183/changes/7df77d37938e3bab958a7e5426b3e5cb0f26d593> >> >> >> >>> Section 5: BCP14 language or not? Please see: >>> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ >>> . While BCP 14 words in Security Considerations is completely appropriate, >>> it should still be used sparingly. The word 'must' is just as normative as >>> 'MUST', but carries less baggage. I would suggest going back through >>> Section 5, and consider which of the BCP 14 words are there for >>> 'interoperability' or to 'prevent harm'. Please pay special attention to >>> section on 'SHOULD' and 'RECOMMENDED'. I'm making some comments within >>> Section 5 to emphasize my point of view. >>> >>> Section 5.1: Naked 'SHOULD's need to have a 'what are the consequences >>> of violating the should' that goes with it. An alternative is to state >>> under what reasonable circumstances the should isn't possible (maybe that >>> is the public client part of this section?). >>> >>> Section 5.4: I'm guessing that there was confusion at some point about >>> issuance of refresh tokens by AS domain A to clients in domain A? My >>> suggestion to make this a tiny bit clearer in para 1 is to add 'domain A' >>> when you mention 'client' -> 'client in domain A'. It does make it wordier >>> and longer, but way more obvious that the refresh tokens across domains are >>> the issue. >>> >>> Section 5.4: It is also not clear why one might choose to violate the >>> sequence of 'SHOULD NOT', 'SHOULD', 'SHOULD'... Why not 'MUST NOT', >>> 'MUST', 'MUST'? Sadly, RFC 7521 doesn't specify why/when 'SHOULD NOT' >>> could be ignored (unless I read it incorrectly). >>> >>> Section 5.5: Why not 'MUST'? Seems reasonable to say that one MUST >>> evaluate the risk and since there is no definition of 'appropriate', then >>> any mitigations will do, no? >>> >> >> All of this makes sense and I took a pass over sec 5 with it in mind Security >> Considerations: attempt improvements around normative language and other >> language too >> <https://github.com/oauth-wg/oauth-identity-chaining/pull/183/changes/2ac9612d7dded24e55dc8e292448d9ed3cc5167b> >> >> [DC] these all look good. > >> >> >>> >>> IANA Considerations: Add this, see: >>> https://authors.ietf.org/en/iana-considerations . It *might* be >>> possible to remove it prior to publication. IANA will know (and tell you) >>> for sure. >>> >> >> This led me to look at and makes some small changes with Fiddling with >> IANA Considerations >> <https://github.com/oauth-wg/oauth-identity-chaining/pull/183/changes/922023acd58aa19deb77d6fbbf7c32afa6a09759> >> but otherwise I'm not sure what action or learning I was supposed to take >> from that? >> >> > [DC] sigh.... it was the placement of this section that confused me. No > problem, I just didn't win the game of hide and seek the IANA Consideration > section game (this is me poking fun at myself, no changes required). > >> >> >>> Acknowledgements (Appendix C): I would remove the parenthetical and >>> just state a generic 'and others for their valuable input....'. Naming >>> everyone who had input is not actually required. [rationale: the () won't >>> age well] >>> >> >> The parenthetical was really meant as an invitation to people that we may >> have overlooked to let us know so we could include them. But the time for >> that has passed so we'll take it out. 2824b2e >> <https://github.com/oauth-wg/oauth-identity-chaining/commit/2824b2e3dd0c536ff09879ed42ca7f013b68d44f> >> >> >> *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]
