[OAUTH-WG] First draft of OAuth 2.0

David Recordon <davidrecordon@facebook.com> Sat, 20 March 2010 01:31 UTC

Return-Path: <davidrecordon@facebook.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 9D0D43A69A0 for <oauth@core3.amsl.com>; Fri, 19 Mar 2010 18:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-3.116, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368]
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 9nfqOxHSJ7AU for <oauth@core3.amsl.com>; Fri, 19 Mar 2010 18:30:07 -0700 (PDT)
Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id B5C693A6872 for <oauth@ietf.org>; Fri, 19 Mar 2010 18:30:07 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.83]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o2K1U2tl023372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <oauth@ietf.org>; Fri, 19 Mar 2010 18:30:03 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Fri, 19 Mar 2010 18:28:46 -0700
From: David Recordon <davidrecordon@facebook.com>
To: OAuth WG <oauth@ietf.org>
Date: Fri, 19 Mar 2010 18:28:45 -0700
Thread-Topic: First draft of OAuth 2.0
Thread-Index: AcrHzK+rSVNNclfBQN6aW1dAZfzZmA==
Message-ID: <526C3C44-18CF-4A94-A4C6-72702F73AC83@facebook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_003_526C3C4418CF4A94A4C672702F73AC83facebookcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-19_08:2010-02-06, 2010-03-19, 2010-03-19 signatures=0
Subject: [OAUTH-WG] First draft of OAuth 2.0
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: Sat, 20 Mar 2010 01:31:07 -0000

As I mentioned a few weeks ago [1], I started working on editing the first draft of OAuth 2.0 over the past two weeks.  While I realize that it's 6pm Friday (sorry about that), I hope to have a solid discussion about it at Monday's meeting.  You can find the current draft of it – plus all of the document history – on my public GitHub account a thttp://github.com/daveman692/OAuth-2.0.  Eran will be doing an initial editing pass before Monday and then spend more time with it next week.

I've attached both a HTML and TXT copy to this email and plan to officially submit it as an Internet Draft.

The following are highlighted changes from draft-hardt-oauth-01:
   1.  A Web Client flow designed for use within JavaScript.  It also
       supports the use cases of the rich app profile so that they're
       not two separate flows.
   2.  A new device flows which is based on the Netflix/Tivo flow (TV
       shows you a code that you type in on your computer).
       http://www.ietf.org/mail-archive/web/oauth/current/msg01346.html
   3.  Remove captchas from the username/password flow.  They haven't
       been successfully implemented within this context and create
       complexity especially when we use other signals to detect
       compromised accounts.
       http://www.ietf.org/mail-archive/web/oauth/current/msg01293.html
   4.  Don't allow bearer tokens without either SSL and/or signatures.
       While some providers may offer this ability, they should be out
       of spec for doing so though technically it won't break the flows.
   5.  Abstract the refresh token flow out of each profile into its own
       section.  Support the ability to request access token secrets
       when refreshing.
   6.  Support signatures for making API requests but not for getting
       access tokens.  If you want to use signatures, you'll get an
       access token and then make a refresh call where you ask for a
       token secret.  This causes the auth server to mark the token as
       no longer being valid as a bearer token via SSL.  This
       performance tradeoff seems realistic given many use cases focus
       on high-volume API transactions and thus the one additional
       request at the onset should be noise.  The signature mechanism is
       currently from OAuth 1.0.

Obviously I couldn't have made so much progress so quickly if it weren't for WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those we all have been discussing here.  I hope that I haven't missed anyone who contributed to prior work and am happy to add other authors if I have (and they wish to be added)!

Thanks,
--David

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html