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

[Breno de Medeiros]

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