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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 8 Oct 2012 14:52:54 +0300

Hi all, 

I went through draft-ietf-oauth-revocation-01 to what has changed
between version -00 and -01. 

A few minor comments:

Title: maybe you should change it from "Token Revocation" to "Revocation
of OAuth Access and Refresh Tokens" to make it a bit more informative.
The abstract is also a bit too short to explain what the document does.
The RFC Editor will at least demand 3 lines of abstract. You may, for
example say that the specification covers revocation of access and
refresh tokens. Important would also to highlight that the revocation is
initiated by the client. You may also want to highlight that this is
mainly used as a logout mechanism. 

I you want to re-word the following sentence a bit:
"
   A revocation request may discard the actual token as well as other
   tokens based on the same access grant and the access grant itself.
" 
For example:
"
A revocation request by the client includes the token that shall be
revoked. Revoking a refresh token will, however, also revoke any access
token created earlier via the presented refresh token.  
"

Introduction: I would not include RFC 2119 language in the introduction.
I am also wondering why a specification shouldn't support the revocation
of both tokens when requested. 

You write that the specification supports the following use cases and
you list two items. The issue, however, is that item #2 isn't what the
specification deals with. Instead, the focus is on item #1 and the
revocation feature is more a logout feature, as you describe it rather
than a way to deal with stolen tokens. 

   o  The end-user triggers revocation from within the client that sends
      the appropriate revocation request to the autorization server.
      The request causes the removal of the client's access grant the
      particular token refers to.  From the end-user's perspective, this
      looks like a "logout" or "reset" function.  This use case makes it
      even more comfortable to the end-user to revoke his access grant
      immediately via the client.

   o  In contrast to revocation by a client, the authorization server
      (or a related entity) may offer its end-users a self-care portal
      to delete access grants given to clients independent of any token
      storing devices.  Such a portal offers the possibility to an end-
      user to look at and revoke all access grants he once authorized.
      In cases the token storing device is not available, e.g. it is
      lost or stolen, revocation by a self-care portal is the only
      possibility to limit or avoid abuse.

Terminology: I would include a Terminology section with the following
content:
"
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
"

You write: 

   In the end, security, usability, and ease of use are increased by
   token revocation. 

Could you explain this a bit? The specification does not help with
stolen tokens. It also does not help with clients who behave
unsupportive. 

Example: I suggest to expand the example token a bit to avoid the
impression that tokens are so short. 
s/token=45ghiukldjahdnhzdauz&/token=45ghiukldj....ahdnhzdauz&/

I don't understand this note:

"It is also conceivable to allow a dedicated user self-care portal to
revoke all kinds of tokens."
The self-care portal shouldn't have tokens and hence cannot really
revoke them. As such, the self-care portal would be either at the
authorization server or very closely related to it (for example with
access to the same backend database). 

Regarding:
" 
If the particular token is a refresh
   token and the authorization server supports the revocation of access
   tokens, then the authorization server SHOULD also invalidate all
   access tokens based on the same access grant.
" 

Why "SHOULD" and not MUST?

Shouldn't this sentence say 

If the presented token is a refresh token  then the authorization server
MUST invalidate all access tokens created by that refresh token." 

Note that I 
 - clarified what gets deleted, and  
 - removed unnecessary options.

You write: 
" 
   Whether the revocation takes effect instantly or with some delay
   depends on the architecture of the particular deployment.  The client
   MUST NOT make any assumptions about the timing and MUST NOT use the
   token again.
" 

This is an interesting aspect since one would wonder why it isn't
sufficient for the client to just delete the tokens it has locally.
Nobody else should have the same set of tokens since they are supposed
to be minted on the fly for the different clients. 

Then, wouldn't it be useful for a logout functionality that the
revocation actually works instantly rather than at an unpredictable time
later ? 

Could you explain why the cross-origin support is needed? 

You write: 
" 
unsupported_token_type: the client
           tried to revoke an access token on a server not supporting
           this feature.
" 
Does this mean that the server does not support the revocation
specification at all or just not the ability to revoke access
(refresh???) tokens?

Security considerations: I would expect to see a discussion about what
scenarios this revocation mechanism does not cover. 

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 08 Oct 2012 20:44:00 +0200

Hi Hannes,

thanks for your review and feedback. Please find my comments inline.

> of OAuth Access and Refresh Tokens" to make it a bit more informative.

why not. What do other WG members think?

> mainly used as a logout mechanism.

ok.
> token created earlier via the presented refresh token.

I see the following issues with your proposal:
- I assume not all authorization servers will support access token 
revocation (none of our servers does)
- Access tokens belonging to the same access grant might have been 
created based on different refresh tokens, since refresh tokens can be 
rotated (we do this for refresh tokens issued to installed 
applications). see also 
http://www.ietf.org/mail-archive/web/oauth/current/msg09244.html

That's why I suggested on the list to add the concept of an underlying 
access grant. This concept proved to be useful during discussions about 
the different token implementation philosophies at the last IIW.

It also allows an authorization server to delete access grants 
underlying an access token even if it does not issue refresh tokens at 
all - some authorization servers manage permanent access grants 
internally and issue access tokens automatically in implicite and code 
grant type (auto-approval).

I therefore would suggest the following wording:
"A revocation request by the client includes the token that shall be 
revoked. Revoking a token may, however, also revoke other tokens based 
on the same access grant and the acces grant itself."

> Introduction: I would not include RFC 2119 language in the introduction.

And put the compliance statement into another section?

> of both tokens when requested.

The assumption is that not all authorization servers will support access 
token revocation because this comes at a cost. It either requires a 
lookup of the RS at the AS on every service request OR a push 
notification of the AS towards all relevant RS on revocation.

> than a way to deal with stolen tokens.

What about the self-care portal (see below)?

>     document are to be interpreted as described in RFC 2119 [RFC2119].

ok.

> stolen tokens.

What about the self-care portal?

> It also does not help with clients who behave
> unsupportive.

I don't understand this statement. "unsupportive" with respective to 
token revocation?

> s/token=45ghiukldjahdnhzdauz&/token=45ghiukldj....ahdnhzdauz&/

I'm wondering why the core spec shows example tokens of roughly the same 
size.

> access to the same backend database).

Yes, that's true. Such a portal must have access to the token database. 
It may be part of the authorization server or a general purpose portal, 
which access the token database via well-defined (internal) interfaces. 
We implemented the later pattern.

> Why "SHOULD" and not MUST?

See above.

> MUST invalidate all access tokens created by that refresh token."

See above. "that refresh token" might not be meaningful in conjunction 
with refresh token rotation.

> to be minted on the fly for the different clients.

Basically, you are right. I'm wondering whether there could be issues in 
clustered environment, potentielly different nodes could use the same 
access token?

> revocation actually works instantly rather than at an unpredictable time

Yes.

> Could you explain why the cross-origin support is needed?

I think this is the only way for a user-agent based application to 
revoke tokens due to the same-origin policy.

@Marius: Could you please shed some more light on this aspect?

> specification at all or just not the ability to revoke access

Revocation of access tokens is an optional feature

> scenarios this revocation mechanism does not cover.

I thought such a section was intended to discuss the security of the 
proposed protocol?

Do you have specific scenarios in mind?

regards,
Torsten.

>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth