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

[nov matake]

I confirmed FB returns both code and token in fragment.

On 2011/09/16, at 11:41, Breno de Medeiros wrote:

> On Thu, Sep 15, 2011 at 19:29, nov matake <nov at matake.jp> wrote:
>> OK, now I understood the requirements and I can agree with full fragment flow.
> 
> Sure.
> 
>> I feel it is OAuth issue not OpenID Connect issue though.
> 
> I agree.
> 
>> 
>> ps.
>> Does someone know about Facebook's code+token flow implementation?
>> If not, I'll try it.
> 
> I have been told it uses all fragment encoding.
> 
>> 
>> 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
>> 
>> 
> 
> 
> 
> -- 
> --Breno