The care and feeding of online relationships

The requirements I’ve been talking about lately in this space aren’t impossible to satisfy. What solutions are here today or on the horizon?

For web services that enable reduced data disclosure and can operate when we’re not around to tell them how, Liberty ID-WSF is a strong match. And its Interaction Service capabilities are a strong match for adhering to user-configured ways of obtaining consent or additional info, when doing an action “silently” would have been outside my established policy.

For encapsulating an individual’s policy in a usefully machine-readable way, an interesting technology stack involving XACML, WS-Policy, CARML, and AAPML is starting to appear (including in open source) that could turn out to be very helpful (Identity Rights Agreements, anyone?) — if we can figure out where in the process human beings can actually apply it and make it stick.

That last “if” is where a lot of exciting stuff is happening. Some folks have been working on an approach called “feeds-based VRM”, a name reflecting both the VRM use cases it first tackled and the Atom feed-based (lightweight pub/sub) architectural approach it uses. Alec Muffet published an excellent paper on the subject in February (also see Adriana Lukas‘s Power to the Persons introductory post) that shows how robust and powerful this model could be.

In my NZ talk I essayed an explanation of the approach using this diagram…

…and posed these questions: What if…

• We could host our own digital data, for sharing only with our chosen online partners, on terms we set?
• We could create the data however we wish –- once –- then share it “in bulk”?
• Partners could grab the freshest version at any time?
• We could audit usage and cut off “bad partners”?
• We could combine this with existing identities –- silo-based, traditionally federated, OpenID -– and identity-aware services?
• We could build an ecosystem for this on the very thinnest of standard Web technology layers?

ID-WSF could do the first few what-ifs, I think, but today provides no solution for cutting off bad partners and today is built on a fairly heavy stack that can’t be called a “thin Web layer” (though the work Hubert has been blogging re: RESTful ID-WSF may change that picture). I believe creating feeds that are (a) custom and (b) access-controlled can potentially satisfy all the what-ifs. It’s a living embodiment of a relationship-forging stage which, when combined with clever auditing, whitelisting, and the like in a highly usable interface, has the ability to let us modify and even terminate data-sharing relationships over time. User-driven indeed!

(By the way, Alec has said he doesn’t want to include policy metadata as part of the feed mechanism for now — he’s keen to vet the basic technical approach first, which makes sense to me, and let more sophisticated applications emerge later. In any case, the very act of customizing a feed for a particular recipient contains some policy within its essence, which is one of the exciting things about it.)

It’s great to see that Adriana et al. have, just today, expounded on their full-size vision in a post and public paper that you’ll definitely want to check out if your interest has been piqued so far. Note that the personal data store component has been dubbed the “Mine!”, and that this component gains new emphasis vs. the “FeedMe” on-the-wire component compared to the original paper. (I’m not sure I buy the full-size vision for the Mine component, but am keenly interested in the ecosystem effects and UI usability of the FeedMe component — and I swear it’s not just ’cause I suggested that as a name! :-) )

No doubt next week’s IIW event will provide great opportunities for digging into all this in more depth. And the Mine paper advertises the mailing list for what will be an open-source Mine project.