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

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Mar 2009 22:20:28 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 09, 2009 4:45 PM
To: [email-masked]
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.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1oYW1tZXItb2F1dGgtMDEudHh0DQo=

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Mar 2009 22:33:32 -0700

Forgot to mention the blog post is:

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

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, March 09, 2009 10:20 PM
> To: [email-masked]
> 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
> 
> 
> 
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> 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.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 10 Mar 2009 17:13:47 +1100

Why is "c%40" sorted after "c2"?
"c@" sorts after "c2", but §3.3.1.2. "Normalize Request Parameters" encodes names at step 1 before sorting at step 2.

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

----------

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Mar 2009 23:19:59 -0700

A bug. Thanks! I'll fix it (in a few weeks when the freeze is over).

EHL

> Of Manger, James H
> Sent: Monday, March 09, 2009 11:14 PM
> To: [email-masked]
> Subject: [oauth] draft 01: sort order c@ vs c2
> 
> "c@" sorts after "c2", but §3.3.1.2. "Normalize Request Parameters"
> encodes names at step 1 before sorting at step 2.
> 
> James Manger
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth