[Openid-specs-ab] response_type=code id_token

Nat Sakimura sakimura at gmail.com
Tue Feb 14 15:49:50 UTC 2012


That's exactly the point.

If someone did not register "code token id_token signed_request",
even if individual elements are registered, it MUST be treated as invalid.
But at the same time, if someone registered it, it has to be enabled.
That means, the implementations MUST keep parsing the IANA registry,
which is not particularly well structured nor guaranteed to be very
scalable.

=nat

On Wed, Feb 15, 2012 at 12:46 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> "id_token signed_request" would be valid if someone registered it.   You
> could have it return code and no id_token or something else unexpected.
>
> I am OK with having id_token_code for the response with code in id_token.
>
> John
>
> On 2012-02-14, at 12:24 PM, Nat Sakimura wrote:
>
> Indeed. Treating any permutation of "code token id_token" the same and
> treating "code token id_token signed_request" undefined is way too much
> work for both parties.
>
> One of our lead developer was so cynical to say that "OK. Let us define
> 100 response types tokens and register permutation of them and see if it
> does not blow up the registry."
>
> =nat
>
> On Wed, Feb 15, 2012 at 12:17 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>> In the OAuth WG there was a proposal for making return_type multi valued.
>>   That was killed by people who din't want a breaking change.
>> So the compromise was to keep it as a single value but allow spaces so
>> people could pretend it is multi valued.
>>
>> The advantage is the client can say "code token" or "token code" and the
>> authorization server MUST treat them as equivalent.
>>
>> This is more work for the Authorization server and probably just confuses
>> the client developer about what is happening.
>>
>> Why when I ask for code is it returned as a query parameter, but returned
>> fragment encoded when I ask for "code token".   Pretending the individual
>> elements have independent meaning leads people to wrong conclusions.
>>
>> I don't want to try and change OAuth itself now.
>>
>> However we could decide to use an underscore rather than space to make it
>> clearer to developers that it is a single value.
>>
>> John B.
>>
>> On 2012-02-14, at 11:41 AM, Nat Sakimura wrote:
>>
>> Coping with all the permutations but not the combinations seems to be a
>> fairly bad task.
>> getting rid of spaces and connecting with an underscore seems to simplify
>> the code.
>> If it were array, it were ok, but it is not.
>>
>> =nat
>>
>> On Tue, Feb 14, 2012 at 11:27 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>>> It's all in the response type registration.
>>>
>>> Remember response type is a *Single Value* that may contain spaces.
>>> This is perhaps proving to be the most confusing thing about the OAuth 2
>>> spec.
>>>
>>> There is no real difference between id_token_code and "id_token code"
>>> other than the fact that when you register "id_token code" you are also
>>> registering "code id_token" as an alias.
>>>
>>> There is *NO *relationship between the string code on it's own and the
>>> string code occurring in combination with any other string in the return
>>> type.
>>>
>>> That said it is probably best to reduce the confusion that developers
>>> will inevitably have not understanding that.
>>>
>>> We can change the registration for the string "id_token code" to say
>>> that you get back a single fragment encoded parameter "id_token" containing
>>> code as a claim value.
>>> We can change the registration for the string "id_token code token" to
>>> say that you get back two fragment encoded parameters "id_token" containing
>>> code as a claim value and access_token containing a access token.
>>>
>>> I should point out the response_type token returns several parameters
>>> none of which are called token  i.e. access_token,  token_type, expires_in,
>>> and scope.  The symmetry is imaginary.
>>>
>>> To Rolland's point about needing to unpack the id_token, the current
>>> logic is that you MUST unpack and verify the id_token directly or by using
>>> the check_id endpoint.
>>> In my proposal you take the element code from the id_token and you are
>>> done.
>>> In the alternate proposal, you MUST do all that then take the
>>> token_thumbprint parameter and compare it to a truncated hash of code.
>>> adding several steps that cause this to be less secure and more complicated.
>>>
>>> One alternative might be to get rid of the confusing space separated
>>> multi token return types.
>>>
>>> Register id_token_code and id_token_code_token to make it clear that we
>>> are not implying a connection to the reregistered code response type.
>>> We could leave id_token code as is for those that don't care about
>>> validating code, or deprecate it.
>>>
>>> My concern is that 90% of developers will never check the hash if we
>>> include the hash of code in  id_token.   If we include code in the id_token
>>> verification happens automatically.
>>>
>>> The other issue is that Google is already putting the hash of code in
>>> id_token so they would need to agree to the change.
>>>
>>> If there is more support for including the hash of code in the id_token,
>>> so that the response is larger and more work to process, and most
>>> developers will ignore it anyway, I am OK with that.
>>>
>>> I just want people to understand the options, so that when everyone sea
>>> why didn't you include code in id_token like Facebook is doing with
>>> signed_request,  how come I can't reuse the code I have for Facebook,  I
>>> can say we discussed it and decided it was not the correct option.
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>> On 2012-02-14, at 6:23 AM, Roland Hedberg wrote:
>>>
>>>
>>> 14 feb 2012 kl. 09:33 skrev Nat Sakimura:
>>>
>>> So, in today's WG Call, John explained that it was what FB was doing,
>>> and would probably be simpler for developers.
>>>
>>>
>>> (It is tracked as https://bitbucket.org/openid/connect/issue/536/ )
>>>
>>>
>>> I checked with Tatsuya, who is building solutions for our customer and
>>> he said it indeed would be simpler, so that is a good news.
>>>
>>>
>>> I'm not sure it will be simpler, it will add another packing/unpacking
>>> layer.
>>>
>>> My concern is semantics.
>>>
>>>
>>> As I understand, scope is something that request what is to be returned
>>> overall, and response_type is a parameter that request what is to be
>>> returned from the Authorization endpoint response parameters.
>>>
>>>
>>> So, if response_type=code, code is returned from the Authz EP, and if
>>> response_type=token, token is retunred from the Authz EP. Expanding on this
>>> semantics, response_type=code id_token would mean that code and id_token
>>> has to be returned from Authz EP as independent parameters. If code is to
>>> be returned as part of the id_token, I feel that it should be just
>>> id_token, or a new response type such ascode_in_id_token.
>>>
>>>
>>> Agree!
>>> So basically we have a set of components some of which could become part
>>> of another component.
>>> Either it's done implicit, that is the smallest number of components are
>>> supposed to be send.
>>> So, if "code id_token" is requested and code can be included in the
>>> id_token then an id_token would be transmitted with code inside.
>>> On the other hand would to do when "code token" is requested ?
>>> Neither of them could contain the other.
>>> Would an id_token be used then as a wrapper containing only the code and
>>> the token.
>>>
>>> To me it sounds like we want a new type of wrapper object that could
>>> contain code, token and id_token.
>>> Rather than extend the existing id_token object.
>>>
>>> -- Roland
>>> _______________________________________________
>>> 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
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120215/c0ea02cd/attachment.html>


More information about the Openid-specs-ab mailing list