Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call

From: Mike Jones <[email-masked]>
Date: Mon, 28 Feb 2011 20:50:58 +0000

As editor, having received no comments on the normative content of draft-ietf-oauth-v2-bearer-03, and having made no breaking changes since draft -01, other than one change voted upon by the working group, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call.

I'll note that this draft requires editorial updates to the IANA Considerations section framework specification to register its errors.  This should happen in draft -14 at the same time that the security considerations are added.  At that point, hopefully we can go to working group last call on the framework specification as well.

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Feb 2011 14:13:33 -0700

I am opposed to all the new registration changes and requirements which have any impact on draft-ietf-oauth-v2. This request seems a bit odd given my feedback (which you have, again, ignored).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: [email-masked]
Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 28 Feb 2011 21:24:31 +0000

I did not ignore your feedback.  I replied to it, pointing out why I believe your position is incorrect.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Monday, February 28, 2011 1:14 PM
To: Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call

EHL

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Feb 2011 14:27:14 -0700

My last note on this was:

---
OAuth 2.0 defines two endpoint, each with a set of error codes. These codes are not extensible and therefore do not require a registry. If you want to allow error code extensibility, you need to make the case for that with requirements and use cases. I have not seen any.

My API uses the 'position' parameter for protected resources. Am I expected to register it? It has nothing to do with OAuth, but if I supported Bearer token would be used alongside the 'oauth_token' parameter. The 'oauth_token' parameter is an nasty hack to make it easy for developers to access protected resources without using the Authorization header (based on browser limitations from 4 years ago). Defining a registry for this parameter is just adding insult to injury.

The bearer token draft can define whatever registries it want for those using *bearer* tokens. It has no say on anything else. Period. If you want to make changed to other drafts, you need to make a case and build consensus. By definition, your drafts cannot change any requirement in other drafts unless you update them (this is an IETF process rule).

Can you provide use cases, requirements, and examples for each of your new proposals?
---

Did I miss a reply?
EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, February 28, 2011 1:25 PM
To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call

EHL

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 28 Feb 2011 21:34:07 +0000

I realize that we disagree.  Unless you change your position, it seems that the working group will need to decide whether registering error codes aids interoperability.  I believe that it does.

(You also appeared to agree as well in draft 11, in which you included the text "[[ Add mechanism for extending error codes ]".)

                                                                -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Monday, February 28, 2011 1:27 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call

---

Did I miss a reply?

EHL

EHL

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Feb 2011 15:05:42 -0700

The text in -11 was from the initial extensibility draft and was removed when I revisited the issue and could not come up with any requirements for extending error codes. You made a claim that an error code registry aids interoperability but offered no use cases or requirements showing how this new registry solves an actual problem.

As most people who ever interacted with an IANA registry know, very few actually help interoperability. Most just frustrate developers for no good reason to the point where the registry is the least useful reference. If you notice the new extensibility language in -13, it makes the registry less strict in its requirements for vendor-specific parameters. IOW, it defines the bare minimum needed to help avoid parameter name collision.

But the error code registry is only one issue. Your proposal goes further and defines two new locations for which you have provided no requirements and use cases to show how your solution solves a problem.

We can add plenty of registries: an endpoint registry for future new endpoints like a device endpoint, a client authentication registry, a grant type registry for extension URI types, a registry for non-URI callback values, etc. The bottom line, a registry is meant to reduce the likelihood of namespace collisions where such a collision will *actually* cause interoperability problems.

If you want to add an error code registry, you MUST provide at least one example of an error code you plan to introduce that will require registration or interoperability will fail.

'Aids interoperability' is not a justification if you don't actually show how your solution accomplishes it (and what problem is this solution trying to solve).

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, February 28, 2011 1:34 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call

                                                                -- Mike

---

Did I miss a reply?

EHL

EHL

                                                                -- Mike

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 28 Feb 2011 17:28:46 -0500

I personally think the error code registry is a good idea, and the resourse parameter registry is a very very bad idea. I also didn't see anything approaching consensus on these changes in the wg, but heres my vote.

- justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Monday, February 28, 2011 4:13 PM
To: Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last   call

EHL

I’ll note that this draft requires editorial updates to the IANA Considerations section framework specification to register its errors.  This should happen in draft -14 at the same time that the security considerations are added.  At that point, hopefully we can go to working group last call on the framework specification as well.

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Feb 2011 18:25:02 -0700

Hey Justin,

Can you provide some examples, use cases or requirements?

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 2:29 PM
> To: Eran Hammer-Lahav; Mike Jones; Hannes Tschofenig; Blaine Cook
> Cc: [email-masked]
> I personally think the error code registry is a good idea, and the resourse
> parameter registry is a very very bad idea. I also didn't see anything
> approaching consensus on these changes in the wg, but heres my vote.
> 
> - justin
> I am opposed to all the new registration changes and requirements which
> have any impact on draft-ietf-oauth-v2. This request seems a bit odd given
> my feedback (which you have, again, ignored).
> 
> EHL
> 
> 
> 
> 
> As editor, having received no comments on the normative content of draft-
> ietf-oauth-v2-bearer-03, and having made no breaking changes since draft -
> 01, other than one change voted upon by the working group, I believe that
> draft-ietf-oauth-v2-bearer-03 is ready for working group last call.
> 
> I'll note that this draft requires editorial updates to the IANA Considerations
> section framework specification to register its errors.  This should happen in
> draft -14 at the same time that the security considerations are added.  At that
> point, hopefully we can go to working group last call on the framework
> specification as well.
> 
>                                                                 -- Mike