Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

Skylar Woodward <> Wed, 27 October 2010 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1637E3A6768 for <>; Wed, 27 Oct 2010 14:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y0iAKgqY0z66 for <>; Wed, 27 Oct 2010 14:46:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 011EC3A67E4 for <>; Wed, 27 Oct 2010 14:46:20 -0700 (PDT)
Received: by gwb15 with SMTP id 15so889625gwb.31 for <>; Wed, 27 Oct 2010 14:48:11 -0700 (PDT)
Received: by with SMTP id w20mr8409346anc.108.1288215723069; Wed, 27 Oct 2010 14:42:03 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 25sm224975anq.28.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 14:42:02 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Skylar Woodward <>
In-Reply-To: <>
Date: Wed, 27 Oct 2010 23:41:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Freeman, Tim" <>, OAuth WG <>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)
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, 27 Oct 2010 21:46:22 -0000

On Oct 27, 2010, at 8:09 PM, Freeman, Tim wrote:

> The questions currently interesting to me about use cases are:
> * The only use cases that made sense to me about signatures used them for auditability, where they enabled blame to be properly placed after information leaked to the wrong people.  People were proposing use cases that claimed that signatures improved privacy, that is, the ability to keep the information out of the hands of the wrong people.  So far as I know all use cases where signatures improved privacy seemed to fall apart after a few minutes inspection.  Do we agree that signatures improve auditability but not privacy, or does someone still believe in a use case where signatures improve privacy?

For Kiva, our use case would be something along the lines of "secondary protection mechanism."   To access certain types of data we want client authentication (ie, identification) to request and use tokens. The specification w/o signatures depends only on SSL to protect secrets, passwords, and tokens and thus client identity. By requesting signed requests we have a second mechanism on top of SSL to protect secrets in the event that request is leaked to an improper endpoint - as secrets are never sent over the wire. To reuse some of Zachary's language, we're combining two solutions to solve one problem.

We agree of course, that SSL, properly used - with no human error, is enough to secure the secrets between the two parties. However, secondary protection mechanisms are popular in the financial world - site keys, RSA fobs, shared secrets, IP-filtering, SMS-issued pins. Though any one mechanism is enough, a second mechanism makes things even more difficult for clever attackers (and careless developers). Given the options available to us, shared secrets confirmed though the use of signatures offer the most attractive balance of protection vs. ease of deployment (many of our partners are in developing countries which offer logistical and technological challenges to other methods).

That said, I don't advocate requiring signatures as a part of the spec (our needs/preferences are possibly too unique?), but I would like them included. Thus, if some non-political use cases drive signatures to be added, we'd certainly like to adopt the common standard. In lack of a published standard for signatures, we'll add our own layer additional layers of protection onto the spec as others have done. (OAuth 1.0a signatures suit us in lack of a simpler new standard for 2.0, especially given the amount of published works related to doing them correctly.)