"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.
...
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.
...
| 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-like style status update servicesupdates), wherever no matter where all those items things "live" on the web. Further, UMA allows this 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 legal contracts agreements and liability. While UMA strives for simplicitytargets 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. It also wants to make this power as usable and human-centered as possible.
For all these reasons, the UMA Work Group is exploring issues related to business authorization trust, contracts, liability, and enforceability that arise among the various actors in UMA interactions.
Brief introduction to UMA
@@TBS - link to Lexicon..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
...
We are actively researching this issue.
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
...