Subject: Re: [Gen-art] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 14:48:18 +0100

Hi Mike,

On 31/01/2012 10:33, Alexey Melnikov wrote:
> On 30/01/2012 05:20, Mike Jones wrote:
>> Thanks for your useful feedback, Alexey.
> Hi Mike,
>>    Below, I'll respond to each of your comments.  I've also added the 
>> OAuth working group to the thread, so they are aware of them as well 
>> and can participate in the discussion.
  [...]
>> About your comments on scope:  OAuth 2.0 (both the Core and Bearer 
>> specs) is designed to be deployed in diverse and non-interoperable 
>> application contexts, meeting a variety of application needs.  In 
>> those various settings, which are often distinct and potentially 
>> non-interoperable, parameters such as scope, realm, etc. may have 
>> very different meanings.  This is not a bug; it is a feature, because 
>> it allows the OAuth pattern to meet the needs of numerous, often 
>> distinct, application environments.  For that reason, a registry of 
>> scope (or realm) parameters would be ill-advised and 
>> counterproductive.  It's perfectly OK and expected for a scope value 
>> such as "email" to have one meaning in one application context and a 
>> different meaning in a different, but distinct application context.  
>> Trying to impose a single meaning on particular scope values across 
>> distinct application contexts is both unnecessary and could break 
>> many existing deployments.  That being said, we fully expect
>> interoperability profiles to emerge that define interoperable sets of 
>> scope values within particular application contexts.  (The OpenID 
>> Connect specifications are one such set of profiles.)  But these 
>> meanings will always be context-specific - not global in scope.
> The way "scope" is currently defined in the document is completely 
> useless. You don't have a single example in the document. You don't 
> say how the semantics of the value differs from realm. You don't say 
> that its values are deployment specific and can be profiled in future 
> documents. Please say something about these issues in the document 
> (your explanation above would work.)
  [...]
>> About your second minor issue on error codes, the error codes 
>> registry already exists, but is in the OAuth Core spec.  See 
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.
> Can you please make this clear in the document (by adding a reference)?

I didn't see any of these addressed in -16...18. If I've missed that or 
if I've missed the discussion why these are not valid concerns, please 
let me know.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 15:03:13 +0100

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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:

1).
    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 
<http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4>. 
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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 15:27:18 +0200

On 2012-04-10 16:03, Alexey Melnikov wrote:
> ...
> ...

Speaking of which, how is an error code returned if the HTTP status is 
*not* 401?

3.1. Error Codes

    When a request fails, the resource server responds using the
    appropriate HTTP status code (typically, 400, 401, 403, or 405), and
    includes one of the following error codes in the response:

    invalid_request
          The request is missing a required parameter, includes an
          unsupported parameter or parameter value, repeats the same
          parameter, uses more than one method for including an access
          token, or is otherwise malformed.  The resource server SHOULD
          respond with the HTTP 400 (Bad Request) status code.

    ...

Is the assumption that the response body is always application/json in 
that case? It might be good to clarify that.

Best regards, Julian