Telechat Review of draft-ietf-oauth-v2-bearer-

Request Review of draft-ietf-oauth-v2-bearer
Requested rev. no specific revision (document currently at 23)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-03-23
Requested 2012-03-09
Other Reviews Genart Last Call review of - by Alexey Melnikov (diff)
Genart Last Call review of - by Alexey Melnikov (diff)
Review State Completed
Reviewer Alexey Melnikov
Review review-ietf-oauth-v2-bearer-genart-telechat-melnikov-2012-04-11
Posted at
Draft last updated 2012-04-11
Review completed: 2012-04-11


I am the assigned Gen-ART reviewer for this draft. For background on 

Gen-ART, please see the FAQ at 


Please resolve these comments along with any other Last Call comments 

you may receive.

Document: draft-ietf-oauth-v2-bearer-18.txt
Reviewer: Alexey Melnikov
Review Date: 10 April 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: 12 April 2012

Summary: Nearly ready to be published as Proposed Standard, with a 

couple of things that should be addressed or at least discussed.

Thank you for addressing most of my other issues. However there are a 

couple remaining which I think are important.

Major Issues:

   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  In some cases, the "scope" value will be used
   when requesting a new access token with sufficient scope of access to
   utilize the protected resource.  The "scope" attribute MUST NOT
   appear more than once.  The "scope" value is intended for
   programmatic use and is not meant to be displayed to end users.

I don't think this provide enough information about what this is, how it 

is to be used and which values are allowed. As this is not meant to be 

displayed to end users, then you need to say what values are allowed and 

which entity can allocate them. Is there a registry for these tokens, 

e.g. an IANA registry?

The editor provided explanation in email, however this was not reflected 

in any version of the draft.

2). Section "3.1.  Error Codes"

I've suggested to use an IANA registry for this field. Apparently there 

is already a registry created by 



However this document doesn't register values defined in section 3.1 

with IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry. 

I find this to be very confusing.

Minor issues: none

Nits: none