[Wg-uma] Fledgling spec text
eve at xmlgrrl.com
Thu Oct 22 10:19:50 EDT 2009
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.
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
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
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
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.
A web user capable of indirectly controlling access by requesters to
protected resources on hosts, by instructing an AM how to make access
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.
An access-restricted resource (per [RFC2616]) that can be obtained
from a host with the acquiescence of an AM.
An HTTP client (per [RFC2616]) capable of interacting with hosts and
AMs to request, and receive access to, protected resources.
... [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 at xmlgrrl.com
More information about the Wg-uma