Re: [OAUTH-WG] Error Registry Consensus Call

Eran Hammer <eran@hueniverse.com> Mon, 07 May 2012 23:20 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2163221F8667 for <oauth@ietfa.amsl.com>; Mon, 7 May 2012 16:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level:
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42b8ApZlIKrj for <oauth@ietfa.amsl.com>; Mon, 7 May 2012 16:20:44 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id CBAEA21F8665 for <oauth@ietf.org>; Mon, 7 May 2012 16:20:44 -0700 (PDT)
Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 7BLi1j0010Dcg9U01BLikM; Mon, 07 May 2012 16:20:42 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Mon, 7 May 2012 16:20:41 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org WG" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Error Registry Consensus Call
Thread-Index: AQHNLKOIX0E3b1HWEkWa/Y91Xa0KqJa+8ENQgAB5f4D//4zPsA==
Date: Mon, 7 May 2012 23:20:40 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201021F34@P3PWEX2MB008.ex2.secureserver.net>
References: <53E17703-C3BD-48A1-8CB6-BD0D3795DD77@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201021DD6@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943664C90F7@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664C90F7@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.74.213.174]
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-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2012 23:20:46 -0000

Errors that have nothing to do with the core spec. There is not overlap in functionality between the two documents and their use cases.

EH

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Monday, May 07, 2012 4:12 PM
> To: Eran Hammer; Hannes Tschofenig; oauth@ietf.org WG
> Subject: RE: [OAUTH-WG] Error Registry Consensus Call
> 
> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer
> Sent: Monday, May 07, 2012 4:07 PM
> To: Hannes Tschofenig; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Error Registry Consensus Call
> 
> A.
> 
> 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.
> 
> EH
> 
> 
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Hannes Tschofenig
> > Sent: Monday, May 07, 2012 3:48 PM
> > To: oauth@ietf.org 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>