Phil Windley's conception of a personal cloud includes not only a fully distributed personal data store composed of many data sources, but also a fully distributed CloudOS that includes an authorization management function. This case study describes how an UMA authorization server can serve in this role for letting Alice subscribe to elements of Bob's cloud, and vice versa.

By and large, purveyors of online services and resources have fallen short in accommodating the accessibility requirements of many of the people they want to serve. The problem is challenging but its urgency is undeniable. This case study suggests that UMA could address one of the core challenges: Providing users the ability to express personal accessibility needs and preferences and to control the release of subsets of that information so that online services can tailor themselves accordingly.

The very first UMA scenario accepted was “Sharing Trustworthy Personal Data with Future Employers”. This scenario overlaps greatly with the concept of Higher Education Achievement Reports (HEARs) that are planned to be introduced at Newcastle University. The HEAR is intended to provide a single comprehensive record of a learner’s achievement at a higher education institution such as Newcastle University. It will be an electronic document, which will adhere to a common structure and can be verified by the academic registrar or equivalent officer. However, HEAR leaves unspecified how such document is shared outside of the institution. The SMART Authorization Manager (SMART AM), the first UMA-compliant authorization server that allows end-users to easily compose very flexible sharing settings for their online data, has presented an opportunity to solve the HEAR challenge.

Personal information sharing is an emerging trend for online daily life activities, including interactions with financial credit institutions. This case study analyzes a specific scenario for a financial credit interaction for an online personal loan request. An individual can fill out a loan application by authorizing the release of trustworthy financial information from multiple sources.

State health information exchanges (HIEs), having adopted standardized secure (Direct) email for their providers are now drafting RFPs for patient-authorized aggregation, discovery and transfer of health records. They will seek identity management, record location and access management services that are simple, cost-effective and likely to be supported by EHR vendors either voluntarily or as a result of federal mandates. Some momentum in favor of UMA comes from the significant likelihood that OAuth will be part of EHR incentive regulations in future years.

Today the emphasis is on data aggregation; in future we assume it will switch to controlled access to distributed data instead (where sometimes data will be distributed in upstream form but aggregated in downstream form). Patients in question will have an online presence (e.g., can log in to patient portals etc.) in future. Even in cases where patients can’t control sharing of their data by others, they must retain the right and ability to monitor it. UMA can play a role in solving some problems of a Relationship Locator Service, and can aid other more complete solutions by providing common access control and authorization plumbing. (Working document is visible here.)

A school (or school coalition) wishes to make available an resource sharing infrastructure to parents that would allow them to share their personal/family resources as well as create "digital communities" consisting of a group of parents.

Although UMA's primary use cases have centered on individual people, the "users" who managed access to their own online resources, the UMA notion of authorization as a service also has relevance to modern enterprises that must secure APIs and other web resources in a developer-friendly way.

It is valuable to enable enterprises to centralize their policies and entltlements (scope generation) in an authorization server that they run, letting each SaaS vendor with which they contract run a resource server that respects those entitlements.

When multiple people need to use the same web app, meaning that the resource server and the client are the same application, there are both optimization opportunities (because of the colocated entity) and interesting use cases (for example, household accounts representing multiple people/identities).