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

Hi Stephen,

Am 28.06.2013 um 15:54 schrieb Stephen Farrell <stephen.farrell@cs.tcd.ie>:

> 
> Hi,
> 
> On 06/16/2013 10:28 AM, Torsten Lodderstedt wrote:
>> 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)
> 
> 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

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.

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

This is already fixed in -10.

Regards,
Torsten.

> 
> Thanks,
> S.
> 
> 
>> 
>> regards,
>> Torsten.
>> 
>> Am 16.06.2013 11:13, schrieb internet-drafts@ietf.org:
>>> 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/
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 