[OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23

Eran Hammer <eran@hueniverse.com> Tue, 07 February 2012 18:05 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7415621F8929 for <oauth@ietfa.amsl.com>; Tue, 7 Feb 2012 10:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id saKO-gaJ4hoY for <oauth@ietfa.amsl.com>; Tue, 7 Feb 2012 10:05:21 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net []) by ietfa.amsl.com (Postfix) with SMTP id 3235E21F8928 for <oauth@ietf.org>; Tue, 7 Feb 2012 10:05:20 -0800 (PST)
Received: (qmail 16165 invoked from network); 7 Feb 2012 18:05:19 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) ( by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2012 18:05:19 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([]) with mapi; Tue, 7 Feb 2012 11:05:05 -0700
From: Eran Hammer <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Tue, 07 Feb 2012 11:04:59 -0700
Thread-Topic: Appsdir review of draft-ietf-oauth-v2-23
Thread-Index: AczlvkX9Wm7N4OupT3CF98JH152i4AABLmug
References: <f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk>
In-Reply-To: <f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2012 18:05:22 -0000

-----Original Message-----
From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] 
Sent: Tuesday, February 07, 2012 9:31 AM
To: apps-discuss@ietf.org; barryleiba@gmail.com; dick.hardt@gmail.com; dr@fb.com; Eran Hammer; hannes.tschofenig@gmx.net; stephen.farrell@cs.tcd.ie
Cc: iesg@ietf.org
Subject: Appsdir review of draft-ietf-oauth-v2-23

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)

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-v2-23

Title: The OAuth 2.0 Authorization Protocol

Reviewer: Henry S. Thompson

Review Date: 2012-02-07

IETF Last Call Date: 2012-01-24

Summary: This draft is almost ready for publication as an Proposed
         Standard but has a few issues that should be fixed
         before publication

[Note - My expertise is in the areas of markup and architecture, with only the average geek's understanding of security and cryptographic technologies.  Any comments below on security issues are therefore of the nature of general audience concerns, rather than technical worries.]

Major Issues:  The failure to require TLS here is worrying.  At the very least I would expect a requirement that clients which do _not_ require TLS MUST provide significant user feedback calling attention to this
-- by analogy, absence of a padlock does _not_ suffice. . .  In a somewhat parallel case, I would expect this section to at least explain why the SHOULD NOT is not a MUST NOT. Since in practice the distinction between trusted and untrusted 3rd-party scripting is difficult if not impossible to draw, as written the 2nd para is effectively overriden by the third.

11  It seems at best old-fashioned that the designer of a new access token type, parameter, endpoint response type or extension error has no better tool available than Google to help him/her discover whether the name they have in mind is in use already.  The same is true under the proposed approach for any developer trying to determine what they can use or must support.  Is there some reason that mandated URI templates, after the fashion of


are not mandated for the registries, e.g.


?  If there is a good reason, please use it to at least explicitly acknowledge and justify the basis for failing to provide a way for users and developers to use the "follow your nose" strategy [1].  If there is no good reason, please include the appropriate language to require something along the lines suggested above.  If you need a model, see [2].

Minor Issues:

A short summary of the changes from OAuth 1.0/RFC5849 would have been helpful, and it might still be a good idea to add one. . .

4.1  Would it be helpful to indicate that steps D&E may occur at any time after C, and may be repeated subsequently?

11.1  It might be useful to have an 11.1.2, which repeats references to the bearer and mac access token type registration drafts?


Apostrophes are missing in a few places in the text ("end-user s", "OAuth s"), presumably because a non-standard character encoding was used by one of the editors.

9  The bulleted list after "When choosing between an external or embedded user-agent, developers should consider:" contains several grammatical errors, e.g. "External user-agents. . . It" and "Embedded user-agents educate end-user" . . .


[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[2] http://www.w3.org/2005/04/xpointer-schemes/
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me _always_ has a .sig like this -- mail without it is forged spam]