UMA Trust Model

Abstract

This document defines the expectations and responsibilities of various parties interoperating in the User-Managed Access (UMA) context. The overall goal for UMA's trust model is to support legal enforceability of any agreements made between authorizing users and requesting parties in the granting of access authorization. This document's audience includes technologists, legal professionals, and operators of UMA-conforming services.

Status

This document is a product of the User-Managed Access Work Group. It is currently under active development. Its latest version can always be found here. See the Change History at the end of this document for its revision number.

Editors

• Susan Morrow
• Eve Maler

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

Introduction

UMA is a Web protocol. As such, it describes a technical "contract" for web-based interactions – standardized request and response messages using standardized data formats – among software entities. The entities fill various roles in order to achieve "user-managed access" to Web resources. The following diagram illustrates the high-level goal of UMA.

The following diagram illustrates the high-level architecture UMA uses to achieve its goal.

Software entities participating in a protocol are known as endpoints. The UMA endpoints are:

• Authorizing user – the "user" in User-Managed Access
  • NOTE: "User" is often used informally in the UMA spec, where what is really meant is the browser (or other client software application) being operated by this person
• Authorization manager (or AM)
• Host (of "protected resources")
• Requester

Software is just a tool; it can’t be held legally responsible for its own actions. Because UMA has a goal of setting legally enforceable conditions for access to resources, we must acknowledge the importance of the natural persons (human beings) and legal persons (such as companies) that run, control, own, contract to use, etc. UMA-conforming software. These are parties (distinguishing them from protocol endpoints). The UMA parties are:

• Authorizing user – the person seeking to protect resources stored at the host (context will tell whether the use of the phrase refers to the party or the entity)
  • NOTE: This could mean a legal person, but Version 1 of UMA focuses primarily on natural persons acting on their own behalf on the Web
• Host operator – the natural or legal person responsible for the running host service
• Authorization manager operator (or AM operator) – the natural or legal person responsible for the running AM service
• Requesting party – the natural or legal person seeking access to protected resources

Sharing Constellations

While the essential end-to-end relationship being managed in UMA is the one between the authorizing user and the requesting party, there are subtle variations around the nature of the latter and the nature of the software they might use. Each type of requesting party and interaction style defines a different sharing constellation. Following are examples of each.

Person-to-self sharing

This describes most types of today's OAuth-mediated access, for example, when Alice introduces the Klout service to her Twitter account. She uses both services herself, and wants them to communicate together on her behalf.

Person-to-person sharing

Today, many Web 2.0 sites offer some level of this control, but methods, strengths, and interfaces are inconsistent between sites and we're not able to reuse policies across sites. For example, Alice can share Flickr photos with Bob by adding him to her Flickr "friends" or "family" list or by mailing him a special link to a photo album. Or Alice can add Bob as a "friend" on Facebook.

Person-to-organization sharing mediated by a human agent of the requesting side

For example, Alice wants to give her dentist's office, DentalCare, temporary access to her calendar, to make it easier to schedule a series of root canal appointments. Carl, the office assistant, might be the actual person acting on behalf of the dental practice who sees Alice's calendar.

Person-to-organization sharing mediated by a automated web service on the requesting side

For example, Alice has crafted a "personal request for proposals" (known as a pRFP among the Vendor Relationship Management community) because she's in the market for a new car, and she's willing to let car dealerships in her region of the country see the RFP and make her offers. Different car dealerships might use Web crawler services to go out and collect such RFPs, and these services will have to prove in automated fashion that they legitimately represent the right kind of business.

Each constellation's requirements for successful user-managed access may be distinct. For example, in person-to-self sharing, it's unlikely Alice will want to impose stringent contract terms on herself. In person-to-organization sharing, if the organization is using a web service client, it makes no sense to present a browser-interaction interface to it. And if the organization is acting through a human agent such as a receptionist or administrator, that person may need to prove they are acting on behalf of the organization.

Trust Relationships

NOTE: Parts of this section require the reader to have UMA protocol knowledge; references to specific sections of the UMA core protocol specification are provided throughout to help with this process.

To trust another party means to expect it to live up to agreed-on responsibilities. If something goes wrong, it must be possible to assign responsibility accurately. For example, if Alice sets policies that she thinks will prevent Zeke from seeing her calendar, and Zeke gets access somehow through some requester software, who exactly was at fault? Since UMA imposes a loose coupling between the setting of policy, the application of policy in assigning authorizations, and the providing of resources, a lot could go wrong. The act of authorization has to be made meaningful through making different parties' actions enforceable and auditable.

The parties in the UMA picture can potentially have the following expectations of each other. Note that expectations can flow in both directions (though a pair of such expectations is likely not reciprocal):

The UMA protocol can only define junctures where entities are required to uphold expectations of technical trust by other entities, meaning that the interactions can be entirely programmatic or automatable. For example, when a host sends a request message X to an AM, and the AM replies with response message Y, each of their sets of expectations is defined by the relevant normative instructions in the UMA specification. Technical trust is measured in terms of technical conformance (UMA Core Sec 7).

This Trust Model adds elements of business trust to this picture, defining a behavior standard the parties are required to live up to in order to meet each others' expectations. These elements of business trust build on the exact same interactions defined by the technical spec, so that a technical action by an entity implies that the party operating the entity intends to live up to the matching set of business expectations. These constitute a standard set of "general rules" that apply to all parties that deploy entities claiming to be UMA-conforming. A pair of business trust expectations and responsibilities is referred to in this document as a trust relationship.

NOTE: UMA's trust relationships are not legally enforceable unless parties include them in contracts, or unless laws or regulations mandate them.

Following is a pictorial summary of the TRs defined by this Trust Model.

Trust Relationships by Party

Following is a summary of TRs organized by party, with references to the relevant TR collections.

TRs Where the Authorizing User Is Responsible

TRs Where the AM Operator Is Responsible

TRs Where the Host Operator Is Responsible

TRs Where the Requesting Party Is Responsible

Trust Relationships Outside of UMA

Parties are free to define or adhere to additional "special rules" beyond the trust relationships defined in this document. Following are typical pairwise agreements the parties might form between themselves.

Note that UMA neither anticipates nor requires any outside trust relationship between the authorizing user and the requesting party. This is because UMA's central purpose is to enable this trust relationship itself.

Following are some examples of pairwise terms of service that parties might execute:

• The host operator relies on the authorizing user to adhere to the host operator’s terms of service (TOS). This trust relationship typically gets formed when the user initially registers for an account at the service.
• The AM operator relies on the operator of a requester web app, apart from any particular requesting party's usage of that web app, to adhere to the AM operator's TOS for API clients. This TR typically gets formed when the client app developer registers for client credentials, or through "API-wrap" TOS (akin to "browse-wrap" that binds a user who merely visits a website).
• The requesting party relies on its employee to act as its legitimate agent. The authorizing user's policy may require the requesting party to prove that the request is being mediated by a legitimate agent for that party. However, the requesting party itself is the one who may impose constraints on its workforce around keeping information learned in the course of business confidential etc.
• The requesting party relies on the operator of a requester web service to adhere to any contractual agreement governing that service. For example, a car dealership may contract out to use a cloud service that crawls the Web looking for personal RFPs that meet the dealership's criteria.
• The operator of the requester app relies on the host operator to be the correct party for supplying trustworthy information of a certain type. For example, in a scenario where the authorizing user is trying to fill in an online loan application through a financial service (the requester) and the host provides credit risk data about the user, the financial service will want to authenticate the host service in some fashion.

Another way of creating rules that go beyond UMA is for parties to join trust frameworks that impose umbrella agreements on their members. Such agreements might contain more specific versions of UMA's trust relationships, or additional trust relationships among the parties, or might include requirements to use specially profiled technical features of UMA, or impose user experience requirements on parties interacting with human beings – or all of the above. This is where levels of identity or attribute assurance, levels of data protection, and levels of data usage control might come in to the picture.

Trust Relationships at the Heart of UMA

This is the set of trust relationships that describes the overall purpose of UMA. The authorizing user works through the AM as a proxy for authorization management.

Trust Relationships Formed by Introducing the Host and AM

This is the set of trust relationships formed in UMA phase 1, when the user introduces a host and AM to work together in protecting resources. The user will likely introduce many hosts to the same AM. In some cases, particular hosts may make it possible to protect some resources with one AM and other resources with a different AM. Many of these trust relationships depend on the authorizing user's expression of various preferences and instructions through a user interface, and to this extent, they have a subjective component.

Trust Relationships Involving the Protection API Token

This is the set of trust relationships that allow the protection outsourcing to take place. The host operator and AM operator have two contexts for dealing with each other: one is specific to the authorizing user (the same two operators could participate in protection for different users) and the other is specific to the requesting party (the same two operators could be protecting the same resource on behalf of the same user but fielding requests from different requesting parties). Many of these trust relationships depend on the authorizing user's expression of various preferences and instructions through a user interface, and to this extent, they have a subjective component.

Trust Relationships Involving the Authorization API Token

This is the set of trust relationships that govern the authorization process. These trust relationships reflect how the requesting party goes from untrusted to trusted for a particular scope of access, as far as the AM operator (acting as a proxy for the authorizing user) is concerned. Many of these trust relationships depend on the authorizing user's expression of various preferences and instructions through a user interface, or on the requesting party's actions, and to this extent, they have a subjective component.

Trust Relationships Involving the Requester Permission Token

This is the set of trust relationships that govern the actual release of access by the host operator to the requesting party.

Change History