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

My .02 - 

On 10/05/2011, at 2:49 AM, Eran Hammer-Lahav wrote:

> 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?

I don't have strong feelings about whether or not it's a good idea overall. However, I tend to think that if it's intended for more than one scheme, it'd make more sense to a) make it a separate header, much like Authentication-Info for successful responses, and b) also note that it's a good idea to put human-friendly information in the response body (e.g., in HTML).

Making it a separate header not only avoids collisions (largely theoretical at this stage), it also doesn't put too much information into WWW-Authenticate (which has never had the cleanest syntax), avoiding potential parsing issues, etc.


> If you answered yes to #1:
> 
> 2. Should the WG apply this to all new HTTP authentication schemes (currently, MAC, but potentially more)?

What does "apply" mean here? Do you just want to allow people to use the same error codes with other auth schemes if they want to, knowing that most existing software won't use it?


> 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 really want people to use it for other schemes, it needs to be a separate spec; no matter how much you say otherwise, folks assume that if it's part of a bigger spec, it's inseparable.


> If you answered no to #1:
> 
> 4. Should the Bearer draft retain the attribute and registry for its own scheme-specific needs?

Not sure how that's relevant here...

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 12 May 2011 01:15:03 UTC