> -----Original Message----- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Thursday, March 31, 2011 7:07 PM > To: Eran Hammer-Lahav; Mike Jones; OAuth WG > Subject: RE: Error extensibility proposal > > I have not seen your explanation of why an error registry does not satisfy the > requirements as originally proposed in the bearer token. Your proposal > recognizes the need to have a registry which is good but then you conflate > parameters registry with an error registry, not all errors will be parameter > driven. So your proposal will confuse those that will just want to register > errors like they do with the other specifications today (they know how to do > this), this seems very odd to have to do it your proposed way. Can you point > me to other specifications that have done it your proposed way?
This is exactly what I want to prevent. There should not be a way to add new error codes without adding some other extension. New errors must be specific to new flows not currently specified in the v2 specification. If someone fully implements v2 and nothing else, they should NEVER receive an unexpected error, just because someone decided to be creative. This is why we have this working group and put so much effort into building consensus. What is a v2 client supposed to do with an unknown error response? Display a 500 error to the user? In previous posts you expressed much concern for the client developer and this seems to be in line with that concern. It is unreasonable to expect client developers to constantly keep up to date with a growing error registry. A practical example for this restriction is the huge difference in the level of consensus required to add error codes to v2 now (while in draft), compared to requests to register new codes later via the registry process. We used to have more error codes and through the working group process narrowed the selection. Based on the registry rules, the few people who still want those error codes can simply reintroduce them (all they need is a stable document to reference, no RFC required). The DE will not be able to block such a request if it is well formed. This is not something I want to enable. My proposal ties new errors to new parameters because that was the only source of new errors we had use cases for. Marius just brought up the device grant type as another example, and that is a use case my proposal does not cover. It does, however, fits my criteria for valid new error codes. I will combine Mike Jones' proposal with mine and resubmit for review. EHL > -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Thursday, March 31, 2011 2:43 PM > To: Anthony Nadalin; Mike Jones; OAuth WG > Subject: RE: Error extensibility proposal > > 'PROPER' REQUIRES USE CASES AND REQUIREMENTS! > > You have to show how the proposal does not satisfy you requirements. It > fully satisfies all the requirements presented to the working group. > > EHL > > > > -----Original Message----- > > From: Anthony Nadalin [mailto:tony...@microsoft.com] > > Sent: Thursday, March 31, 2011 11:40 AM > > To: Mike Jones; Eran Hammer-Lahav; OAuth WG > > Subject: RE: Error extensibility proposal > > > > I also object, an error registry the proper approach here. > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Mike Jones > > Sent: Thursday, March 31, 2011 11:31 AM > > To: Eran Hammer-Lahav; OAuth WG > > Subject: Re: [OAUTH-WG] Error extensibility proposal > > > > I object to this proposal on two grounds: > > > > First, changing some of the "error" return codes to HTTP numbers is an > > unnecessary and unsolicited breaking change at a time that we should > > be stabilizing the spec. > > > > Second, the OAuth Errors registry is simpler and follows IETF standard > > practices. I know of no other specification where a parameters > > registry is overloaded in this manner. Please incorporate the OAuth > > Errors registry into the framework specification in lieu of this proposal. > > > > Thank you, > > -- Mike > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Tuesday, March 29, 2011 4:02 PM > > To: OAuth WG > > Subject: [OAUTH-WG] Error extensibility proposal > > > > *** Requirements > > > > The following proposal is based on two requirements: > > > > 1. Provide a way to return an OAuth error response for error > > situations other then 400 and 401. For example, if the server is > > temporarily unavailable, it will return an HTTP 503 status. However, > > it is often desirable to still return a response body using the same > > format as any other error. This makes client development easier, having to > always check for a single error code. > > > > 2. Allow extensions modifying the behavior of the authorization and > > token endpoints via additional request/response parameters to define > > additional error codes to go along with the new functionality. For > > example, the UX extension defines the 'display' parameter. It could > > define a matching 'unsupported_display' error response. > > > > No other use cases were identified for error extensibility. Note that > > this proposal is strictly limited to error resulting from the > > authorization and token endpoints. No other endpoints are included (in > > particular, protected resources are not covered by this proposal). > > > > *** Design goals > > > > The proposal was specifically designed to be minimalistic, tailored to > > the specific use cases defined, and as effortless as possible. This > > avoids defining error codes identical to existing HTTP status codes, > > as well as bind new errors to specific extension parameters. Since the > > error is useless without understanding the extension, this method > > guarantees that those developing and implementing extensions will > present it as a complete unit. > > > > *** Proposal > > > > - Non 400/401 responses > > > > If the HTTP response status code is 4xx (other than 400/401) or 5xx, > > the 'error' parameter SHOULD be set to the HTTP status code. For example: > > > > HTTP/1.1 503 Service Unavailable > > Content-Type: application/json > > Cache-Control: no-store > > > > { > > "error":"503" > > } > > > > This will also enable passing HTTP status codes such as 503 via the > > redirection response which is currently not possible. It will allow > > the authorization server to indicate a 503 situation without defining > > another error code that has the exact same meaning. > > > > - Extension errors > > > > Instead of defining an additional error registry, I propose we add a > > single field to the 'OAuth parameters registry' template: > > > > Additional error codes: > > Additional error codes related to the parameter usage. Error > > codes SHOULD begin with the parameter name > > when possible (e.g. 'example_invalid' error code for use with > > the 'example' parameter). > > > > Error collisions are unlikely because when a new extension is > > authored, the registry is reviewed for potential conflicts. Since the > > errors are extension- specific, collisions only matter if two > > extensions are to be used together. In that case, the review process > > will identify any potential problems. And since the errors are > > meaningless without understanding the extension, a registry with a > random list of errors is not very helpful. > > > > *** Feedback > > > > Please send any feedback, comments, support, and objections by 3/1 (so > > it can be included or not in -14). > > > > EHL > > > > > > _______________________________________________ > > 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
