Subject: [OAUTH-WG] draft-ietf-oauth-revocation-03

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2012 10:36:06 +0200

Hi Torsten,

thanks for the draft update. It looks good to me. 

I only have a minor wording suggestion for Section 3. 

Instead of 
"
   Depending on the authorization server's token design, revocation of
   access tokens might be a costly process.  For example, revocation of
   self-contained access tokens requires (time-consuming) backend calls
   between resource and authorization server on every request to the
   resource server or to push notifications from the authorization
   server to the affected resource servers.  Alternatively,
   authorization servers may choose to issue short living access tokens,
   which can be refreshed at any time using the corresponding refresh
   tokens.  In this case, a client would revoke the refresh token and
   access tokens issued based on this particular refresh token are at
   most valid until expiration.  Whether this is an viable option or
   whether access token revocation is required should be decided based
   on the service provider's risk analysis.
"

what about the following text:

"
OAuth 2.0 allows deployment flexibility with respect to the style of access tokens. The access tokens may be self-contained so that an resource server needs no further interaction with an authorization server issuing these tokens to perform an authorization decision of the client requesting access to a protected resource. A system design may, however, instead use access tokens that are opaque to the resource server. This consequently requires a resource server to issue a request to an authorization server to retrieve the content of the access token every time a client presents an access token. While these are not the only options they illustrate the implications for revocation. In the latter case the authorization server is able to revoke an access token previously issued to a client when the resource server relays a received access token. In the former case some (currently non-standardized) back-end interaction between the authorization server and the resource server may be used when immediate access token revocation is desired or another design alternative is to issue short-lived access tokens, which can be refreshed at any time using the corresponding refresh tokens. This allows the authorization server to have a limit on the time revoked access tokens are in use. 

Which approach of token revocation is chosen will depend on the overall system design and on the application service provider's risk analysis. The cost of revocation in terms of required state and communication overhead is ultimately the result of the desired security properties.  
"

Ciao
Hannes