Re: [OAUTH-WG] Error Registry Consensus Call

Eran Hammer <> Mon, 07 May 2012 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9598721F866A for <>; Mon, 7 May 2012 16:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kSYnOAtrR53h for <>; Mon, 7 May 2012 16:06:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A383C21F8665 for <>; Mon, 7 May 2012 16:06:52 -0700 (PDT)
Received: from ([]) by with bizsmtp id 7B6s1j0020CJzpC01B6s71; Mon, 07 May 2012 16:06:52 -0700
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Mon, 7 May 2012 16:06:52 -0700
From: Eran Hammer <>
To: Hannes Tschofenig <>, " WG" <>
Thread-Topic: [OAUTH-WG] Error Registry Consensus Call
Thread-Index: AQHNLKOIX0E3b1HWEkWa/Y91Xa0KqJa+8ENQ
Date: Mon, 7 May 2012 23:06:51 +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:06:53 -0000


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