Re: [OAUTH-WG] Error Registry Consensus Call

Mike Jones <> Mon, 07 May 2012 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AF0221F8688 for <>; Mon, 7 May 2012 16:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.421
X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IfRQ4oZUGwCn for <>; Mon, 7 May 2012 16:12:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 335E921F8686 for <>; Mon, 7 May 2012 16:12:21 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 7 May 2012 23:12:07 +0000
Received: from mail138-va3 (localhost []) by (Postfix) with ESMTP id 4DC60400D5; Mon, 7 May 2012 23:12:07 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VS-33(zz9371I14ffI542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail138-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail138-va3 (localhost.localdomain []) by mail138-va3 (MessageSwitch) id 1336432325691996_6448; Mon, 7 May 2012 23:12:05 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 9F6F720065; Mon, 7 May 2012 23:12:05 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 7 May 2012 23:12:05 +0000
Received: from ([]) by ([]) with mapi id 14.02.0298.005; Mon, 7 May 2012 23:12:17 +0000
From: Mike Jones <>
To: Eran Hammer <>, Hannes Tschofenig <>, " WG" <>
Thread-Topic: [OAUTH-WG] Error Registry Consensus Call
Thread-Index: AQHNLKOK4/Ar7WEiKkOvuAeb5S02zZa+8uWAgAAATNA=
Date: Mon, 7 May 2012 23:12:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Error Registry Consensus Call
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 May 2012 23:12:22 -0000

The bearer spec is not intended as a general purpose HTTP Auth scheme.  Note that it includes a "scope" response, which firmly anchors it to use with OAuth, where it provides flows E-F which follow flows A-D that are specified in the framework spec - thus completing the end-to-end OAuth protocol usage flows.

These are OAuth-specific errors.

-----Original Message-----
From: [] On Behalf Of Eran Hammer
Sent: Monday, May 07, 2012 4:07 PM
To: Hannes Tschofenig; WG
Subject: Re: [OAUTH-WG] Error Registry Consensus Call


For the following reasons (all extensively discussed on this list before):

1. The OAuth core specification has nothing to do with HTTP authentication schemes.
2. The bearer specification is a general purpose HTTP Auth scheme and defining such a registry needs to be defined within those boundaries - that is, either specific to Bearer to generic to all HTTP Auth scheme opting into the error parameter.
3. There wasn't strong consensus that the error parameter was even necessary or useful to begin with. Limiting it to bearer reflects the wider IETF consensus on the matter (based on feedback received at the time from the HTTPbis WG).
4. It would be odd for someone using the bearer scheme outside of OAuth to use the OAuth error registry (and take over values that will be helpful for the core specification).
5. There is no overlap in functionality or values between the protected resource endpoint (which is part of the proprietary API namespace) and the OAuth endpoint for which the registry was created. To piggyback the OAuth registry just because it is slightly easier would be wrong. There is no interop value accomplished.

This is not simply a question of where to stick the registry. Adding this to the OAuth registry would be a fundamental change in architecture and philosophy and a significant change at this point. Adding it to the bearer specification is the only viable option.

I would request that such a change go through another IETF LC if this was the WG consensus but hope we can avoid it.


> -----Original Message-----
> From: [] On Behalf 
> Of Hannes Tschofenig
> Sent: Monday, May 07, 2012 3:48 PM
> To: WG
> Subject: [OAUTH-WG] Error Registry Consensus Call
> Hi all,
> there is an open issue concerning draft-ietf-oauth-v2-bearer-19 that 
> may impact draft-ietf-oauth-v2-26 (depending on it's resolution) and 
> we would like to get feedback from the working group about it.
> Here is the issue: When a client makes an access to a protected 
> resources then things may go wrong and an error may be returned in 
> response. draft- ietf-oauth-v2-bearer talks about this behavior.
> That's great but these error codes need to be registered somewhere. 
> Note that the registry can be created in one document while the values 
> can be registered by many documents.
> So, where should the registry be?
> There are two choices.
> a) A new OAuth errors registry goes into draft-ietf-oauth-v2-bearer.
> b) draft-ietf-oauth-v2 expands the scope of the existing OAuth Errors 
> registry to encompass errors returned from resource servers.
> Currently, draft-ietf-oauth-v2 creates registries for error codes only 
> for the exchanges from A-to-D (symbols used from Figure 1 of 
> draft-ietf-oauth-v2), but excludes registration of errors from flows E-F.
> We must create a registry for error codes from flows E-F.  In which 
> document do we want to create this registry?
> So, give us your feedback whether you have a preference by the end of 
> the week.
> Ciao
> Hannes & Derek
> _______________________________________________
> OAuth mailing list
OAuth mailing list