User-Managed Access


User-Managed Access or UMA, (UMA, pronounced "OOH-mah" like the given name), is an OAuth 2.0- RFC 6749-based protocol.

User-Managed Access adds three main concepts and corresponding structures and flows.

First, User-Managed Access defines a standardized API at the Authorization Server, called the Protection API, that the Resource Server speaks to; this enables multiple Resource Server’s to communicate with one Authorization Server and vice versa, and because the Protection API is itself secured with OAuth 2.0, allows for formal trust establishment between each pair. This also allows an Authorization Server to present an Resource Owner with a centralized user interface.

Second, User-Managed Access defines a formal notion of a Requesting Party (RqP) that is autonomous from an Resource Owner, enabling party-to-party sharing and delegation of access authorization. An Resource Owner need not consent to token issuance at run time but can set policy at an Authorization Server, allowing an Requesting Party to attempt access with an asynchronous Operation.

Third, User-Managed Access enables access attempts to result in successful issuance of tokens associated with authorization data based on a process of Trust Elevation in the RqP, for example, gathering identity claims or other claims from them.

User-Managed Access compiles with the Law of User Control and Consent#

User-Managed Access purpose of the protocol specifications is to "enable a Resource Owner to control the authorization of data sharing and other protected Resource access made between online services on the owner’s behalf or with the owner’s authorization by an autonomous Requesting Party". This purpose has privacy and consent implications for web applications and the Internet of Things (IoT), as explored by the collection of case studies contributed by participants in the standards group

User-Managed Access defines how resource Owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of Resource Servers, and where a centralized Authorization Server governs access based on Resource Owner policies. Resource Owners configure authorization Servers with access policies that serve as asynchronous authorization Grants.

User-Managed Access serves numerous use cases where a Resource Owner uses a dedicated service to manage authorization for access to their resources, potentially even without the run-time presence of the Resource Owner. A variety of use cases can be found in UMA-usecases and UMA-casestudies.

Practical control of access among loosely coupled parties requires more than just messaging protocols. This specification defines only the "technical contract" between UMA-conforming entities. Work is ongoing to define recommendations for developing agreements about the rights and responsibilities of parties operating and using these entities on a contractual or legal level (see, for example, UMA-obligations). Parties operating entities that claim to be UMA-conforming should provide documentation of any rights and obligations between and among them.

In enterprise settings, application Access Control sometimes involves letting back-office applications serve only as Policy Enforcement Points (PEPs), depending entirely on access decisions coming from a central Policy Decision Point (PDP) to govern the access they give to requesters. This separation eases auditing and allows policy administration to scale in several dimensions. User-Managed Access makes use of a separation similar to this, letting the Resource Owner serve as a policy administrator crafting authorization strategies for resources under their control.

In order to increase interoperable communication among the Authorization Server, Resource Server, and OAuth Client, User-Managed Access leverages two purpose-built APIs related to the outsourcing of authorization, themselves protected by OAuth 2.0 (or an OAuth-based authentication protocol) in embedded fashion.

User-Managed Access 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?”).

User-Managed Access has enterprise implications as well as "user-centric" implications. Companies are 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, User-Managed Access has contractual and legal implications.

User-Managed Access began as ProtectServe, an experimental Web data sharing approach project by Eve Maler while at Sun Microsystems.[2]

Further Explanations #

User-Managed Access defines how Resource Owners can control protected-resource access by OAuth Clients operated by arbitrary Requesting parties, where the resources reside on any number of Resource Servers, and where a centralized Authorization Server governs access based on Resource Owner Policies.

Resource Owners configure Authorization Servers with access Policies that serve as asynchronous authorization grants.

A corresponding specification defines obligations of legally responsible parties that engage in UMA-conforming interactions. The effort to incubate the development of UMA as a web standard is taking place in the Kantara Initiative organization.

The purpose of the UMA Work Group (Kantara Initiative Charter) is to develop specs that let an individual control the authorization of data sharing and service access made between online services on the individual's behalf, and to facilitate interoperable implementations of the specs.[1]

The most recent specifications for User-Managed Access 1.0 can be found at: https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

Undergoing interoperability testing and increased OpenID Connect integration.

A Working Group of the Kantara Initiative free for anyone to join and contribute.

Simple OAuth based,

  • identifier-agnostic
  • RESTful
  • modular
  • Generative
  • Able for rapid-deployment

Contributed to the Standards for consideration:#

UMA Use Case#

User-Managed Access Tokens#

User-Managed Access introduces some additional Tokens:

More Information#

There might be more information for this subject on one of the following: