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

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
>