[Openid-specs-ab] response_type=code id_token

Nat Sakimura sakimura at gmail.com
Tue Feb 14 23:31:09 UTC 2012


Good.

Perhaps we should start building the agenda.

I made a wiki page for it in the working group repository.

http://hg.openid.net/connect/wiki/2012-03-02%20F2F%20Agenda

=nat

On Wed, Feb 15, 2012 at 3:54 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  John and I had spoken about this on the phone for about an hour last
> week and weren’t able to come to any conclusions as to what the “right”
> solution was.  I believe that this one is thorny enough that we should plan
> to discuss and resolve it at the in-person working group meeting at RSA:**
> **
>
> ** **
>
> When:****
>
>                Friday, March 2, 9 AM – 1 PM****
>
> Where:****
>
>                Microsoft Office at Westfield Centre ****
>
>                Conf Room SF/Pacifica-7120****
>
>                 835 Market St. Suite 100, San Francisco, CA, 94103 ****
>
>                 (415) 972-6400****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Nat Sakimura
> *Sent:* Tuesday, February 14, 2012 8:01 AM
> *To:* Justin Richer
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] response_type=code id_token****
>
> ** **
>
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120215/5e2e0212/attachment-0001.html>


More information about the Openid-specs-ab mailing list