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 Management 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.
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.
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.
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,
- Able for rapid-deployment
Contributed to the Standards for consideration:#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.
More Information#There might be more information for this subject on one of the following:
- 10 Reasons Why OpenID Connect
- Access Control Models
- Auth 2.0 Resource Set Registration
- Authorization API
- Authorization Server
- Best Practices Password
- Best Practices for LDAP Security
- Consent Mechanism
- Consent Standards
- Federated Identity Management
- Health Relationship Trust
- Identity Provider (IDP)
- Life Management Platform
- Need to know
- Neo-Security Stack
- OAuth 2.0 Dynamic Client Registration Protocol
- OAuth 2.0 Profiles
- OAuth Scopes
- OAuth Token Profile
- OpenID Connect
- OpenID Connect Scopes
- Privacy Enhancing Technologies
- Protection API
- Protection API Token
- Remember Me
- Requesting Party
- Requesting Party Token
- Requesting Party Token Endpoint
- Resource Set
- Target Resource
- User-Managed Access Profile
- WEB Access Management
- Web Authentication
- Web Blog_blogentry_030117_1
- Web Blog_blogentry_260715_1
- Why OAuth 2.0