Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Roman Danyliw
> Sent: 05 January 2022 15:13
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-oauth-iss-auth-
> [e-mail]
> 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 <[e-mail]> On Behalf Of Robert Wilton via
> > Datatracker
> > Sent: Tuesday, November 30, 2021 5:31 AM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; oauth-
> > [e-mail]
> > 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