Other use cases include the encoding extensions (such as the XML one, and if anyone gets around to it, the form-encoded one) and a "format not supported" error. Having a standard set of oauth errors on the protected resource is a good idea. That said:
> I am still not convinced we need to address error code extensibility, but > given my use case example above, I would be open for allowing URI error > codes. Any reason why using URI as error code isn't sufficient (please > present new use cases for such requirements)? Like I said in a previous email, I'm happy with it being a uri-based extension, like grant_type. I still think there's value in structuring what the short codes are, and I think we need *some* kind of extensibility and a way to make sure that errors don't come from different spaces with the same code and mean different things. I don't particularly care what the exact extension mechanism for this is so long as there's an accepted way to get new stuff in there without stomping on other things. I disagree that the errors are all about the client being able to automatically do something about them -- they're just as useful to push up the stack to developers. Regardless, if it's an accepted practice that other RFCs can simply "update the Oauth2 RFC" document without the use of a registry, and that we can permit some kind of namespacing for non-registered names (ie, use URIs), then we're probably covering our bases. -- Justin > EHL > > > > > > Cheers, > > -- Mike > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, March 14, 2011 6:30 PM > > To: David Recordon > > Cc: oauth@ietf.org > > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > > Of David Recordon > > > Sent: Monday, March 14, 2011 6:04 PM > > > To: Mike Jones > > > Cc: oauth@ietf.org > > > 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 > > > <michael.jo...@microsoft.com> 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:record...@gmail.com] > > > > Sent: Monday, March 14, 2011 4:15 PM > > > > To: Mike Jones > > > > Cc: oauth@ietf.org > > > > 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 > > > <michael.jo...@microsoft.com> 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 > > > >> OAuth@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/oauth > > > >> > > > >> > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
