Subject: [OAUTH-WG] Bearer token DISCUSS items related to errors

From: Eran Hammer <[email-masked]>
Date: Thu, 10 May 2012 00:17:10 +0000

Most people on this WG are not aware of all the details around the on-going IESG review and my objections to making additional changes to the core specification. Currently, these are the open issues preventing the bearer specification from being approved:

>From Russ Housley:

  Section 3.1 specifies Error Codes.  Alexey suggested the use
  of an IANA registry for this field.  Apparently there is already a
  registry created by draft-ietf-oauth-v2. However this document does
  not register values defined in this section in that registry.  Please
  explain why the IANA registry is not leveraged by this document.

>From Sean Turner:

  s3.1: Shouldn't the character set restrictions on error, error_description,
  and error_uri be in draft-ietf-oauth-v2?

>From Pete Resnick:

[ the use of a reserved query parameter 'access_token' ]

---

Sean Turner closed this issue today so it is no longer relevant. Basically, as currently drafted, there is no overlap between the parameters and the encoding reflects the transport restrictions of each specification. While I don't have a technical objection to limiting the character set of the error parameter in the core specification, I do object to making a breaking change at this point without any actual technical justification.

Peter Resnick's issue has nothing to do with this so I will not discuss it.

The only remaining issue is Russ' which SHOULD have been replied to with:

---
The use of the error registry in draft-ietf-oauth-v2 for the error codes defined in the bearer specification was extensively discussed by the working group and the special design committee appointed by the chairs. The working group consensus was that these errors, while similar is name and meaning to those used in the core specification, belong elsewhere. They relate to the protected resource namespace which is not covered by the core specification.

In addition, there was no working group consensus whether the error parameter used by the bearer specification was the preferred mechanism for relaying errors in protected resource access or HTTP authentication schemes (e.g. the MAC token scheme draft does not use such mechanism and opted to rely on simple HTTP status codes instead). At the time, the working group reached out to HTTPbis for guidance and did not receive a conclusive answer.

This issue was documented in the issues tracker [1] and was closed after extensive discussions. The working group's consensus was that if a registry is required, it should be defined within the bearer specification.
---

All Russ was asking for is an explanation. Instead, he was told there was no good reason and that it should be changed. That was clearly not an honest representation of clear working group consensus from over 10 months ago which was achieved at great effort.

EH

[1] http://trac.tools.ietf.org/wg/oauth/trac/ticket/11

---

From: Mike Jones <[email-masked]>
Date: Thu, 10 May 2012 00:42:24 +0000

I believe that you're intentionally oversimplifying things.  My memory was that originally you objected to having the OAuth Errors Registry at all.  Issue 11 was about getting it created in the first place, despite your objections.  The compromise with you to get you to agree to it was that you intentionally excluded registration of errors resulting from OAuth flows E and F.  I fully remember what a painful process it was to get you to agree to that much, if that's the "extensive discussion by the working group" that you're referring to.  I wouldn't characterize the result as "working group consensus" so much as exhaustion.

As I see it as an individual, Russ's DISCUSS results from the simple observation that OAuth errors are not consistently registered across the OAuth specs.  This may or not be changed, depending upon the result of the consensus call and a decision by the chairs.  I'm fine with either outcome, but believe that the working group should earnestly consider his request.

We're almost done.  I hope that after the consensus calls, this and the other open issues can be quickly addressed and we can finally achieve OAuth 2.0 RFCs.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Wednesday, May 09, 2012 5:17 PM
To: [email-masked] WG ([email-masked])
Subject: [OAUTH-WG] Bearer token DISCUSS items related to errors

---

---

EH

---

From: Eran Hammer <[email-masked]>
Date: Thu, 10 May 2012 00:47:39 +0000

I don't need to repeat three months of extensive arguments. AIRI, you were as strongly opinionated about this as I was, and it was largely an argument between my, you, and Tony Nadalin. After we failed to reach WG consensus - we did resolve some items as you indicated below - the chairs formed a design committee on which both Tony and I served. The committee unanimously decided to not include the protected resource location in the registry. The chairs presented this to the group, then closed the items.

My point is, it was a long and extensive debated that required much effort to resolve. Now all of a sudden, getting a quick round of +1 is enough to undo 3 months of negotiations. That's clearly a broken process.

EH

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, May 09, 2012 5:42 PM
To: Eran Hammer; [email-masked] WG ([email-masked])
Subject: RE: Bearer token DISCUSS items related to errors

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer
Sent: Wednesday, May 09, 2012 5:17 PM
To: [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: [OAUTH-WG] Bearer token DISCUSS items related to errors

---

---

EH

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 May 2012 19:38:12 -0600

On 5/9/12 6:17 PM, Eran Hammer wrote:

> All Russ was asking for is an explanation. Instead, he was told there
> was no good reason and that it should be changed. That was clearly not
> an honest representation of clear working group consensus from over 10
> months ago which was achieved at great effort.

Was it presented this way in the proto write-up or verbally on an IESG
telechat or in some other way? Just curious to figure out where things
went awry here...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer <[email-masked]>
Date: Thu, 10 May 2012 01:42:12 +0000

I'm just looking at the parts copied to the list and in the tracker. I haven't actually seen much response coming from Russ. I did reach out to him directly to see if the discuss can be resolve without further action.

EH

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2012 6:38 PM
> To: Eran Hammer
> Cc: [email-masked] WG ([email-masked])
> Subject: Re: [OAUTH-WG] Bearer token DISCUSS items related to errors
> 
> telechat or in some other way? Just curious to figure out where things went
> awry here...
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
>

---

From: Eran Hammer <[email-masked]>
Date: Thu, 10 May 2012 02:20:15 +0000

On 4/10/12 8:25 PM, Mike Jones wrote:

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

This doesn't sound like an editor reflecting working group consensus...

The design committee concluded its work mid-May 2011. Draft -16 reflected the changed proposed by the committee.

Barry's notes at the conclusion of the design committee 5/17/11:

> #10, error registry:
> Marc, Julian, PSA commented on Eran's post to httpbis list.
> No objection, no strong opinion, not sure it's needed.  Separate 
> header better than using error codes.
> PROPOSAL: Bearer doc specifies how it handles error conditions, and 
> there is no registry now.  A future doc that uses Bearer as a base can 
> create a registry if needed.  Agreement on the call with this.

So the actual feedback was that the error parameter wasn't necessarily the best choice for returning error in the first place, that it was not necessarily the right general purpose mechanism, but that no harm was done by allowing bearer to keep it and try it out. The intention was clearly to leave things be and see how people are using it. Then if someone actually wants to extend it (at the time we had no use cases for extending bearer error codes), they can create the registry.

Bottom line: this exact issue was intensely debated and reached a conclusion after 3 months of debates. The chair made a clear consensus call. Issue was closed until Mike Jones declare it as a "defect in the errors registry text" without providing much context. When I provided this context to Sean Turner, he closed the same issue raised against the core specification in his discuss.

EH

> Sent: Wednesday, May 09, 2012 6:42 PM
> To: Peter Saint-Andre
> I'm just looking at the parts copied to the list and in the tracker. I haven't
> actually seen much response coming from Russ. I did reach out to him
> directly to see if the discuss can be resolve without further action.
> 
> EH
> 
> > > All Russ was asking for is an explanation. Instead, he was told
> > > there was no good reason and that it should be changed. That was
> > > clearly not an honest representation of clear working group
> > > consensus from over 10 months ago which was achieved at great effort.
> >
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth