BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG)

The OAuth working group has defined an authorization protocol [1] for delegating access to protected resources. Once access has been authorized, the client is issued a set of token credentials which are uses to make authenticated HTTP requests. To accomplish that, the OAuth working group has proposed two new HTTP authentication schemes: Bearer [2] and MAC [3].

The working group has been debating the issue of what's the best current practice for returning an error status in an HTTP authentication scheme. The Basic and Digest schemes do not specify the error condition and simply return a 401 response with a new challenge. The MAC proposal follows this pattern.

The Bearer scheme proposal is taking a more active approach, defining an 'error' response attribute for use with the WWW-Authenticate header and an error code registry to go along. The parameter and registry (especially the registry) are meant for reuse by other HTTP authentication schemes. At the moment, the three error conditions proposed by the Bearer draft are: invalid request, invalid token, and insufficient scope (which arguably is better suited using a 403 response with or without a new challenge).

While these error codes arguably do not provide an immediate actionable value (pending the help of future discovery specifications), the attribute and registry propose a forward-looking solution for when clients will be able to automatically resolve such issues (with the help of future discovery specifications).

The OAuth WG is seeking guidance on the following questions:

1. Should the WG define a general purpose method for returning errors with a 401 WWW-Authenticate headers, including a cross-scheme error code registry?

If you answered yes to #1:

2. Should the WG apply this to all new HTTP authentication schemes (currently, MAC, but potentially more)?
3. Should this new error attribute and registry be part of the main OAuth 2.0 specification, part of one of the upcoming schemes (for use with other schemes), or standalone?

If you answered no to #1:

4. Should the Bearer draft retain the attribute and registry for its own scheme-specific needs?

EHL

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
[3] http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-03

Received on Monday, 9 May 2011 16:50:23 UTC