Thanks for the feedback, comments and PR Mohamed. We updated the draft to take this into account.
Cheers Pieter On Wed 3 Jun 2026, 02:25 Mohamed Boucadair via Datatracker, < [email protected]> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-oauth-identity-chaining-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi Arndt, Pieter, Kelley, Michael, Brian, and Aaron, > > Thank you for the effort put into this document. > > Thanks to Bing Liu for the OPSDIR review and the authors for engaging. > > Please find below some few minor comments: > > # It is not clear at this stage how a client knows that server in that > other > domain: > > CURRENT: > The client in trust domain A then presents > the received grant as an assertion to the authorization server in > trust domain B, using the JWT authorization grant feature of .. > > An easy fix is s/trust domain B/trust domain B (Section 2.2) > > # Mysterious use cases > > CURRENT: > The identity and authorization chaining flow outlined below describes > how a combination of OAuth 2.0 Token Exchange [RFC8693] and JWT > Profile for OAuth 2.0 Client Authentication and Authorization Grants > [RFC7523] are used to address the use cases identified. > > Which use cases are we referring to here? Those in the appendix? Else? > Please > clarify in the text. > > # Figure 1 > > How a client knows its trust domain and what triggers discovery of a > server in > another domain? > > # Discovery > > CURRENT: > This specification does not define authorization server discovery. A > client may use the authorization_servers property as defined in OAuth > 2.0 Protected Resource Metadata [RFC9728], maintain a static mapping > or use other means to identify the authorization server. > > The second sentence lists discovery examples which may be interpreted as > contradicting with “not define”. > > I think “s/does not define/does not mandate any” or similar would be > better. > > # I suggest to add a mention in the main body to introduce the appendixes. > > # A PR with some nits and minor edits [1]. Feel free to grab whatever > useful > for you. > > Cheers, > Med > > [1] https://github.com/oauth-wg/oauth-identity-chaining/pull/193 > > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
