Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

Eran Hammer <eran@hueniverse.com> Wed, 25 January 2012 06:24 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 4101C21F8675 for <oauth@ietfa.amsl.com>; Tue, 24 Jan 2012 22:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 aLuChVazB67z for <oauth@ietfa.amsl.com>; Tue, 24 Jan 2012 22:24:03 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 92CAF21F84C5 for <oauth@ietf.org>; Tue, 24 Jan 2012 22:24:03 -0800 (PST)
Received: (qmail 17705 invoked from network); 25 Jan 2012 06:24:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 06:23:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 24 Jan 2012 23:23:57 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Julian Reschke <julian.reschke@gmx.de>, "ietf@ietf.org" <ietf@ietf.org>
Date: Tue, 24 Jan 2012 23:23:51 -0700
Thread-Topic: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
Thread-Index: Acza70cEhZRkpgsWT3eanhkQYYblkgAOmHSA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de>
In-Reply-To: <4F1F3D84.1030300@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: The IESG <iesg@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
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: Wed, 25 Jan 2012 06:24:04 -0000

I fully agree with Julian's perspective. I believe there is sufficient feedback requiring further review of this issue. If the editor cannot facilitate a path forward, I request the chairs to intervene. 

I will make sure this feedback is fully applied to the MAC token specification in the next draft.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Julian Reschke
> Sent: Tuesday, January 24, 2012 3:24 PM
> To: ietf@ietf.org
> Cc: The IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
> 
> On 2012-01-23 16:58, Julian Reschke wrote:
> > On 2012-01-23 16:46, The IESG wrote:
> >>
> >> The IESG has received a request from the Web Authorization Protocol
> >> WG
> >> (oauth) to consider the following document:
> >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
> >> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ...
> >
> > Please see my comments in
> > <https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html>
> > which I think have not been addressed.
> > ...
> 
> In an off-list conversation I heard that what I said before may not be as clear
> as it could be.
> 
> So...
> 
> 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.
> 
> 2) In the IANA considerations, it references the registration procedure
> defined in <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-
> 2.3>
> (now -18, but that doesn't matter here).
> 
> 3) That document recommends in
> <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1>:
> 
>     o  The parsing of challenges and credentials is defined by this
>        specification, and cannot be modified by new authentication
>        schemes.  When the auth-param syntax is used, all parameters ought
>        to support both token and quoted-string syntax, and syntactical
>        constraints ought to be defined on the field value after parsing
>        (i.e., quoted-string processing).  This is necessary so that
>        recipients can use a generic parser that applies to all
>        authentication schemes.
> 
> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been
> mentioned that it might not have ignored it if it had UPPERCASE
> requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual
> protocol, not on recommendations on other specs.
> 
> 5) The registration requirement for a new scheme is "IETF review", which RFC
> 5226 defines in <http://tools.ietf.org/html/rfc5226#section-4.1> as:
> 
>        IETF Review - (Formerly called "IETF Consensus" in
>              [IANA-CONSIDERATIONS]) New values are assigned only through
>              RFCs that have been shepherded through the IESG as AD-
>              Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
>              intention is that the document and proposed assignment will
>              be reviewed by the IESG and appropriate IETF WGs (or
>              experts, if suitable working groups no longer exist) to
>              ensure that the proposed assignment will not negatively
>              impact interoperability or otherwise extend IETF protocols
>              in an inappropriate or damaging manner.
> 
> In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from
> HTTPbis pointing out the problem  -- from Mark Nottingham, the WG chair,
> and myself, one of the authors.
> 
> And yes, I believe the way OAuth defines the syntax *will* impact
> interoperability.
> 
> Also, I haven't seen any explanation why OAuth can not follow the
> recommendation from HTTPbis.
> 
> Hope this clarifies things,
> 
> Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth