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]
