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

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 11 Jun 2010 19:02:40 +0200

Hi Eran,

you probably didn't notice my posting. What do you think about adding a 
revocation request to the spec?

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: 	Re: [OAUTH-WG] in-app logout?
Datum: 	Wed, 26 May 2010 20:26:18 +0200
Von: 	Torsten Lodderstedt <[email-masked]>
An: 	Eran Hammer-Lahav <[email-masked]>
CC: 	OAuth WG ([email-masked]) <[email-masked]>

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<[email-masked]>   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<[email-masked]>   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<[email-masked]>
>>>
>>>  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<[email-masked]>   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
>>>  [email-masked]
>>>  https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>  _______________________________________________
>>>  OAuth mailing list
>>>  [email-masked]
>>>  https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>  --
>>>  http://lukasrosenstock.net/
>>>
>>>
>>>
>>  _______________________________________________
>>  OAuth mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>  _______________________________________________
>  OAuth mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 10:24:22 -0700

I'm 135 messages behind on the list. I'm knee deep in -07.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Friday, June 11, 2010 10:03 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Fwd: Re: [OAUTH-WG] in-app logout?

Hi Eran,

you probably didn't notice my posting. What do you think about adding a revocation request to the spec?

regards,
Torsten.

-------- Original-Nachricht --------
Betreff:

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

Datum:

Wed, 26 May 2010 20:26:18 +0200

Von:

Torsten Lodderstedt <[email-masked]><mailto:[email-masked]>

An:

Eran Hammer-Lahav <[email-masked]><mailto:[email-masked]>

CC:

OAuth WG ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>

Hi Eran,

regards,

Torsten.

> On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<[email-masked]><mailto:[email-masked]>  wrote:

>> On Friday, May 21, 2010, Lukas Rosenstock<[email-masked]><mailto:[email-masked]>  wrote:

>>> 2010/5/16 Dick Hardt<[email-masked]><mailto:[email-masked]>

>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<[email-masked]><mailto:[email-masked]>  wrote:

>>> [email-masked]<mailto:[email-masked]>

>>> [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Fri, 11 Jun 2010 14:49:51 -0400

I'd like to voice support for Dick's proposal of re-scoping[1] and (in
later discussion) revoking access tokens using the refresh token as
authentication. I'd like to see us give clients a way to manipulate
tokens through OAuth entirely. I also think that revoke should be a
separate mechanism from rescoping, and that it should be handled through
a parameter, such as "type" in Dick's proposal.

It would not only give us more full token management, I think it will
actually help with some redelegation situations that I've been talking
about with some of my colleagues here. You can scope an access token
down to a subset of your original scopes without user intervention, and
then hand that subscoped token to another client. I'll be getting
together with folks to talk about this redelegation stuff shortly, so
more on that later; but it is something we're definitely interested in,
and I've seen others voice interest in it as well. 

This does raise the question of one refresh token (and therefore one
user authorization) being associated with multiple simultaneously-valid
access tokens, though. The spec seems to assume a single access token is
valid for a given authorization at a time, but is mostly silent on the
matter.

 -- Justin

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg02408.html

On Fri, 2010-06-11 at 13:02 -0400, Torsten Lodderstedt wrote:
> Torsten Lodderstedt
> <[email-masked]>
>                                An: 
> Eran Hammer-Lahav
> <[email-masked]>
>                                CC: 
> OAuth WG ([email-masked])
> <[email-masked]>
> 
> 
> Hi Eran,
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 11 Jun 2010 15:02:22 -0400

+1 to re-delegation

I'd like to add that with down-scoping and re-delegation it would be 
nice to be able to bind a re-delegated access token to the client that 
will present it. With re-delegation, the down-stream client doesn't have 
an easy "refresh" token so a short-lived access token might not be the 
best solution.

I realize this may not be the main stream use case, but I would like to 
make sure it's not prohibited in any proposed solution.

Thanks,
George