Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 29 September 2010 05:44 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 4C30D3A6E7B for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 22:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level:
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 T6YzcbiC8-1K for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 22:44:22 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BF09C3A6E7A for <oauth@ietf.org>; Tue, 28 Sep 2010 22:43:47 -0700 (PDT)
Received: (qmail 21897 invoked from network); 29 Sep 2010 05:42:38 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Sep 2010 05:42:37 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 28 Sep 2010 22:42:37 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 28 Sep 2010 22:42:46 -0700
Thread-Topic: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Thread-Index: ActfaoKkAAbUVIQKTBe9AKyruHT30wAKedYg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DB890@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BE4113B3-D849-4BA1-B8FC-975C636D1303@gmail.com>
In-Reply-To: <BE4113B3-D849-4BA1-B8FC-975C636D1303@gmail.com>
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
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
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, 29 Sep 2010 05:44:27 -0000

> -----Original Message-----
> From: Dick Hardt [mailto:dick.hardt@gmail.com]
> Sent: Tuesday, September 28, 2010 5:09 PM

> I am mildly concerned that breaking the spec into multiple parts makes it
> harder for the spec reader to understand what is going on. Where does a
> complete example of getting and using a token? Imagine how confusing
> HTTP would be if the request and response were in separate specs.

You mean like break the HTTP specification into, say, 7 parts? Maybe something like this:

1: URIs, Connections, and Message Parsing
2: Message Semantics
3: Message Payload and Content Negotiation
4: Conditional Requests
5: Range Requests and Partial Responses
6: Caching
7: Authentication

This is exactly what the original HTTP authors are doing these days [1]. You should have probably chose another example to make your point :-).

Joking aside, I don't buy this argument for two reasons. First, most developer are not going to read the actual specification - they will read API documentations, books, and tutorials. Very few people actually read RFC 2616 in whole (most just use it as a reference for status codes). Second, you are exaggerating the complexity of following a link to another part.

Would it be better to have everything in one document? Sure! But is it worth delaying this work by another year or so? That's the point of this compromise. It gives everyone the technical details they care about, treats competing views equally, at the small cost of having to read one more document (but same number of pages) if you only care about bearer tokens. That's the compromise.

I am confident that I can write easy to follow prose that will explain that this specification shows how to obtain a token, while other specifications show how to use it (and discuss the specific properties of different token types).
 
I believe my detailed proposal addresses all the points raised in your feedback.

EHL

[1] http://tools.ietf.org/wg/httpbis/