I'm 135 messages behind on the list. I'm knee deep in -07. EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Friday, June 11, 2010 10:03 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) 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 <tors...@lodderstedt.net><mailto:tors...@lodderstedt.net> An: Eran Hammer-Lahav <e...@hueniverse.com><mailto:e...@hueniverse.com> CC: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) <oauth@ietf.org><mailto:oauth@ietf.org> 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<b...@dentedreality.com.au><mailto:b...@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<l...@lukasrosenstock.net><mailto:l...@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.ha...@gmail.com><mailto:dick.ha...@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.man...@team.telstra.com><mailto:james.h.man...@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<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> http://lukasrosenstock.net/ >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
