Re: [OAUTH-WG] why are we signing?

Dick Hardt <Dick.Hardt@microsoft.com> Wed, 02 December 2009 21:14 UTC

Return-Path: <Dick.Hardt@microsoft.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 1DEB93A690D for <oauth@core3.amsl.com>; Wed, 2 Dec 2009 13:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level:
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 QjxSt674T+1s for <oauth@core3.amsl.com>; Wed, 2 Dec 2009 13:14:41 -0800 (PST)
Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 19F453A6849 for <oauth@ietf.org>; Wed, 2 Dec 2009 13:14:41 -0800 (PST)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 13:14:59 -0800
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 2 Dec 2009 13:14:32 -0800
From: Dick Hardt <Dick.Hardt@microsoft.com>
To: Mike Malone <mjmalone@gmail.com>
Thread-Topic: [OAUTH-WG] why are we signing?
Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4CAAA8m8IACiKgAgAEc2gCAABV1AA==
Date: Wed, 02 Dec 2009 21:14:30 +0000
Message-ID: <18811A0A-0FA7-4481-8B7F-83A6C4DF2F7C@microsoft.com>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <cb5f7a380911120745w2f576d1ej300723581e50f03f@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <cb5f7a380911130837q40d07388y1ae9b472be0ae57a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A4E79C63-7B5C-4FBA-9DDA-5FEB35B9584D@microsoft.com> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <a9d9121c0912021157h299bfc96y139c48fa918c8776@mail.gmail.com>
In-Reply-To: <a9d9121c0912021157h299bfc96y139c48fa918c8776@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1b265f40-cbf9-4963-abd4-a8392c116335>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] why are we signing?
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: Wed, 02 Dec 2009 21:14:44 -0000

On 2009-12-02, at 9:57 AM, Mike Malone wrote:
> I'm far from an expert on TLS/PKI, but here's a thought (and I'm
> pretty sure this has come up before)... If TLS is simpler than
> signatures then why not just use PKI for everything. A lot of the
> problems that have come up with OAuth are solved by PKI - client certs
> replace tokens, you can delegate authority by creating
> sub-certificates, the consumer provisioning problem is largely solved,
> etc.
> 
> It seems like WRAP is using bits of PKI to solve half of the problem
> and then re-inventing other bits of PKI for the other half. If TLS/PKI
> is the solution, why not go whole hog?


I'm confused by your PKI references to WRAP.

The token in WRAP is not just about identifying the Client, it also enables authorization.

In the implementations we (Microsoft) have done, the token contains all the claims that the Protected Resource needs to make an access control decision.

I hope to have the OAuth WRAP spec reformated as an I-D late next week.

-- Dick