OAuth 2.0 Authorization Server Issuer Identification
draft-ietf-oauth-iss-auth-resp-05

Thank you for the work on this document, and for addressing my DISCUSS.

Many thanks to Julian Reschke for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/XfLbtK1eLb7s0Z6e_AqGgkoWny0/.

Francesca

I support Francesca's DISCUSS.

I also concur with Eric's observations about the shepherd writeup.  Those important details are missing.

Please quote "iss" wherever you use it.  Every time I ran into it, my first thought was that it's a typo and I had to re-parse it a couple of times.

Thank you for this document, and also writing it in a manner that even someone unfamiliar with OAuth can understand :-)  -- I use it, but the internals are very much a black box to me...

Thank you for the work put into this document. 

Special thanks to Rifaat Shekh-Yusef for the shepherd's write-up, but alas it does not include ANY comments about the WG consensus and this it the most important point in the write-up. I am trusting the responsible AD and the WG chairs about the consensus.

I have no special comments to add: it looks 

Regards,

-éric

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.3. , paragraph 2, nit:
> s by any other mechanism which is outside of the scope of this specification.
>                                   ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 4. , paragraph 4, nit:
> f alternative countermeasures are outside of the scope of this specification.
>                                   ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

These URLs in the document can probably be converted to HTTPS:
 * http://arxiv.org/abs/1508.04324
 * http://www.iana.org/assignments/oauth-parameters
 * http://openid.net/specs/openid-connect-core-1_0.html

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