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

[Breno de Medeiros]

On Thu, Sep 15, 2011 at 17:52, nov matake <nov at matake.jp> wrote:
> +1 for code in query and token in fragment
> I don't get the reason why (mainly JS) clients need code in fragment even
> when token is already there.

That's not correct -- JS applications need _all_ parameters in
fragment or otherwise they get re-fetched from server and re-started.
If the values are in fragment, the app can just be re-started from
local cache.

Every integration with javascript should use full fragment encoding.
So every response that includes 'token' should have all parameters
fragment encoded.


> On 2011/09/16, at 9:33, Edmund Jay wrote:
>
> 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
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



-- 
--Breno