Breno, <div><br></div><div>That actually raises another question. <div><br></div><div>When the response_type=code%20id_token, is the code returned in the query string, or is it returned in the fragment? </div><div><br></div>
<div>I would very much appreciate a full documentation wrt this. </div><div><br></div><div>Regards, </div><div><br></div><div>Nat<br><br><div class="gmail_quote">On Thu, Sep 15, 2011 at 6:23 PM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Sep 15, 2011 at 17:52, nov matake <<a href="mailto:nov@matake.jp">nov@matake.jp</a>> wrote:<br>

> +1 for code in query and token in fragment<br>
> I don't get the reason why (mainly JS) clients need code in fragment even<br>
> when token is already there.<br>
<br>
</div>That's not correct -- JS applications need _all_ parameters in<br>
fragment or otherwise they get re-fetched from server and re-started.<br>
If the values are in fragment, the app can just be re-started from<br>
local cache.<br>
<br>
Every integration with javascript should use full fragment encoding.<br>
So every response that includes 'token' should have all parameters<br>
fragment encoded.<br>
<div><div></div><div class="h5"><br>
<br>
> On 2011/09/16, at 9:33, Edmund Jay wrote:<br>
><br>
> While trying to resolve issue # 31<br>
> ( <a href="https://bitbucket.org/openid/connect/issue/31/standard-5121-inconsistency-with-messages" target="_blank">https://bitbucket.org/openid/connect/issue/31/standard-5121-inconsistency-with-messages</a> )<br>
> in the Issue Tracker, the working group runs in to the problem of how to<br>
> return authorization responses when multiple response_types are requested.<br>
><br>
> According to the OAuth 2.0 specs, the responses are returned as follows :<br>
><br>
> response_type                   response<br>
> -----------------------------------------------------<br>
> code                                code returned in the query<br>
> token                               token returned in the fragment<br>
><br>
> code token                       unspecified (leave open for possible<br>
> extension spec to register response_type combination)<br>
><br>
> code id_token<br>
> token id_token<br>
> code token id_token<br>
><br>
><br>
> For the unspecified cases, John Bradley holds the position that if a<br>
> fragment is returned, then all parameters are returned in the fragment.<br>
> Others (Nat, Edmund) believes that code should be returned in the query<br>
> while token and id_token are always returned in the fragment.<br>
><br>
> We would like to request consensus from the group on how to handle such<br>
> responses, so that the responses for the specified combinations can be<br>
> clearly specified and registered with OAuth.<br>
><br>
> -- Edmund<br>
><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>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><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>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
--Breno<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">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></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></div>