!!! Overview[2]
[{$pagename}] or [UMA], (UMA, pronounced "OOH-mah" like the given name), is an [OAuth 2.0]- [RFC 6749]-based [protocol]. 

[{$pagename}] adds three main concepts and corresponding structures and flows. 

__First__, [{$pagename}] 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__, [{$pagename}] 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__, [{$pagename}] 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.

!! [{$pagename}] compiles with the [Law of User Control and Consent]
[{$pagename}] 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

[{$pagename}] defines how [resource Owners] can control protected-resource access by [clients|OAuth Client] operated by [arbitrary requesting parties|Requesting Party], where the [resources|Protected Resource] 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|Policy] that serve as asynchronous [authorization Grants].

[{$pagename}] serves numerous use cases where a [Resource Owner] uses a dedicated service to manage [authorization] for access to their [resources|Protected Resource], 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. [{$pagename}] makes use of a separation similar to this, letting the [Resource Owner] serve as a [policy administrator|Policy Administration Point] crafting [authorization] strategies for resources under their control.

In order to increase interoperable communication among the [Authorization Server], [Resource Server], and [OAuth Client], [{$pagename}] 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.

[{$pagename}] 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?|Authentication] 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?”).

[{$pagename}] has [enterprise implications|https://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Access+Management+2.0+for+the+Enterprise|target='_blank'] 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, [{$pagename}] has contractual and legal implications.

[{$pagename}] began as ProtectServe, an experimental Web data sharing approach project by [Eve Maler] while at [Sun Microsystems].[2]

!! Further Explanations 
[{$pagename}] defines how [Resource Owners] can [control|Law of User Control and Consent] protected-resource access by [OAuth Clients] operated by arbitrary [Requesting parties|Requesting Party], where the resources reside on any number of [Resource Servers], and where a centralized [Authorization Server] governs access based on [Resource Owner] [Policies|Policy]. 

[Resource Owners] configure [Authorization Servers] with access [Policies|Policy] that serve as asynchronous authorization grants.

A corresponding specification defines [obligations|UMA-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)|http://kantarainitiative.org/confluence/display/uma/Home|target='_blank'] 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 [{$pagename}] 1.0 can be found at: [https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol|https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol|target='_blank']

Undergoing interoperability testing and increased [OpenID Connect] integration.

A Working Group of the [Kantara Initiative|http://kantarainitiative.org/confluence/display/uma/Home|target='_blank'] 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:
* [draft-hardjono-oauth-umacore|http://tools.ietf.org/html/draft-hardjono-oauth-umacore-06|target='_blank']
* [Binding Obligations on User-Managed Access Participants|https://tools.ietf.org/html/draft-maler-oauth-umatrust-03|target='_blank']

!! [UMA Use Case]!! [{$pagename}] [Tokens]
[{$pagename}] introduces some additional [Tokens]:
* [Protection API Token] or [PAT] - An [Entity] seeking protection API access MUST have the [OAuth Scope] "[uma_protection]". An [Access Token] with at least this scope is called a [Protection API Token] (PAT) and an [Entity] that can acquire an [Access Token] with this [OAuth Scope] is by definition a [Resource Server]. 
* [Requesting Party Token] or [RPT] - the [Token] that a client presents to a [Resource Server] when trying to access a [Protected Resource]. 
* [Authorization API Token] or [AAT] - An [Entity] seeking authorization API access MUST have the [OAuth Scope] "[uma_authorization]". An [Access Token] with at least this scope is called an [Authorization API Token] or [AAT] and an [Entity] that can acquire an [Access Token] with this [OAuth Scope] is by definition a [client|OAuth Client].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [UMA|https://kantarainitiative.org/confluence/display/uma/Home|target='_blank'] - based on 2015-04-27
* [#1] - [Eve Maler-LinkedIn|https://www.linkedin.com/in/evemaler|target='_blank'] - based on 2015-09-05
* [#2] - [User-Managed Access (UMA) Profile of OAuth 2.0|https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html|target='_blank'] - based on 2015-09-20