Per the previous discussions, the use case is enabling OAuth specifications to
be able to extend the set of interoperable error codes. Use of an IANA
registry for this purpose is standard IETF practice. (To see *lots* of other
examples of this in practice, go to http://www.iana.org/protocols/ and search
for "error".)
One non-hypothetical motivating example is extending the set of errors in
4.2.2.1 to add an "insufficient_scope" error to indicate that the request is
valid but requires higher privileges than currently held by the caller. This
is different than "invalid_scope".
Another possible error code that is meaningful and actionable in some contexts
is "please_retry", indicating that this same request may succeed later if
retried. Services may return this when out of resources or during
initialization.
Given that we all intend OAuth to be a building block for a family of related
protocols and for new services, it would be presumptive of us to assert that
we've identified of all the actionable error conditions up front. This is
exactly parallel to the argument for the OAuth Parameters registry, which does
exist.
The IETF has a straightforward mechanism and for extending parameter spaces in
an orderly way. I believe that we'll best serve those building new protocols
and services on top of OAuth by using it!
Cheers,
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, March 14, 2011 6:30 PM
To: David Recordon
Cc: [email protected]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
Friday, March 18
It's a clear example of defining facilities without *ANY* use cases or
requirements.
We have clear use cases and actual registration requests for the current
registries defined in v2.
What's most annoying about this entire push for an error registry is that the
author and supporters have all failed to show a single example of an actual
value to be registered. I don't think I'm asking for much.
Registries must be held to the same level of adoption as any other part of the
protocol. If a feature is not being use by the time the document is finalized,
it MUST NOT be included and left out. Otherwise, this is pure astronaut
architecture and design by committee.
As for the reference to the editorial comment in draft 11 - there were other
such notes in part drafts which were simply removed without addressing
throughout the process. This registry is new, and is baseless. An important
part of our process is weeding out what is not necessary, and an error registry
clearly fails to meet this standard.
This entire thread should be stopped until someone can offer clear use cases
and requirements. Otherwise, this is a joke.
EHL
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of David Recordon
> Sent: Monday, March 14, 2011 6:04 PM
> To: Mike Jones
> Cc: [email protected]
> Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry,
> deadline Friday, March 18
>
> Has anyone extended error codes? Is there a list of error codes
> currently being used in the wild that need standardizing?
>
> --David
>
>
> On Mon, Mar 14, 2011 at 11:28 PM, Mike Jones
> <[email protected]> wrote:
> > This is not new. This is meeting the need expressed in draft 10,
> > Section
> 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending
> error codes ]]".
> >
> > It's there to provide a coordination mechanism among OAuth-related
> specifications so that different specs use the same errors for the same thing.
> >
> > -- Mike
> >
> > -----Original Message-----
> > From: David Recordon [mailto:[email protected]]
> > Sent: Monday, March 14, 2011 4:15 PM
> > To: Mike Jones
> > Cc: [email protected]
> > Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry,
> > deadline Friday, March 18
> >
> > I still haven't seen an explanation of what this registry
> > accomplishes or why
> it's become needed in the past few weeks.
> >
> > --David
> >
> >
> > On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones
> <[email protected]> wrote:
> >> As you know, the OAuth 2.0 Bearer Token draft -03 established the
> >> OAuth Errors Registry to increase interoperability among
> >> implementations using the related OAuth specifications. As you
> >> also know, there has been some discussion about whether:
> >>
> >>
> >>
> >> A) The OAuth Errors Registry belongs in in the Framework
> >> specification rather than the bearer token specification,
> >>
> >> B) The OAuth Errors Registry should continue to be defined in the
> >> Bearer Token specification and apply to all OAuth specifications,
> >>
> >> C) The OAuth Errors Registry should reside in the Bearer Token
> >> specification but be scoped back to only apply to that
> >> specification, or
> >>
> >> D) The OAuth Errors Registry should be deleted because the set of
> >> errors should not be extensible.
> >>
> >>
> >>
> >> Please vote for A, B, C, or D by Friday, March 18th.
> >>
> >>
> >>
> >> I personally believe that A makes the most sense, but given that
> >> other points of view have also been voiced, this consensus call is
> >> needed to resolve the issue.
> >>
> >>
> >>
> >>
> >> Cheers,
> >>
> >> --
> >> Mike
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >
> >
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
