... h1. Overview
Protecting access to user data through a DataPortability environment is a central concern. In cases where discovery is available, the user needs to be able to have strong controls over what new applications see. In any environment, the user needs the powers to revoke data access at any time, and remove the ability for one application to see data from others.
This recommendation proposes the use of OAuth, being developed at [http://www.oauth.net]. It provides a simple HTTP based mechanism for controlling access to web-based resources, and is under active development both in terms of code libraries and extensions to handle more complex or different scenarios.
Many other technologies are available, such as AuthSub, BBAuth, FlickrAuth. Many of these have been considered already by the OAuth group, and their standard aims to encompass the best of those standards into a format that can be adopted easily by all.
h1. Technology Purpose
As more services begin to interoperate, an increasing use-pattern is to ask for the user credentials of other services so as to query user data stores, such as address books. Not only does this require the user to trust the new application completely (as they are being granted full powers over the user's account), it also results in a situation where the only way a user can revoke access to the given application is to change the password to their account. Accessing applications are not individually accountable - they all appear to access the data as the user.
OAuth solves many of these problems by issuing applications with tokens that the application can use to access the data. These tokens make the applications individually accountable for their actions, and the user is able to revoke further access at any point.
OAuth was developed by an assembled community of both interested individuals, and those representing larger companies wishing to agree on a standardised authorisation mechanism.
h1. Selection Rationale
_Why this technology was selected over others in the same field, including:_
# _Brief details of other technologies._
# _Why this technology is better._
h1. Details of Adoption
_Forming a vital component of the final approval process, this section should detail implementations that have adopted the technology, and therefore are showing that the technology has real-world applications and acceptance._
h1. Action Group Backing
_Members of the action groups that back this technology should be listed here, as a formal tracking of support for the recommendation._ |