[Wg-uma] Fledgling spec text

[Eve Maler]

Paul's message yesterday contained some fledgling spec text for the  
first step in the protocol.  Seeing it, and happening to be reading  
the current OAuth I-Ds at the time, I got inspired to try and write a  
fledgling Introduction section for our spec.  If you can, please take  
a look at both Paul's text (now linked from the online agenda for  
today's call) and the following before our call today.

	Eve



1. Introduction

The User-Managed Access (UMA) protocol provides a method for users to  
control third-party application access to their protected resources,  
residing on any number of host sites, through a centralized  
authorization manager that makes access decisions based on user  
instructions.

For example, a web user (authorizing user) can arrange to authorize an  
online service (requester) to gain one-time or ongoing access to a set  
of personal data including his private home address stored at a  
personal data service (host), by instructing the host to check with  
his authorization decision-making service (authorization manager)  
first.  The requester might be an e-commerce site acting on behalf of  
the user himself to assist him in arranging for shipping a purchased  
item, or it might be an address book service acting on behalf of the  
user's friend, or it might be a survey service run by a company that  
compiles population demographics.

In enterprise settings, application access management often involves  
letting back-office applications serve only as policy enforcement  
points (PEPs), requesting access decisions from a central policy  
decision point (PDP) when approached by requesters.  This  
externalization eases auditing and access policy administration.  UMA  
introduces a fourth role to the traditional access management model:  
the authorizing user.

UMA uses, profiles, and extends OAuth in several ways:

o UMA hosts and authorization managers have a literal OAuth client/ 
server relationship for hosts' requests for access authorization.

o UMA requesters and hosts have a metaphorical OAuth client/server  
relationship, differing in that UMA requesters might or might not be  
acting on behalf of the authorizing user himself, and in that UMA  
hosts externalize authorization decisions rather than making such  
decisions locally.

UMA also gives authorizing users the ability to demand, through the  
authorization manager, that requesters meet terms for access to hosted  
data and services (such as requiring the requester to make a payment,  
or to agree not to sell the data thus acquired).

The UMA protocol has the following stages:

1. Host registration with the AM
2. Requester registration with the AM
3. Access token issuance
4. Terms negotiation
5. Resource access

1.1 Terminology

authorization manager (AM)
	An HTTP server (per [RFC2616]) capable of interacting with hosts in  
order to convey resource access decisions and with requesters in order  
to register them.

authorizing user
	A web user capable of indirectly controlling access by requesters to  
protected resources on hosts, by instructing an AM how to make access  
decisions.

host
	An online service capable of interacting with AMs in the role of an  
HTTP client (per [RFC2616]) in order to receive and act on access  
decisions, and of interacting with requesters in the role of an HTTP  
server (per [RFC2616]) in order to respond to access requests.

protected resource
	An access-restricted resource (per [RFC2616]) that can be obtained  
from a host with the acquiescence of an AM.

requester
	An HTTP client (per [RFC2616]) capable of interacting with hosts and  
AMs to request, and receive access to, protected resources.

token
	... [we may have several terms that are token-related -- various  
tokens, handles, keys, and whatnot -- and I wasn't sure of the full  
list at this point in time]


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog