[Openid-specs-ab] About ID Tokens being access tokens

[Andreas Åkre Solberg]

On 29. aug.2011, at 18:05, John Bradley wrote:

> On the last call it was decided that the check session endpoint would NOT take the id_token as the access token.
> You, Andreas, and perhaps Breno seem to think the id_token should be treated as the access token for the check session endpoint.

I would say it depends.

Right now, 
* the 'id_token' is not issued as a normal access token, 
* it cannot be associated with a token_type; instead it is defined to always be used identical to a 'bearer' token.
* the 'id_token' has a 'deeper meaning' than a transparent handle, that makes the server endpoint want to access it.

In the previous emails I've suggested to change all the three points above. Given, that we will not change the above I would say that I support to pass the token as a POST parameter (or similar) and not describe it as an access token, in order to reduce confusion, and for making it easier to access on the server.

> Mov seems to have reasons that won't work with the OAuth lib he is using.  

In the proposal I've described in the recent emails; if the check session service was a 'Standard OAuth protected endpoint', and the token was transparent; the server would not need to access the token itself, instead if would verify through the OAuth Server API that the request was verified with a OAuth token in the correct scope.

If we are talking about a 'more local' check session endpoint, and the implicit flow; then the JS client would not be able to send the Authorization header; and it would send it as a query string parameter instead; something that is allowed in the Oauth Bearer Token spec [1]; then the local server would be able to access the access token, and pass it on to the remote check endpoint service acting as an OAuth client.

How does that sound, Mov?

[1]: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param