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

[John Bradley]

They both should support JWT.  The OP MUST,  and the RP should, however it can pass the JWT to the check session endpoint.


On 2011-08-29, at 5:14 PM, nov matake wrote:

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

-------------- 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/20110829/9d7914b2/attachment.p7s>