Dick, > 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.
Defining refresh_token as a URI does not prevent it being a self-contained signed token. The only limitation implied is a URI size limit. A few KB, however, is not that onerous a limit -- it is sufficient to hold a 4096-bit RSA signature with a couple of KB over for permissions etc.). -- James Manger On Thu, May 13, 2010 at 7:10 AM, Manger, James H <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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
