The OAuth 2.0 Authorization Framework

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    oauth mailing list <>,
    oauth chair <>
Subject: Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)

The IESG has approved the following document:
- 'The OAuth 2.0 Authorization Framework'
  (draft-ietf-oauth-v2-31.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working

The IESG contact persons are Stephen Farrell and Sean Turner.

A URL of this Internet Draft is:

Technical Summary

   The OAuth 2.0 authorization protocol enables a third-party 
   application to obtain limited access to an HTTP service, either 
   on behalf of a resource owner by orchestrating an approval 
   interaction between the resource owner and the HTTP service, 
   or by allowing the third-party application to obtain access on 
   its own behalf. This specification replaces and obsoletes the 
   OAuth 1.0 protocol described in RFC 5849. 

Working Group Summary

   There have been a number of controversies over the course 
   of the development of OAuth 2.0. All were eventually worked 
   out to the satisfaction of the working group as a whole, and the 
   result has significant consensus in the group, but some of it 
   hasn't been easy. The native application scenario (see section 9) 
   remains a significant point in question: applications that users 
   install -- perhaps may be convinced to install by malefactors -- are 
   always a difficult security point, and that is true with OAuth as 
   well. As the text in the document says, these "may require 
   special consideration", particularly in regard to security.

   Because OAuth is trying to tie together applications and services 
   from different trust domains, and because it is relying on end 
   users to make important decisions, largely based on what they're 
   told by the user interfaces, there are an extraordinary set of 
   possible threats and security considerations involved. The working 
   group has chosen to handle this with a Security Considerations 
   section that covers general issues and focuses on protocol issues, 
   and a separate document (draft-ietf-oauth-v2-threatmodel) that 
   describes detailed threats and further security considerations in 
   more depth than would be possible in the base protocol spec. 
   There has been a great deal of discussion about where the line 
   is -- what should go into the Security Considerations (section 10) 
   in the base spec, and what will be in the companion document 
   (to which there is an informative reference at the beginning of 
   section 10).

   In the end, the current text reflects strong working group 
   consensus, though it is not without disagreement. The working 
   group believes the two documents together do the right job, they 
   continue to work on draft-ietf-oauth-v2-threatmodel, and they 
   expect to complete that document within the next months. 

Document Quality

   There has been fairly broad deployment of OAuth 1.0, from 
   such companies as Yahoo!, Facebook, Google, and Twitter, and 
   many of the existing deployments have been keeping up with 
   the OAuth 2.0 progress, and adjusting their implementations 
   accordingly. Quite a number of working-group participants have 
   given the current spec very thorough review. 


   Derek Atkins is the document shepherd.
   Stephen Farrell is the responsible AD.

RFC Editor Note