[Openid-specs-ab] response_type=code id_token

John Bradley ve7jtb at ve7jtb.com
Tue Feb 14 14:27:12 UTC 2012

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120214/f0816855/attachment.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/f0816855/attachment.p7s>

More information about the Openid-specs-ab mailing list