There are two separate issues here which Mike's latest draft conflated into one.
Issues 1: The v2 specification currently does not allow for defining additional error codes to the authorization and token endpoints. The only way to define additional error codes is by updating the RFC (once published). Updating an RFC is an acceptable way of extending an existing specification, but only if it is done very infrequently. The other two options are to allow URI-formatted error code, or define a registry. In any case, all three extensibility model have a single purpose - to reduce the likelihood of an error code name collision. It does not improve interoperability unless clients actually implement the additional codes. The goal of the v2 specification must be to cover all possible scenarios so that a client implementing nothing but these codes will be able to handle error cases related to this specification. After a long discussion, the only valid use case to arise is the one in which an extension such as the UX specification (providing a way for the client to specify the display size of the authorization web page for various devices) needs additional codes. For example, the UX specification defines the 'display' authorization request parameter. If the client provides bad value, the server may want to return an error specific to this situation. The open issue is how to address this use case. Since such additional error codes are always a result of an additional request parameter, I am looking for a way to allow parameter registration to specify such related error codes without defining yet another registry. This solution is specific to the only use case we have. Defining an error registry is likely to do more harm than good, encouraging developers to define new generic error codes that are not extension-specific which will only reduce interoperability. Issue 2: The bearer token specification includes registration requirements for protected resource request parameters as well as potential error codes when a protected resource request fails. A few people have strongly objected to this new proposal since the semantics of the protected resource request is by definition, outside the scope of any OAuth specification. The only parameter allowed to infringe on the resource server namespace is the currently named 'oauth_token' parameter. There is an ongoing discussion to renamed it to 'bearer_token'. Hope this helps. EHL From: [email protected] [mailto:[email protected]] On Behalf Of Phil Hunt Sent: Monday, March 21, 2011 8:17 PM To: Manger, James H Cc: [email protected] Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry I'm still not understanding why each RFC (e.g. the bearer spec) can't define its own error codes. If you were to support the bearer token RFC, then you obviously understand the normative errors. I'm just not getting what the value of a central "OAuth" registry is. An OAuth registry also unnecessarily limits possibility of re-use of token schemes in other frameworks outside of OAuth or conversely limits the ability to use tokens (such as kerberos) in an OAuth "framework". So again, I ask what the benefit of a registry is achieved that could not be achieved within the token spec itself. Phil [email protected]<mailto:[email protected]> On 2011-03-21, at 4:38 PM, Manger, James H wrote: The bearer spec defines 3 errors (invalid_request, invalid_token, insufficient_scope), which accompany 3 different status codes (400 Bad request, 401 Unauthorized, 403 Forbidden respectively). Client apps are probably better off switching behaviour based on the HTTP status code, and ignoring the error string (perhaps put it in a log, or on a debug console so a developer can see it). It seems like overkill to have: * An HTTP status code (eg 401) * An HTTP status message (eg Unauthorized) * An error string (eg invalid_token) * An error_description (eg token is formatted incorrectly) * An error_uri (eg http://api.example.com/error/45) * The body of the HTTP response (eg an HTML page with extensive details about the error and links to the API documentation) 6 sources of error information -- and all for a bearer token that is usually opaque to the client app! Encouraging new error strings to be defined - by having a registry for them - is not ideal. Client apps that don't recognize a value learn nothing. At least with HTTP status codes a client app knows the class of error (eg 4xx or 5xx) and can behave accordingly even if it doesn't recognize the specific value (eg 538). I'd vote for F) ditch error string/description/uri for the BEARER HTTP authentication scheme. -- James Manger On 2011-03-21, at 9:48 AM, Mike Jones wrote: People voted as follows in the poll I conducted on the OAuth Errors Registry: For A: Mike Jones Igor Faynberg Justin Richter Anthony Nadalin For D or C: Eran Hammer-Lahav William Mills Given that twice as many people indicated a preference for A as for any other option, that seems to indicate a consensus for A. Therefore Eran, when you update your draft, can you please proceed on that basis? Thanks, -- Mike _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
