[Openid-specs-ab] response_type=code id_token

Nat Sakimura sakimura at gmail.com
Tue Feb 14 14:41:35 UTC 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120214/c120d775/attachment.html>


More information about the Openid-specs-ab mailing list