<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">It's all in the response type registration. <div><br></div><div>Remember response type is a <b>Single Value</b> that may contain spaces. This is perhaps proving to be the most confusing thing about the OAuth 2 spec.</div><div><br></div><div>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.</div><div><br></div><div>There is <b>NO </b>relationship between the string code on it's own and the string code occurring in combination with any other string in the return type.</div><div><br></div><div>That said it is probably best to reduce the confusion that developers will inevitably have not understanding that.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>In my proposal you take the element code from the id_token and you are done.</div><div>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.</div><div><br></div><div>One alternative might be to get rid of the confusing space separated multi token return types.</div><div><br></div><div>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. </div><div>We could leave id_token code as is for those that don't care about validating code, or deprecate it.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On 2012-02-14, at 6:23 AM, Roland Hedberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>14 feb 2012 kl. 09:33 skrev Nat Sakimura:<br><br><blockquote type="cite">So, in today's WG Call, John explained that it was what FB was doing, and would probably be simpler for developers.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(It is tracked as <a href="https://bitbucket.org/openid/connect/issue/536/">https://bitbucket.org/openid/connect/issue/536/</a> )<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><br>I'm not sure it will be simpler, it will add another packing/unpacking layer.<br><br><blockquote type="cite">My concern is semantics.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><br>Agree!<br>So basically we have a set of components some of which could become part of another component.<br>Either it's done implicit, that is the smallest number of components are supposed to be send.<br>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.<br>On the other hand would to do when "code token" is requested ? <br>Neither of them could contain the other. <br>Would an id_token be used then as a wrapper containing only the code and the token.<br><br>To me it sounds like we want a new type of wrapper object that could contain code, token and id_token.<br>Rather than extend the existing id_token object.<br><br>-- Roland<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>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></blockquote></div><br></div></body></html>