<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On not being OpenID: I would say that if you're not getting an ID
    Token back, you're not doing OpenID Connect, you're just doing
    OAuth2. If you happen to be doing OAuth2 against something that has
    a User Info Endpoint, that's fine, but it's not binding you to the
    user's session. It's definitely the right thing to avoid mucking
    about with OAuth2 wherever possible. <br>
    <br>
    But the question being addressed below was "how do I know when to
    include the ID Token?", and I think it should break down as follows
    (assuming user grants access and all else is validated):<br>
    <br>
    - if the request to the token endpoint includes the scope 'openid',
    throw the id token into the JSON response<br>
    - if the request to the authorization endpoint is for type 'token'
    and the scope includes 'openid', throw the id token into the
    fragment<br>
    - if the request to the authorization endpoint is for type 'code
    id_token' and the scope includes 'openid', throw the id token into
    the fragment along with the code (again, avoids the query parameter
    leakage issue brought up before)<br>
    - if the request to the authorization endpoint is for type 'code
    token' and the scope includes 'openid', throw the id token and the
    access token into the fragment along with the code<br>
    <br>
    What I'm saying is that #3 above is an odd special case that could
    be subsumed by #4 above. This all gets rid of the need for the
    id_token response type entirely. Apart from being a breaking change,
    I don't see how this doesn't cover the use cases described below.<br>
    <br>
     -- Justin<br>
    <br>
    On 02/21/2012 04:48 PM, John Bradley wrote:
    <blockquote
      cite="mid:99ABE28A-702D-4E86-A4E9-D49A57174F25@ve7jtb.com"
      type="cite"><br>
      <div>
        <div>On 2012-02-21, at 5:41 PM, Justin Richer wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          <div bgcolor="#FFFFFF" text="#000000"> John, thanks for the
            background. This leaves me with a major question though:<br>
            <br>
            <blockquote
              cite="mid:B1146249-6C51-403C-A33C-8AC9A6E4CD48@ve7jtb.com"
              type="cite">
              <pre wrap="">That was the way we originally had it.   Later on people thought that using the OAuth multi-response type was more OAuth friendly.

Originally if you had the scope openid:
1 response_type=code   both code and id_token were query encoded in the response</pre>
            </blockquote>
            <br>
            Maybe I'm missing something, but in the "code" flow, you
            don't get back an id_token in that response. You get back a
            code, and that code can be exchanged for an access token and
            an id_token, since you asked for something that includes the
            "openid" scope. From Standard, section 2.2.1:<br>
            <br>
            <div>
              <div>
                <div>
                  <div>
                    <div> <dt>code</dt>
                      <dd> When supplied as the value for the <tt>response_type</tt>
                        parameter, a successful response MUST include an
                        Authorization Code as defined in the OAuth 2.0
                        specification. Both successful and error
                        responses MUST be added as parameters to the
                        query component of the response. All tokens are
                        returned from the Token Endpoint. Authorization
                        Servers MUST support this <tt>response_type</tt>.
                      </dd>
                    </div>
                  </div>
                </div>
              </div>
            </div>
            <div> </div>
            <br>
            So the whole issue of query-encoding the id_token isn't even
            an option here. It *is* an option if you're asking for
            something akin to "code id_token", but that wasn't on the
            table. In the current spec, those are both defined as
            fragment encoded anyway.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        Having id_token returned in the front channel was one of the
        early must haves from the major IdP.   Given that in the early
        days we returned id_token query encoded in the front channel and
        from the token endpoint.  </div>
      <div>It looked like a hack.   There was no way to change the
        semantics of code.   With the multi token response type change
        around draft 19 of OAuth I think,  Google and Facebook decided
        that was the best way to indicate the response_type, rather than
        overloading the semantics of scopes.</div>
      <div><br>
      </div>
      <div>Currently if you ask for code it is defined in the OAuth 2
        core spec and you get code back just as you would expect, the
        same goes for token.  We avoided reinterpreting the OAuth spec
        as much as possible.</div>
      <div>The permissible way to ask for multiple tokens is the return
        type and that is what we are currently doing.</div>
      <div><br>
        <blockquote type="cite">
          <div bgcolor="#FFFFFF" text="#000000"> <br>
            <blockquote
              cite="mid:B1146249-6C51-403C-A33C-8AC9A6E4CD48@ve7jtb.com"
              type="cite">
              <pre wrap="">2 response_type=token  both access_token and id_token were fragment encoded.

There was no way to just get code or access_token, and no way to get just id_token.
</pre>
            </blockquote>
            <br>
            The former, yes, there is: just don't include the "openid"
            scope. The latter, no. But if you ask for a token with just
            the "openid" scope and don't ask for any other permissions,
            the server *could* give you a null or empty or otherwise
            useless access token there, if it wanted to. I agree that if
            this is a real and viable use case, then it should be a
            separate kind of response_type, but I'm not seeing that
            right now.<br>
            <br>
          </div>
        </blockquote>
        The thing is that if you don't include the openid scope you are
        not doing openid Connect and our spec has nothing to say in the
        matter.   So removing the openid scope so that the IdP can't
        tell if it is a connect request or some other OAuth request is
        not a real option.</div>
      <div><br>
      </div>
      <div>The only thing I might change at this point on response_type
        if I had a do over would be to use underscores rather than
        spaces to reduce confusion.   Other than that I don't think we
        have a problem.</div>
      <div><br>
      </div>
      <div>In reality a client will only use a single response type
        appropriate for it.   They are not dynamically changing these
        things.   If you want code as a query parameter just ask for
        'code' all the options are available to the clients without
        confusing it with the scopes.</div>
      <div><br>
      </div>
      <div><br>
        <blockquote type="cite">
          <div bgcolor="#FFFFFF" text="#000000">
            <blockquote
              cite="mid:B1146249-6C51-403C-A33C-8AC9A6E4CD48@ve7jtb.com"
              type="cite">
              <pre wrap="">It was simpler I will give you that.

It is a bit different from adding id_token to the token endpoint in that there is no OAuth mechanism for controlling the response from the endpoint.  I suppose the alternative would have been to add an extra parameter to the token endpoint request to say if you wanted a id_token.
</pre>
            </blockquote>
            <br>
            No, again, that's what the scope already handles. If we
            didn't have a standardized scope value, then I'd agree with
            this.<br>
            <br>
          </div>
        </blockquote>
        <div>Again if you remove the openid scope it is not openid.
           That is the scope that asks for the user_info endpoint and
          the user_id.</div>
        <div><br>
        </div>
        <div>John</div>
        <br>
        <blockquote type="cite">
          <div bgcolor="#FFFFFF" text="#000000">  -- Justin<br>
            <br>
            <blockquote
              cite="mid:B1146249-6C51-403C-A33C-8AC9A6E4CD48@ve7jtb.com"
              type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">- just using "token" instead of all combinations of id_token and token ?

The response type "token" could cause the OP to return both the id_token and the access token in the fragment, which is similar to the response of the tokens endpoint. I know this would return tokens the client is potentially not interested in. But this seems to be accepptable for the code response type.

</pre>
                </blockquote>
                <pre wrap="">I actually rather like this approach. It keeps the question of whether or not you want OpenID confined to the value of the 'scope' field (that is, presence of an 'openid' value in there), and it makes serialization of the ID Token just a part of the access token output, like the code flow with the token endpoint. Of course we still have to profile how it gets encoded, but it's ultimately another field in the token output.

-- Justin

</pre>
                <blockquote type="cite">
                  <pre wrap="">Am 20.02.2012 20:44, schrieb John Bradley:
</pre>
                  <blockquote type="cite">
                    <pre wrap="">Response types are single values.   (I am starting to hate Erin's compromise)

The response types are documented in: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html">http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html</a>

The response types "code id_token",  "id_token token", and "code id_token token"  MUST return a id_token and the response SHOULD be fragment encoded.

Now you are asking yourself why is that SHOULD be fragment encoded as opposed to MUST be fragment encoded.

The reason for that is that the response_type registration is leaving wiggle room to use the same response type with post message as well.

For that to work the client would need to register a JS Origin and DOM Channel Names(or pick a fixed strings).  We did stub in post message configuration parameters, but removed them due to there not being a OAuth spec yet.

Probably more than the yes you were looking for, but the history provides some perspective.

John B.
On 2012-02-20, at 3:52 PM, Torsten Lodderstedt wrote:

</pre>
                    <blockquote type="cite">
                      <pre wrap="">Hi John,

thanks for the clarification.

So all response types containing the string value "id_token" cause the authorization server to directly return a id_token (along with all other parameters) to the client via fragment?

regards,
Torsten.

Am 20.02.2012 19:48, schrieb John Bradley:
</pre>
                      <blockquote type="cite">
                        <pre wrap="">Inline

On 2012-02-20, at 3:30 PM, Torsten Lodderstedt wrote:

</pre>
                        <blockquote type="cite">
                          <pre wrap="">Hi all,

I'm trying to catch up with the Implementors Draft and need some advice from the group.

Is it correct that "code" is the only response type, which is delivered to the client via URI query parameter? For all other response types, the response parameters are encoded within the URI fragment.
</pre>
                        </blockquote>
                        <pre wrap="">Yes
</pre>
                        <blockquote type="cite">
                          <pre wrap="">Furthermore, is the client always issued an access token _and_ an id_token for scope "openid" and response type "code"?
</pre>
                        </blockquote>
                        <pre wrap="">The response from the Authorization server is code as was asked for.

The Token endpoint includes id_token in it's response as an extra parameter.

So strictly speaking Yes id_token is always issued if the scope is 'openid'  (scope is a single value with spaces, so don't say includes) and the response_type is code.

However the response type is code and only code.

The id_token is only returned if code is exchanged at the token endpoint for and access_token and id_token.

So I suppose you could avoid getting id_token by not exchanging code, but I don't think anyone is going to think that is a good idea.

The problem is that response)type only controls what comes back from the Authorization endpoint, and not the token endpoint.

The only option we found was overloading a scope to change the behaviour of the token endpoint to return the extra value.

The token endpoint response is direct, so size is not a big issue.  It was simpler to always return it from that endpoint than create a complicated way of asking for it from the token endpoint.

Worst case the response is a bit bigger, but the client ignores the extra parameter.

John B.
</pre>
                        <blockquote type="cite">
                          <pre wrap="">thanks in advance,
Torsten.
_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
                        </blockquote>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>