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

George Fletcher <> Tue, 28 September 2010 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13C5A3A6D49 for <>; Tue, 28 Sep 2010 09:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.133
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YJ6LpE4K2mqz for <>; Tue, 28 Sep 2010 09:05:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F4043A6CEE for <>; Tue, 28 Sep 2010 09:05:15 -0700 (PDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id o8SG5h2g017068; Tue, 28 Sep 2010 12:05:43 -0400
Received: from palantir.local (unknown []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 266FCE0006EB; Tue, 28 Sep 2010 12:05:40 -0400 (EDT)
Message-ID: <>
Date: Tue, 28 Sep 2010 12:05:37 -0400
From: George Fletcher <>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "OAuth WG (" <>
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-sid: 3039ac1d33c44ca212545a54
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.
> =
> _______________________________________________
> OAuth mailing list