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? -----Original Message----- From: Eran Hammer-Lahav [mailto:[email protected]] 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:[email protected]] > 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 > [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
