Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
John Panzer <jpanzer@google.com> Tue, 28 September 2010 19:18 UTC
Return-Path: <jpanzer@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68ED3A6BF3 for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 12:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.948
X-Spam-Level:
X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hdelhaBSfsK for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 12:18:17 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 805B73A6DE0 for <oauth@ietf.org>; Tue, 28 Sep 2010 12:18:17 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o8SJIwYd010643 for <oauth@ietf.org>; Tue, 28 Sep 2010 12:18:58 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285701538; bh=Ym/kRayHIk7irY9U0x+lDK5zNKI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NtqMHV1mGNNUYr4+NwGWE7EYlYACWOYj9KIX23Oal0FxYu7pCZCpl6RsMVfOT7Lu/ T8wS7nl0GW1nMWXDFDs0g==
Received: from pxi3 (pxi3.prod.google.com [10.243.27.3]) by wpaz17.hot.corp.google.com with ESMTP id o8SJIHmN032630 for <oauth@ietf.org>; Tue, 28 Sep 2010 12:18:57 -0700
Received: by pxi3 with SMTP id 3so2303537pxi.21 for <oauth@ietf.org>; Tue, 28 Sep 2010 12:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=f26xcig3mDdl+cix0fffr3ZRaT4cZtJKRIMWsP5dpcM=; b=o9/Keute3Nab/99xvMBCU4/XFmLpm2zZt3IqTowriOlGwDszeCGcUCeSNV862OtnKo nCdhrVepaQtz9RAXQ6+Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=UhoaCYpC5nfe5YDBrmRZQa7rIQSN8uxzN6NCqe++47BQdM4boiQEfIj7B0rd3oIV4g rem1EX8YDzPi1YmWrXXA==
Received: by 10.142.139.11 with SMTP id m11mr402344wfd.195.1285701536885; Tue, 28 Sep 2010 12:18:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.233.7 with HTTP; Tue, 28 Sep 2010 12:18:36 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: John Panzer <jpanzer@google.com>
Date: Tue, 28 Sep 2010 12:18:36 -0700
Message-ID: <AANLkTi=asCF0ffkxm0PjuZozGsStmHcpVu1=gEkN_TzJ@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary="000e0cd1858a64aba8049156b7f0"
X-System-Of-Record: true
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 28 Sep 2010 19:18:20 -0000
+1. -- John Panzer / Google jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Mon, Sep 27, 2010 at 11:25 PM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: > (Please take a break from the other threads and read this with an open > mind. I have tried to make this both informative and balanced.) > > > > --- IETF Process > > > > For those unfamiliar with the IETF process, we operate using rough > consensus. This means most people agree and no one strongly objects. If > someone strongly objects, it takes a very unified group to ignore that > person, with full documentation of why the group chose to do so. That person > can raise the issue again during working group last call, area director > review, and IETF last call - each has the potential to trigger another round > of discussions with a wider audience. That person can also appeal the > working group decision before it is approved as an RFC. > > > > The process is managed by the working group chairs. The chairs elect the > editor and make consensus calls. So far this working group had only a few > consensus calls (breaking the 1.0a RFC into two parts and dropping these in > favor of a unified WRAP + 1.0a draft). From my experience and understanding > of the process, this working group does not have rough consensus on any of > the open items to make consensus calls and close the issues. Simply > dismissing the few objections raised will not accomplish finishing the > document sooner, but will only add more rounds of debates now and at a later > time. > > > > One of the problems we have is that we work without a charter. Usually, the > charter is the most useful tool chairs have when limiting scope and closing > debates. For example, had we fixed the charter last year to explicitly say > that we will publish one document with both bearer tokens and signatures, > the chairs could have ended this argument by pointing to the charter. Since > we have no charter, the chairs have little to offer in terms of ending these > disagreements. We never officially agreed what we are here to solve. > > > > The reality of this working group is that we need to find a way to make > everyone happy. That includes every one of those expressing strong opinions. > Any attempt to push people around, dismiss their views, or reject reasonable > compromises will just keep the issues open. If this small group cannot reach > agreement, the specification will surely fall apart during working group > last call, area director review, IETF last call, application area review, > security area review, general area review, IANA review, and IESG review. > > > > It’s a long process, and at each step, anyone can raise their hand and > object. A united working group is the most important tool to end discussions > over objections and concerns raised at each step. It also give people the > confidence to implement a working group final draft before it is published > as an RFC (because it is much less likely to change). > > > > --- Open Issues > > > > This working group has failed to reach consensus on a long list of items, > among them are the inclusion of signatures, signatures format, use of HTTP > authentication headers, restrictions on bearer tokens, support for specific > profiles, etc. While many of these items faded away, I would not be surprise > to see them all come back. > > > > The current argument over signatures ignores compromises and agreements > reached over the past two years. This working group explicitly rejected WRAP > as the replacement for OAuth 1.0 and the whole point of combining 1.0a with > WRAP was the inclusion of signatures. We reached another agreement to keep > signatures at the Anaheim meeting. The current draft is a version of WRAP > alone. > > > > There are currently three separate threads going on: > > > > 1. OAuth 1.0a style signatures vs. JSON proposals > > 2. Including a signature mechanism in core > > 3. Concerns about bearer tokens and HTTPS > > > > The first item will not be resolved because we are not going to reach > industry consensus over a single signature algorithm (this is a general > comment, not specific to these two proposals). The only thing we can do is > let those who care about each solution publish their own specification and > let the market decide. > > The second item, while it was part of the very first compromise this > working group made (when we combined the two specifications), cannot be > resolved because of #1. We can’t agree on which signature method to include, > and including all is not practical. For these reasons, including a signature > algorithm in core is not likely to happen. I have made some proposals but > they received instant negative feedback which means we have no consensus. > > > > The third item has also been debated and blogged for a long time and is not > going to be resolved in consensus. Instead, we will need to find the right > language to balance security concerns with the reality that many providers > are going to deploy bearer tokens no matter what the IETF says. The OAuth > 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS, > and I would expect the same issue to come up with the current draft. > > --- Proposal > > > > 1. Add a parameter to the token response to include an extensible token > scheme. > > > > The default (if omitted) will be whatever the bearer token scheme is > called. This will allow the authorization server to return any token type it > deems appropriate, and for other specifications to define additional > parameters such as token_secret. Others can extend the token request > endpoint by allow the client to request a specific token scheme. > > > > 2. Break the core specification into multiple parts. > > > > Go back to the original working group consensus to break the document into > two parts: getting a token and using a token. Getting a token will include > everything from core expect for section 5. Section 5 will become a new > specification which will describe how to use a bearer token (replacing the > generic ‘OAuth’ scheme with something more descriptive like). > > > > 3. Introduce two signature proposals in one or more documents, for the JSON > token and 1.0a-like method. > > > > One, both, or none can become working group item. > > > > --- Benefits > > > > 1. Remove the HTTP binding from the core specification, leaving it > transport agnostic for using access tokens. > > > > 2. Solve a few open issues: > > > > * Concerns over bearer tokens as the preferred/promoted/default token > method. > > * The use of one or more HTTP authentication schemes, and the general > architecture of using tokens. > > * Issues around scheme names. > > * Concerns over requiring HTTPS will be limited to only one part of the > protocol. > > * The need to pick one signature format. > > * The need to finish signatures before the core (‘how to get an access > token’). > > * The need to decide on discovery for the entire protocol (moves it to each > scheme). > > > > 3. Allow moving the core specification to last call within a few weeks (and > maybe also the bearer token part). > > > > --- Downside > > > > The only downside of this approach is that people will need to read at > least two documents. It will not take any more effort or time, just some > guidance. > > > > --- Request for feedback > > > > This proposal represents a purely editorial compromise. I believe it gives > everyone enough to move forward. It has no impact on implementations. By > breaking the problem into pieces, we allow those who strongly disagree to > simply disengage that work and focus on the parts that matter to them. > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
- [OAUTH-WG] Looking for a compromise on signatures… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Manger, James H
- Re: [OAUTH-WG] Looking for a compromise on signat… Justin Richer
- Re: [OAUTH-WG] Looking for a compromise on signat… Stefanie Dronia
- Re: [OAUTH-WG] Looking for a compromise on signat… George Fletcher
- Re: [OAUTH-WG] Looking for a compromise on signat… Luke Shepard
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Marius Scurtescu
- Re: [OAUTH-WG] Looking for a compromise on signat… Brian Campbell
- Re: [OAUTH-WG] Looking for a compromise on signat… John Panzer
- Re: [OAUTH-WG] Looking for a compromise on signat… Keenan, Bill
- Re: [OAUTH-WG] Looking for a compromise on signat… Peter Saint-Andre
- Re: [OAUTH-WG] Looking for a compromise on signat… Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] Looking for a compromise on signat… Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] Looking for a compromise on signat… Dick Hardt
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Mark Mcgloin
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Anthony Nadalin
- Re: [OAUTH-WG] Looking for a compromise on signat… Mark Mcgloin
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Thomas Hardjono
- Re: [OAUTH-WG] Looking for a compromise on signat… Luke Shepard
- Re: [OAUTH-WG] Looking for a compromise on signat… Lukas Rosenstock
- Re: [OAUTH-WG] Looking for a compromise on signat… Dick Hardt
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Dick Hardt
- Re: [OAUTH-WG] Looking for a compromise on signat… Pelle Wessman
- Re: [OAUTH-WG] Looking for a compromise on signat… Eran Hammer-Lahav
- Re: [OAUTH-WG] Looking for a compromise on signat… Breno