Wikipedia Article Refresh

Owned by Alec Laws
Last updated: Feb 02, 2023
6 min read

https://en.wikipedia.org/wiki/User-Managed_Access

  1. Fix links, and first 2 sections

  2. Revist other sections

 

  1. <ref>{{Cite web|url=http://kantarainitiative.org/confluence/display/uma/Charter|title = Charter - WG - User Managed Access - Kantara Initiative}}</ref>

  2. <ref>{{Cite web|url=https://kantarainitiative.org/confluence/display/LC/User+Managed+Access|title = User Managed Access - Leadership Council - Kantara Initiative}}</ref>

  3. <ref name="ki case">{{Cite web|url=http://kantarainitiative.org/confluence/display/uma/Case+Studies|title = Case Studies - WG - User Managed Access - Kantara Initiative}}</ref>

  4. <ref>http://kantarainitiative.org/confluence/display/uma/Home UMA Work Group Wiki</ref>

  5. <ref>http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode UMA workgroup meeting minutes</ref>

  6. <ref>{{Cite web|url=http://kantarainitiative.org/confluence/display/uma/Home|title = Home - WG - User Managed Access - Kantara Initiative}}</ref>

     

 

{{Cleanup bare URLs|date=August 2022}}
'''User-Managed Access''' (UMA) is an [[OAuth#OAuth 2.0|OAuth]]-based access management protocol standard that “enables a resource owner to control the authorization of [[Data shaping|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”[1]

Version 2.0 of the standard was approved by the [[Kantara Initiative]] on March 23, 2015.[2]

 

 

UMA has privacy and consent implications for web and mobile applications

  • fine-grained control

  • async policy management

  • privacy and consent needs

    including use-cases in Health and Financial sectors, as explored by the collection of case studies contributed by participants in the standards group.[3]

 

 

== History and background ==

The [[Kantara Initiative|Kantara Initiative's]] UMA Work Group[4] held its first meeting[5] on August 6, 2009. UMA's design principles and technical design have been informed by previous work by Sun Microsystems employees, begun in March 2008, on a protocol called ProtectServe. In turn, ProtectServe was influenced by the goals of the [[Vendor Relationship Management]] movement and an offshoot effort called feeds-based VRM.

ProtectServe and UMA's earliest versions leveraged the [[OAuth]] 1.0 protocol. As OAuth underwent significant change through the publication of the Web Resource Authorization Protocol (WRAP) specification and, subsequently, drafts of OAuth 2.0, the UMA specification has kept pace, and it now uses the OAuth 2.0 family of specifications for several key protocol flows.

Version 1.0 of the standard was approved by the [[Kantara Initiative]] on March 23, 2015.[X] and was updated to Version 2.0 on DATE

UMA is open to any means of user identification as required by the use case, and does not depend on OpenID Connect. However, it optionally uses the OpenID Connect protocol as a means of collecting identity claims from a requesting party in order to attempt to satisfy the authorizing user's access policy.

  • should this also reference VCs as a means to collect claims?
    UMA does not use or depend on OpenID Connect as a means of user identification. However, it optionally uses the OpenID Connect protocol as a means of collecting identity claims from a requesting party in order to attempt to satisfy the authorizing user's access policy.


UMA does not dictate policy format, as policy evaluation is performed internally to the authorization server (AS) from the UMA perspective.
UMA also does not use or depend on the eXtensible Access Control Markup Language ([[XACML]]) as a means of encoding user policy or requesting policy decisions. However, XACML could be used to implement the policies inside the AS. Its implementation is out-of-scope of UMA. The UMA protocol flows for requesting access permission have some features in common with the XACML protocol.

  • maybe not need to call out XACML, there are lots of ways to model fine-grained policies at the AS and it’s up the the implementation

== Standardization status ==

The UMA group conducts its work in the Kantara Initiative[6] and has also contributed a series of Internet-Draft specifications to the [[Internet Engineering Task Force]] (IETF) as an eventual home for UMA standardization work. To this end, the WG has contributed several individual Internet-Drafts to the IETF for consideration. One of these, a specification for OAuth dynamic client registration,<ref>http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Internet Draft: OAuth 2.0 Dynamic Client Registration Core Protocol</ref> served as input for the more generalized mechanism ultimately developed for OAuth.<ref>{{Cite journal|url=https://tools.ietf.org/html/rfc7591|title = OAuth 2.0 Dynamic Client Registration Protocol|date = July 2015|last1 = Richer|first1 = Justin|last2 = Jones|first2 = Michael|last3 = Bradley|first3 = John|last4 = Machulak|first4 = Maciej|last5 = Hunt|first5 = Phil| editor-first1=J | editor-last1=Richer | doi=10.17487/RFC7591 |doi-access = free}}</ref>
UMA was presented to the OAuth Working Group<ref>{{Cite web|url=https://datatracker.ietf.org/wg/oauth/about/|title = Home - WG - Web Authorization Protocol (Oauth) - IETF}}</ref> at the IETF 104 conference in March 2019,<ref>{{Cite web|url=https://datatracker.ietf.org/meeting/104/materials/minutes-104-oauth-00|title = IETF104 - oauth WG - meeting minutes }}</ref> but that did not result in any UMA specifications being adopted by the IETF.

== Implementation and adoption status ==

  • this section needs verification of the references, UMA 2 only?

  • subsection for UK Pensions Dashboard? other production use-cases?

The UMA core protocol has several implementations,<ref>{{Cite web|url=http://kantarainitiative.org/confluence/display/uma/UMA+Implementations|title = UMA Implementations - WG - User Managed Access - Kantara Initiative}}</ref> including several open source implementations. Sources of active and available open-source implementations include [[ForgeRock]],<ref>{{Cite web|url=http://forgerock.org/openuma/|title = Digital Identity for Consumers and Workforce | ForgeRock}}</ref> Gluu,<ref>http://www.gluu.org/open-source/open-source-vs-on-demand/ {{Webarchive|url=https://web.archive.org/web/20140209133913/http://www.gluu.org/open-source/open-source-vs-on-demand/ |date=2014-02-09 }} Gluu OSS implementation of UMA</ref> IDENTOS Inc.,<ref>https://identos.com/ IDENTOS Inc. Federated Privacy Exchange (FPX)</ref> MITREid Connect,<ref> link|date=July 2018 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> [[Atricore]], Node-UMA,<ref> [[Atricore]] OSS implementation of UMA for Node.js</ref> Roland Hedberg,<ref>{{Cite web|url= = Rohe/Pyuma|website = [[GitHub]]|date = 22 January 2018}}</ref> [[Keycloak]],<ref>{{Cite web |url=http://www.keycloak.org/docs/4.0/release_notes/index.html |title=Keycloak 4.0.0.Final |access-date=2019-03-05 |archive-date=2019-03-06 |archive-url=https://web.archive.org/web/20190306234830/https://www.keycloak.org/docs/4.0/release_notes/index.html |url-status=dead }}</ref> and [[WSO2 Identity Server]].<ref name=" ">{{Cite web|url=https://docs.wso2.com/display/IS580/User+Managed+Access|title = User Managed Access - Identity Server 5.8.0 latest - WSO2 Documentation}}</ref> A Kantara Initiative group is working on developing "free and open-source software (FOSS), in several popular programming languages, that empowers developers to incorporate UMA protection and authorization API enablement into applications, services, and devices".<ref>{{Cite web |url=http://kantarainitiative.org/confluence/display/umadev/Home |title=Home - WG - User-Managed Access Developer Resources - Kantara Initiative |access-date=2015-08-13 |archive-date=2016-02-16 |archive-url=https://web.archive.org/web/20160216134803/http://kantarainitiative.org/confluence/display/umadev/Home |url-status=dead }}</ref>

UMA-enabled products are available from Gluu,<ref>{{Cite web |url=http://www.gluu.org/gluu-server/access-management/ |title=Web Access Management | the Gluu Server for SSO, WAM, & 2FA | Gluu |access-date=2015-08-13 |archive-date=2015-08-05 |archive-url=https://web.archive.org/web/20150805132945/http://www.gluu.org/gluu-server/access-management/ |url-status=dead }}</ref> Jericho Systems,<ref><https://www.jerichosystems.com/company/pr04082015.html</ref>> ForgeRock,<ref>{{Cite web|url=https://www.forgerock.com/platform/user-managed-access/|title = User-Managed Access (UMA) - ForgeRock}}</ref> IDENTOS Inc.<ref>{{Cite web|url=https://identos.com/products-federated-privacy-exchange-fpe/|title=Federated Privacy Exchange - by IDENTOS}}</ref> and WSO2 Identity Server <ref name=" "/>

== Comparison to OAuth 2.0 ==

[[File:User Managed Access entities and relationships.png|thumb|This diagram provides a high level overview of the entities and relationships involved in the UMA specification.]]

  • this diagram needs an update to UMA 2. Could use the version from UMA Fedz. Add some numbers for protocol flow?

 

The diagram (see right) highlights key additions that UMA makes to OAuth 2.0.

In a typical OAuth flow, a human resource owner (RO) operating a client application is redirected to an authorization server (AS) to log in and consent to the issuance of an access token so that the client application can gain access to the resource server (RS) on the RO’s behalf in future, likely in a scoped (limited) fashion. The RS and AS are in all likelihood operating within the same security domain, and any communication between them is not standardized by the main OAuth specification.

UMA adds three main concepts and corresponding structures and flows. First, it defines a standardized API at the AS, called the protection API, that the RS speaks to; this enables multiple RS’s to communicate with one AS and vice versa, and because the API is itself secured with OAuth, allows for formal trust establishment between each pair. This also allows an AS to present an RO with a centralized user interface. Second, UMA defines a formal notion of a requesting party (RqP) that is autonomous from an RO, enabling party-to-party sharing and delegation of access authorization. An RO need not consent to token issuance at run time but can set policy at an AS, allowing an RqP to attempt access asynchronously. Third, UMA 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.

== Applicable use cases ==

  •  

     

UMA's architecture can serve a variety of consumer-facing and enterprise-facing use cases. The UMA group collects case studies on its wiki.<ref name="ki case"/>

One example set of use cases is in healthcare IT and consumer health. In the OpenID Foundation organization, a working group called Health Relationship Trust (HEART)<ref>{{Cite web|url=http://openid.net/wg/heart/|title=HEART WG | OpenID|date=27 October 2014}}</ref> is working to "harmonize and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs", building upon, among other standards, UMA.

Another example set of use cases, which originally influenced UMA's development, is in the area of "personal data stores" in the fashion of [[vendor relationship management]]. In this conception, an individual can choose an operator of an authorization service that accepts connections from a variety of consumer-facing digital resource hosts in order to offer a dashboard with resource sharing management capabilities.

== References ==
<references />

== External links ==

[[Category:Cloud standards]]
[[Category:Computer access control]]
[[Category:Identity management]]
[[Category:Federated identity]]
[[Category:Identity management systems]]

 

 

Other

  • could OAuth or OpenID pages have a reference to UMA?