UMA Frequently Asked Questions
These are questions we have fielded while giving UMA presentations and demos. More answers to come shortly. If you want us to answer one of the empty questions you see appearing here, or have other questions, tweet us!
General Questions
What is UMA?
Click to collapse/expand...User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is a protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.
UMA 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?”).
Further reading:
What is UMA's relationship with Kantara and IETF?
Click to collapse/expand...
The specifications related to the UMA web protocol are being incubated in the Kantara Initiative, with the intent to contribute the draft work to the IETF. An initial UMA Internet-Draft was contributed in time for discussion at the IETF81 OAuth Working Group meeting in July 2011, and the UMA WG spec editor had the opportunity there to present on UMA. It is anticipated that the OAuth group will take up post-2.0 rechartering in October 2011, potentially considering UMA-related scope items for inclusion. If there is sufficient interest, the UMA WG plans to contribute an I-D by the end of 2011 that will be fully remanded to the IETF for further work and completion.
Further reading:
What is a typical UMA scenario, and who are the actors in it?
Click to collapse/expand...
Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is what UMA calls an "authorizing user". She might want to share her online calendar information with a number of different parties for a variety of purposes, while not making it fully public to the whole world.
The calendar is known as a "protected resource", and Alice manages it at a web application we call a "host". She could have many hosts for many different kinds of content she creates, along with other data about herself. In some cases, such as with credit scores, she can't actually control the values of data about herself.
The parties Alice wants to share her calendar with are called "requesting parties". They use "requester" applications to attempt access.
In some cases, Alice herself is a requesting party in addition to being the authorizing user, such as when she wants to share calendar data out to different calendar applications that she likes to use. We call this "person-to-self" sharing.
In other cases, she wants to allow her friend Bob and her various family members to get calendar access. We call this "person-to-person" sharing.
Finally, she may want to allow non-individuals, such as e-commerce companies and government agencies, to get access. We call this "person-to-organization" sharing.
With UMA, Alice can manage all these types of sharing in a unified way, from a single web-application point of control we call an "authorization manager" or AM. She can set policies that guide the AM in allowing or disallowing access by requesters to protected resources at hosts.
Further reading:
UMA's Relationship to Other Efforts
Can't you achieve UMA goals just by using OAuth?
Click to collapse/expand....
In fact, UMA is built on top of OAuth. But OAuth solves a somewhat simpler problem. Here are some features UMA adds to the picture.
OAuth solves for person-to-self sharing. UMA, in addition, solves for secure person-to-person sharing and person-to-organization sharing.
OAuth allows for pairwise app-to-app connections. UMA, in addition, defines a hub from which many pairwise sharing connections can be managed, controlled, and revoked.
OAuth authorizes sharing connections mostly based on simple authentication by the requesting side (client). UMA allows a user to craft policies that drive fine-grained claims-based authorization decisions, including getting the requesting party to make promises or have a third party make attestations on its behalf.
OAuth leaves unstated how its "authorization server" and "resource server" components interact. UMA fully defines a standard interface between its enhanced versions of these two components, the authorization manager and host.
Further reading:
Is UMA up to date with OAuth development?
Click to collapse/expand...
Yes. The UMA protocol has been defined on top of OAuth 2.0, and we try to keep up with OAuth drafts.
Further reading:
Why doesn't UMA use OAuth terminology?
Click to collapse/expand...
At first, UMA did try to use OAuth 1.0 terminology, such as "service provider" for the server side and "consumer" for the client side. As many others had found previously, "consumer" was particularly confusing because we wanted to put an emphasis on the individual who is controlling sharing actions, so we developed alternate terminology ("authorizing user", "requester", "host") and also named the special component that UMA uniquely introduced ("authorization manager").
With WRAP and then OAuth 2.0, OAuth's own terminology and componentry evolved in what we felt was a helpful direction (for example, separating the "resource server" from the "authorization server"). We have considered several times the question of adopting the newest OAuth terminology, but always end up sticking with UMA-specific terms in formal settings because the UMA parties and entities are enhanced and specialized versions of their OAuth counterparts.
If UMA goals get adopted in the OAuth post-2.0 work, we hope there will be formal opportunities to synchronize wording. In the meantime, in our design work and liaison conversations, we find the UMA and OAuth analogues do substitute nicely for each other.
Further reading:
Does UMA make use of the JSON format or JSON Web Tokens (JWT)?
Click to collapse/expand...
UMA uses the JSON format heavily in its request and response messaging specifications.
For now, UMA assumes that AM-issued tokens are opaque (not internally structured) and that, therefore, the AM responsible for having issued the token will be responsible for dereferencing it as necessary. Therefore, for example, the UMA protocol includes a way for a host to make API calls to the AM to check the status of a token presented to it by a requester. However, we anticipate building in optional support for AM-issued tokens that use the JSON Web Token format, which will enable "local" validation without requiring a round trip to the server at run time.
Further reading:
How is UMA related to OpenID and OpenID Connect?
Click to collapse/expand...UMA's purpose is to ensure that users can control access to their data and content. It does this by allowing a user to set up policies that specify who can get access. UMA has a design principle not to require usage of any one identifier system, such as OpenID identifiers. However, we also recognize that access authorization policies often need to identify other parties, for example, in access control lists (ACLs). UMA thus needs a way to handle identity claims about the requesting party, and for this purpose it integrates the option of using OpenID Connect (which, like UMA, is OAuth-based).
OpenID Connect specifies ways to retrieve claims that identify someone uniquely (for example, with a well-known globally unique identifier) or non-uniquely (such as providing a birth date). UMA policies can dictate requirements for the values of such claims in order for the AM to give the requesting party authorization for access.
To achieve this, the UMA AM acts as an OpenID Connect Relying Party, to authenticate the requesting party and start the OpenID Protocol. A second UMA AM interface, the Claims Client, is then responsible for requesting an access token for the requesting party’s UserInfo EndPoint. This allows the claims request to be processed through the requesting party's authorization server, which can then be sent as a response back to the AM for interpretation and access decision-making.
Further reading:
hide lafoglia
hideki nara
Comments (0)
Leave a comment...