Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

George Fletcher <gffletch@aol.com> Tue, 28 September 2010 16:05 UTC

Return-Path: <gffletch@aol.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 13C5A3A6D49 for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 09:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level:
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 YJ6LpE4K2mqz for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 09:05:15 -0700 (PDT)
Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id 7F4043A6CEE for <oauth@ietf.org>; Tue, 28 Sep 2010 09:05:15 -0700 (PDT)
Received: from mtaout-db04.r1000.mx.aol.com (mtaout-db04.r1000.mx.aol.com [172.29.51.196]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o8SG5h2g017068; Tue, 28 Sep 2010 12:05:43 -0400
Received: from palantir.local (unknown [10.181.183.128]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 266FCE0006EB; Tue, 28 Sep 2010 12:05:40 -0400 (EDT)
Message-ID: <4CA21251.8040603@aol.com>
Date: Tue, 28 Sep 2010 12:05:37 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------020200030307040505080407"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:467755680:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d33c44ca212545a54
X-AOL-IP: 10.181.183.128
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 16:05:24 -0000

  +1 I think this is a great path forward

On 9/28/10 2:25 AM, Eran Hammer-Lahav 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