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 15:35 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 7443D21F8680 for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2012 07:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 s3J7bb6ncHfW for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2012 07:35:44 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 495C021F85C2 for <oauth@ietf.org>; Wed, 25 Jan 2012 07:35:44 -0800 (PST)
Received: (qmail 20087 invoked from network); 25 Jan 2012 15:35:44 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 15:35:44 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 25 Jan 2012 08:35:41 -0700
From: Eran Hammer <eran@hueniverse.com>
To: "eran@hammer-lahav.net" <eran@hammer-lahav.net>, Mike Jones <Michael.Jones@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, "ietf@ietf.org" <ietf@ietf.org>
Date: Wed, 25 Jan 2012 08:35:35 -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: AczbPI44ucw8FyvfTTSWdvUFZixqdQAOHCwwAAB24UA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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 15:35:45 -0000

And by 'restrict the encoding' I meant limit the allowed character-set in the value to remove the need for encoding (but encoding which results in a valid value - as unnecessary as it may be - is still allowed).

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer
> Sent: Wednesday, January 25, 2012 7:32 AM
> To: Mike Jones; Julian Reschke; 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
> 
> Didn't change my view. I'm expanding it to say that we should restrict the
> encoding but at the same time reuse the exact same syntax as the default
> header. It's bad for the web if developers write custom parsers just for
> Bearer that will break on any other scheme. For example:
> 
>    WWW-Authenticate: Bearer realm="example", OTHER-SCHEME
> param=something
> 
> Is a valid header but one that will cause clients written to the Bearer spec to
> fail.
> 
> EHL
> 
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Wednesday, January 25, 2012 12:37 AM
> > To: Eran Hammer; Julian Reschke; 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
> >
> > Eran, do I then correctly understand that you've changed your mind on
> > the position you took in http://www.ietf.org/mail-
> > archive/web/oauth/current/msg07698.html, which was: "All I agree with
> > is to limit the scope character-set in the v2 spec to the subset of
> > ASCII allowed in HTTP header quoted-string, excluding " and \ so no
> > escaping is needed, ever."?  I ask this, because if I correctly
> > understand your statement that you agree with Julian, you are now
> > taking the position that you are OK with recipients being required to
> > perform escape processing for the scope (and
> > other) parameters and with them being required to accept them either
> > as tokens or as quoted strings.
> >
> > This raises a question I'd like to ask John Bradley, William Mills,
> > Phil Hunt, and Justin Richter:  Since all of you replied with a +1 to
> > Eran's original statement, are you still in agreement with it, or are
> > you now possibly reconsidering your position, as Eran apparently has.
> > I'm asking, because your messages have been part of the basis upon
> > which I've been taking the position as editor that the working group
> > consensus is that no quoting may occur.  (The other reason that I
> > believed, as editor, that this was a consensus position is that this
> > syntax restriction has been present in every Bearer draft, as it was
> > in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.)
> > If that's not the actual working group consensus (or it's not anymore), it
> would be good to know that now.
> >
> > Finally, I'd like to respond publicly to a comment made to me in a
> > private note sent to me about the current discussions.  In it, the
> > sender (an IETF "old
> > hand") observed that it could appear from the strength of my responses
> > to Julian's feedback that I might be trying to defend a particular
> > personal view of how these issues should be resolved.  I responded to
> > him that the irony here is that I'm not trying to representing a
> > personal position.  Rather, I'm truly trying to do what I believe an
> > IETF editor is supposed to do, which is to represent the working group's
> positions.
> >
> > I'm quite open to the working group making it clear that its position
> > has changed with respect to Julian's comments and equally open to the
> > working group standing behind the text in the current draft.  If the
> > chairs would like to help bring this issue to successful closure, I
> > would highly welcome their participation as well.
> >
> > Personally, I'd mostly just like to see the spec finished!
> >
> > 				-- Mike
> >
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Eran Hammer
> > Sent: Tuesday, January 24, 2012 10:24 PM
> > To: Julian Reschke; 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
> >
> > 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
> > _______________________________________________
> > 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