[Openid-specs-ab] response_type=code id_token

Mike Jones Michael.Jones at microsoft.com
Tue Feb 14 18:54:11 UTC 2012


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<mailto: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<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<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

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


More information about the Openid-specs-ab mailing list