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

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 24 April 2013 17:16 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7076421F963F; Wed, 24 Apr 2013 10:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.032
X-Spam-Level:
X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo9bqJ7PCBP5; Wed, 24 Apr 2013 10:16:58 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7009521F961E; Wed, 24 Apr 2013 10:16:41 -0700 (PDT)
Received: from [79.253.49.97] (helo=[192.168.71.56]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1UV3J9-0005Nw-DB; Wed, 24 Apr 2013 19:16:39 +0200
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-C1161E88-7F4A-42F0-946C-0AAA3EB40977
Content-Transfer-Encoding: 7bit
Message-Id: <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
X-Mailer: iPad Mail (10B329)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 24 Apr 2013 19:16:37 +0200
To: Mark Nottingham <mnot@mnot.net>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "draft-ietf-oauth-revocation.all@tools.ietf.org" <draft-ietf-oauth-revocation.all@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 17:16:59 -0000

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