[Openid-specs-ab] response_type=code id_token

Justin Richer jricher at mitre.org
Tue Feb 14 15:51:35 UTC 2012

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 
> <mailto: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
>>     <mailto: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 <mailto: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
>>>>             <mailto: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 list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120214/ff66655d/attachment-0001.html>

More information about the Openid-specs-ab mailing list