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

Dick Hardt <dick.hardt@gmail.com> Mon, 27 September 2010 20:52 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 D26EB3A6D72 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 13:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 bmqjrleZSAYW for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 13:52:49 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1E9EE3A6CF3 for <oauth@ietf.org>; Mon, 27 Sep 2010 13:52:48 -0700 (PDT)
Received: by pwi3 with SMTP id 3so959872pwi.31 for <oauth@ietf.org>; Mon, 27 Sep 2010 13:53:27 -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=JOt30NtmKpNNR0X690t5UAjDrLHs2C5Ll+bYOwaC6cA=; b=vCGPPNbbQv+mkdrKrLHTXvsiA9vh1gFf3rRSgZdnKDAA6QxDHqucxKS9L1Gs2gVD7V eF+vufbmxNYjHcUyXPtaSBtFSP6BB3Rj7EH6BreVZTisbXQnCmFWp91LQw1VVRP/sL3l biiWq8KsGV19iwXiO295LA+cxOsRWpl2qAhxY=
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=DaqtOh6IXyWaMbCN1O/NSFRrE9yazxNiJj/1AVuh13BfsbAuTYhn5qwMeh5XEOa9JR TN9wJV8j3fUHu2iiMjQvKU4tgnTDd48zv+kkP8wxKkRzdYT3iVob7hURlUngH/qaBADr UhYfcaYsIr0fz0Hu2r2a2OtnELoY9XHZcCYwg=
Received: by 10.142.247.28 with SMTP id u28mr7006696wfh.264.1285620807703; Mon, 27 Sep 2010 13:53:27 -0700 (PDT)
Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id e12sm7883759wfh.1.2010.09.27.13.53.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 13:53:26 -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: <4CA0E1A2.60606@lodderstedt.net>
Date: Mon, 27 Sep 2010 13:53:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7C68183-E3C0-4D9F-A676-301BA42A9843@gmail.com>
References: <C8C2AB33.3AD38%eran@hueniverse.com> <BFD0447E-42BB-441F-A7B3-B0CFB0F6317B@gmail.com> <E0B0A685-4BA7-451B-B0DF-C0FC429595D1@xmlgrrl.com> <4CA0C96E.8090907@alcatel-lucent.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70CB6FF@TK5EX14MBXC101.redmond.corp.microsoft.com> <4CA0E1A2.60606@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
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 20:52:50 -0000

On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:

> Am 27.09.2010 19:11, schrieb Anthony Nadalin:
>> What is needed is needed is the security considerations section complete, I don't think that the signature specification has to be in the core to be complete, there are previsions to use SSL, if one needs to go beyond this then a reference to the signature specification would be in the security considerations section. The separation allows for an OAuth independent solution that would/could cover message and token encryption and signing. If signature is going to be an extension point
> 
> I don't understand why signing tokens and signing message shall be solved with the same solution.

They don't have to use the same solution, but you have the same issues (discovery, key management) in both cases, so why not solve them the same way?

> 
> In my opinion, tokens are opaque to any client and are just passed through as an uninterpreted string from authorization server (AS) to the resource server (RS) via the client. So the OAuth spec does not necessarily have to standardize their format (incl. signatures) in order to facilitate protocol interoperability. AS and RS just have to use the same format. Since both have a thight relationship that should not be a problem. If one like it can use an existing formats like SAML assertions or SWT.

If the AS and RS are tightly bound, then the token can be opaque. If there is one to many or many to many relationships, then you need a standard token, and for scale, you want to sign the token.

> 
> That's completely different from message signing. Here all parties are involved. So any client accessing a pair of AS and RS has to know how to sign a message in order to prove legitimate token ownership and/or protect the message from modifications.

See point above.

-- Dick