Overview[2]#

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 compiles with the Law of User Control and Consent.

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:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-35) was last changed on 30-Jul-2017 13:33 by jim