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. So I'm going to ignore that possibility, and guess that someone was interested in changing secrets... So if we want to issue new refresh tokens because we like to change secrets, we should cover: - whether existing refresh tokens are revoked. (I'd vote for MUST be revoked) - the minimum latency between issuing a new refresh token and revoking the old one. (I'd vote for minimum latency measured in hours or longer. Clients that have cached refresh tokens need to refresh their cache within this time period, or they're borked.) - the maxium latency for revoking the old token. (I'd vote for maximum latency measured in hours or days, just for security reasons. But I can't think of what would break if servers ignored this advice.) Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
