Re: [OAUTH-WG] Refresh Tokens

Isn't this what section 1.5 is already there for? 

   Refresh tokens are credentials used to obtain access tokens.  Refresh
   tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner).  Issuing a refresh token is optional and is included when
   issuing an access token.

   A refresh token is a string representing the authorization granted to
   the client by the resource owner.  The string is usually opaque to
   the client.  The token denotes an identifier used to retrieve the
   authorization information.  Unlike access tokens, refresh tokens are
   intended for use only with authorization servers and are never sent
   to resource servers.

What could make this text clearer? 

(Though while I'm here, I just noticed a nit: 
  "Issuing a refresh token is optional and is included when issuing an
access token." 

Could be clearer, as in something like: 

 "Issuing a refresh token is optional, but when one is issued it is
included along with an access token.")

 -- Justin

On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote:
> Does it want to be in the main definition or the security
> considerations section?
> 
> 
> 
> 
> ______________________________________________________________________
> From: Anthony Nadalin <tonynad@microsoft.com>
> To: Dick Hardt <dick.hardt@gmail.com>
> Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
> Sent: Thursday, August 11, 2011 11:15 AM
> Subject: Re: [OAUTH-WG] Refresh Tokens
> 
> Many reasons, but none are explained in the specification
>  
> From: Dick Hardt [mailto:dick.hardt@gmail.com] 
> Sent: Thursday, August 11, 2011 10:51 AM
> To: Anthony Nadalin
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> My recollection of refresh tokens was for security and revocation.
>  
> security: By having a short lived access token, a compromised access
> token would limit the time an attacker would have access
>  
> revocation: if the access token is self contained, authorization can
> be revoked by not issuing new access tokens. A resource does not need
> to query the authorization server to see if the access token is
> valid.This simplifies access token validation and makes it easier to
> scale and support multiple authorization servers.  There is a window
> of time when an access token is valid, but authorization is revoked. 
>  
>  
>  
> On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:
> 
> 
> 
> Nowhere in the specification is there explanation for refresh tokens,
> The reason that the Refresh token was introduced was for anonymity.
> The scenario is that a client asks the user for access. The user wants
> to grant the access but not tell the client the user's identity. By
> issuing the refresh token as an 'identifier' for the user (as well as
> other context data like the resource) it's possible now to let the
> client get access without revealing anything about the user. Recommend
> that the above explanation be included so developers understand why
> the refresh tokens are there.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 