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] https://www.ietf.org/mailman/listinfo/oauth
