IETF Logo Mail Archive

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

Dick Hardt <Dick.Hardt@microsoft.com> Tue, 01 December 2009 18:56 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 7BBAD3A6946 for <oauth@core3.amsl.com>; Tue, 1 Dec 2009 10:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.492
X-Spam-Level:
X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Rxz7YXlVByW6 for <oauth@core3.amsl.com>; Tue, 1 Dec 2009 10:56:02 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AF2783A6921 for <oauth@ietf.org>; Tue, 1 Dec 2009 10:56:02 -0800 (PST)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 10:56:21 -0800
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Tue, 1 Dec 2009 10:52:54 -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/gIAa2A2AgAA2ZwCAAVTsAA==
Date: Tue, 01 Dec 2009 18:52:40 +0000
Message-ID: <2944C863-B474-4E4D-BFCB-734BF8F29406@microsoft.com>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com> <daf5b9570911092158k682aff63l959c423c399b2277@mail.gmail.com> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <daf5b9570911111754u49f72a0aia59814b5da497a51@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> <a9d9121c0911301432y76487b39hed670f0ed609c768@mail.gmail.com>
In-Reply-To: <a9d9121c0911301432y76487b39hed670f0ed609c768@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: <6bf10c85-e4cd-4cd6-a466-ff7f9be72872>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "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: Tue, 01 Dec 2009 18:56:03 -0000

Thanks for the response Mike,  comments inline ... 

On 2009-11-30, at 12:32 PM, Mike Malone wrote:

> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <Dick.Hardt@microsoft.com> wrote:
>> 
>> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
>>> 
>>> I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable.
>> 
>> Are these use cases enumerated somewhere?
> 
> I'm not completely opposed to the TLS route, but since you asked...
> off the top of my head, here are a couple drawbacks to using TLS
> instead of signing:
>  - Bigger burden on developers who need to debug this stuff (i.e.,
> you can't sniff your own traffic to debug requests & responses).
>  - Properly setting up TLS can be complicated and expensive. For
> developers who don't have a lot of ops skills the barrier may be too
> high.

These sound barriers to a developer using TLS as opposed to use cases where TLS is not suitable.

OAuth 1.0A has similar burdens compared to getting the user's username and password.
- find a library for OAuth for your platform and install it (which may not be possible in a shared hosting environment)
- acquire a Consumer Key and Secret and store it somewhere secure

>  - You can no longer pass around signed URLs as another level of
> delegation (a use case that I use regularly for making XHR & POST
> requests from the browser). This could be a non-issue if some other
> mechanism for fourth-party delegation existed.

I don't understand this use case. Would you be able to provide a pointer to a description somewhere?

v2.23.0 | Report a Bug | By Email