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

[Breno de Medeiros]

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