Dick, I may have misinterpreted you design objective of "allowing existing systems to use existing tokens" as meaning: the refresh_token field shouldn't be defined as a URI as some existing tokens are too big to fit in URIs.
If the size of existing tokens is an issue then the user-agent flow will not work -- since it returns an access_token (and, optionally, a refresh_token as well) in a URI fragment. An existing token always needs to be extracted from a request: typically from a FORM-encoded string of parameters. Defining refresh_token as a URI doesn't really change this: an existing token can still be extracted from a query parameter in such a URI. I believe this still meets a design objective of allowing existing systems to use existing tokens. So I suggest renaming refresh_token to, say, token_uri, and defining it to be a URI. P.S. An authz service could even choose the following so a refresh request looks much like the current draft if it really needed that. "token_uri": "/token?refresh_token=8xLOxBtZp8" -- James Manger -----Original Message----- From: Dick Hardt [mailto:[email protected]] Sent: Monday, 17 May 2010 10:27 AM To: Manger, James H Cc: OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] in-app logout? On 2010-05-16, at 5:20 PM, Manger, James H wrote: > 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.). Agreed, a token could be a self contained token. A design objective was allowing existing systems to use existing tokens. -- Dick -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Manger, James H Sent: Friday, 14 May 2010 12:10 AM To: Torsten Lodderstedt; OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] in-app logout? 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 protected] https://www.ietf.org/mailman/listinfo/oauth
