Versions Compared

Old Version 49

changes.mady.by.user Former user

Saved on

compared with

New Version 50

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:

Further reading:

...

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:

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

For external information and thoughts on UMA, see:

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 completionwork 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 a typical UMA scenario, and who are the actors in it?

...

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?

...

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.

...

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:

Why doesn't UMA use OAuth terminology?

...

Prior to that, they were relationship manager, service provider (SP), and consumer.

Further reading:

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

...

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 to give the requesting party authorization for access.

To achieve this, the UMA AM authorization server acts as an OpenID Connect Relying Party, to authenticate the requesting party and start the OpenID Protocol. A second UMA AM authorization server 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.

...

...

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 AS 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.

...

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:

...

...