[Openid-specs-ab] Responses for multiple response_type - Issue #31

[hideki nara]

I vote for John.

If there are some important reason to return code  + token at the same
time,  client should process them
at the same time.
If only the code is returned in query parameter,  client may process it
without the returned token.

I know clients can process code later if anonymous session hold auth request
objects, but
it is not simple implementation.

I might missed some important issues...

---
hdknr


2011/9/16 Edmund Jay <ejay at mgi1.com>

> While trying to resolve issue # 31 (
> https://bitbucket.org/openid/connect/issue/31/standard-5121-inconsistency-with-messages) in the Issue Tracker, the working group runs in to the problem of how to
> return authorization responses when multiple response_types are requested.
>
> According to the OAuth 2.0 specs, the responses are returned as follows :
>
> response_type                   response
> -----------------------------------------------------
> code                                code returned in the query
> token                               token returned in the fragment
>
> code token                       unspecified (leave open for possible
> extension spec to register response_type combination)
>
> code id_token
> token id_token
> code token id_token
>
>
> For the unspecified cases, John Bradley holds the position that if a
> fragment is returned, then all parameters are returned in the fragment.
> Others (Nat, Edmund) believes that code should be returned in the query
> while token and id_token are always returned in the fragment.
>
> We would like to request consensus from the group on how to handle such
> responses, so that the responses for the specified combinations can be
> clearly specified and registered with OAuth.
>
> -- Edmund
>
>
> _______________________________________________
> 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/20110916/4845680d/attachment.html>