"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.
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.
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.
User-Managed Access (UMA) gives 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 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. 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 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 convenient (e.g., no requirements to alert recipients every time a new trip gets booked); her expectations for the uses of that information are met (e.g., she's not worried about the whole world knowing when her house is going to be empty); and she feels "in control" of 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 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 FrodoReviews.com (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 website: 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 CopMonkey.com.
As hinted in the introduction, UMA involves four main players:
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.
Recall that the authorizing user can make demands of the other side to judge their suitability for access. 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:
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:
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.
@@TBS - new diagram
@@TBS - new diagram
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.
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.
We suspect that certain sharing patterns lend themselves to choosing different profiles for UMA's step 2 (getting a token).
We are actively researching this issue.