Skip to main content

OAuth 2.0 Token Revocation
draft-ietf-oauth-revocation-11

Yes

(Stephen Farrell)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)

Note: This ballot was opened for revision 09 and is now closed.

Richard Barnes Former IESG member
(was Discuss) Yes
Yes (2013-05-29) Unknown
C1. "Depending on the authorization server's revocation policy..."
It seems really bad for interop to have all of this be at the server's discretion and opaque to the client.  While its true that clients have to be able to handle unilateral revocation, at the very least this leads to unpredictable user experience.  (Why am I being asked to authenticate again?)  Suggest that the document either place constraints on the server, or have the server's response say exactly which tokens have been revoked.  The latter option might leak some information if tokens are not opaque, but doesn't present a security risk, since by definition the tokens are no longer good.

C2. "unsupported_token_type" -- This seems insufficient.  What if a server can invalidate some access tokens and not others?  (For example, if it has different relationships with different resource servers.)  It seems like what you really  want here is just a statement by the server that "I can't revoke this token". 

C3. It might be helpful to describe what happens if a client tries to revoke something other than a valid token.  If the token is bogus (not issued by the Authorization Server), then it seems like "invalid_grant" makes sense.  However, if the token was issued and revoked by the Authorization Server, then it seems like the request should return success -- not "invalid_grant", as RFC 6749 implies.
Stephen Farrell Former IESG member
Yes
Yes (for -09) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-06-16 for -10) Unknown
Thanks for addressing my questions and comments in the -10 version.
Benoît Claise Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2013-05-24 for -09) Unknown
I have no objection to the publication of this document, but I am curious about one thing.  Given that this document is describing a new feature for OAuth, was there thought given to having it update RFC 6749?
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2013-05-27 for -09) Unknown
Dan Romascanu's Gen-ART review raised an issue that I agree with. I have not seen any discussion of this issue despite searching my mail archives. Let me know if I missed something. 

I think this issue is borderline Discuss, but it is filed as a Comment. For now... further discussion may convince me that this is either not an issue or that is actually a blocking problem due to incomplete following of RFC 5226.

The issue is that Section 4.1.2. specifies, in my opinion, an odd way to use Specification Required. Normally, there are no exceptions to convince an expert that a specification is forthcoming. I also think that the review process rules with the list are a bit overspecified.

Had I written this myself, I would probably have said something like:

"New values are assigned through Specification Required, Expert Review, or IESG Approval [RFC5226]. It is expected that the Specification Required is the normal assignment process. Expert Review should only be used when no specification is yet available publicly but an early allocation is desired. Such assignments should be reserved only for exceptional cases, however."
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-05-29 for -09) Unknown
no objection once the current discusses are clear.

section 4 the iana considerations section should have an introduction imho.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2013-05-29 for -09) Unknown
I've been following Barry's DISCUSSion, and I agree.

I also agree with his comment about the word "revoke".

In section 2:

   Implementations MUST support the revocation of refresh tokens and
   SHOULD support the revocation of access tokens (see Implementation
   Note).

This sort of follows up Brian's comment: The above indicates new requirements on OAuth. If OAuth servers MUST now support revocation, that's a change to the base spec. Doesn't that require that this document Updates the base spec?
Sean Turner Former IESG member
No Objection
No Objection (2013-05-29 for -09) Unknown
0) Invalidate & revoke are used interchangeably when referring to a token; a revocation request leads to a token invalidation, a revoked token, and an invalid token.   Might be worth explaining that you're using the terms interchangeably here.

1) s2: The base OAuth specification specifies the endpoint URL.  Why do you need to include it here?  If you are don't you need to include all the requirements like it MUST NOT include a fragment component?  Couldn't this:

 The client requests the revocation of a particular token by making an
 HTTP POST request to the token revocation endpoint URL.  This URL MAY
 include a query component.

Be this:

 The client requests the revocation of a particular token by making an
 HTTP POST request to the token revocation endpoint URL [RFC6749].

2) s2.1: Please remove "Note:"; 2119 language in notes is normally frowned upon.

3) s2.2: Do you want to tighten up the text to say that no content is returned and that if a content is present it is ignored/discarded?  I'd hate for a server to send a huge blob back when the client is actually expecting nothing in response.
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-05-28 for -09) Unknown
I agree with Barry's DISCUSS about this document describing something other than a revocation. I'd encourage a change in terminology. 

In 2.  Token Revocation

   Since requests to the token revocation endpoint result in the
   transmission of plain text credentials in the HTTP request, the
   authorization server MUST require the use of a transport-layer
   security mechanism when sending requests to the token revocation
   endpoints.  The authorization server MUST support TLS 1.0
   ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future
   replacements, and MAY support additional transport-layer mechanisms
   meeting its security requirements.

I'm far out of my depth on this point, but are we still MUSTing TLS 1.0 with no caveats? A quick Google of "TLS 1.0 vulnerability" did not look encouraging. Maybe the relevant folk are current with security community thinking on TLS 1.0?
Stewart Bryant Former IESG member
No Objection
No Objection (2013-05-29 for -09) Unknown
I share Jari's concern about the proposed IANA process.

The proposed process seems far too complex to me and will likely lead to problems in execution.
Ted Lemon Former IESG member
No Objection
No Objection (2013-05-30 for -09) Unknown
The cross-document section reference below is broken in the xml source:

   The client also includes its authentication credentials as described
   in Section 2.3.  of [RFC6749].

Regarding TLS 1.0 vs. 1.2, why not replicate the language in RFC6749 rather than adding a MUST for TLS 1.0?   I would suggest just strongly advising implementors to support TLS 1.2 and mentioning that if they don't support TLS 1.0, they will run into problems with peers that do not support TLS 1.2, rather than using normative language.