"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.

...

• Eve Maler
• Tom Smedinghoff ??
• Mark Lizar

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 allows a user to make access demands. The implications of these demands quickly go beyond cryptography and web protocols and into the realm of rights, contracts and liability.

Rights in that an individual has the right to control access to their information.  UMA provides a infrastructure for dedicated access services.  This relates to rights in that individuals Access control needs to be externalized from web applications and provided as a dedicated online service.

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 services 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 viewing and 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. UMA targets end-user convenience and development simplicity as goals. But it also seeks enforceability of authorization agreements, in order to make the act of granting data and service access truly informed, uncoerced, 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 issues related to authorization policy, 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 ones, who have expertise in these areas, and we welcome suggestions for improvement.)

...

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

• 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 TravelIt.com (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 Schedewl.com (think Google Calendar) for subscribing to TravelIt. She would also like her social travel site Airplanr.com (think Dopplr) to pick up her itineraries automatically and make them available to friends who are on that system.

...

• Alice is an authorizing user: a web user who gets to be in charge of authorizing access to his or her "stuff" on the web (known as protected resources).
• The TravelIt application acts as a host: one of possibly many websites where Alice's resources are stored and managed in various fashions.
• The Schedewl, Airplanr, and FrodoReviews applications act as requesters: web-based applications that seek access to the authorizing user's protected resources. Access may mean more than just downloading or viewing, for example adding more "stuff" to be stored, or manipulating or transforming it in some other way.
• The CopMonkey application acts as an authorization manager or AM: a unified web-based control point that makes it easy for Alice to set up protections for all those resources at their various hosts, and to control and track access to them by requestersby 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.

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 Schedel.com, and Airplanr.com) to judge their suitability for access. 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:

...

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

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 (or their legal or business representative) in real time, pestering them with questions. Rather, the authorizing user can, at leisure, 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 AM may ask it policy may compel the AM  to  ask the requestor to convey the following:

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

Now we 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.

...

NEED TO EDIT FROM HERE ****

Intermediaries the authorizing user may employ in protecting resources

...