Coping with all the permutations but not the combinations seems to be a fairly bad task. <div>getting rid of spaces and connecting with an underscore seems to simplify the code. </div><div>If it were array, it were ok, but it is not. </div>
<div><br></div><div>=nat</div><div><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 11:27 PM, 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">
<div style="word-wrap:break-word">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><div class="h5"><div>On 2012-02-14, at 6:23 AM, Roland Hedberg wrote:</div><br></div></div><blockquote type="cite"><div><div>
<div class="h5"><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/" target="_blank">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></div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">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></div></blockquote></div><br></div></div></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>