Hi Rob! Thanks for your review. I wanted to close the loop on your COMMENT. See below.
> -----Original Message----- > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Robert Wilton via > Datatracker > Sent: Tuesday, November 30, 2021 5:31 AM > To: The IESG <i...@ietf.org> > Cc: oauth@ietf.org; draft-ietf-oauth-iss-auth-r...@ietf.org; oauth- > cha...@ietf.org > Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss- > auth-resp-03: (with COMMENT) > > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-iss-auth-resp-03: 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/blog/handling-iesg-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-iss-auth-resp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document, just one comment on a couple of sentences in the > security section that I found unclear in this paragraph: > > There are also alternative countermeasures to mix-up attacks. When > an authorization response already includes an authorization server's > issuer identifier by other means, and this identifier is checked as > laid out in Section 2.4, the use and verification of the iss > parameter is not necessary and MAY be omitted. This is the case when > OpenID Connect response types that return an ID token from the > authorization endpoint (e.g., response_type=code id_token) or JARM > response mode are used, for example. However, if a client receives > an authorization response that contains multiple issuer identifiers, > the client MUST reject the response if these issuer identifiers do > not match. The details of alternative countermeasures are outside of > the scope of this specification. > > I'm probably missing something but this seems to suggest both: > - the use and verification of the iss parameter is not necessary and MAY be > omitted. - if a client receives an authorization response that contains > multiple > issuer identifiers, > the client MUST reject the response if these issuer identifiers do not > match. Indeed, both are suggested courses of action, but across three scenarios: (a) one iss which gets compared against the server's metadata document (paragraph 2 of Section 2.4) (b) no iss is present because there is a OpenIDConnect ID token or JARM JWT (both mechanisms provide a nearly equivalent mitigation to "iss", see last three paragraphs of Section 2.4) (c) multiple iss where the above behavior applies for rejection if they don't match; and also checks per (a) (this text) Regards, Roman _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
