Versions Compared

Old Version 54

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A number of historical articles and other materials about UMA are available:

For UMA information in other languages, see:

  • Domenico Catalano's UMA introduction in Italian
  • Cordny Nederkoorn's article on UMA in a Dutch , and a poster (best printed on A0-A3 paper; 8.5x11 or 8.5x14 is okay but small) was presented at the IEEE Security and Privacy symposium poster session.

For UMA information in other languages, see:

  • Domenico Catalano's UMA introduction in Italian
  • Cordny Nederkoorn's article on UMA in a Dutch publication
  • Tatsuo Kudo's SlideShare deck covering UMA in Japanese
  • Wikipedia information in Italian and Spanish, thanks to Riccardo Abeti and Domenico Catalano

For external information and thoughts on UMA, see:

Further reading:

What is a typical UMA scenario, and who are the actors in it?

Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is a "resource owner" who manages her calendar resource online. She might want to share hercalendar 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 called a "resource server". She could have many resource servers 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 "client" applications to attempt access.

In some cases, Alice herself is a requesting party in addition to being a resource owner, 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 called an "authorization server". She can set policies that guide the authorization server in allowing or disallowing access by clients to protected resources at resource servers.

Further reading:

What is the UMA protocol flow?

Phase 1 of the UMA core protocol involves the resource owner introducing the resource server and authorization server so they can work together. Phases 2 and 3 together involve the requesting party, using a client, making an access attempt, being tested for suitability by the authorization server to receive permission, and ultimately succeeding or failing in the attempt by presenting a token with permissions associated with it.

Further reading:

...

UMA-related short links:

Further reading:

What is a typical UMA scenario, and who are the actors in it?

Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is a "resource owner" who manages her calendar resource online. She might want to share her 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 called a "resource server". She could have many resource servers 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 "client" applications to attempt access.

In some cases, Alice herself is a requesting party in addition to being a resource owner, 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 called an "authorization server". She can set policies that guide the authorization server in allowing or disallowing access by clients to protected resources at resource servers.

Further reading:

What is the UMA protocol flow?

Phase 1 of the UMA core protocol involves the resource owner introducing the resource server and authorization server so they can work together. Phases 2 and 3 together involve the requesting party, using a client, making an access attempt, being tested for suitability by the authorization server to receive permission, and ultimately succeeding or failing in the attempt by presenting a token with permissions associated with it.

...

UMA's Relationship to Other Efforts

...

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. UMA specification draft modules have variously been contributed as IETF individual Internet-Drafts. One such draft so far, covering dynamic client registration, was accepted as an OAuth WG work item, an item that has now progressed.

...

OAuth leaves unstated how its "authorization server" and "resource server" components interact (though a recent proposal for "token introspection" is tackling part of this problem). UMA fully defines a standard interface between its enhanced versions of these two components.

Further reading:

Is UMA up to date with OAuth development?

...

As of late 2012, it does! Some of the old UMA collateral still uses UMA-specific terminology , but we're moving to a world of authorization servers, resource servers, and clients.The previous terms in UMA were (authorization manager (AM), host, and requester.Prior , and prior to that, they were relationship  relationship manager, service provider (SP), and consumer), but we have generally fully moved to a world of authorization servers, resource servers, and clients.

Further reading:

...

UMA uses the JSON format heavily in its request and response messaging specifications.For now, UMA assumes that tokens are opaque (not internally structured) and that, therefore, the authorization server 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 resource server to make API calls to the AM to check the status of a token presented to it by a client. However, we anticipate building in optional support for tokens that use the JSON Web Token format, which will enable "local" validation without requiring a round trip to the server at run time.and response messaging specifications.

The default, mandatory-to-implement token format for UMA "requesting party tokens" (RPTs, the token that a client presents to a resource server when trying to access a protected resource) is opaque on the wire, and a resource server introspects it at the authorization server at run time. Its format is JWT, with an extension property called "permissions" that takes into account UMA's extended concept of resource set scopes.

Further reading:

...

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 authorization server to give the requesting party authorization for access.To achieve this, the UMA authorization server acts as an OpenID Connect Relying Party, to authenticate the requesting party and start the OpenID Protocol. A second UMA authorization server 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 To achieve this, the UMA authorization server can act as an OpenID Connect Relying Party.

Further reading:

...

How is UMA related to XACML?

UMA is not formally related to XACML, but we can imagine some patterns of usage that bridge XACML and UMA. For example, UMA does not standardize a policy expression format or its evaluation, and treats an authorization server as a conflated policy decision point (or at least authoritative authorization data source), policy administration point, and policy information point for the purposes of UMA's in-band flows. An authorization server could also provide "raw" authorization data for which a resource server could then seek interpretation at a true XACML PDP. An UMA representative made a presentation to the XACML TC on 19 October 2012 to discuss liaison and technical opportunities. A specialized UMA token profile could also be used to provide a pattern for XACML's ongoing efforts to simplify/RESTify the current XACML standard.

...

How can UMA make requesting parties adhere to the user's wishes for privacy and data usage control?

The demands the user resource owner may want to make on the requesting side can't be solved only with cryptography and web protocols; you quickly get into the realm of agreements and liability.

UMA stays away from techniques like DRM (digital rights management), where you cryptographically "lock" your data before sending it on (though this could be layered on the data that flows over UMA). For end-user convenience, development simplicity, and web-wide adoption, instead UMA puts the emphasis on user visibility into and control over access by others.

...

Because individuals are often at a power disadvantage compared to big companies and big websites, truly empowering people to control sharing is a tall order. The UMA Work Group has considered the problems it can tackle, and the ways in which a number of complementary efforts – such as trust and privacy frameworks – can be used in combination with it.

Further reading:

...

UMA requires a trust "dance" among several parties, who are aligned in some of their interests but who have divergent incentives in many other cases. The UMA Binding Obligations framework explains to what extent trust can be built between pairs of parties at a contractual level.

Further reading:

...

At its current state of development, UMA comes with a draft technical specification and a draft contractual framework, called Binding Obligations, that lays out a set of minimum obligations to help make UMA participants confident about engaging in acts of distributed authorization. This is not a full trust framework in the U.S. FICAM sense, for example, but is meant to complement contracts and umbrella agreements wherever they might be used. The Binding Obligations document currently assumes that those who operate UMA-enabled software services will self-identify as conforming to the technical spec, and by that act, would take on obligations during the normal course of sending and receiving UMA-conforming messages. This is an area the UMA Work Group is actively working on.

Further reading:

...

What implementations of UMA are there?

We are aware of four several major implementations so far.

Further reading:

Have there been any usability studies on UMA?

The original SMART project performed formal usability studies at Newcastle University, which led to improvements from SMARTAM 1.0 to SMARTAM 2.0. We anticipate that further usability testing will be done by various parties as the number of interoperable implementations grows.

Further reading:

...

For individual people interacting with the web, this model means that they can conveniently reuse any sharing circles (such as "friends and family" lists) they might have among all the Web applications and information they control. They can also set up criteria for access at a single place (the UMA authorization manager) and then go about their lives, not necessarily having to be online and paying attention when someone wants access to their stuff.

Further reading:

What sort of entity might serve as an UMA authorization server?

An UMA authorization server has a natural affinity with those who operate identity providers (IdPs). It's well known that any one IdP can't provide on-board storage of all information relevant to an individual, and this fact is now being recognized in the new OpenID Connect model of IdPs that mediate access to claims from other authorities. The Open Identity Exchange's Street Identity project shows the value of using an IdP as a "relationship manager" to gather user consent for sharing a claim (in this case, a verified street address) whose authoritative version resides elsewhere. UMA leverages OpenID Connect to enable IdPs to offer this kind of service to users, adding features unique to UMA along the way (such as sharing data with other people and organizations, not just "yourself" using a different app).

Further reading: