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

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Apr 2013 10:07:50 +1000

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.

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.

Minor Issues:

2) The specification title is too broad; "Token Revocation" could apply to many IETF technologies. Suggest "OAuth Token Revocation".

--
Mark Nottingham   http://www.mnot.net/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Apr 2013 19:16:37 +0200

Hi Mark,

thanks for your feedback. I added my comments inline.

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

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

---

From: Dick Hardt <[email-masked]>
Date: Wed, 24 Apr 2013 10:34:48 -0700

Hi Torsten

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

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.

-- Dick

On Apr 24, 2013, at 10:16 AM, Torsten Lodderstedt <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Apr 2013 20:06:45 +0200

Hi Dick,

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

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

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 24 Apr 2013 22:49:17 +0200

> And there are much more possible options, e.g. using WebFinger. But is their THE discovery mechanism?

What is the point of a specification that avoids making decisions? Being in the HTTP environment actually provides so detailed 'guidelines' how to do design such things like discovery and deletion of 'stuff' that it makes no sense whatsoever to defer that to, um, profiles (which is sort of a synonym for 'dunno, shove that decision in that future basket').

Stick a post in the ground and move on :-)

My 2c

Jan

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 26 Apr 2013 10:50:03 -0700

On Wed, Apr 24, 2013 at 11:06 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Unlike RFC 6749 where the user is starting from documentation, OAuth
> Revocation is an extension to an existing protocol.
>
>
> 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
>
> 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.
>
> 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.
>
>
> 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.
>
>
> --