[Openid-specs-ab] response_type=code id_token

John Bradley ve7jtb at ve7jtb.com
Tue Feb 14 15:46:07 UTC 2012


"id_token signed_request" would be valid if someone registered it.   You could have it return code and no id_token or something else unexpected. 

I am OK with having id_token_code for the response with code in id_token.

John
On 2012-02-14, at 12:24 PM, Nat Sakimura wrote:

> Indeed. Treating any permutation of "code token id_token" the same and treating "code token id_token signed_request" undefined is way too much work for both parties. 
> 
> One of our lead developer was so cynical to say that "OK. Let us define 100 response types tokens and register permutation of them and see if it does not blow up the registry." 
> 
> =nat
> 
> On Wed, Feb 15, 2012 at 12:17 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> In the OAuth WG there was a proposal for making return_type multi valued.   That was killed by people who din't want a breaking change.  
> So the compromise was to keep it as a single value but allow spaces so people could pretend it is multi valued.
> 
> The advantage is the client can say "code token" or "token code" and the authorization server MUST treat them as equivalent.
> 
> This is more work for the Authorization server and probably just confuses the client developer about what is happening.  
> 
> Why when I ask for code is it returned as a query parameter, but returned fragment encoded when I ask for "code token".   Pretending the individual elements have independent meaning leads people to wrong conclusions.
> 
> I don't want to try and change OAuth itself now.   
> 
> However we could decide to use an underscore rather than space to make it clearer to developers that it is a single value.
> 
> John B.
> 
> On 2012-02-14, at 11:41 AM, Nat Sakimura wrote:
> 
>> Coping with all the permutations but not the combinations seems to be a fairly bad task. 
>> getting rid of spaces and connecting with an underscore seems to simplify the code. 
>> If it were array, it were ok, but it is not. 
>> 
>> =nat
>> 
>> On Tue, Feb 14, 2012 at 11:27 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> It's all in the response type registration.  
>> 
>> Remember response type is a Single Value that may contain spaces.   This is perhaps proving to be the most confusing thing about the OAuth 2 spec.
>> 
>> There is no real difference between id_token_code and "id_token code" other than the fact that when you register "id_token code" you are also registering "code id_token" as an alias.
>> 
>> There is NO relationship between the string code on it's own and the string code occurring in combination with any other string in the return type.
>> 
>> That said it is probably best to reduce the confusion that developers will inevitably have not understanding that.
>> 
>> We can change the registration for the string "id_token code" to say that you get back a single fragment encoded parameter "id_token" containing code as a claim value.
>> We can change the registration for the string "id_token code token" to say that you get back two fragment encoded parameters "id_token" containing code as a claim value and access_token containing a access token.
>> 
>> I should point out the response_type token returns several parameters none of which are called token  i.e. access_token,  token_type, expires_in, and scope.  The symmetry is imaginary.
>> 
>> To Rolland's point about needing to unpack the id_token, the current logic is that you MUST unpack and verify the id_token directly or by using the check_id endpoint.
>> In my proposal you take the element code from the id_token and you are done.
>> In the alternate proposal, you MUST do all that then take the token_thumbprint parameter and compare it to a truncated hash of code.   adding several steps that cause this to be less secure and more complicated.
>> 
>> One alternative might be to get rid of the confusing space separated multi token return types.
>> 
>> Register id_token_code and id_token_code_token to make it clear that we are not implying a connection to the reregistered code response type.     
>> We could leave id_token code as is for those that don't care about validating code, or deprecate it.
>> 
>> My concern is that 90% of developers will never check the hash if we include the hash of code in  id_token.   If we include code in the id_token verification happens automatically.
>> 
>> The other issue is that Google is already putting the hash of code in id_token so they would need to agree to the change. 
>> 
>> If there is more support for including the hash of code in the id_token, so that the response is larger and more work to process, and most developers will ignore it anyway, I am OK with that.
>> 
>> I just want people to understand the options, so that when everyone sea why didn't you include code in id_token like Facebook is doing with signed_request,  how come I can't reuse the code I have for Facebook,  I can say we discussed it and decided it was not the correct option.
>> 
>> John B.
>> 
>> 
>> 
>> 
>> On 2012-02-14, at 6:23 AM, Roland Hedberg wrote:
>> 
>>> 
>>> 14 feb 2012 kl. 09:33 skrev Nat Sakimura:
>>> 
>>>> So, in today's WG Call, John explained that it was what FB was doing, and would probably be simpler for developers.
>>>> 
>>>> (It is tracked as https://bitbucket.org/openid/connect/issue/536/ )
>>>> 
>>>> I checked with Tatsuya, who is building solutions for our customer and he said it indeed would be simpler, so that is a good news.
>>> 
>>> I'm not sure it will be simpler, it will add another packing/unpacking layer.
>>> 
>>>> My concern is semantics.
>>>> 
>>>> As I understand, scope is something that request what is to be returned overall, and response_type is a parameter that request what is to be returned from the Authorization endpoint response parameters.
>>>> 
>>>> So, if response_type=code, code is returned from the Authz EP, and if response_type=token, token is retunred from the Authz EP. Expanding on this semantics, response_type=code id_token would mean that code and id_token has to be returned from Authz EP as independent parameters. If code is to be returned as part of the id_token, I feel that it should be just id_token, or a new response type such ascode_in_id_token.
>>> 
>>> Agree!
>>> So basically we have a set of components some of which could become part of another component.
>>> Either it's done implicit, that is the smallest number of components are supposed to be send.
>>> So, if "code id_token" is requested and code can be included in the id_token then an id_token would be transmitted with code inside.
>>> On the other hand would to do when "code token" is requested ? 
>>> Neither of them could contain the other. 
>>> Would an id_token be used then as a wrapper containing only the code and the token.
>>> 
>>> To me it sounds like we want a new type of wrapper object that could contain code, token and id_token.
>>> Rather than extend the existing id_token object.
>>> 
>>> -- Roland
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
>> 
>> 
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> 
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120214/6bf4087a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120214/6bf4087a/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list