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

[Mike Jones <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Eran Hammer
Sent: Wednesday, May 09, 2012 5:17 PM
To: [e-mail] WG ([e-mail])
Subject: [OAUTH-WG] Bearer token DISCUSS items related to errors

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