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

[Robert Wilton via Datatracker <[e-mail]>]

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.

These seems to conflict to me, but perhaps I'm misunderstanding their intent?

Regards,
Rob