Case Study: Subscribing to a Friend's Cloud

Introduction

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.

Problem Scenario

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.

...

Alice has no way to orchestrate access authorizations across her entire personal cloud. The CloudOS "authorization service" function is missing from the picture.

Proposed Improvements

UMA makes the following solutions possible.

...

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.

Solution Scenario

In UMA trust model terminology, this scenario is considered to be in the category person-to-person. Alice is the Authorizing Party, 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 authorization service of the CloudOS would be an "authorization manager" or AM in UMA technical terms, run by an Authorization Manager Operator.

...

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).

Solution Flow

This scenario uses classic UMA. See the swimlane diagrams for details.

Solution Demo

The UMA group's Google TechTalk video from February 2012 demonstrates how the SMARTAM authorization service could be used to provide subscription request workflows.