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

[nov matake]

Are you talking about library on RP side or OP side?

On 2011/08/30, at 9:04, John Bradley wrote:

> The id_token would be a JWT.   The RP could check the signature directly,  or send it as the bearer access token for the check session endpoint.
> 
> The library would need to understand JWT access tokens.  However that is the point of JWT, and it expected that many libraries will do that so they can be stateless.
> 
> John
> On 2011-08-29, at 4:37 PM, nov matake wrote:
> 
>> Your proposal gives id_token as a bearer token, so it sounds good for my library.
>> I think people wanted JWT format not to make check session call REQUIRED though.
>> 
>> On 2011/08/30, at 4:41, Andreas Åkre Solberg wrote:
>> 
>>> 
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>