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

From: [email-masked]
Date: Sun, 16 Jun 2013 02:13:45 -0700

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           : OAuth 2.0 Token Revocation
	Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
	Filename        : draft-ietf-oauth-revocation-10.txt
	Pages           : 11
	Date            : 2013-06-16

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-10

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

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 16 Jun 2013 11:28:22 +0200

Hi,

the new revision addresses DISCUSSES and comments raised during IESG 
evaluation:

- DISCUSS by Barry Leiba: incoporated Barry's text proposal - it 
strengthens requirements on the authorization server to immediately 
revoke tokens while acknowledging the practical constraints on change 
propagation among distributed servers
- D2 by Richard Barnes: changed text to refer to respective section of 
RFC 6749 on TLS version
- description of revocation endpoint URL now refers to respective 
section of RFC 6749 (comment by Sean Turner)
- added intro to IANA section (comment by Joel Jaeggli)
- some nits and editorial changes - should cover all comments raised 
during IESG evaluation

There are two open issues
- discussion regarding the TLS version on the list
- DISCUSS regarding the mandate to use TLS (D1/Richard Barnes)

regards,
Torsten.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jun 2013 14:54:29 +0100

Hi,

> - DISCUSS regarding the mandate to use TLS (D1/Richard Barnes)

Can we please close these on the list so we don't have to
spend time on 'em in Berlin?

As a reminder Richard's discuss says:

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 ..."

Thanks,
S.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 29 Jun 2013 10:31:33 +0200

Hi Stephen,

> corresponding URI, just in case the client screws up

If the server does not support HTTP (which is prohibited by the spec), the client cannot send the request over HTTP so there is no way to expose the token. I don't understand why the server should support HTTP.

> deleting the sentence starting "The authorization server MUST

This is already fixed in -10.

Regards,
Torsten.