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

Dick Hardt <> Wed, 29 September 2010 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFC2F3A6E4A for <>; Tue, 28 Sep 2010 17:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RZwOJN8qR4LW for <>; Tue, 28 Sep 2010 17:08:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98F7C3A6E48 for <>; Tue, 28 Sep 2010 17:08:13 -0700 (PDT)
Received: by pzk6 with SMTP id 6so61009pzk.31 for <>; Tue, 28 Sep 2010 17:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=iIgE5YwV8texPcEBXtWIJzZhSW0uR6ZeOB+Ac403a/8=; b=XoYGejp/hXUQT2ijCbyXOCFVhAARI8Os54b60e6eHufWVxlnhNDsN/xoGabesuQSpU Gta0We9s8sRQdJTivxGWR+GdQFcSYEcrdbltHz35wP/t5V43mqkx0IUbL6/8jNOWBhKo FqRL3DLjS56OYZNC/2YcWkjMHyjjQuumtkbM0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=lRrOlM0xObrezvETpBQRyl/eloPzy5c5t8fRnqEnUq58yfE0Ly48g4YAJ2fM2EZH++ M9mOVPNc/34wgTfinebLi3xfNFljprhka6IZW/f0HkZYyYJCeIZOLW0CXx/8KGodWALh 0WuJTySW2DihY6zER50MvYqg81YvVHnIefriU=
Received: by with SMTP id y1mr681937wfy.193.1285718935868; Tue, 28 Sep 2010 17:08:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id e12sm9449839wfh.1.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 17:08:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-33-321569175"
From: Dick Hardt <>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 28 Sep 2010 17:08:50 -0700
Message-Id: <>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <>
X-Mailer: Apple Mail (2.1081)
Cc: "OAuth WG (" <>
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: Wed, 29 Sep 2010 00:08:16 -0000

I am mildly concerned that breaking the spec into multiple parts makes it harder for the spec reader to understand what is going on. Where does a complete example of getting and using a token? Imagine how confusing HTTP would be if the request and response were in separate specs.

I'm not sure that this compromise is a compromising. Seems like it enables people that think bearer tokens are bad can pretend to ignore them because they are in a different document.

My argument for having the signature mechanism in a different document was so that it could be used by other specs. This proposal breaks the spec at a different level, and I don't see the benefit. What am I missing?

I am supportive of having signatures be part of OAuth. I was hoping that if a signing mechanism was agreed on, that it would be in a format that would be reusable by others and would be able to have general libraries developed for it.

-- Dick

On 2010-09-27, at 11:25 PM, 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