[Openid-specs-ab] Responses for multiple response_type - Issue #31
Breno de Medeiros
breno at google.com
Fri Sep 16 02:17:59 UTC 2011
Sorry, but simplicity is not the issue here. The point here is that if
you have javascript code and are using the token flow, it's
_incorrect_ to force you to re-fetch the application. That's not how
people write AJAX apps. If you want simplicity, you use the pure code
flow.
On Thu, Sep 15, 2011 at 19:10, hideki nara <hdknr at ic-tact.co.jp> wrote:
> 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
>>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
--
--Breno
More information about the Openid-specs-ab
mailing list