Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 10 March 2009 05:32 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 BEA863A6A18 for <oauth@core3.amsl.com>; Mon, 9 Mar 2009 22:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Level:
X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, GB_I_LETTER=-2]
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 yWE9XzkxqULY for <oauth@core3.amsl.com>; Mon, 9 Mar 2009 22:32:37 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D3CE63A6A16 for <oauth@ietf.org>; Mon, 9 Mar 2009 22:32:37 -0700 (PDT)
Received: (qmail 4778 invoked from network); 10 Mar 2009 05:33:12 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Mar 2009 05:33:12 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 9 Mar 2009 22:33:12 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Mon, 09 Mar 2009 22:33:32 -0700
Thread-Topic: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt
Thread-Index: AcmhEhfYzVUcOjReTn2UlDmONQfYhwALDYTwAADb92A=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723425023C6EEE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723425023C6EEB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723425023C6EEB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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] FW: I-D Action:draft-hammer-oauth-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Oauth bof discussion <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, 10 Mar 2009 05:32:38 -0000

Forgot to mention the blog post is:

http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, March 09, 2009 10:20 PM
> To: oauth@ietf.org
> Subject: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt
> 
> I spent the last 3 days writing the entire spec from scratch (except
> for the security consideration section which was just adjusted to the
> new terminology). The new revision is based on feedback I collected
> over the past year for the original specification. The main differences
> are:
> 
> * Terminology. Gone are the confusing terms (consumer, request token,
> consumer key, etc.). Instead I am using terms from the HTTP spec,
> slightly adjusted.
> 
> * Structure. The previous revision mixed authentication with
> authorization and had very little reason to the way normative text was
> placed across sections. The new structure splits the spec in two. The
> first part talks about how to make authenticated requests using two
> sets of credentials. The second part offers a method (one of many) for
> getting a token via redirection.
> 
> * Encoding. The biggest issue with the previous revision was confusion
> over parameter encoding and the signature base string. I cleaned up
> that section, added new examples, and removed a couple instruction to
> encode the signature (bugs). If followed to the letter, the spec would
> break all existing implementations... The good thing is it is confusing
> enough that most people understood it the wrong way (which is actually
> the right way). Take a look at the old section about PLAINTEXT:
> 
> ---
> oauth_signature is set to the concatenated encoded values of the
> Consumer Secret and Token Secret, separated by a '&' character (ASCII
> code 38), even if either secret is empty. The result MUST be encoded
> again.
> ---
> 
> 'The result MUST be encoded again' is just plain wrong. It is encoded
> again but according to the parameter transmission method, not the
> special way OAuth does it, and the spec as written would actually
> double encode it.
> 
> * Normative requirements. The spec previously contained many MUSTs and
> SHOULDs about stuff that could not be verified like documentation and
> obtaining client credentials. I took out all the ones that didn't
> actually made any practical difference.
> 
> I'm sure there is more, since this is practically a brand new spec
> (same exact protocol). Please read and provide feedback.
> 
> EHL
> 
> 
> 
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-
> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
> Sent: Monday, March 09, 2009 4:45 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action:draft-hammer-oauth-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : The OAuth Core Protocol
> 	Author(s)       : E. Hammer-Lahav, B. Cook
> 	Filename        : draft-hammer-oauth-01.txt
> 	Pages           : 33
> 	Date            : 2009-03-09
> 
> This document specifies the OAuth core protocol.  OAuth provides a
> method for clients to access server resources on behalf of another
> party (such a different client or an end user).  It also provides a
> redirection-based user agent process for end users to authorize access
> to clients by substituting their credentials (typically, a username and
> password pair) with a different set of delegation- specific
> credentials.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.