Power to the People - Data Sharing Power That is - UMA Draft Recommendation Released

After more than a year of hard work, UMA WG (User Managed Access Working Group ) announced the draft recommendation for UMA protocol.

UMA is a communication protocol and is defined by its formal FAQ as

User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is a protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.

Former colleague and current lead of UMA WG @ Kantara Eve Maler gave a very good presentation last year at Cloud Identity Summit that you can see here. There is also a Webinar on July 13.

To explain UMA and what it tries to do, I feel an example works the best (the spec and the terminology are not the easiest way to understand UMA).


Alice is an on demand speaker and celebrity chef, she travels a lot. She uses 

•         A Calendar application,
•         A general purpose social networking site
•         A niche professional networking/community site of food enthusiast
•         Owns a selling account with a popular marketplace for high end kitchen gadgets and appliance.

(All above service are called resources and Alice is a resource owner)

She uses the services of several useful applications:

• Travelers Guide: An application that recommends restaurants and activity in all major cities based on Alice’s preferences of profile on general purpose social network.
• Chef Tracker: An application that notifies Alice’s professional connections and fans when she is coming to their town and where she speaks.
• Merchandise Lister: A web application that lists Alice’s autographed recipe books and limited edition appliances to multiple online channels including the marketplace.

(All above are called consumer or requester)

Alice can grant authorization to the three applications above using OAuth directly. In this case the four resource servers (Social network, professional network, calendar server and marketplace) each maintain Alice’s authorization to respective application(s).

However Alice (a busy professional) does not have a centralized and easy to access location where she can see all the authorization she granted to different applications.  It is true that each resource server maintains a record of Alice’s granted authorization, but since each server has a different way to display the authorization (and they often buried in random places around the resource server) it is unlikely that Alice ever gets a clear view of how different applications are using her information.

Or alternatively, Alice can go to a one server – called Authorization Manager (AM) – and give authorization to three applications at one place.

The benefits are clear. Alice can literally see all applications that access her information (and the extent of their access) at one place. For example Alice can limit the access of Travelers Guide to one week (during which she travels)  

To understand why UMA is important and what UMA does, we should first understand some of the implicit assumptions (or some may argue simplifications) behind OAuth 2.0 authorization.

OAuth 2.0 does require an authorization step, where the “resource owner” authorizes a consumer application to access a resource on his/her behalf. This authorization however requires and assumes:

-       

• Authorization is performed at the time of resource access by consumer
• Resource owner should be present to grant authorization
• Authorization assume that future access to resource is always made on behalf of resource owner  by requester (consumer application) – not on behalf of someone else (say Alice’s assistant in the example above) - This is very important point and deserves its own post :-) OAuth scope does not cover this class of use cases at all.

And more importantly in my view (and from giving the power back to people point of view)

•        Resource owner (user) has to keep track of application/consumers s/he has authorized to access various resource on his/her behalf (how many of you know how many application you have authorized to access the collection of your online accounts? And exactly what type of privileges you granted to them? Think about it!)

Now, granted, this is not OAuth problem, by it is the byproduct of individual consumer obtaining authorization to access variety of resources individually.

UMA is set to address all the above with the introduction of a central Access Manager (AM – in UMA terminology) and, the protocols to connect Resource Server and Consumer to AM.

UMA is an ambitious undertaking (in my experience all authorization initiatives are!) primarily because its success depends on whether users (resource owners) can successfully express policies the govern consumer access to the resources owned by them. This is the linchpin of any authorization project I have ever seen or been part of.

Whether UMA is adopted and implemented as a viable product is remained to be seen, but UMA protocol is a firm step in the right direction.

In the next entry, I will focus on UMA model and associated communication protocol among its participants.