[Openid-specs-ab] Lite Draft 9

John Bradley ve7jtb at ve7jtb.com
Fri Aug 19 19:12:57 UTC 2011


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110819/4fed50e4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110819/4fed50e4/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list