[secdir] OAuth

["Hannes Tschofenig" <[e-mail]>]

Hi all, 

I would like to point you to the Open Web authentication BOF on Monday,
1300-1500, in Continental 4. 

Your security related review comments are highly appreciated. Here is the
link to the latest version of the OAuth draft:
http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt

Ciao
Hannes

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext Eran Hammer-Lahav
>Sent: 10 March, 2009 07:34
>To: [e-mail]
>Subject: Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt
>
>Forgot to mention the blog post is:
>
>http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html
>
>EHL
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
>On Behalf 
>> Of Eran Hammer-Lahav
>> Sent: Monday, March 09, 2009 10:20 PM
>> To: [e-mail]
>> 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: [e-mail] [mailto:i-d-announce- 
>> [e-mail]] On Behalf Of [e-mail]
>> Sent: Monday, March 09, 2009 4:45 PM
>> To: [e-mail]
>> 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.
>_______________________________________________
>oauth mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/oauth
>