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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
