Re: [OAUTH-WG] issuing new refresh tokens

[Andrew Arnott <[e-mail]>]

On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton <[e-mail]> wrote:

> Draft 10 has the following sentence in section 4.1.4:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
>
> "The authorization server MAY issue a new refresh token."
>
> That carries a surprising amount of baggage.  I suggest removing the
> sentence, or changing it to MUST NOT, pending a discussion of the use
> cases for issuing new refresh tokens.
>
> Does anyone remember why that sentence got added to the spec?
>
> There are two reasons I can see for issuing new refresh tokens:
> 1) secrets are like underwear, change them frequently
> 2) someone has a cryptographically implemented refresh token that
> needs to be re-signed or re-issued
>
> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy,
> these pretty much have to be backed by server-side state or there is
> no way to run your system.


Brian, can you tell me what you mean by cryptographically implemented
refresh token, and why using one would be crazy?  You say using them would
require server-side state.  I'd say just the opposite.  If you *are* signing
your refresh tokens (a cryptographic operation) you don't need to store them
on the auth server, but if you aren't using cryptography, then you must
store the tokens on the auth server in order to validate them when they come
back to you.

So in short, I'm thinking the opposite of what you state.  So please
enlighten me.  What am I missing?