Yes. <div><br></div><div>As I understand, OAuth's response_type parameter tells what is to be returned by the Authorization Endpoint. </div><div>We should stick to the semantics of it and should not alter it. </div><div>
<br></div><div>Perhaps we could state it in our specs, but that actually is something that OAuth spec. really should do. </div><div><br></div><div>FYI, I wrote a blog post with a table showing what are to be returned in each cases. </div>
<div><br></div><div>Hope this helps. </div><div><br></div><div><a href="http://nat.sakimura.org/2012/02/22/the-relationship-between-endpoint-responses-and-response_type-scope-pair/">http://nat.sakimura.org/2012/02/22/the-relationship-between-endpoint-responses-and-response_type-scope-pair/</a></div>
<div><br></div><div><br></div><div>=nat</div><div><br><div class="gmail_quote">On Wed, Feb 22, 2012 at 7:53 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Breno, keeping scopes and response types separate will cause fewer problems down the road.<br>
<br>
We have a number of new response types registered, (I may have to hurt the next person who talk about them being com posable.)<br>
<br>
Each response_type clearly defines what is returned from the authorization server, and how it is to be returned (ignoring grey area for post message).<br>
<br>
The openid scope makes the protocol openid asking for a authentication grant. e.g. Do you want to log into x and give them access to your user_id. Simple.<br>
<br>
The openid protocol requires that id_token is always returned from the token endpoint when exchanging code. Simple.<br>
<br>
The registered responstypes define what is returned from the authorization endpoint and how. Simple.<br>
<br>
Removing some of the return_types and overloading the openid scope with more semantics is more complicated.<br>
<br>
My opinion<br>
John B.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 2012-02-21, at 7:16 PM, Breno de Medeiros wrote:<br>
<br>
> On Tue, Feb 21, 2012 at 14:07, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br>
>> On not being OpenID: I would say that if you're not getting an ID Token<br>
>> back, you're not doing OpenID Connect, you're just doing OAuth2. If you<br>
>> happen to be doing OAuth2 against something that has a User Info Endpoint,<br>
>> that's fine, but it's not binding you to the user's session. It's definitely<br>
>> 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<br>
>> the ID Token?", and I think it should break down as follows (assuming user<br>
>> grants access and all else is validated):<br>
>><br>
>> - if the request to the token endpoint includes the scope 'openid', throw<br>
>> the id token into the JSON response<br>
>> - if the request to the authorization endpoint is for type 'token' and the<br>
>> scope includes 'openid', throw the id token into the fragment<br>
>> - if the request to the authorization endpoint is for type 'code id_token'<br>
>> and the scope includes 'openid', throw the id token into the fragment along<br>
>> with the code (again, avoids the query parameter leakage issue brought up<br>
>> before)<br>
>> - if the request to the authorization endpoint is for type 'code token' and<br>
>> the scope includes 'openid', throw the id token and the access token into<br>
>> the fragment along with the code<br>
>><br>
>> What I'm saying is that #3 above is an odd special case that could be<br>
>> subsumed by #4 above. This all gets rid of the need for the id_token<br>
>> response type entirely. Apart from being a breaking change, I don't see how<br>
>> this doesn't cover the use cases described below.<br>
><br>
> I don't see why this is simpler. It's actually more obscure to<br>
> developers. The scope 'openid' refers to scope of access -- namely the<br>
> request to learn the user's identifier at the issuer.<br>
><br>
>><br>
>> -- Justin<br>
>><br>
>><br>
>> On 02/21/2012 04:48 PM, John Bradley wrote:<br>
>><br>
>><br>
>> On 2012-02-21, at 5:41 PM, Justin Richer wrote:<br>
>><br>
>> John, thanks for the background. This leaves me with a major question<br>
>> though:<br>
>><br>
>> That was the way we originally had it. Later on people thought that using<br>
>> the OAuth multi-response type was more OAuth friendly.<br>
>><br>
>> Originally if you had the scope openid:<br>
>> 1 response_type=code both code and id_token were query encoded in the<br>
>> response<br>
>><br>
>><br>
>> Maybe I'm missing something, but in the "code" flow, you don't get back an<br>
>> id_token in that response. You get back a code, and that code can be<br>
>> exchanged for an access token and an id_token, since you asked for something<br>
>> that includes the "openid" scope. From Standard, section 2.2.1:<br>
>><br>
>> code When supplied as the value for the response_type parameter, a<br>
>> successful response MUST include an Authorization Code as defined in the<br>
>> OAuth 2.0 specification. Both successful and error responses MUST be added<br>
>> as parameters to the query component of the response. All tokens are<br>
>> returned from the Token Endpoint. Authorization Servers MUST support this<br>
>> response_type.<br>
>><br>
>> So the whole issue of query-encoding the id_token isn't even an option here.<br>
>> It *is* an option if you're asking for something akin to "code id_token",<br>
>> but that wasn't on the table. In the current spec, those are both defined as<br>
>> fragment encoded anyway.<br>
>><br>
>><br>
>> Having id_token returned in the front channel was one of the early must<br>
>> haves from the major IdP. Given that in the early days we returned<br>
>> id_token query encoded in the front channel and from the token endpoint.<br>
>> It looked like a hack. There was no way to change the semantics of code.<br>
>> With the multi token response type change around draft 19 of OAuth I think,<br>
>> Google and Facebook decided that was the best way to indicate the<br>
>> response_type, rather than overloading the semantics of scopes.<br>
>><br>
>> Currently if you ask for code it is defined in the OAuth 2 core spec and you<br>
>> get code back just as you would expect, the same goes for token. We avoided<br>
>> reinterpreting the OAuth spec as much as possible.<br>
>> The permissible way to ask for multiple tokens is the return type and that<br>
>> is what we are currently doing.<br>
>><br>
>><br>
>> 2 response_type=token both access_token and id_token were fragment encoded.<br>
>><br>
>> There was no way to just get code or access_token, and no way to get just<br>
>> id_token.<br>
>><br>
>><br>
>> The former, yes, there is: just don't include the "openid" scope. The<br>
>> latter, no. But if you ask for a token with just the "openid" scope and<br>
>> don't ask for any other permissions, the server *could* give you a null or<br>
>> empty or otherwise useless access token there, if it wanted to. I agree that<br>
>> if this is a real and viable use case, then it should be a separate kind of<br>
>> response_type, but I'm not seeing that right now.<br>
>><br>
>> The thing is that if you don't include the openid scope you are not doing<br>
>> openid Connect and our spec has nothing to say in the matter. So removing<br>
>> the openid scope so that the IdP can't tell if it is a connect request or<br>
>> some other OAuth request is not a real option.<br>
>><br>
>> The only thing I might change at this point on response_type if I had a do<br>
>> over would be to use underscores rather than spaces to reduce confusion.<br>
>> Other than that I don't think we have a problem.<br>
>><br>
>> In reality a client will only use a single response type appropriate for it.<br>
>> They are not dynamically changing these things. If you want code as a<br>
>> query parameter just ask for 'code' all the options are available to the<br>
>> clients without confusing it with the scopes.<br>
>><br>
>><br>
>> It was simpler I will give you that.<br>
>><br>
>> It is a bit different from adding id_token to the token endpoint in that<br>
>> there is no OAuth mechanism for controlling the response from the endpoint.<br>
>> I suppose the alternative would have been to add an extra parameter to the<br>
>> token endpoint request to say if you wanted a id_token.<br>
>><br>
>><br>
>> No, again, that's what the scope already handles. If we didn't have a<br>
>> standardized scope value, then I'd agree with this.<br>
>><br>
>> Again if you remove the openid scope it is not openid. That is the scope<br>
>> that asks for the user_info endpoint and the user_id.<br>
>><br>
>> John<br>
>><br>
>> -- Justin<br>
>><br>
>> - just using "token" instead of all combinations of id_token and token ?<br>
>><br>
>> The response type "token" could cause the OP to return both the id_token and<br>
>> the access token in the fragment, which is similar to the response of the<br>
>> tokens endpoint. I know this would return tokens the client is potentially<br>
>> not interested in. But this seems to be accepptable for the code response<br>
>> type.<br>
>><br>
>> I actually rather like this approach. It keeps the question of whether or<br>
>> not you want OpenID confined to the value of the 'scope' field (that is,<br>
>> presence of an 'openid' value in there), and it makes serialization of the<br>
>> ID Token just a part of the access token output, like the code flow with the<br>
>> token endpoint. Of course we still have to profile how it gets encoded, but<br>
>> it's ultimately another field in the token output.<br>
>><br>
>> -- Justin<br>
>><br>
>> Am 20.02.2012 20:44, schrieb John Bradley:<br>
>><br>
>> Response types are single values. (I am starting to hate Erin's<br>
>> compromise)<br>
>><br>
>> The response types are documented in:<br>
>> <a href="http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html" target="_blank">http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html</a><br>
>><br>
>> The response types "code id_token", "id_token token", and "code id_token<br>
>> token" MUST return a id_token and the response SHOULD be fragment encoded.<br>
>><br>
>> Now you are asking yourself why is that SHOULD be fragment encoded as<br>
>> opposed to MUST be fragment encoded.<br>
>><br>
>> The reason for that is that the response_type registration is leaving wiggle<br>
>> room to use the same response type with post message as well.<br>
>><br>
>> For that to work the client would need to register a JS Origin and DOM<br>
>> Channel Names(or pick a fixed strings). We did stub in post message<br>
>> configuration parameters, but removed them due to there not being a OAuth<br>
>> spec yet.<br>
>><br>
>> Probably more than the yes you were looking for, but the history provides<br>
>> some perspective.<br>
>><br>
>> John B.<br>
>> On 2012-02-20, at 3:52 PM, Torsten Lodderstedt wrote:<br>
>><br>
>> Hi John,<br>
>><br>
>> thanks for the clarification.<br>
>><br>
>> So all response types containing the string value "id_token" cause the<br>
>> authorization server to directly return a id_token (along with all other<br>
>> parameters) to the client via fragment?<br>
>><br>
>> regards,<br>
>> Torsten.<br>
>><br>
>> Am 20.02.2012 19:48, schrieb John Bradley:<br>
>><br>
>> Inline<br>
>><br>
>> On 2012-02-20, at 3:30 PM, Torsten Lodderstedt wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I'm trying to catch up with the Implementors Draft and need some advice from<br>
>> the group.<br>
>><br>
>> Is it correct that "code" is the only response type, which is delivered to<br>
>> the client via URI query parameter? For all other response types, the<br>
>> response parameters are encoded within the URI fragment.<br>
>><br>
>> Yes<br>
>><br>
>> Furthermore, is the client always issued an access token _and_ an id_token<br>
>> for scope "openid" and response type "code"?<br>
>><br>
>> The response from the Authorization server is code as was asked for.<br>
>><br>
>> The Token endpoint includes id_token in it's response as an extra parameter.<br>
>><br>
>> So strictly speaking Yes id_token is always issued if the scope is 'openid'<br>
>> (scope is a single value with spaces, so don't say includes) and the<br>
>> response_type is code.<br>
>><br>
>> However the response type is code and only code.<br>
>><br>
>> The id_token is only returned if code is exchanged at the token endpoint for<br>
>> and access_token and id_token.<br>
>><br>
>> So I suppose you could avoid getting id_token by not exchanging code, but I<br>
>> don't think anyone is going to think that is a good idea.<br>
>><br>
>> The problem is that response)type only controls what comes back from the<br>
>> Authorization endpoint, and not the token endpoint.<br>
>><br>
>> The only option we found was overloading a scope to change the behaviour of<br>
>> the token endpoint to return the extra value.<br>
>><br>
>> The token endpoint response is direct, so size is not a big issue. It was<br>
>> simpler to always return it from that endpoint than create a complicated way<br>
>> of asking for it from the token endpoint.<br>
>><br>
>> Worst case the response is a bit bigger, but the client ignores the extra<br>
>> parameter.<br>
>><br>
>> John B.<br>
>><br>
>> thanks in advance,<br>
>> Torsten.<br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
<br>
</div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>
</div>