Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 26 Jun 2017 14:46:19 +0900

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
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations>"
in "OAuth 2.0 Multiple Response Type Encoding Practices
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>" does
not include "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

The reason I'm wondering is that "3.3.2.1. Authentication Request
<http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest>"
in "OpenID Connect Core 1.0
<http://openid.net/specs/openid-connect-core-1_0.html>" requires
Authentication Requests be made as defined in "3.1.2.1. Authentication
Request <http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest>"
and "3.1.2.1" requires the scope request parameter contain openid.

Best Regards,
Takahiko Kawasaki

---

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 26 Jun 2017 21:16:32 +0900

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
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#FragmentExample>
does not include id_token and so I've not mentioned it.

Best,
Taka

2017-06-26 17:09 GMT+09:00 Philippe Signoret <
[email-masked]>:

> 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>"
> <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://tools.ietf.org/html/rfc6749#section-4.1.1>"
> in "RFC6749 The OAuth 2.0 Authorization Framework
> <https://tools.ietf.org/html/rfc6749>").
>
>
>
> 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:[email-masked]] *On Behalf Of *Takahiko
> Kawasaki
> *Sent:* Monday, June 26, 2017 7:46 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type
> Encoding Practices
>
>
>
> Hello,
>
>
>
> <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>"
> <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?
>
>     &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
>
>   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>
>
>
>
> <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>"
> <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>"

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 27 Jun 2017 02:59:24 +0900

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?

, is the implementation of the authorization server correct?

Best Regards,
Takahiko Kawasaki

2017-06-26 21:53 GMT+09:00 Philippe Signoret <
[email-masked]>:

> 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:[email-masked]]
> *Sent:* Monday, June 26, 2017 2:17 PM
> *To:* Philippe Signoret <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Example 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%23FragmentExample&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761951990482&sdata=mRz8ViYA0cYXXO4iVw1vAgO4Xejh%2FDcxYegTfdeOSBw%3D&reserved=0>
> 2017-06-26 17:09 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.
> com>:
>
> 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>"
> <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>
> ").
>
>
>

---

From: George Fletcher <[email-masked]>
Date: Mon, 26 Jun 2017 16:42:34 -0400

From section 3.1.2.1 of the OpenID Connect Core...

scope
    REQUIRED. OpenID Connect requests MUST contain theopenidscope 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 Sections5.4
    <http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims>and11
    <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:
> 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
>      &redirect_uri=https%3A%2F%2Fclient.example.org <http://2Fclient.example.org>%2Fcb
>    Host:server.example.com <http://server.example.com>
> 2017-06-26 21:53 GMT+09:00 Philippe Signoret 
> <[email-masked] 
> <mailto:[email-masked]>>:
>
>     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:
>
>     OAuth 2.0 Multiple Response Types registers “id_token” as a
>     response type in that same registry:
>
>     This section registers a new Response Type, theid_token, in
>     accordance with the stipulations in the OAuth 2.0 specification,
>     Section 8.4. The intended purpose of theid_tokenis 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 theopenidscope 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*
>     *From:*Takahiko Kawasaki [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Philippe Signoret <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *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.
>
>     2017-06-26 17:09 GMT+09:00 Philippe Signoret
>     <[email-masked]
>     <mailto:[email-masked]>>:
>
>         scope=openidis required for OpenID Connect Authentication
>         Requests (e.g. "3.3.2.1. Authentication Request
>         <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:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Takahiko Kawasaki
>         *To:* [email-masked] <mailto:[email-masked]>
>         *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
>             &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
>
>         <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>
>
>         requires Authentication Requests be made as defined in
>         "3.1.2.1. Authentication Request
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 27 Jun 2017 13:20:26 +0900

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 <[email-masked]>:

> 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
> 2017-06-26 21:53 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.
> com>:
>
>> In other words, the fact that id_token is in the response_type does _
>> *not**_ *automatically make it an OpenID Connect 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*
>> scope=openid is required for OpenID Connect Authentication Requests
>> (e.g. "3.3.2.1. Authentication Request
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>