Re: [OAUTH-WG] Basic signature support in the core specification

Dick Hardt <> Mon, 27 September 2010 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEC983A6A1A for <>; Mon, 27 Sep 2010 06:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.284
X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qqbt1Q0l3aNS for <>; Mon, 27 Sep 2010 06:30:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 12DAF3A69AB for <>; Mon, 27 Sep 2010 06:30:20 -0700 (PDT)
Received: by pzk6 with SMTP id 6so1601848pzk.31 for <>; Mon, 27 Sep 2010 06:30:58 -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=WHrg0Y9XuchWAYdP0+iP4LIR+36YG35rOzqTxgIYbXk=; b=taxroaKqaPL2KsmeD6E3vkWc3AHxw8VQJQDGAGDEdZt3+BaCcTlNvcvR9f7vIfMLMO F/UNF7ZGqOXfDTL7zyCmoLNDZToiSZbw0onvYVnyvQe6fRM/ctiYjEOcyNKPr9awpDl8 LErlaSnYpvd3cVa5ByLbGB4/VJUWOsEaj6V1M=
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=CtkC6qW4SkX/7ew2Ehx42Atk2ESZBgv/go619+dC3rmYe/oIkN01G06bo9ji7TfZpM UZZEJXkWayS8Ia8EMQzbUbaECu9XJ5OABtYV/RBByEQM2nwDnrBiDITTFgyBoCEBx09B QnviBipEeIEpBNcmapOOFLaNjTKQAPg6yfASw=
Received: by with SMTP id n3mr6454971wfg.30.1285594258609; Mon, 27 Sep 2010 06:30:58 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id y36sm7415456wfd.6.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 06:30:56 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-6-196892513"
From: Dick Hardt <>
In-Reply-To: <>
Date: Mon, 27 Sep 2010 06:30:54 -0700
Message-Id: <>
References: <> <> <> <90C41DD21FB7C64BB94121FBBC2E72343D45D80132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72343D45D80136@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
To: John Panzer <>, Eran Hammer-Lahav <>
X-Mailer: Apple Mail (2.1081)
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
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: Mon, 27 Sep 2010 13:30:21 -0000

I'll echo John's comments and remind you that Micrsoft, Yahoo! and Google security experts with plenty of real world experience worked on WRAP which is OAuth bearer tokens.

Microsoft, Google, Salesforce, Facebook and others have deployed bearer token OAuth in production after internal security reviews. I don't think that is a personal opinion, that is fact. 

wrt. another comment you had about security considerations, Brian Eaton did write up a bunch of security considerations for WRAP.

On 2010-09-27, at 12:01 AM, John Panzer wrote:

> On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav <> wrote:
> > -----Original Message-----
> > From: Dick Hardt []
> > Sent: Sunday, September 26, 2010 11:21 PM
> > >  What I absolutely object to is presenting a specification that to a new
> > reader will read as if bearer tokens are the default way to go. OAuth 2.0 core
> > today reads like a complete protocol and that's my problem.
> >
> > It is a complete protocol for many existing use cases.
> That's clearly a matter of personal opinion :-) and why we have been arguing about this for over a year.
> > For those use cases
> > where it is not, you can call require signatures and point people to the
> > signature spec, just like the use of bearer tokens points people to the TLS
> > specs.
> According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is a recipe for disaster.
> Actually in [1], Ben Laurie does not say that a simple reference to TLS is a recipe for disaster.  (Go read it.)  In fact his first point is that you need a well-define threat model before you can talk sensibly about any of this; I would really like us to do that in this case too.
> People tend to implement TLS incorrectly on the client side which voids many of the important protections it is meant to provide.
> The bits they tend to implement incorrectly (specifically, things like checking for certificate revocations) seem to me to be very general and exactly the kinds of things one needs in order to implement _any_ protection against the endpoint impersonation you are worried about.  Why would they be more likely to get it right for a new protocol than for an existing one?
> As the editor, I am having a hard time consolidating your view which treats readers as security experts, capable of making educated decisions about the protocol, and the demands from others that the specification should be completely accessible to any developer (especially those with no security background) and read like a tutorial on OAuth.
> If we want to keep the full range, we need to clearly express it, including highlighting the significant shortcomings of bearer tokens, the known TLS deployment issues, and the value in whatever signature proposals we have ready to reference or include.
> Standards are meant to improve interoperability, but also security. This is why any IETF charter dealing with an existing technology states that the working group may break compatibility if it has interop or security reasons to do so. We are doing fine on interop, but doing pretty badly on security.
> [1]
> [2]
> _______________________________________________
> OAuth mailing list