Relationship, authorization, make up your mind

Having been properly chastised by Paul for creating some confusion around the “relationship manager” (RM)/”authorization manager” (AM) terminology, I want to make amends, explain, and ultimately jump into the very interesting social-authorization discussion that Paul and George have been conducting.

In a nutshell, an RM is an application, and an AM is a ProtectServe protocol entity. An RM at a minimum has to serve as an AM endpoint but could also provide SP and even Consumer endpoints.

We’ve formally conceived of an RM app because data-sharing relationship management is only valuable if we have some app saving and applying a user’s desired policies, auditing and archiving a bunch of information, and other tasks entirely out of the view of other “computer entities” in the picture. A computer protocol is important for interoperability but, obviously, isn’t sufficient for success; app functionality and user experience have to be given equal prominence with interop.

A “minimum RM” could be represented like this.

The gray “archive” box stands for the pieces of RM functionality that don’t have a protocol-compliance job. Our mockup screenshots show how such an RM could be used — managing the access to calendars that live at a “foreign” online calendaring SP.

Of course, all these foreign SPs could host any sort of data on the user’s behalf. One of those SPs could be, say, a web app that helped you package up your various sets of resources (living wherever) into convenient Atom feeds. Any resources referenced in feed entries, or even buried inside other types of resources (like imgs inside HTML pages), might reside at different SPs, such that the Consumer would have to interact with a bunch of SPs in attempting access (just as it would have do GETs against a bunch of different servers today).

A fancier RM could be represented like this.

This RM serves as a ProtectServe SP endpoint, providing on-board serving/packaging of some resources, along with being an AM. For example, let’s say you self-host your RM at your blog, and your RM plug-in has a feature for storing “self-asserted” info right there. It also offers Atom packaging for, say, typical items needed during e-commerce account registration: name, default shipping address with phone number, and credit card data.

The RM might optimize the implementation of AM/SP interactions in the case of its “local” SP because everything’s internal to one app, but all “foreign” SPs have to be treated according to the formal protocol, and any auditing and archiving should be done for all SPs, including the local one.

Here’s an all-singing, all-dancing RM.

Now the RM functions as a ProtectServe Consumer too. This is much more futuristic territory, but: if it’s useful for a person to track the data she shares, couldn’t it also be useful to track the data that others have shared with her, and the terms she had to meet to get that latter data? If the protocol could successfully handle payment demands and receipts and such, we’d now have a peer-to-peer data-commerce network.

This deployment scenario offers one way to handle the social-authorization use cases being discussed by Paul and George. Bob’s RM (in the role of a Consumer) could interact with Alice’s RM (in the role of an AM) to register to get future authorized access to Alice’s resources (hosted at whatever SPs). Alice’s RM could perhaps become an OAuth (or ProtectServe!) Consumer of some SP that supports the PoCo API, which could — especially if extended in the way George and Paul have been discussing — help Alice manage her universe of potential data recipients in a standardized way. At the very least, her RM might offer on-board functionality to organize sets of Consumers by hierarchy, tagging, or other means, which could control authorization policies en masse.

One final note: Nothing in the ProtectServe protocol prevents a user from deploying multiple RMs, something that could be an important tool for empowerment, data portability, privacy, and so on. Depending on the use cases you want to cater to, however, this might have protocol implications; today our design doesn’t allow SPs to parcel out authorization tasks to different AMs for different subsets of a user’s resources.