Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07

Hi Dick,

Am 24.04.2013 um 19:34 schrieb Dick Hardt <dick.hardt@gmail.com>om>:

> Hi Torsten
> 
> Unlike RFC 6749 where the user is starting from documentation, OAuth Revocation is an extension to an existing protocol.
> 

I don't get your point. Revocation is an extension to the OAuth framework.
Why is the situation any different from any other endpoint?

> FWIW: I agree with Mark that having the revocation URL be returned as an additional parameter in the access token request similar to how the refresh token is preferable.

> 
> Use of the  DELETE verb on the revocation URL is a great suggestion and makes the protocol more web like and straight forward.
> 

We discussed this and other alternative options a long time ago and the WG decided to go for the design described in the draft.

Regards,
Torsten.
> -- Dick
> 
> On Apr 24, 2013, at 10:16 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
>> Hi Mark,
>> 
>> thanks for your feedback. I added my comments inline.
>> 
>> Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>et>:
>> 
>>> I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).
>>> 
>>> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>>> 
>>> Document: draft-ietf-oauth-revocation-07
>>> Title: Token Revocation
>>> Reviewer: Mark Nottingham
>>> Review Date: 24 April 2013
>>> IETF Last Call Date: 30 April 2013
>>> IESG Telechat Date: unknown
>>> 
>>> Summary: This draft is has issues that should be fixed before publication.
>>> 
>>> Major Issues:
>>> 
>>> 1) Section 2 states that the means of discovering the revocation endpoint is out of scope of this specification, and that it can be achieved by consulting documentation. 
>>> 
>>> This is a poor design choice, at odds with the Web architecture, and fails to provide interoperability. A discovery mechanism should be specified.
>> 
>> 
>> I'm surprised about your assessment. My draft is just an extension to RFC6749, which leaves discovery out of scope as well. 
>> In my opinion, how the clients gets to know the revocation URL is a domain or application specific aspect. I expect OAuth profiles, such as OpenID Connect, to define this.
>> 
>>> 
>>> One way to do it would be to allow the revocation URI to be indicated at an earlier part of the OAuth interchange. 
>>> 
>>> Another (potentially simpler) to do it would be to assign a URI to the token itself, and allow a properly authorised client to DELETE that URI; this removes the need to specify a body format.
>> 
>> And there are much more possible options, e.g. using WebFinger. But is their THE discovery mechanism?
>>> 
>>> Minor Issues:
>>> 
>>> 2) The specification title is too broad; "Token Revocation" could apply to many IETF technologies. Suggest "OAuth Token Revocation".
>> 
>> I will change the title.
>> 
>> Regards,
>> Torsten.
>> 
>>> 
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 