Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt

From: [email-masked]
Date: Wed, 13 Feb 2013 14:13:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : Token Revocation
	Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
	Filename        : draft-ietf-oauth-revocation-05.txt
	Pages           : 9
	Date            : 2013-02-13

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 13 Feb 2013 23:19:01 +0100

Hi all,

I just published a new revision, which should cover all the issues 
raised/dicussed during WGLC.

I applied the following changes:
- introduced a new parameter "token_type_hint", which a client may use 
to give the authorization server a hint about the type of the token to 
be revoked
- replaced "authorization" by "authorization grant"
- an attempt to revoke an invalid token is now handled like a successful 
revocation request (status code 200)
- CORS is now a MAY instead of SHOULD
- extended description of how developer/client may obtain endpoint location
- Improved wording regarding expected client behavior after sucessful 
processing of the revocation request -> "The client must assume the 
revocation is immediate upon the return of the request."
- Explanation of different policies and why having different server 
policies should not cause interop problems
- aligned structure with core spec by introducing sub-sections for 
request and response

regards,
Torsten.

Am 13.02.2013 23:13, schrieb [email-masked]:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 14 Feb 2013 10:32:11 +0000

Hi
> revocation request (status code 200)
Does it create some precedent, meaning that while people suggest using 
4xx statuses to indicate different sort of failures in this case 200 is 
returned, to eliminate a potential security attack. I mean, should it 
become the recommended practice ?

For example, in the discussion about DELETE, should it be 204 that is 
returned all the time ?

Sergey

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 17 Feb 2013 12:03:57 +0100

Hi Sergey,

Am 14.02.2013 11:32, schrieb Sergey Beryozkin:
> 4xx statuses to indicate different sort of failures in this case 200 
> is returned, to eliminate a potential security attack. I mean, should 
> it become the recommended practice ?
>

good point. In this particular case, we decided to go with 200 merely 
because the "error" indicates a state the client anyway wanted to 
achieve for the particular token. I dont know whether this can be 
generalized.

regards,
Torsten.