OAuth 2.0 Threat Model and Security Considerations
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, oauth mailing list <email@example.com>, oauth chair <firstname.lastname@example.org> Subject: Document Action: 'OAuth 2.0 Threat Model and Security Considerations' to Informational RFC (draft-ietf-oauth-v2-threatmodel-08.txt) The IESG has approved the following document: - 'OAuth 2.0 Threat Model and Security Considerations' (draft-ietf-oauth-v2-threatmodel-08.txt) as Informational RFC This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/
Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The document: o Documents any assumptions and scope considered when creating the threat model. o Describes the security features in-built into the OAuth protocol and how they are intended to thwart attacks. o Gives a comprehensive threat model for OAuth and describes the respective counter measures to thwart those threats. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document began life as a working document for the development of a Security Considerations section of the base OAuth protocol document. It quickly became far too large for that purpose, and at IETF 80 a design team was set up to extract the key points for a proper Security Considerations section, leaving the remainder for this Informational document. Throughout the development, the goal has been to include as much as possible. There's been some discussion of whether this has resulted in a document that's too long to be practical. And that concern has resulted in some pushback at the end of its life cycle, resisting the addition of new material that seemed non-specific to OAuth. There have nevertheless been some compromises made, as some participants considered it important in a few cases to highlight threats that apply to services in general, but that might be falsely construed either as not applying to OAuth, or as being mitigated in some way by OAuth. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? In the end, we have a document that's thorough and well written, and that represents the consensus of the working group, with a liberal view toward inclusion. The authors have already noted, in the acknowledgments, key contributors and reviewers. Personnel Barry Leiba is the document shepherd. Stephen Farrell is the responsible AD. RFC Editor Note - Both section 8.1 and 8.2 are called "Informative References" but 8.1 should be "Normative References" so in both the TOC and body of the document please change the title of 8.1 to "Normative References"