[OAUTH-WG] Re: AD comments on draft-ietf-oauth-identity-chaining

[Deb Cooley <[e-mail]>]

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.

Other comments/confessions?  in line with [DC]

Deb

On Fri, Apr 24, 2026 at 12:11 PM Brian Campbell <[e-mail]>
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 <[e-mail]> 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.*