[Openid-specs-ab] response_type=code id_token

Nat Sakimura sakimura at gmail.com
Tue Feb 14 16:00:50 UTC 2012


OK. You are right.

That's slightly better, but still dealing with the permutation is not fun.

I  should probably take some sleep before further ranting :-)

=nat

On Wed, Feb 15, 2012 at 12:51 AM, Justin Richer <jricher at mitre.org> wrote:

>  Not necessarily -- you're not required to support all registered types,
> so you only need to parse the registry when you're changing which request
> types you support. You should still be allowed to reject something that you
> don't recognize or support as "invalid" even if it's been registered, as
> far as I can tell. The registry is just meant to prevent namespace
> collisions, not to give a checklist for implementors to deal with.
>
>  -- Justin
>
>
> On 02/14/2012 10:49 AM, Nat Sakimura wrote:
>
> 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
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>


-- 
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/6ad26526/attachment-0001.html>


More information about the Openid-specs-ab mailing list