Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 08 February 2011 05:46 UTC

Return-Path: <eran@hueniverse.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 590003A7012 for <oauth@core3.amsl.com>; Mon, 7 Feb 2011 21:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4tJ-4LSx+qh2 for <oauth@core3.amsl.com>; Mon, 7 Feb 2011 21:46:08 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C32493A6C9A for <oauth@ietf.org>; Mon, 7 Feb 2011 21:46:07 -0800 (PST)
Received: (qmail 27392 invoked from network); 8 Feb 2011 05:46:13 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 05:46:11 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 22:46:10 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Skylar Woodward <skylar@kiva.org>, OAuth WG <oauth@ietf.org>
Date: Mon, 07 Feb 2011 22:45:56 -0700
Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
Thread-Index: AcvG6+zzWEcHzevzR2iwFVcy1BpGKgAZhIvg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org>
In-Reply-To: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
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, 08 Feb 2011 05:46:09 -0000

Hi Skylar, 

> -----Original Message-----
> From: Skylar Woodward [mailto:skylar@kiva.org]
> Sent: Monday, February 07, 2011 9:25 AM

> On including parameters for signing...
> 
> I'd retract my suggestion that we'd include parameter-hash in the header.
> Instead, I would suggest making parameters optional in calculating the
> signature using a flag as with bodyhash. Providers could require including
> parameters if so desired. Parameters could be included as currently defined,
> or with a hash method similar to entity-body (which I find both simpler and
> more congruent).
> 
> Again, the goal in making query parameters optional is to allow providers to
> make signature calculation as simple as possible for clients (so much as it is in
> line with the security requirements of the provider) and avoid complexities in
> implementation such as those that tripped up OAuth 1.

I have been opposed this line of thinking for over two years now.

As actual code shows, producing the normalized request string per this specification is straight-forward. Developers finding it hard should use a library and not try to write their own. They can also cut-and-paste the 10 or so lines it takes to produce the string.

This authentication method comes with well understood security properties. By making query parameters optional because of developer ease, providers will be giving up an important part of the protection this protocol offers. This is especially true for the majority of APIs where query parameters are critical to the request integrity.

The right solution here is to provide either a library for your developers, or an API without any parameters.

EHL

> 
> 
> 
> On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:
> 
> > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
> >
> > New version includes the following changes:
> >
> >    o  Added body-hash support.
> >    o  Updated OAuth 2.0 reference to -12 and added token type registration
> template.
> >    o  Removed error and error URI attributes (codes were just a duplication
> of the HTTP status codes).
> >
> > Feedback would be greatly appreciated.
> >
> > EHL
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth