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

Pelle Wessman <pelle@kodfabrik.se> Fri, 01 October 2010 14:41 UTC

Return-Path: <pelle@kodfabrik.se>
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 7011E3A6C63 for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 07:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5bDbP-he20pN for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 07:41:22 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 813573A6C83 for <oauth@ietf.org>; Fri, 1 Oct 2010 07:41:22 -0700 (PDT)
Received: by pvg7 with SMTP id 7so1019126pvg.31 for <oauth@ietf.org>; Fri, 01 Oct 2010 07:42:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.92.3 with SMTP id p3mr6394689wab.77.1285944130571; Fri, 01 Oct 2010 07:42:10 -0700 (PDT)
Received: by 10.115.77.10 with HTTP; Fri, 1 Oct 2010 07:42:10 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <Actez1CK1yneinyMRserD5y1FIwYng==> <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 1 Oct 2010 16:42:10 +0200
Message-ID: <AANLkTik+_echO_iWs-OOT33gF3p8zn-1UUmt+h3hkxu_@mail.gmail.com>
From: Pelle Wessman <pelle@kodfabrik.se>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary=00163645950a1a8f0204918f330b
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: Fri, 01 Oct 2010 14:41:24 -0000

+1, I think this sounds like a sensible path forward

On Tue, Sep 28, 2010 at 8:25 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote;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
>
>