Eran, Thanks. Thats the best summary of the problem and I think it will help move the discussion forward (finally).
Issue 1: Since only one token format could be in play at any time, there doesn't seem to be a chance for conflict unless a bearer token collides with either OAuth or HTTP itself. Let's say, worst case, two RFC's defined the same error code (lets say MAC and BEARER) with a different normative meaning. Would there really be a conflict? It doesn't seem so. The token type would dictate the RFC which would describe the definition in that case. So the value of a registry strictly becomes a more documentary function - to ensure a nice neat namespace for status codes. The downside? It ties token specs strictly to OAuth. This is the part I object to. Issue 2: I think if fully de-coupled, then the BEARER spec would be free to add whatever detail they like - as long as there is agreement within the BEARER spec community. Finally, while I agree, detailed error messages helps in user interface design (and have been a big proponent in the past), it seems that in most "Internet" cases, services decline to give detailed errors (e.g. take OpenID or SAML as examples). They tend to just report generic errors. So is there much practical value here if nobody is likely to use them? Phil [email protected] On 2011-03-21, at 9:32 PM, Eran Hammer-Lahav wrote: > 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] > > > > > 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] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
