Re: [OAUTH-WG] in-app logout?

+1 on the support.

Torsten, I just wonder if you see this as (possible a part of ) a 
single-sign off method?

Igor

Torsten Lodderstedt wrote:
> Hi Eran,
>
> in my perception, there is some support on the list for having a 
> request to revoke refresh tokens. Will you add such a request to the 
> specification? Do you need a text proposal?
>
> regards,
> Torsten.
>
>> IMHO this would look more like a hack than proper protocol design. We 
>> need
>> a delete/revoke operation that's the pendant to the other token 
>> operations (i.e.
>> crud ops).
>>
>> Hubert
>>
>>
>>
>> On Fri, May 21, 2010 at 7:05 PM, Beau 
>> Lebens<beau@dentedreality.com.au>  wrote:
>>   
>>> Could this just be implemented through support for a scope change
>>> where scope=none or revoke or something?
>>>
>>> On Friday, May 21, 2010, Lukas Rosenstock<lr@lukasrosenstock.net>  
>>> wrote:
>>>     
>>>> Why not simply add this functionality to the token endpoint?The 
>>>> same place that was used to fetch the access token first or refresh 
>>>> it could be used to revoke the same token with another request. The 
>>>> only requirement would be to define something like type=revoke.
>>>> I feel that is much easier than making the token a URL which 
>>>> supports DELETE.
>>>> However, any mechanism will break implementations that rely on 
>>>> minimal or no communication between authorization server and 
>>>> protected resource, because all protected resources have to be 
>>>> informed.
>>>>
>>>> Regards, Lukas
>>>>
>>>> 2010/5/16 Dick Hardt<dick.hardt@gmail.com>
>>>>
>>>> James: An important capability of the refresh token is that it 
>>>> *can* be a self contained token in that is not an id, but a signed 
>>>> token that can be examined and acted upon on presentation.
>>>> Torsten: enabling a client to revoke a refresh token looks like a 
>>>> useful mechanism. I anticipate it will be viewed as a vitamin 
>>>> feature rather than a painkiller and will fall by the wayside 
>>>> unless the security conscience rally to have it included.
>>>>
>>>>
>>>> -- Dick
>>>>
>>>>
>>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James 
>>>> H<James.H.Manger@team.telstra.com>  wrote:
>>>> Torsten,
>>>>
>>>>       
>>>>> What about refresh token revocation/deletion?
>>>>>          
>>>> HTTP already has a method to do this: DELETE
>>>> It just needs each token to have a URI.
>>>>
>>>> Tokens (almost) already have URIs -- its just not immediately 
>>>> obvious because the URI has to be built from a common token 
>>>> endpoint and a refresh_token.
>>>>
>>>> I think it would improve the spec if refresh_token was renamed to, 
>>>> say, token_id; and its value defined as a URI (which can be a 
>>>> relative URI so the string may not need to change at all).
>>>>
>>>> To refresh a token you POST to the token's URI.
>>>> To delete a token you send a DELETE request to the token's URI.
>>>>
>>>> It doesn't cause major changes, but there are some benefits.
>>>> It is a more web-style design.
>>>> It leaves only 1 type of token in the spec -- an access token -- 
>>>> which simplifies the text and aids understanding.
>>>> There are no arguments about length, allowed chars etc because it 
>>>> is a URI -- a well-known type, often with native support.
>>>> Its obvious how to delete the token as there is a standard HTTP 
>>>> method DELETE to apply to the token URI.
>>>>
>>>> If a particular service supported an additional way to delete items 
>>>> in its API (eg POST with a method=delete query parameter) that 
>>>> could apply to the OAuth part as well.
>>>>
>>>> -- 
>>>> James Manger
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> -- 
>>>> http://lukasrosenstock.net/
>>>>
>>>>
>>>>        
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>      
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>    
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth