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

[Deb Cooley <[e-mail]>]

Just a ping to bring this back up to the top of your inboxes....

Deb

On Wed, Apr 8, 2026 at 8:55 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.
>
> 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).
>
> 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.
>
> Section 2.2:  Since this 'MAY' does not enable/disable interoperability
> (the goal of BCP 14), consider changing it to 'may' or even 'could'.
>
> Section 2.3, bullet 1:  'MUST deny' or 'MUST NOT approve'?  Which will be
> more obvious to the implementer?
>
> 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....'
>
> 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?
>
> 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.
>
> 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]
>
>