Child pages
  • Legal Considerations in UMA Authorization
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

Abstract

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

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
  • Eve Maler
  • Tom Smedinghoff ??
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

User-Managed Access (UMA) gives a web user a unified control point for authorizing who and what can get access to her online personal data (such as identity attributes), content (such as photos), and web-based services (such as seeing and making 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 in order to test their suitability for receiving authorization. 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 and development simplicity as goals, it also seeks some measure of enforceability of authorization agreements, in order to empower ordinary web users more fully and to make the acts of granting data and service access truly meaningful, informed, and uncoerced.

For all these reasons, the UMA Work Group is exploring issues related to authorization trust, contracts, liability, and enforceability that arise among the various actors in UMA interactions. This document is intended to be accessible to relatively nontechnical readers who have expertise in these areas.

UMA overview and terminology

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

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

Now, this description is fairly technical and, so far, 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 that the authorizing user can make demands of the other side to judge their suitability for access. This is where we must ask: What is the nature of the "other side"? 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 (such as corporation), or a real human being other than the authorizing user, who uses a requester endpoint to seek authorized access to some portion of that "stuff".

Finally, we need to ask: What is the nature of these "demands" and their responses? Since we're talking about web interactions, the authorizing user isn't exactly sitting across a table from the requesting party in real time, pestering them with questions. Rather, the authorizing user can, at leisure, configure the AM with policies that constrain the conditions for access by others. When a requester endpoint comes calling, the AM may ask them to provide a set of the following:

  • A claim: An affirmative or promissory statement about the requesting party.

Now we can 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:

  • Alice is an authorizing user who is active on the web and uses a variety of web applications to store, manage, and share her data and content and services.
  • CopMonkey.com is a service provider that Alice has chosen to use as her unified authorization manager (AM) on the web. She had to create an account at CopMonkey to get started using it.
  • TravelRadar.com is a calendar service provider that Alice uses as a host for her travel information. She had to create an account at TravelRadar to get started using it.
  • FrodoReviews.com is a travelogue company that wants access to Alice's travel patterns for its own research/survey purposes.
  • Bob is a friend of Alice's who often picks her up from the airport when she comes home from her trips. Bob likes to use the DontForget.com online service to remember to retrieve her.
  • @@

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.

In cases where a claim constitutes acceptance of an access-sharing contract offer made by the authorizing user (as presented by the AM as his or her agent in requiring the claim), the authorizing user and requesting party are the parties to the contract, and all other legal or natural persons running UMA-related services involved in managing such access are intermediaries that are not party to the contract (though they might end up being third-party beneficiaries in some cases).

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:

  1. Requesting party is a natural person, that is, a human being

    1. That person is the same as the authorizing user (person-to-self sharing)

      1. That person operates the service that runs the requester endpoint ("Alice authorizes herself to see her geolocation at a host, using her own homegrown requester app that logs travel")

      2. That person uses some third-party service that runs the requester endpoint as an intermediary, with which he/she has a separate agreement for terms of use ("Alice authorizes herself to subscribe to her calendar at host Googol Cal, using the popular Schedewl online app"): A

    2. That person is different from the authorizing user (person-to-person sharing)

      1. That person operates the service that runs the requester endpoint ("Alice authorizes Bob to see her geolocation at a host, using his own homegrown requester app that tracks her travel")

      2. That person uses some third-party service that runs the requester endpoint as an intermediary, with which he/she has a separate agreement for terms of use ("Alice authorizes Bob to subscribe to her calendar at a host, using the popular Schedewl online app where he has an account"): X

  2. Requesting party is a legal person, such as a company (person-to-service sharing)

    1. That legal person operates the service that runs the requester endpoint on its own behalf ("Alice authorizes the survey company DataSuck to pull copies of her self-asserted demographic data on an ongoing basis")

    2. That legal person operates the service that runs the requester endpoint on the behalf of some person, with whom it has a separate agreement for terms of use

      1. That person is the same as the authorizing user ("Alice authorizes Schedewl to subscribe to her calendar at host Googol Cal, acting on behalf of her own account at Schedewl"): B

      2. That person is different from the authorizing user ("Alice authorizes Schedewl to subscribe to her calendar at host Googol Cal, acting on behalf of Bob's account at Schedewl"): Y

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.

We are actively researching this issue.


Change History

Version Date Comment
Current Version (v. 2) Apr 11, 2010 16:18 Eve Maler
v. 10 Oct 28, 2010 12:51 Mark Lizar:
Migrated to Confluence 4.0
v. 9 Oct 28, 2010 12:51 Mark Lizar
v. 8 Oct 14, 2010 13:50 Mark Lizar
v. 7 Sep 30, 2010 13:34 Mark Lizar
v. 6 Apr 14, 2010 01:30 Eve Maler
v. 5 Apr 14, 2010 01:26 Eve Maler
v. 4 Apr 14, 2010 01:15 Eve Maler
v. 3 Apr 11, 2010 18:47 Eve Maler
v. 2 Apr 11, 2010 16:18 Eve Maler
v. 1 Apr 08, 2010 19:12 Eve Maler
  • No labels