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

Dick Hardt <dick.hardt@gmail.com> Mon, 27 September 2010 06:20 UTC

Return-Path: <dick.hardt@gmail.com>
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 B94C23A6C6D for <oauth@core3.amsl.com>; Sun, 26 Sep 2010 23:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
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 7XJgG-U2RldT for <oauth@core3.amsl.com>; Sun, 26 Sep 2010 23:20:08 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id DD63F3A6AFC for <oauth@ietf.org>; Sun, 26 Sep 2010 23:20:08 -0700 (PDT)
Received: by pxi6 with SMTP id 6so1660145pxi.31 for <oauth@ietf.org>; Sun, 26 Sep 2010 23:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mSJi1iMloHrN+pHTRJFQOdhbXPRp+XNjrNQvkvO3Pu8=; b=fssv2bEZjnQrwlOo0t/JkMkMccIHPYf2erH/6adllwIeLnWBObLlrBKehexC2nNYsL fELl2sYwNw7WZgC27ahwL0cKjKDsO95D/sWyMkrsCStAtwObElypSeQHpMmZkWa5lKw2 sieK45sS3hK7RfEQldn6+d+8yz35qYCQzqKk0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=mzLHjmk0hzyvYrUKHS5bU+UD21/6bme+FGVFg6Rjiry28HRri/KozL6LC6FdQNTE4g oUUMI6iSk6dSSyC3ieR+zXkAEweFQk7fGQyd727K+tZrPoQXGQ/kSBtJtgE83R11xYbM 5bObjAlSQMRs5pFPylfRtX3iER7d7zir75vkw=
Received: by 10.142.117.7 with SMTP id p7mr5946104wfc.90.1285568446912; Sun, 26 Sep 2010 23:20:46 -0700 (PDT)
Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id 9sm6949448wfd.0.2010.09.26.23.20.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Sep 2010 23:20:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D45D80132@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sun, 26 Sep 2010 23:20:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD71CDA0-15FA-4860-87EA-BE9C4B6932E4@gmail.com>
References: <C8C15057.3AC64%eran@hueniverse.com> <D01C840D-BA0A-42AE-A6C4-C43E6E84C2F2@gmail.com> <255B9BB34FB7D647A506DC292726F6E1126BFB1574@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D45D80132@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1081)
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
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: Mon, 27 Sep 2010 06:20:09 -0000

On 2010-09-26, at 11:02 PM, Eran Hammer-Lahav wrote:

> Clearly, this group is making choices based on the kind of applications using OAuth 1.0 today. The decision to focus on bearer tokens came from specific experiences and types of consumer web services.

Any other applications are hypothetical.

> 
> I'm all for a simple and generic way to issue a token with additional attributes such as a secret, required algorithm, etc. But main objection is to the publication of a standard that promotes bearer token as its "purest" form, and moves something that I consider a core security component to somewhere else.

It is only a core security component in some use cases.

>  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. 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.