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: 

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

2.1.2.5  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

  http://www.iana.org/assignments/media-types/text/...

are not mandated for the registries, e.g.

  http://www.iana.org/assignments/access-token-types/bearer

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

Nits:

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

ht

[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]