[Openid-specs-ab] Response types clarification

Justin Richer jricher at mitre.org
Tue Feb 21 18:01:41 UTC 2012

> - 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.

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

> Am 20.02.2012 20:44, schrieb John Bradley:
>> Response types are single values.   (I am starting to hate Erin's 
>> compromise)
>> The response types are documented in: 
>> http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
>> 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:
>>> 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:
>>>> Inline
>>>> On 2012-02-20, at 3:30 PM, Torsten Lodderstedt wrote:
>>>>> 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.
>>>> Yes
>>>>> Furthermore, is the client always issued an access token _and_ an 
>>>>> id_token for scope "openid" and response type "code"?
>>>> 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.
>>>>> thanks in advance,
>>>>> Torsten.
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list