...
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:
- 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:
- Wikipedia entry for "User-Managed Access" (English)
- WholeChainCom blog entry on selective sharing
- UnboundID blog entry on attribute management and white paper (registration required) on the "identity economy"
- Phil Windley white paper in the Live Web series: From Personal Computers to Personal Clouds
- Oliver Pfaff's "New Trends in Web Security" SlideShare
Table of Contents | ||||
---|---|---|---|---|
|
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):
A number of historical articles and other materials about UMA are available:
- A poster (best printed on A0-A3 paper; 8.5x11 or 8.5x14 is okay but small) was presented at the IEEE Security and Privacy symposium poster session.
- A comprehensive technical report published under the auspices of Newcastle University called User-Managed Access to Web Resources (also available on ncl.ac.uk site) explains the requirements that drive UMA, analyzes the design features that respond to these requirements, and reviews related work.
- A ReadWriteWeb article, Identity Management and Networks: The Enterprise Considers the Social Way from 23 Sep 2010, discusses UMA's potential impact.
- Group chair Eve Maler has written about UMA and its predecessor, ProtectServe, here.
- Some historical materials (may be out of date) explain the original thinking behind UMA and its predecessor, ProtectServe.
Further reading:
...
Table of Contents | ||||
---|---|---|---|---|
|
...
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:
A number of historical articles and other materials about UMA are available:
- A poster (best printed on A0-A3 paper; 8.5x11 or 8.5x14 is okay but small) was presented at the IEEE Security and Privacy symposium poster session.
- A comprehensive technical report published under the auspices of Newcastle University called User-Managed Access to Web Resources (also available on ncl.ac.uk site) explains the requirements that drive UMA, analyzes the design features that respond to these requirements, and reviews related work.
- A ReadWriteWeb article, Identity Management and Networks: The Enterprise Considers the Social Way from 23 Sep 2010, discusses UMA's potential impact.
- Group chair Eve Maler has written about UMA and its predecessor, ProtectServe, here.
- Some historical materials (may be out of date) explain the original thinking behind UMA and its predecessor, ProtectServe.
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:
- Wikipedia entry for "User-Managed Access" (English)
- WholeChainCom blog entry on selective sharing
- UnboundID blog entry on attribute management and white paper (registration required) on the "identity economy"
- Phil Windley white paper in the Live Web series: From Personal Computers to Personal Clouds
- Oliver Pfaff's "New Trends in Web Security" SlideShare
Further reading:
- UMA Case Studies
- Latest specification of the UMA profile of OAuth
- UMA's binding obligations specification for dealing with contractual obligations
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:
- Kantara Initiative UMA WG charter
- IETF I-D draft-hardjono-oauth-umacore-00Minutes of IETF81 OAuth meetingon UMA profile of OAuth (may not be perfectly up to date compared to internal drafts)
- IETF I-D on Resource Set Registration
- OAuth WG status page
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:
- UMA webinar from December 2011 (slides, recording)
- UMA Scenarios and Use Cases
- UMA 1.0 Core ProtocolCase Studies
- Latest specification of the UMA profile of OAuth
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.
...
- Blog entry with Venn diagram comparing OAuth, OpenID Connect, and UMA
- UMA webinar from December 2011 (slides, recording)
- UMA 1.0 Core ProtocolConnect, and UMA
- Latest specification of the UMA profile of OAuth
- UMA-OAuth comparison slides from May 2010
- UMA scoped access slides from May 2011
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:
- UMA 1.0 Core Protocol, particularly Latest specification of the UMA profile of OAuth (see the terminology section)Latest OAuth 2.0 draft
- OAuth's RFCs: 6749 and 6750
- UMA's binding obligations specification (see the terminology discussions)
- UMA historical materials
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.
...
- Blog entry with Venn diagram comparing OAuth, OpenID Connect, and UMA
- UMA webinar from December 2011 (slides, recording)
- UMA Requirements
- UMA Binding Obligations framework's binding obligations specification (see the terminology discussions)
- OpenID Connect specifications
...
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:
...
- UMA Requirements
- UMA Binding Obligations framework
- W3C workshop position paper on Controlling Data Usage with UMA
...