[Openid-specs-ab] Lite Draft 9

Nat Sakimura sakimura at gmail.com
Sat Aug 20 01:38:48 UTC 2011


Connect Messaages

3.1.1.  ID Token

The ID Token is a token that contains claims pertinent to the authentication event. The default format of an ID Token is a JWT which contains JSON claims. Authorization servers MAY return ID Tokens in a different format. Clients can discover the ID Token format used by authorization servers via OpenID Connect Discovery [OpenID.Discovery] or by possessing prior knowledge of the authorization server.



=nat via iPad

On 2011/08/20, at 10:10, John Bradley <ve7jtb at ve7jtb.com> wrote:

> The default and only defined token format for id_token is JWT.
> 
> We were careful not to preclude using other token types in lite,  however no other token types are defined and no mechanism for a RP to discriminate between token types has been defined.
> 
> We did have a discussion that content sniffing is not a good idea.  
> 
> That leaves indicating the token type in the response or in the registration.
> 
> If at registration then the client needs to remember to always use Check session if they don't know how to parse the token.
> 
> A legitimate question would be is there anyone actually planning on using something other then JWT for the id_token.
> 
> I don't want to add complexity and find out that everyone uses JWT anyway.
> 
> John
> On 2011-08-19, at 9:04 PM, Nat Sakimura wrote:
> 
>> To be exact, the default format of the I'd_token is JWT, I believe. 
>> If the server provides type of the token via either discovery or out of band information, it could use other formats, like FB signed request. 
>> 
>> =nat via iPad
>> 
>> On 2011/08/20, at 4:12, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> 
>>> The id_token is the access token for the check session endpoint.
>>> 
>>> Only the id_token is sent to the check session endpoint.
>>> 
>>> As Oauth only has one access token we have to give the access token for the session endpoints a separate name.  That is id_token.  I did rase the possibility of calling it session but no one took me up on that.
>>> 
>>> The access token for the check session endpoint is a signed JWT that way a client can inspect it directly and never use the check session endpoint.
>>> 
>>> John B.
>>> On 2011-08-19, at 3:06 PM, Allen Tom wrote:
>>> 
>>>> In section 3.3.1 - Are both the access_token and the id_token supposed to be sent to the Check Session endpoint? The way that Section 3.3.1 in Draft 9 is currently written, it sounds like only the id_token is sent in the request, and that the id_token is actually the access_token.
>>>> 
>>>> It would probably be helpful to have an example Check Session request in the spec.
>>>> 
>>>> Allen
>>>> 
>>>> 
>>>> On Fri, Aug 19, 2011 at 12:02 PM, Allen Tom <allentomdude at gmail.com> wrote:
>>>> The explanation in Section 3 regarding when to use the Implicit vs Code flow is vague, because it's not clear as to what it means for a client to securely maintain state between itself and the auth server.
>>>> 
>>>> It might be better to just say that the Code flow should be used if the redirect_uri doesn't use HTTPS, and if the client is able to securely store its client_secret.
>>>> 
>>>> Allen
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> 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/20110820/73b33abc/attachment.html>


More information about the Openid-specs-ab mailing list