[Openid-specs-ab] Lite Draft 9

Andreas Åkre Solberg andreas.solberg at uninett.no
Thu Aug 25 10:03:16 UTC 2011

On 24. aug. 2011, at 19:56, John Bradley wrote:

> Google has however added a bit of a twist on the last call.
> They are proposing that a hash of the access token be included in the id_token.
> The idea is that that allows a RP to know if the received access token relates to the id_token.

Sorry, but I feel completely lost here.

An id_token is kind of a handle to the current user session (at the provider), right?
And the access token is kind of credentials to get user information about the authenticated user, right?

There may be many id_token-s (for the same 'session' at the RP), derived from the same session at the provider; by the use of the 'Refresh Session' service.
And the consumer may request more than one access token for the same user, by using the OAuth refresh_token.

If both the access token and id_token is refreshed, which of the access token should then the new id_token refer to ?

The way I've understood it, an id_token can be related to a session at the provider, and the access_token is not associated with any session directly, but could potentially be tracked back to the session where it was issued.

Like this: http://clippings.erlang.no/ZZ56D6DED4.jpg

I'm tempted to suggest that the id_token included a session identifier. Then two id_tokens could be more easily reckgonized to represent the same session. The User Info Service could then potentially return a reference to the session (via the session identifier) where the access token was issued.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4448 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110825/38ca9079/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list