Not ignoring points made along the way as there are points from each view point, and not sure it's counterproductive to state the issues and what is driving the issues on a single list. So let's move on.
I don't believe that there is anything wrong in combining into a single registry, as this has been done in other specifications. I don't believe that HTTP status codes can convey all the information that may be needed by the client, you may be able to shoehorn all into the three but that is a disservice to the poor client who may have to figure these codes out. What I'm hearing is that some folks feel that we will ever have any OAuth Extensions and anything that extends OAuth can do whatever it likes and we don't want to have any conventions dictated by the base. From: Eran Hammer-Lahav [mailto:[email protected]] Sent: Tuesday, March 22, 2011 9:52 PM To: Anthony Nadalin; Phil Hunt; Manger, James H Cc: [email protected] Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry These are separate issues and collapsing them into one list is counterproductive (not to mention ignoring many useful points made along the way). What made this entire topic a mess is the original error registry proposal included in the bearer token specification which conflated completely different things into one useless registry. Regarding the v2 specification: - Should the error codes defined in sections 4.2.2.1 and 5.2 be extensible? There is agreement that some extensibility is needed. The open question is whether such extensibility should be combined with the existing parameter extension registry or not. The reason for combining it with the existing registry is that so far, the only valid use case raised on the list was for defining extension-specific errors such as 'unknown display type' for the UX extension. Regarding the bearer token and MAC token specifications: - Should these specification define error codes beyond the HTTP status code returned (400, 401, 403)? James Manger and I argue that given that there are three error conditions and three corresponding codes, there is no point in defining additional error codes. The HTTP status provides the client with all the information it needs. Others argue that they need finer error codes for cases such as token expiration (which is covered by 401). - Should the error codes defined for the bearer token specification be extensible? Since the MAC specification does not define additional error code and does not allow for any extensibility which can alter the protocol behavior (and generate additional error states), no error extensibility is needed. Bearer token specification defines an error registry but does not offer any use cases or requirements for such theoretical scenario. - Should the bearer token and MAC token specification share an error registry, error response, header format, etc.? The two specification are dramatically different and each has its own set of utilization methods, terminology, and errors. In addition, the MAC specification extends OAuth but is not an OAuth extension. OAuth extensions are specifications directly affecting the process of obtaining tokens, not using tokens. EHL From: Anthony Nadalin [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Tuesday, March 22, 2011 2:32 PM To: Eran Hammer-Lahav; Phil Hunt; Manger, James H Cc: [email protected]<mailto:[email protected]> Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry There seems to be some basic disagreements; (1) The various token specifications standalone (e.g. draft-ietf-oauth-v2-bearer-03, etc.) and are not extensions to draft-ietf-oauth-v2-xx and have no need to have common error messages/codes (2) Errors in draft-ietf-oauth-v2-xx are final and we don't see a need to have a mechanism to add additional ones because of #(1) (3) We want to put a burden on the clients to have to deal with all the various error messages/codes from the different token profiles and the client has to figure this out Given the above I'm not sure why we have a registry for the parameters, seems incionsistent. From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Eran Hammer-Lahav Sent: Monday, March 21, 2011 9:33 PM To: Phil Hunt; Manger, James H Cc: [email protected]<mailto:[email protected]> Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry 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]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Phil Hunt Sent: Monday, March 21, 2011 8:17 PM To: Manger, James H Cc: [email protected]<mailto:[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
