OAuth 2.0 Token Revocation
draft-ietf-oauth-revocation-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-08-14
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-08-08
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-07-23
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-07-22
|
11 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-07-22
|
11 | (System) | RFC Editor state changed to EDIT |
2013-07-22
|
11 | (System) | Announcement was received by RFC Editor |
2013-07-22
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-07-22
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-07-19
|
11 | (System) | IANA Action state changed to In Progress |
2013-07-19
|
11 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-07-19
|
11 | Amy Vezza | IESG has approved the document |
2013-07-19
|
11 | Amy Vezza | Closed "Approve" ballot |
2013-07-19
|
11 | Amy Vezza | Ballot approval text was generated |
2013-07-19
|
11 | Amy Vezza | Ballot writeup was changed |
2013-07-19
|
11 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-07-13
|
11 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss |
2013-07-13
|
11 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-11.txt |
2013-07-12
|
10 | Richard Barnes | [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 … [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 |
2013-07-12
|
10 | Richard Barnes | Ballot discuss text updated for Richard Barnes |
2013-06-16
|
10 | Barry Leiba | [Ballot comment] Thanks for addressing my questions and comments in the -10 version. |
2013-06-16
|
10 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2013-06-16
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-06-16
|
10 | Torsten Lodderstedt | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-06-16
|
10 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-10.txt |
2013-06-06
|
09 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. |
2013-05-30
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-05-30
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-05-30
|
09 | Ted Lemon | [Ballot comment] The cross-document section reference below is broken in the xml source: The client also includes its authentication credentials as described in … [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. |
2013-05-30
|
09 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-05-29
|
09 | Pete Resnick | [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 … [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? |
2013-05-29
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-05-29
|
09 | Joel Jaeggli | [Ballot comment] no objection once the current discusses are clear. section 4 the iana considerations section should have an introduction imho. |
2013-05-29
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-05-29
|
09 | Richard Barnes | [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 … [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 ..." |
2013-05-29
|
09 | Richard Barnes | [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 … [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. |
2013-05-29
|
09 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2013-05-29
|
09 | Sean Turner | [Ballot comment] 0) Invalidate & revoke are used interchangeably when referring to a token; a revocation request leads to a token invalidation, a revoked token, … [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. |
2013-05-29
|
09 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-05-29
|
09 | Stewart Bryant | [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 … [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. |
2013-05-29
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-05-28
|
09 | Spencer Dawkins | [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 … [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? |
2013-05-28
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-05-27
|
09 | Jari Arkko | [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 … [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." |
2013-05-27
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-05-27
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-05-26
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-05-24
|
09 | Brian Haberman | [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 … [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? |
2013-05-24
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-05-24
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-05-23
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2013-05-23
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2013-05-23
|
09 | Barry Leiba | [Ballot discuss] -- Section 2.1 -- In the next step, the authorization server invalidates the token. The client MUST assume the revocation is … [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. |
2013-05-23
|
09 | Barry Leiba | [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 … [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? |
2013-05-23
|
09 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-05-23
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-05-23
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-22
|
09 | Stephen Farrell | Placed on agenda for telechat - 2013-05-30 |
2013-05-22
|
09 | Stephen Farrell | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-05-22
|
09 | Stephen Farrell | Ballot has been issued |
2013-05-22
|
09 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2013-05-22
|
09 | Stephen Farrell | Created "Approve" ballot |
2013-05-22
|
09 | Stephen Farrell | Ballot writeup was changed |
2013-05-19
|
09 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-09.txt |
2013-05-19
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-19
|
08 | Torsten Lodderstedt | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2013-05-19
|
08 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-08.txt |
2013-05-14
|
07 | Stephen Farrell | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-05-02
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tom Yu. |
2013-04-30
|
07 | Dan Romascanu | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Dan Romascanu. |
2013-04-30
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-24
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-04-24
|
07 | Amanda Baber | 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 … 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. |
2013-04-18
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2013-04-18
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2013-04-17
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2013-04-17
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2013-04-17
|
07 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2013-04-17
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2013-04-17
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2013-04-16
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-04-16
|
07 | Cindy Morgan | 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 … 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). |
2013-04-16
|
07 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-04-16
|
07 | Stephen Farrell | Last call was requested |
2013-04-16
|
07 | Stephen Farrell | Ballot approval text was generated |
2013-04-16
|
07 | Stephen Farrell | Ballot writeup was generated |
2013-04-16
|
07 | Stephen Farrell | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-04-16
|
07 | Stephen Farrell | Last call announcement was changed |
2013-04-16
|
07 | Stephen Farrell | Last call announcement was generated |
2013-04-16
|
07 | Stephen Farrell | Last call announcement was generated |
2013-04-15
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-04-15
|
07 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-07.txt |
2013-04-12
|
06 | Stephen Farrell | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2013-04-09
|
06 | Stephen Farrell | State changed to AD Evaluation from Publication Requested |
2013-04-08
|
06 | Amy Vezza | (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? … (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. ------------------------------- |
2013-04-08
|
06 | Amy Vezza | Note added 'Hannes Tschofenig (hannes.tschofenig@gmx.net) is the document shepherd.' |
2013-04-08
|
06 | Amy Vezza | Intended Status changed to Proposed Standard |
2013-04-08
|
06 | Amy Vezza | IESG process started in state Publication Requested |
2013-04-07
|
06 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-06.txt |
2013-02-13
|
05 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-05.txt |
2013-01-07
|
04 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-04.txt |
2012-11-24
|
03 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-03.txt |
2012-11-18
|
02 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-02.txt |
2012-10-06
|
01 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-01.txt |
2012-05-27
|
00 | Torsten Lodderstedt | New version available: draft-ietf-oauth-revocation-00.txt |