Subject: Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

From: Mike Jones <[email-masked]>
Date: Wed, 11 Apr 2012 00:25:02 +0000

Hi Alexey,

About your issue 1:  The OAuth Core spec, where "scope" is primarily defined, includes the sentence "The [scope] strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3).  I could add that clarification to the Bearer spec as well to make it clear that the scope values are context-dependent, if that would address your concern.

About your issue 2:  Investigating the OAuth Errors Registry a bit further (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) while I'd like to be able to register the OAuth Bearer errors in this registry, what I believe to be a defect in the errors registry text currently prevents this.  Specifically, the registry enumerates only three "Error usage location" values:  authorization code grant error response, implicit grant error response, and token error response.  To be able to use this registry, it would also have to have a fourth usage location:  "resource access error response".  If you'd like to file an issue against the OAuth Core spec to get this additional usage location added to the registry, then I'd be glad to use it.  I believe that this would be significantly preferable to adding a separate OAuth Bearer errors registry that's exactly like the general-purpose one, only separate from it.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Tuesday, April 10, 2012 7:03 AM
To: [email-masked]
Cc: General Area Review Team; [email-masked]; The IESG
Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

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

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sean Turner <[email-masked]>
Date: Wed, 11 Apr 2012 19:42:09 -0400

On issue 2, Russ has already entered his ballot on the base spec so I'll 
pick this one up.

spt

On 4/10/12 8:25 PM, Mike Jones wrote:
> 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>.
>
> 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>.

---

From: Eran Hammer <[email-masked]>
Date: Thu, 12 Apr 2012 03:44:38 +0000

Issue 2 received extensive WG discussion.

At the core of it was the question of how the IETF should handle HTTP authentication error codes. We consults with the HTTPbis WG and consensus was that at this point we do not want to create a general purpose error registry for HTTP authentication schemes. In fact, Bearer is the exception using special error codes which could (and should) just use HTTP 4xx code. 

While bearer is closely linked to OAuth, it is still a standalone scheme. There was no consensus that other schemes (even the OAuth related MAC scheme) will sign into such a registry. 

In short, the OAuth error registry is not an appropriate venue for the bearer error codes. It is unfortunate that Mr. Jones failed to represent the WG consensus on this issue in his response to the IESG. 

EH

On Apr 11, 2012, at 19:42, "Sean Turner" <[email-masked]> wrote:

> On issue 2, Russ has already entered his ballot on the base spec so I'll pick this one up.
> 
> spt
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 10:54:33 +0200

Citing from Sean's dicuss 
(<https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ballot/#sean-turner>):

> 1) I'm hoping the answer to this one is "there's no problem" but I gotta ask and
> maybe the APPs ADs can confirm:  Is there any issue with this specification
> using ABNF from [I-D.ietf-httpbis-p1-messaging] while OAUTH 2.0 uses [RFC5234]?

The ABNF from HTTPbis is a superset of RFC 5234 in that it defines a 
list rule for readability. I don't think that this rule is used anymore 
in the bearer spec, so it can just say it's using RFC 5234.

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Apr 2012 12:22:17 +0100

> Hi Alexey,
Hi Mike,
I've dropped issue 2, Sean took charge of discussing it with IESG.
> About your issue 1:  The OAuth Core spec, where "scope" is primarily defined, includes the sentence "The [scope] strings are defined by the authorization server" (see http://tools.ietf.org/html/dra…
Yes, but only partially. I would also like to see a clear statement that 
there is no centralized registry for scope values, plus some examples 
(more than 1) of how values of this attribute can look like.

With out this information I don't think the spec is implementable.