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

[nov matake]

OK, now I understood the requirements and I can agree with full fragment flow.
I feel it is OAuth issue not OpenID Connect issue though.

ps.
Does someone know about Facebook's code+token flow implementation?
If not, I'll try it.

Facebook is already supporting the flow though.

On 2011/09/16, at 10:47, Breno de Medeiros wrote:

> On Thu, Sep 15, 2011 at 18:43, Nat Sakimura <sakimura at gmail.com> wrote:
>> Breno,
>> That actually raises another question.
>> When the response_type=code%20id_token, is the code returned in the query
>> string, or is it returned in the fragment?
>> I would very much appreciate a full documentation wrt this.
> 
> The answer in this case is not as clear cut. It's problematic to send
> a non-encrypted id_token via query parameters due to leakage issues.
> If you're going to encode something in the fragment, I'd rather encode
> it all in fragment. I believe that partial encoding in
> query-and-fragment is _never_ a good answer.
> 
> The best answer might be something like:
> 
> - If using encryption, it's okay to send in query; otherwise, send in fragment.
> 
> - Since I don't think we're describing encryption now, I'd rather say fragment.
> 
>> Regards,
>> Nat
>> 
>> On Thu, Sep 15, 2011 at 6:23 PM, Breno de Medeiros <breno at google.com> wrote:
>>> 
>>> 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
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
>> 
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> 
> 
> 
> 
> -- 
> --Breno