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

[Roman Danyliw <[e-mail]>]

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