Child pages
  • Privacy by Design Implications of UMA
Skip to end of metadata
Go to start of metadata

Privacy by Design Implications of UMA

It is useful to examine how User-Managed Access (UMA) relates to the seven foundational principles of Privacy by Design (PbD). In this document we provide an analysis of each principle, and a companion analysis of how UMA and UMA-enabled solutions can support the principle.

1. Proactive not Reactive; Preventative not Remedial

This principle is key for promoting meaningful, informed, uncoerced consent, and potentially even for going beyond what most people think of as consent (an "Accept" button at run time). In discussions of patient-centric healthcare, for example, the notion of "consent directives" puts the emphasis on ways in which data sharing must be bound by patient preferences and preauthorizations on file.

While many systems put a premium on gathering user consent at the time of the access request, UMA enables users (human beings in the "resource owner" role of the UMA protocol) to set access policies before a requesting party ever attempts to interact with the resource in question. This enables a different relationship between resource owners and applications (or even other autonomous parties) seeking access. As noted in a W3C privacy workshop position paper focusing on UMA, "Granting access to data is then no longer a matter of mere passive consent to terms of use. Rather, it becomes a valuable offer of access on user-specified terms, more fully empowering ordinary web users to act as peers in a network that enables selective sharing."

2. Privacy as the Default Setting

This principle captures the importance of user actions that follow the path of least resistance so that the user experience design is human-centered. As noted by Don Norman in The Design of Everyday Things, "Everyday activities must usually be done relatively quickly, often simultaneously with other activities. .... Much human behavior is done subconsciously, without conscious awareness and not available to inspection. .... Subconscious thought is biased toward regularity and structure, and it is limited in formal power. It may not be capable of symbolic manipulation, of careful reasoning through a sequence of steps. [2002 ed., p. 125]"

UMA enables an authorization server to offer a variety of data sharing controls to users, centralizing these controls so that access blocking can easily be applied across any number of resource servers. In most such applications, we anticipate that global preferences such as "block all sharing unless I say otherwise" or "make all sharing public unless I say otherwise" will be available. The UMA-enabled service SmartAM.net does, in fact, block sharing by default. While the UMA protocol itself does not require an authorization server to block sharing by default, a number of environmental factors could contribute to making this option widely available. For example, a requirement to offer this option can be captured in a trust framework agreement that governs a personal cloud or healthcare access federation.

3. Privacy Embedded into Design

Embedding privacy controls into online service development is a goal not often achieved – except in services designed specifically to address consumer privacy concerns.

UMA, of course, exists to enable a resource owner – the "user" in User-Managed Access -- to control the authorization of data sharing and other protected-resource access made between online services on his or her behalf, or with his or her authorization by an autonomous requesting party. Any online service that leverages UMA as its resource protection mechanism is enabling a whole new level of embedded privacy controls, using an open protocol that is designed to be as friendly to web developers as possible to facilitate adoption and interoperability. UMA's first design principle is "Simple to understand, implement in an interoperable fashion, and deploy on an Internet-wide scale."

 4. Full Functionality - Positive-Sum, not Zero-Sum

This principle is important for including all parties affected in the conversation. Often, user empowerment equates to service disempowerment, and this is why we see little uptake of some privacy enhancement technologies.

UMA strives to offer benefits to all of the actors in an online service ecosystem. For example, a user can benefit from being able to define who is in her "family circle" exactly once, then reuse that definition across sites to control sharing of the data she manages in all those places. And a site can benefit from outsourcing user data access control to a centralized authorization hub for the same reasons that it might outsource user login to a social sign-in identity provider: to concentrate on what it does best, leverage a third-party service's special expertise and knowledge, and get more functionality with less effort. Where authentication has seen innovation through standards-based social sign-in, authorization for the purpose of privacy could see innovation through standards-based "social access control".

Further, UMA's draft Binding Obligations specification creates a starter set of obligations by which every party to an authorization interaction is bound, for mutual benefit and protection. It is anticipated that trust frameworks built on top of these obligations will set rules for all the parties participating in an access federation.

 5. End-to-End Security - Full Lifecycle Protection

Privacy has a synergistic relationship with security and other system controls. This principle recognizes the important role of comprehensive protection.

UMA applies protection at the interface of resource owner and requesting party, and by virtue of having this touchpoint, could enable some elements of lifecycle protection by enabling the authorization hub to keep an audit log of access policies, requests, approvals, and revocation during the span of time that a resource is under its protection. A user could then assess the extent of sharing of his personal data at any one time. Using UMA's ability to extract "promissory claims" from requesting parties, the user could impose downstream data usage controls by extracting "chain of confidentiality" promises. (As a set of "access control and privacy APIs" applying only at the resource server's Internet interface, UMA anticipates that the resource server itself will be responsible for all required back-end security defenses that protect the resources at rest.)

 6. Visibility and Transparency - Keep it Open

Proprietary access control mechanisms used by online services do nothing to aid this principle, and often give cover for improper sharing. At the same time, service operators do struggle to find cost-effective ways to increase user visibility of data sharing.

UMA's draft Binding Obligations specification is designed to map proper behavior by all the parties to their protocol-level actions, which are testable for interoperability and auditable for non-repudiation. This mechanism strives to maximize enforceability of behavior norms, given that data sharing typically has few other mechanisms available for restricting downstream data usage. The binding obligations provide the underpinnings for further trust framework agreements governing entire access federations. Such agreements typically define assessment, accreditation, enforcement, and liability mechanisms.

7. Respect for User Privacy - Keep it User-Centric

This principle captures an admirable aspiration. The challenge in meeting it comes when online services serve users that are not themselves service customers; as has often been noted, they are instead the product. This sets up conflicting and even perverse incentives. Thus the irony of Facebook – with its particular business model – being pressured to have a user-centric privacy policy.

As explained in the Binding Obligations specification, "UMA shares with NSTIC a priority to enable and empower individual people in the context of their online interactions." While striving to have full respect for every party taking part in a sharing interaction, UMA nonetheless exists to give users sharing controls and options they've never had before.

Privacy by Design for Software Engineers

To the extent that UMA supports PbD principles, it can benefit software engineers developing online services intended for use by individuals, by offering the option of making these services UMA-conforming resource servers. The draft PbD for Software Engineers specification describes additional ways to enhance privacy by design in the app development process.

  • No labels