Thank you.
If it is allowed that an "unspecified" behavior can be not only "not work correctly" but also "work correctly (as if scope included openid)", the condition "REQUIRED. OpenID Connect requests MUST contain the openid scope value" is not necessary (it doesn't have to say REQUIRED and MUST). Therefore, my natural interpretation is that an "unspecified" behavior is "not work correctly". However, this is my interpretation. If the interpretation is not a majority, I should accept that the example in "5. Definitions of Multi-Valued Response Type Combinations" is allowed as an unspecified behavior. Best Regards, Takahiko Kawasaki 2017-06-27 5:42 GMT+09:00 George Fletcher <gffle...@aol.com>: > From section 3.1.2.1 of the OpenID Connect Core... > > scope REQUIRED. OpenID Connect requests MUST contain the openid scope > value. *If the* *openid* *scope value is not present, the behavior is > entirely unspecified.* Other scope values MAY be present. Scope values > used that are not understood by an implementation SHOULD be ignored. See > Sections 5.4 > <http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims> and 11 > <http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess> for > additional scope values defined by this specification. > In this light, there is no specification that covers the behavior of the > AS given the authorization request you provided. > > At least that is my reading of the specs. > > Thanks, > George > > > On 6/26/17 1:59 PM, Takahiko Kawasaki wrote: > > Thank you. Please let me ask a simplified question. > > If an authorization server returns this response (including id_token): > > HTTP/1.1 302 Found > Location: https://client.example.org/cb# > access_token=SlAV32hkKG > &token_type=bearer > &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso > &expires_in=3600 > &state=af0ifjsldkj > > when it receives this request (without scope=openid): > > GET /authorize? > response_type=id_token%20token > &client_id=s6BhdRkqt3 > &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb > &state=af0ifjsldkj HTTP/1.1 > Host: server.example.com > > , is the implementation of the authorization server correct? > > Best Regards, > Takahiko Kawasaki > > > 2017-06-26 21:53 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft. > com>: > >> None of the examples in that spec are _*OpenID Connect*_ authentication >> requests. They are, however, valid _*OAuth 2.0**_* authorization >> requests. The one in question demonstrates use of the >> response_mode=id_token, as defined in the realm of OAuth 2.0. If (and only >> if) it had scope=openid, _*then*_ it would become an OpenID Connect auth >> request, and the OpenID Connect specs would apply. >> >> >> >> In other words, the fact that id_token is in the response_type does _ >> *not**_ *automatically make it an OpenID Connect request. >> >> >> >> Another way of seeing it is that the OAuth 2.0 Multiple Response Type >> Encoding spec is laying some foundations, as part of the OAuth 2.0 >> framework, upon which OpenID Connect is then built. >> >> >> >> In Section 11.3. OAuth Authorization Endpoint Response Types Registry >> <https://tools.ietf.org/html/rfc6749#section-11.3>, the OAuth 2.0 spec >> (RFC 6749) defines a registry of response types: >> >> >> >> This specification establishes the OAuth Authorization Endpoint >> >> Response Types registry. >> >> >> >> Then, in Section 3, ID Token Response Type >> <http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token>, >> OAuth 2.0 Multiple Response Types registers “id_token” as a response type >> in that same registry: >> >> >> >> This section registers a new Response Type, the id_token, in accordance >> with the stipulations in the OAuth 2.0 specification, Section 8.4. The >> intended purpose of the id_token is that it MUST provide an assertion of >> the identity of the Resource Owner as understood by the Authorization >> Server. The assertion MUST specify a targeted audience, e.g. the requesting >> Client. However, the specific semantics of the assertion and how it can be >> validated are not specified in this document. >> >> >> >> Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines >> (amongst other things) that including “scope=openid” is how the client >> indicates that this is an OpenID Connect request, makes use of the >> previously registered Response Type “id_token” (in some flows—other flows >> don’t use the “id_token” response type), and proceeds to specify the format >> and contents of the ID Token: >> >> >> >> OpenID Connect implements authentication as an extension to the OAuth 2.0 >> authorization process. Use of this extension is requested by Clients by >> including the openid scope value in the Authorization Request. >> Information about the authentication performed is returned in a *JSON >> Web Token (JWT)* >> <http://openid.net/specs/openid-connect-core-1_0.html#JWT> [JWT] called >> an ID Token (see *Section 2* >> <http://openid.net/specs/openid-connect-core-1_0.html#IDToken>). >> >> >> >> Philippe >> >> >> >> *From:* Takahiko Kawasaki [mailto:daru...@gmail.com] >> *Sent:* Monday, June 26, 2017 2:17 PM >> *To:* Philippe Signoret <philippe.signo...@microsoft.com> >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type >> Encoding Practices >> >> >> >> The response_type of the example includes id_token and it is the reason >> I've brought it up. id_token triggers Authentication Request. >> >> >> >> # The response_type in the example in Appendix A >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23FragmentExample&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761951990482&sdata=mRz8ViYA0cYXXO4iVw1vAgO4Xejh%2FDcxYegTfdeOSBw%3D&reserved=0> >> does not include id_token and so I've not mentioned it. >> >> >> >> Best, >> >> Taka >> >> >> >> >> >> >> >> 2017-06-26 17:09 GMT+09:00 Philippe Signoret < >> philippe.signo...@microsoft.com>: >> >> scope=openid is required for OpenID Connect Authentication Requests >> (e.g. "3.3.2.1. Authentication Request >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>" >> in "OpenID Connect Core 1.0 >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=FrFLKpyHVfZbRw1OsOs7QH%2F2bSrJbJluKnny0X%2FiJxw%3D&reserved=0>"), >> but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1. >> Authorization Request >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-4.1.1&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761952000490&sdata=%2FHh3%2BtauyK%2F03OVtSOX7p8XpidnT%2FPGHq8cwvl07vwg%3D&reserved=0>" >> in "RFC6749 The OAuth 2.0 Authorization Framework >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761952000490&sdata=a0%2BsS06wPx%2FxzxKc6z7pBXnQ0p4V7yciycZ%2F6uKJ2SU%3D&reserved=0> >> "). >> >> >> >> OpenID Connect is “an identity layer on top of the OAuth 2.0 protocol”. >> OpenID Connect specs will often refer to aspects of the OAuth 2.0 protocol, >> but the OAuth 2.0 specs will generally not refer to the OpenID Connect >> constructs. (Because OpenID Connect is a specific case of OAuth 2.0.) >> >> >> >> Philippe >> >> >> >> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Takahiko >> Kawasaki >> *Sent:* Monday, June 26, 2017 7:46 AM >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type >> Encoding Practices >> >> >> >> Hello, >> >> >> >> I'm not so sure that this is the right place to ask, but I'm wondering >> whether it is correct or not that the following non-normative example found >> in "5. Definitions of Multi-Valued Response Type Combinations >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23Combinations&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=A2%2F5R%2FFDSMUN8lthoex%2BAnF3h%2FouQHjXBPhW3Yv5D7M%3D&reserved=0>" >> in "OAuth 2.0 Multiple Response Type Encoding Practices >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=oax1ui3n46P2n67Mqx14t0458TZjrcw9IUsdCoGsmho%3D&reserved=0>" >> does not include "scope=openid". >> >> >> >> GET /authorize? >> >> response_type=id_token%20token >> >> &client_id=s6BhdRkqt3 >> >> &redirect_uri=https%3A%2F%2Fclient.example.org >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F2Fclient.example.org&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=%2BaCAvhV9qt75Cqajdrr84BVG6MRS3747Ux5CsjJtgQE%3D&reserved=0>%2Fcb >> >> &state=af0ifjsldkj HTTP/1.1 >> >> Host: server.example.com >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver.example.com&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=PoXzHooKqVnYx4pzWD%2B4THUElRZjsUC2TNdMlTrhfiY%3D&reserved=0> >> >> >> >> The reason I'm wondering is that "3.3.2.1. Authentication Request >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>" >> in "OpenID Connect Core 1.0 >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=FrFLKpyHVfZbRw1OsOs7QH%2F2bSrJbJluKnny0X%2FiJxw%3D&reserved=0>" >> requires Authentication Requests be made as defined in "3.1.2.1. >> Authentication Request >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23AuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=WoKMDXrFJDmvaGHGY8ry8Nn7iG5qliNjqNw8UamnHHg%3D&reserved=0>" >> and "3.1.2.1" requires the scope request parameter contain openid. >> >> >> >> >> >> Best Regards, >> >> Takahiko Kawasaki >> >> >> >> >> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
