Subject: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG)

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 May 2011 09:49:45 -0700

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 May 2011 09:35:30 +0200

On 09.05.2011 18:49, Eran Hammer-Lahav wrote:
> ...
> ...

Not sure. Are there error conditions servers *want* to reveal, and which 
also have interoperable implications for clients across authentication 
schemes? That is, can they really be re-used?

If that's the case, a standalone document defining these parameters, 
with an easy way for new schemes to include these params would make sense.

> ...
> ...

That being said, here are a few comments about the aforementioned spec.

    error           = "error" "=" quoted-string
    error-desc      = "error_description" "=" quoted-string
    error-uri       = "error_uri" = <"> URI-reference <">

This probably should be

    error           = "error" "=" quoted-string
    error-desc      = "error_description" "=" quoted-string
    error-uri       = "error_uri" "=" DQUOT URI-reference DQUOT

(missing quotes around the "=", and also please avoid prose productions).

Also, you do seem to ignore I18N issues with the error_description. 
What's the encoding?

(and, as a matter of taste, I'd prefer hyphens instead of underscores in 
parameter names...).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 May 2011 11:12:08 +1000

My .02 - 

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

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

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