Thank you. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Mike Jones > Sent: Tuesday, March 15, 2011 1:17 PM
> 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".) A registry is *one* possible solution for extensibility. Once the requirements are established we can pick the most appropriate solution. > 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". Insufficient scope is only applicable when making protected resource requests. Since v2 doesn't address how to make authenticated requests and does not define error codes for that case, such an error code is irrelevant. The MAC scheme does not use error codes at all as existing HTTP status codes fully cover every error case. I would be surprised if the bearer token scheme cannot do the same. > 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. HTTP 503 Service Unavailable covers this and is the appropriate method to return such information. > 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. We have reviewed the document for over a year and came up with a comprehensive error response list for the endpoint defined within the specification. However, here is an example use case... Other specifications extending v2 can define additional error codes if necessary. For example, the UX extension adds a 'display' parameter to the authorization endpoint which can result in an 'unknown_display' error. However, such an error is only valuable if the client has a way to correct the request and try again, which is something the UX extension will need to address if defining such an error code. It would be helpful to hear from the UX authors how to intend to address errors related to their new parameters. > 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! As for the registry solution, a registry is not the only route for addressing such a case. Extensions can use error URIs (which is something *we* have opted to do for extension grant types, instead of using a registry). Additionally, such extensions can simply 'update the v2 RFC' to include an additional error code. A registry does not help or improve interoperability if the client is not aware of the extension and is constantly updated with new registry values (or whatever the extension policy requires). Using error URI codes is much simpler, consistent with the specification, and something I would be supportive of adding via a simple sentence to -13 saying that additional error codes may be defined and must be absolute URIs. 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)? EHL > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
