As part of his CloudOS series of blog posts, Phil Windley describes how people who have "personal clouds" may want to subscribe to each other's clouds in order to get various kinds of access to them. UMA has a role to play in enabling Alice to gain access to feeds of Bob's information sourced from various protected cloud-based hosts used by him, and vice versa – without requiring a perfectly symmetric sharing relationship between them.
Phil posits that if people are to have functional, effective personal clouds, they need a CloudOS that manages essential functions. One of these functions is an authorization service to enable selective access to cloud data, and one of the use cases for authorization is the ability for Bob to request various kinds of access to Alice's various resources (and vice versa). Alice's personal cloud may include resources as diverse as social networking accounts and the online controls for physical equipment such as cars and DVRs.
Today's systems for enabling sharing of online resources have the following downsides.
Each host of Alice's resources has its own proprietary, incompatible way of letting Alice control sharing. For example, Flickr has an arcane system for revealing non-public photos to selected people, who either surf around on guest passes or become Flickr members who can have "friends" or "family" status according to Flickr account holder Alice.
In some cases, the method of controlling access is highly insecure. For example, Flickr's guest passes use URLs that are "private" in the sense that they're emailed directly to the recipient but are not actually protected from public access in any way, should the URL escape into the wild.
Hosts that use OAuth-based access authorization, such as third-party apps that enable Alice to "subscribe" to her own Facebook account, do not enable sharing with Bob; they are intended for Alice's use alone, with different sets of apps in the picture.
Hosts that use OAuth-based protection also tend to give Alice limited choice about what access she can grant. While some OAuth-protected apps such as Twitter have begun to enable Alice to "un-check" OAuth scopes that she does not want to grant third-party apps, those apps have an incentive to ask for as many scopes as they can get away with; Alice is not in a position to dictate the terms of access, so she is not a true peer in access negotiations.
Alice has no way to orchestrate access authorizations across her entire personal cloud. The CloudOS "authorization service" function is missing from the picture.
UMA makes the following solutions possible.
Each of Alice's hosts that make up part of her personal cloud can outsource the means of controlling access to a centralized authorization service that Alice can select, making that authorization service just another interchangeable element of her CloudOS.
Alice's authorization service can present to her a unified and feature-rich means of controlling access to all the hosts in her personal cloud, even reusing access policies such as "share only with my immediate family members" across multiple resources at multiple hosts without any additional work.
Each host effects access control not by using "private URLs", but by requiring requesters to present their authorizations. This means of security is much more rigorous and auditable.
Alice can set up policies that enable Bob to gain access to whatever elements of her personal cloud she wishes, with that access being constrainable along whatever dividing lines each host makes available. For example, if the host stores Alice's photos and sets up access scopes such as read vs. edit vs. print, Alice can grant Bob access for any subset of these scopes.
Alice doesn't need to be online when others attempt access to her resources. If she has set up policies to demand that these others "prove their worth" (for example, requiring Bob to demonstrate that he is in control of the "bob-at-gmail" address), her authorization service can function entirely in silent mode to give Bob access to the requested resource.
Alice's authorization service can make a feature available whereby unsolicited attempts to access her resources generate a subscription request. Alice can then field these requests at her leisure in approval-workflow fashion when she next visits the service.
In UMA trust model terminology, this scenario is considered to be in the category person-to-person. Alice is the resource owner (technical term) and Authorizing Party (contractual term), acting on her own behalf, and Bob is the Requesting Party, also acting on his own behalf. (In his turn, Bob would serve as the Authorizing Party for his own personal cloud, and Alice might very well be a Requesting Party seeking subscriptions to it.) The CloudOS-enabled authorization service would be an "authorization server" in UMA technical terms, run by an Authorization Manager Operator. Every cloud-hosted source of Alice's information would, in UMA technical terms, be a "resource server", run by a Resource Server Operator. The software application Bob would use to access Alice's cloud info would be a "client".
In UMA's rendering of Phil Windley's personal cloud conception, her UMA-protected cloud would include anything for which:
The login account is required in order to enable Alice to introduce the host and the authorization service, and also to enable Alice to manage which resources she wants shared or protected by the service (to the extent that the host makes this feature available).
This scenario uses classic UMA. See the swimlane diagrams for details. A YouTube video provides a demo of sample apps, showing how the individuals in question might experience these processes.
The UMA group's Google TechTalk video from February 2012 demonstrates how the SMARTAM authorization service could be used to provide subscription request workflows. (Note that it uses old UMA terminology: authorization manager, host, and requester rather than authorization server, resource server, and client.)