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

[Ballot discuss]
D1. The mandate for TLS usage actually seems backward here.  Suppose a server receives a request over HTTP.  At this point, the credentials have been exposed, so you would *want* the token to be invalidated!  Suggest:
-- Clients MUST NOT send over HTTP
-- Server revocation URIs MUST be HTTPS
-- Servers MAY support HTTP to the corresponding URI, just in case the client screws up

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
D1. The mandate for TLS usage actually seems backward here.  Suppose a server receives a request over HTTP.  At this point, the credentials have been exposed, so you would *want* the token to be invalidated!  Suggest:
-- Clients MUST NOT send over HTTP
-- Server revocation URIs MUST be HTTPS
-- Servers MAY support HTTP to the corresponding URI, just in case the client screws up

D2. Why are the requirements TLS versions different here than in RFC 6749?  Especially in a way that makes them worse.  Suggest deleting the sentence starting "The authorization server MUST support TLS 1.0 ..."

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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."

[Ballot comment]
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?

[Ballot discuss]
-- Section 2.1 --

  In the next step, the authorization server invalidates the token.
  The client MUST assume the revocation is immediate upon the receipt
  of an HTTP 200 response from the server.  The client MUST NOT use the
  token again after the revocation.

This strikes me as backward.  There's no protocol-related reason that the client MUST NOT use the token.  On the other hand, it ought to be required that the token MUST NOT be *accepted* after it's invalidated.  No?

Similarly, I wouldn't say that the client "MUST assume" anything, but, rather, that the invalidation MUST be immediate upon the sending of the HTTP 200 response.

[Ballot comment]
First, I have to note that this isn't "revocation" in any sense that we use it in English.  The bearer of the token tells the issuer that the token is no longer needed, and in response, the issuer invalidates it.  I might call that "token invalidation" or "token surrender", but "revocation" has a strong implication of an action that's taken outside the control of the affected party, and usually over the objection of the affected party.  Calling this "revocation" is misleading, and could actually be a problem if true revocation should be proposed at some point.  I strongly urge you to change the title of the document and how you refer to the action.  I suggest "invalidation" or "surrender".

-- Section 2.1 --

          Specific implementations, profiles, and extensions of this
          specification MAY define other values for this parameter
          parameter using the registry defined in Section 4.1.2.

Nit: fix "parameter parameter".

  If the token passed to the request
  is an access token, the server MAY decide to revoke the respective
  refresh token as well.

Editorial: I suggest removing "decide to"; it seems a bit silly.  What does it add?  (And also in the subsequent paragraph.)

-- Section 2.2 --

Why does the server respond with 200 when the token is invalid?  Why is that not considered an attempt to revoke a token that can't be revoked?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-oauth-revocation-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a question about the IANA Actions requested in this document.

Upon approval of this document, IANA understands that there are two actions which IANA must complete.

First, in the OAuth Extensions Error Registry located at:

http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#extensions-error

a new Error Value will be registered as follows:

Name: unsupported_token_type
Usage location revocation endpoint error response
Protocol extension Token Revocation Endpoint
Change controller IETF
Reference: [ RFC-to-be ]

Second, a new registry will be created called the "OAuth Token Type Hint" registry. The new registry will be managed via Specification Required as defined by RFC 5226. The registry will also have a methodology for early registration as defined in section 5.1.2 of the approved document.

IANA understands that there will be at least one initial registration in this new registry.

IANA Question --> The authors request that the registry be populated as follows:

"The OAuth Token Type Hint registry's initial contents are:

o Hint Value: access_token

o Change controller: IETF

o Specification document(s): [this document]

o Response type name: refresh_token

o Change controller: IETF

o Specification document(s): [this document]

IANA wonders if this is a suggestion that there is only one registration, or if there are two and the words "Response Type Name" is a typo and should have been "Hint Value?"

IANA understands that these two actions are the only one required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Token Revocation) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Token Revocation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document proposes an additional endpoint for OAuth authorization
  servers, which allows clients to notify the authorization server that
  a previously obtained refresh or access token is no longer needed.
  This allows the authorization server to cleanup security credentials.
  A revocation request will invalidate the actual token and, if
  applicable, other tokens based on the same authorization grant.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/


No IPR declarations have been submitted directly on this I-D.


The draft has a normative reference to RFC2246 (as well as
5346) as it follows the same approach to TLS as the base
oauth spec. (RFC6749, section 1.2).

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type being requested in Standards Track. The type is appropriate for this type of OAuth protocol extension.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


The OAuth Token Revocation specification proposes an additional endpoint for OAuth authorization
servers, which allows clients to notify the authorization server that
a previously obtained refresh or access token is no longer needed.
This allows the authorization server to cleanup security credentials.
A revocation request will invalidate the actual token and, if
applicable, other tokens based on the same authorization grant.


Working Group Summary:

The document experienced no particular problems in the working group.

Document Quality:

The document has been deployed by four companies, namely by Salesforce, Google, Deutsche Telekom, and MITRE.
The working group reviewed and discussed the document extensively.

Personnel:

Hannes Tschofenig is the document shepherd. The responsible area director is Stephen Farrell.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

I have reviewed this version of the document and provided feedback to earlier versions of the draft.
The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I have no concerns about the level of reviews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No, there is no need for further reviews.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns regarding the document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Two of the three authors have confirmed that they are not aware of any IPRs. Marius Scurtescu so far has not responded to my mails.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures available for this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group is in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits have been verified. There is one reference ([portable-contacts]) that is not used in the document that has to be removed with the next draft update or by the RFC Editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document does not contain content that requires formal reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are published RFCs already.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will not change the status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document defines a new error code and follows the requirements in RFC 6749.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The shepherd is currently the expert for RFC 6749 IANA registry allocations.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No text written in a formal language is contained in the document.

-------------------------------