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

[Rifaat Shekh-Yusef <[e-mail]>]

On Sat, Apr 25, 2026 at 9:31 AM Deb Cooley <[e-mail]> 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 <
> [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.*
>
>