Hi Roman, Thanks for getting back to me - I'm somewhat out of my depth here, but really I think that I find this sentence to be somewhat ambiguous: "the use and verification of the iss parameter is not necessary and MAY be omitted."
I read this as allowing both: (i) a send can choose to not include the iss parameter (under the given scenarios). (ii) a receiver can choose to not verify the iss parameter (under the given scenarios). >From you comments below, I think that the text is only intended to mean (i). >If so, perhaps the sentence would be clearer as just "the iss parameter is not >necessary and MAY be omitted"? But if you feel the that text is sufficiently clear that is also okay with me. Thanks, Rob > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Roman Danyliw > Sent: 05 January 2022 15:13 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org> > Cc: oauth-cha...@ietf.org; oauth@ietf.org; draft-ietf-oauth-iss-auth- > r...@ietf.org > Subject: RE: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth- > iss-auth-resp-03: (with COMMENT) > > 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
