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

On Wed, Apr 24, 2013 at 11:06 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi Dick,
>
>
>
> Am 24.04.2013 um 19:34 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> 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.
>
>
I think discovery should be solved in general for OAuth 2, an ad hoc
solution for revocation does sound right. For example, when authorization
codes are returned the URL of the token endpoint is not returned. Returning
discovery information with every single response is an overkill IMO, but
the whole discussion should happen somewhere else.

Maybe tokens should have been URLs, but again, it is too late for that
discussion and this spec cannot enforce or require that.

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