Child pages
  • Legal Considerations in UMA Authorization

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

"Privacy is not about secrecy. It's about context, control, choice, and respect." (UMA webinar, after Bob Blakley)



This document explores legal issues raised by the act of using User-Managed Access (UMA) to authorize another party to get web resource access.


  • Eve Maler
  • Tom Smedinghoff ??
  • Mark Lizar


Add sharing scenario.

Intellectual Property Notice

The User-Managed Access Work Group operates under Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) and the publication of this document is governed by the policies outlined in this option.


Table of Contents




User-Managed Access (UMA) gives a web user a allows a user to make access demands as well as manage access to their own resources outside of each and every service provider . The implications of these demands quickly go beyond cryptography and web protocols and into the realm of rights, contracts and liability.

 UMA is a protocol  for access control to resources at a host. E.g. a Internet Service provider.  

Such a service should allow a user to control data-sharing  and service-access relationships between online services hosting and accessing data. An external User controlled access manager requires the ability to reside in distinct domains and establish relationships between services in a dynamic way. For the access relationship service to be usable across multiple web applications, it should not be required to understand the representations of resources it is charged with protecting and its functionality should be applicable to arbitrary web resources.

UMA is developed to give a web User a unified control point for authorizing who and what can get access to his or her online personal data (such as identity attributes), content (such as photos), and web-based services (such as seeing viewing and making creating Twitter-style status updates), no matter where all those things "live" on the web. Further, UMA allows the user to make demands of the other side parties to the transaction with which these parties must comply in order to test for their suitability request for receiving authorizationauthorization to view/consume the user's data to be approved. These demands can include requests for information (such as "Who are you?") and promises (such as "Do you agree to these Non-Disclosure Agreement terms?").

This is a tall order, with implications that go beyond cryptography and security, and web protocols and technology, into the realm of agreements and liability. While UMA targets end-user usability convenience and development simplicity as goals, . But it also seeks some measure of enforceability of authorization agreements, in order to empower ordinary web users more fully and to make the acts act of granting data and service access truly meaningfulinformed, informed, and uncoercedun coerced, and meaningful – no longer a matter of mere passive consent but rather a step that more fully empowers ordinary web users.

For all these reasons , the UMA Work Group is exploring legal considerations need to be aware of the impact UMA has on issues related to authorization trustpolicy, contracts, liability, and enforceability that arise among the various actors in UMA interactions.

(Note: This document is intended in the process of being edited to be accessible to readers, even relatively nontechnical readers ones, who have expertise in these areas, and we welcome suggestions for improvement.)

Starter Scenarios

Let's imagine a web user, Alice Adams, who doesn't mind sharing her personal travel information with the right sources as long as the process of sharing

  • Is convenient (e.g., no requirements to alert authorized recipients every time a new trip gets booked);
  • meets her expectations for the uses of that information are met (e.g., she's not worried about recipients divulging to the whole world that her house is going to be empty);
  • Provides control mechanism dictating what's allowed and not allowed (e.g., she can get an at-a-glance view of who's seeing what).

She uses a website called (think TripIt) to store all of her travel itineraries. Since it's the nature of travel information to change frequently, she wants to be sure that her good friend Bob Baker always has the latest version so he can pick her up from the airport on time and make sure her cat is fed while she's away; he likes to use (think Google Calendar) for subscribing to TravelIt. She would also like her social travel site (think Dopplr) to pick up her itineraries automatically and make them available to friends who are on that system.

Because Alice is a frequent and seasoned traveler, she's interested in entertaining discount offers from travelogue company (think Frommer's) for making her itineraries available to them for survey purposes.

To this picture, UMA adds the possibility of a new kind of web-based application: a kind of "traffic cop" for overseeing all these instances of travel itinerary sharing, which will help Alice manage her digital footprint. We'll call this site

 (am thinking of re-vamping this scenario so that it refelects an external access control manager than that of the Host (service provider) Mark ??

UMA overview and terminology

As hinted in the introduction, UMA involves four main players:

  • An Alice is an authorizing user: A a web user who gets to be in charge of authorizing access to his or her "stuff" on the web A (known as protected resources).
  • The TravelIt application acts as a host: One one of possibly many websites where the authorizing userAlice's data, content, and services resources are stored and managed in various fashions (all this "stuff" is known as protected resources)A requester: One of possibly many web-enabled .
  • The Schedewl, Airplanr, and FrodoReviews applications act as requesters: web-based applications that seek access to the authorizing user's "stuff"; access may not mean protected resources. Access may mean more than just downloading or viewing, but could also include for example adding more "stuff" to be stored, or manipulating or transforming the "stuff" it in some other wayAn .
  • The CopMonkey application acts as an authorization manager or AM: A a unified web-based control point on the web that makes it easy for the authorizing user Alice to set up protections for all those resources at all those their various hosts, and to control and track access to them by requesters


  • requester's.
  • *# Establish general policies for the access and protection of all her protected  resources at their various hosts,
    1. Set up unique individual rules for specific combination's of protected resources, hosts and requester's,
    2. track access to her protected resources by requester's and
    3. manually manage specific interactions as established in her policies.

So far, this description relates only to the UMA web protocol itself. These four players are commonly referred to as "endpoints" in discussions of computing protocols (or sometimes as "entities" or "parties", but we'll avoid these in order to avoid confusion with the legal connotations of these words). Protocols define rules, and you can think of each these players as serving in a unique role with certain expectations and responsibilities, as if the rules were about soccer and governed the allowed actions of goalkeepers versus outfielders.But remember

You might be asking, Where did Bob go? Recall that the authorizing user can make demands of the other side counter parties (Bob is an other party like, and to judge their suitability for access. This is where we We must ask: What is the nature of the "other sidecounter parties " like Bob? The authorizing user is flesh-and-blood, but the AM, host, and requester endpoints are just tools. They are implemented in software, and the software is deployed in the form of networked applications and services. A tool can't be responsible for the consequences of accessing an authorizing user's "stuff". For this reason, we introduce another important player that's not strictly part of the UMA protocol:

  • A requesting party: Either a legal person In our examples, Bob and the companies that run Airplanr and FrodoReviews are requesting parties: legal persons (such as corporationcorporations) , or a and real human being beings (other than the authorizing user, who uses Alice herself) who use a requester endpoint to seek authorized access to some portion of that "stuff".


  • protected resource.

Image Added

We'll explore this complex set of players more in a moment.

The policy capabilities of UMA allow the authorizing user to configure the AM with policies that constrain the conditions for access by others . When in advance, so that the authorizing user need not be present (online) when transactions with requesters take place. Then, when a requester endpoint comes calling, the policy may compel the AM may ask them to provide a set of  to  ask the requestor to convey the following:

  • A claim: An set of claims: i.e. one or more affirmative or promissory statement statements about the requesting party that are intended to satisfy some policy Alice has configured into her AM.

Now we can have enough language to begin discussing potential access authorization agreements and liability that may obtain between two parties (yes, in the legal sense) interacting in an UMA environment: the authorizing user and the requesting party.

Authorization Scenarios

Let's introduce a cast of characters that will help us explore different scenarios:



Intermediaries the authorizing user may employ in protecting resources

Alice likely is an ordinary user of the web, and tends to use web applications written by third parties rather than hacking her own services and deploying them on the networked workstation that sits under her home-office desk. Thus, she chose to use the third-party services run by the TravelIt and CopMonkey companies, and in creating accounts with them, she likely had to agree to (or negotiate) terms of service with each of these companies. They are thus intermediaries in providing UMA protection to her resources, rather than parties to actual authorized access.

Image Added


Sharing with Airplanr


Image Added


Sharing with FrodoReviews


Image Added


Sharing with Bob through Schedewl


Image Added


The nature of claims

A claim may be affirmative, representing a statement of fact (as asserted by the requesting or another claim issuer); or promissory, a promise (as asserted by the requesting party specifically to the authorizing user). A statement of fact might be "The requesting party is over 18 years of age." A promise might be "The requesting party will adhere to the specific Creative Commons licensing terms indicated by the AM." There are technical dimensions to expressing and conveying claims, but since UMA strives to provide enforceability of resource-access agreements, there may also be legal dimensions.


Where the primary resource user and the authoring user differ, there is likely to be an interaction (invisible to UMA) at the host service that allows (or forces) the primary resource user to designate an authorizing user, and an agreement that the authorizing user acts as the primary resource user's agent or guardian or similar.

Person-to-service access: a walkthrough

@@TBS - new diagram

Person-to-person access: a walkthrough

@@TBS - new diagram

Parties and legal responsibilities

For our purposes in UMA 1.0, an authorizing user is always a natural person (a human being). We foresee use cases where the authorizing party could be a non-human, but our 1.0 scope sticks to human beings in this role to ensure that we think about how to craft the user experience for this person (who is the all-important "user" in UMA!). An authorizing user may set policies at the AM that end up legally binding him/her, depending on the claims coming from the requesting party in response.

A requesting party may be either a natural person or a legal person.

The AM and requester protocol endpoints, the software that implements them, and the services that deploy them are just tools to help the parties get to a desired result. However, the requesting party "behind" these tools is a party that may be held legally responsible for any claims made to the authorizing user. Thus, some legal person such as a company may operate the service that hosts or requests a resource, or offers authorization services.

Here are the choices for requesting party:


Note that 1.a.ii and 2.b.i are protocol alternatives (denoted with A and B) for what could be the same basic kind of authorized access. In the first, the authorizing user and the requesting party are both Alice, and if any claims are required she supplies them to herself, but she has chosen to use some service run by a third party to manage requests for access. In the second, Alice uses the same such service but expects it to speak for itself in responding to demands for claims (possibly providing claims about her in the process).

Similarly, 1.b.ii and 2.b.ii are protocol alternatives (denoted with X and Y). In the first, Alice authorizes Bob for access, and Bob happens to use an intermediary service to help manage his requests. In the second, Bob uses the same such service but expects it to speak for itself in responding to demands for claims (again, possibly providing claims about him in the process).

We are actively researching this issue. See the notes from UMA telecon 2010-03-18 for discussion about the impact of choosing one alternative over another.


Mapping requesting parties to profiles for getting access tokens

We suspect that certain sharing patterns lend themselves to choosing different profiles for UMA's step 2 (getting a token).

  • Person-to-self sharing could possibly use any profile of the WRAP user delegation type, since the same person would have an account on the requester and AM sides.
  • Person-to-service sharing could possibly use any profile of the WRAP autonomous client type, since the service itself operates the WRAP client that is embedded in the UMA requester.
  • Person-to-person sharing could also possibly use any profile of the WRAP autonomous client type, since everyone and everything on the requesting side is "autonomous" with respect to the authorizing side. However, an entirely new set of profiles might be appropriate instead, to take into account the requesting person's personal involvement in providing claims, confirming agreements, etc.


  • When Alice authorizes sharing of her TravelIt resource with Airplanr (in the context of "herself again" logged into Airplanr), a user authorization flow might possibly be appropriate as part of the process of Airplanr satisfying CopMonkey that it's really Alice again. ??
  • When Alice authorizes sharing of her TravelIt resource with FrodoReviews acting on its own behalf, an autonomous client flow seems appropriate.
  • When Alice authorizes sharing of her TravelIt resource with Bob through Schedewl, we're not sure if this should use an autonomous client flow or if something similar to it needs to be written specially to add the "on behalf of a totally different person" semantic.


Change History