Versions Compared

Old Version 49

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

These are questions we have fielded while giving UMA presentations and demos. If you want us to answer one of the empty questions you see appearing here, or have other questions, tweet us!

For UMA information in other languages, see:

For external information and thoughts on UMA, see:

Table of Contents
maxLevel3
minLevel2

General Questions

What is UMA?

User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is a protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.

UMA allows a user to make demands of the requesting side in order to test their suitability for receiving authorization. These demands can include requests for information (such as “Who are you?” or “Are you over 18?”) and promises (such as “Do you agree to these non-disclosure terms?” or “Can you confirm that your privacy and data portability policies match my requirements?”).

UMA has the following actors and basic architecture (NOTE: we have aligned our terminology more closely with OAuth's, so expect a revised diagram very soon):

Image Removed

A number of historical articles and other materials about UMA are available:

...

Table of Contents
maxLevel3
minLevel2

...

General Questions

What is UMA?

User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is an OAuth-based protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.

UMA allows a user to make demands of the requesting side in order to test their suitability for receiving authorization. These demands can include requests for information (such as “Who are you?” or “Are you over 18?”) and promises (such as “Do you agree to these non-disclosure terms?” or “Can you confirm that your privacy and data portability policies match my requirements?”).

UMA has enterprise implications as well as "user-centric" implications. At least one company has begun using it for coordinating the protection of enterprise APIs in much the way that today's Web Access Management (WAM) systems protect corporate web apps. As well, since it is a system for distributing authorization responsibilities, UMA has contractual and legal implications.

UMA has the following actors and basic architecture, with entities that closely align with core OAuth entities:

Image Added

A number of historical articles and other materials about UMA are available:

Further reading:

What is UMA's relationship with Kantara and IETF?

The specifications related to the UMA web protocol are being incubated in the Kantara Initiative, with the intent to contribute the draft work to the IETF. An initial UMA Internet-Draft was contributed in time for discussion at the IETF81 OAuth Working Group meeting in July 2011, and the UMA WG spec editor had the opportunity there to present on UMA. It is anticipated that the OAuth group will take up post-2.0 rechartering in October 2011, potentially considering UMA-related scope items for inclusion. If there is sufficient interest, the UMA WG plans to contribute an I-D by the end of 2011 that will be fully remanded to the IETF for further work and completion.

Further reading:

For UMA information in other languages, see:

  • Domenico Catalano's UMA introduction in Italian
  • Cordny Nederkoorn's article on UMA in a Dutch publication
  • Tatsuo Kudo's SlideShare deck covering UMA in Japanese
  • Wikipedia information in Italian and Spanish, thanks to Riccardo Abeti and Domenico Catalano

For external information and thoughts on UMA, see:

UMA-related short links:

Further reading:

What is a typical UMA scenario, and who are the actors in it?

Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is a "resource owner" who manages her calendar resource online. She might want to share hercalendar her calendar information with a number of different parties for a variety of purposes, while not making it fully public to the whole world.

...

With UMA, Alice can manage all these types of sharing in a unified way, from a single web-application point of control called an "authorization server". She can set policies that guide the authorization server in allowing or disallowing access by clients to protected resources at resource servers.

Further reading:

What is the UMA protocol flow?

Phase 1 of the UMA core protocol involves the resource owner introducing the resource server and authorization server so they can work together. Phases 2 and 3 together involve the requesting party, using a client, making an access attempt, being tested for suitability by the authorization server to receive permission, and ultimately succeeding or failing in the attempt by presenting a token with permissions associated with it.

Further reading:

...

...

UMA's Relationship to Other Efforts

What is UMA's relationship with Kantara and IETF?

The specifications related to the UMA web protocol are being incubated in the Kantara Initiative, with the intent to contribute the draft work to the IETF. UMA specification draft modules have variously been contributed as IETF individual Internet-Drafts. One such draft so far, covering dynamic client registration, was accepted as an OAuth WG work item, an item that has now progressed.

Further reading:

What is UMA's relationship with the NSTIC Identity Ecosystem effort?

UMA can solve a variety of different access management problems. One of the key problems it was designed to solve was "user-centric" control of access to personal data. A use case was submitted to the NSTIC Identity Ecosystem Steering Group that relates closely to UMA: Delegated Authentication for User Managed Access. The use case is proceeding through the IDESG lifecycle.

Further reading:

Can't you achieve UMA goals just by using OAuth?

In fact, UMA is built on top of OAuth. But typical profiles of OAuth solves solve a somewhat simpler problem. Here are some features UMA adds to the picture.

OAuth in its typical deployment models solves for person-to-self sharing (that is, Alice is the person using both the client app and the resource server app). UMA, in addition, solves for secure person-to-person sharing and person-to-organization sharing.

...

OAuth leaves unstated how its "authorization server" and "resource server" components interact (though a recent proposal for "token introspection" is tackling part of this problem). UMA fully defines a standard interface between its enhanced versions of these two components.

Further reading:

Is UMA up to date with OAuth development?

Yes. The UMA protocol has been defined on top of the RFC version of OAuth 2.0, and we try to keep up with OAuth drafts. It now also references the OAuth dynamic client registration specification and a proposed OAuth token introspection specification, and it has defined a modularized proposal for resource set registration that we believe is valuable for OAuth generally and for OpenID Connect usage, as well as UMA usage.

Further reading:

...

Further reading:

Why doesn't UMA use OAuth terminology?

As of late 2012, it does! Some of the old UMA collateral still uses UMA-specific terminology , but we're moving to a world of authorization servers, resource servers, and clients.The previous terms in UMA were (authorization manager (AM), host, and requester.Prior , and prior to that, they were relationship manager, service provider (SP), and consumer, relationship manager, service provider (SP), and consumer), but we have generally fully moved to a world of authorization servers, resource servers, and clients.

Further reading:

Does UMA make use of the JSON format or JSON Web Tokens (JWT)?

UMA uses the JSON format heavily in its request and response messaging specifications.For now

, UMA assumes that tokens are opaque (not internally structured) and that, therefore, the authorization server responsible for having issued the token will be responsible for dereferencing it as necessary. Therefore, for example, the UMA protocol includes a way for a resource server to make API calls to the AM to check the status of a token presented to it by a requester. However, we anticipate building in optional support for tokens that use the JSON Web Token format, which will enable "local" validation without requiring a round trip to the server at run timeThe default, mandatory-to-implement token format for UMA "requesting party tokens" (RPTs, the token that a client presents to a resource server when trying to access a protected resource) is opaque on the wire, and a resource server introspects it at the authorization server at run time. Its format is JWT, with an extension property called "permissions" that takes into account UMA's extended concept of resource set scopes.

Further reading:

...

OpenID Connect specifies ways to retrieve claims that identify someone uniquely (for example, with a well-known globally unique identifier) or non-uniquely (such as providing a birth date). UMA policies can dictate requirements for the values of such claims in order for the AM authorization server to give the requesting party authorization for access. To achieve this, the UMA AM acts authorization server can act as an OpenID Connect Relying Party, to authenticate the requesting party and start the OpenID Protocol. A second UMA AM interface, the Claims Client, is then responsible for requesting an access token for the requesting party’s UserInfo EndPoint. This allows the claims request to be processed through the requesting party's authorization server, which can then be sent as a response back to the AM for interpretation and access decision-making.

Further reading:

Google Tech Talk video demonstrating the use of OpenID Connect claims for authorization in UMA flows

How is UMA related to XACML?

UMA is not formally related to XACML, but we can imagine some patterns of usage that bridge XACML and UMA. For example, UMA does not standardize a policy expression format or its evaluation, and treats an authorization manager as a conflated policy decision point (or at least authoritative authorization data source), policy administration point, and policy information point for the purposes of UMA's in-band flows. An AM could provide authorization data for which a host could then seek interpretation at a true XACML PDP. An UMA representative made a presentation to the XACML TC on 19 October 2012 to discuss liaison and technical opportunities. A specialized UMA token profile could also be used to provide a pattern for XACML's ongoing efforts to simplify/RESTify the current XACML standard.

Further reading:

Data Sharing, User Control, and Privacy Implications

...

.

Further reading:

How is UMA related to XACML?

UMA is not formally related to XACML, but we can imagine some patterns of usage that bridge XACML and UMA. For example, UMA does not standardize a policy expression format or its evaluation, and treats an authorization server as a conflated policy decision point (or at least authoritative authorization data source), policy administration point, and policy information point for the purposes of UMA's in-band flows. An authorization server could also provide "raw" authorization data for which a resource server could then seek interpretation at a true XACML PDP. An UMA representative made a presentation to the XACML TC on 19 October 2012 to discuss liaison and technical opportunities. A specialized UMA token profile could also be used to provide a pattern for XACML's ongoing efforts to simplify/RESTify the current XACML standard.

Further reading:

...

Data Sharing, User Control, and Privacy Implications

What is the relationship of UMA to the Privacy by Design principles?

It is useful to examine how User-Managed Access (UMA) relates to the seven foundational principles of Privacy by Design (PbD). The group has prepared an analysis of each principle, and a companion analysis of how UMA and UMA-enabled solutions can support the principle.

Further reading:

How can UMA make requesting parties adhere to the user's wishes for privacy and data usage control?

The demands the user resource owner may want to make on the requesting side can't be solved only with cryptography and web protocols; you quickly get into the realm of agreements and liability.

UMA stays away from techniques like DRM (digital rights management), where you cryptographically "lock" your data before sending it on (though this could be layered on the data that flows over UMA). For end-user convenience, development simplicity, and web-wide adoption, instead UMA puts the emphasis on user visibility into and control over access by others.

UMA is shooting for a reasonable minimum level of enforceability of authorization agreements, so that if the requesting side goes against your express wishes – wishes they promised to adhere to – then you have a meaningful chance of taking them to court over it.

Further reading:

...

...

Because individuals are often at a power disadvantage compared to big companies and big websites, truly empowering people to control sharing is a tall order. The UMA Work Group has considered the problems it can tackle, and the ways in which a number of complementary efforts – such as trust and privacy frameworks – can be used in combination with it.

Further reading:

...

Isn't an Authorization Manager a privacy-destroying panopticon?

...

UMA seems positioned to be a positive force in managing privacy, but how will it overcome the challenges with Big Data?

Where personal data has been flowing unfettered in the back channel, entirely unmanaged by the people to whom the data applies, we anticipate that UMA will initially have little effect. It would take some other large force, such as data protection regulation or social/economic pressure around privacy, for that flow to slow or cease and to be pumped through an alternative flow that adds the individual into the mix somehow, such as UMA. UMA is likely to have the biggest near-term effect when it comes to new "data products" that people were formerly unwilling to share because they couldn’t throttle the sharing effectively, or that were formerly unavailable in a machine-readable way but now are accessible through documented web APIs.

...

UMA requires a trust "dance" among several parties, who are aligned in some of their interests but who have divergent incentives in many other cases. The UMA Binding Obligations framework explains to what extent trust can be built between pairs of parties at a contractual level.

Further reading:

...

At its current state of development, UMA comes with a draft technical specification and a draft contractual framework, called Binding Obligations, that lays out a set of minimum obligations to help make UMA participants confident about engaging in acts of distributed authorization. This is not a full trust framework in the U.S. FICAM sense, for example, but is meant to complement contracts and umbrella agreements wherever they might be used. The Binding Obligations document currently assumes that those who operate UMA-enabled software services will self-identify as conforming to the technical spec, and by that act, would take on obligations during the normal course of sending and receiving UMA-conforming messages. This is an area the UMA Work Group is actively working on.

Further reading:

...

What implementations of UMA are there?

We are aware of four several major implementations so far.

Further reading:

Have there been any usability studies on UMA?

The original SMART project performed formal usability studies at Newcastle University, which led to improvements from SMARTAM 1.0 to SMARTAM 2.0. We anticipate that further usability testing will be done by various parties as the number of interoperable implementations grows.

Further reading:

...

For individual people interacting with the web, this model means that they can conveniently reuse any sharing circles (such as "friends and family" lists) they might have among all the Web applications and information they control. They can also set up criteria for access at a single place (the UMA authorization manager) and then go about their lives, not necessarily having to be online and paying attention when someone wants access to their stuff.

Further reading:

What sort of entity might serve as an UMA authorization server?

An UMA authorization server has a natural affinity with those who operate identity providers (IdPs). It's well known that any one IdP can't provide on-board storage of all information relevant to an individual, and this fact is now being recognized in the new OpenID Connect model of IdPs that mediate access to claims from other authorities. The Open Identity Exchange's Street Identity project shows the value of using an IdP as a "relationship manager" to gather user consent for sharing a claim (in this case, a verified street address) whose authoritative version resides elsewhere. UMA leverages OpenID Connect to enable IdPs to offer this kind of service to users, adding features unique to UMA along the way (such as sharing data with other people and organizations, not just "yourself" using a different app).

Further reading: