[Openid-specs-ab] response_type=code id_token

Roland Hedberg roland.hedberg at adm.umu.se
Tue Feb 14 09:23:56 UTC 2012


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


More information about the Openid-specs-ab mailing list