Tag Archives: VRM

Close encounters of the third kind

There are three obvious patterns for how humans and identity-enabled apps can interact.

The first pattern is human-initiated. This is when you reach out to an app — say, visiting a browser bookmark for Dopplr — in order to use it in real-time. These days, often you log in somewhere else (at some identity “provider”) so that the app you want to use can “consume” information about you to do the job you want. Think single sign-on and login-time transfer of data about you.

The second pattern is app-to-app. This is when an app, having been previously introduced to other apps that are sources of info about you, talks to them about you on your behalf, even if you’re not around — like when FireEagle and Dopplr share your location info. But it’s done in a way that’s privacy-enhanced and sensitive to your preferences. OAuth has been great for demonstrating why this is valuable, and of course it’s the central point of Liberty Identity Web Services too. (Check out Paul Madsen’s helpful series comparing OAuth and ID-WSF.)

I’m thinking it’s time for the pattern of the third kind to get more attention: app-initiated. This is when an app needs your attention and reaches out to you to get consent, or data, or an acknowledgment of receipt. Today in the wild, we see lots of notices sent through email and SMS (package tracking, flight cancellations), but don’t have a good way to set up our preferences for the way apps request action on our part. The Liberty Interaction Service could be a part of the solution.

This third pattern seems absolutely key for managing privacy robustly, assuming you’re properly auditing the app-to-human contact and its results. Here are some of the scenarios that have come up recently.

Emergency contacts: When you travel internationally or sign up to get treatment from a doctor or surgeon, you usually have to provide an emergency contact. It would be better to do this by telling apps how to look up how to contact the person in question, rather than giving phone numbers or email addresses that can go stale or be inappropriate (too synchronous or asynchronous, or too unlikely to elicit a response) for a particular purpose. This would also be useful for a variety of delegation-type tasks, like indicating who’s willing to sign for packages while you’re away — especially in conjunction with the Liberty People Service.

Integrating identity selectors: This was suggested by Pamela Dingle (in response to my critique of “classic” identity selector behavior at Burton Catalyst). Provision your Interaction Service to know how to fire up your identity selector when you’re online, so apps could use it to initiate contact with you to gather consent and get new claims. Cool idea, and maybe worth exploring a profile someday; I ended up mentioning it at a meeting of the Web Services Harmonization SIG we we wouldn’t lose it.

Health research: Gather consent when new uses of previously collected data arise (aggregating study data in a privacy-sensitive way), and gather more data over time for longitudinal studies. This idea came up at the Project VRM workshop in Boston, and it’s useful for not just health research but pretty much all VRM-enabled data-sharing scenarios — it can increase an app’s ability to gather less data on initial contact (the fewer required fields, the better!), and thus a human’s comfort level with choosing this vendor.

I get the idea that a lot of my Liberty colleagues haven’t gotten excited about the potential of the Interaction Service the way I do. Am I nuts? Am I missing other juicy use cases? What would it take to get something like this working in a standard way with things like OAuth?

Venn and the art of data-sharing

I come to the VRM world from a tradition (if that’s the right word) of digital identity management. With so many organizational efforts swirling around trying to create identity layers, data portability, metasystems, and suchlike, I kept noticing that there was a common set of bedrock features involving human beings and the networked apps they use. And, yes…I saw it as a Venn diagram.

I’ve been trying this out on folks for a while now, and used it in a couple of recent talks, particularly my Gnomedex 8.0 one. Here’s my thinking behind it. (This is more than a straight Venn because of the metaphorical shadow thingie. Couldn’t resist! My web services Venn “cheated” too.)

Digital identity management is, at base, about identification so app usage can be correlated and audited, authorization to provide secure controlled access, and personalization, all counterbalanced by privacy. It has a strong individual (single-human-to-app) bent, though sometimes it involves Shibboleth-style scenarios where you mostly track anonymous group members rather than unique people.

Social networking is about building feelings of connectedness and offering the benefits of collaboration, such as crowdsourcing. Social apps focus on human-to-human relationships, but to provide infrastructure for this, they have to do plenty of the human-to-app variety. Social networking today stresses revelation of personal details (the OpenSocial best practices doc is one example) much more than it stresses privacy, though the latter is an increasing concern.

VRM partly involves what could be called restriction of data flow — undoing vendors’ grip on users’ info in a way that’s familiar to proponents of privacy-enhanced and user-controlled IdM. But other VRM scenarios involve enhancement of individuals’ opportunities to share personal information, for example by issuing a personal RFP to potential vendors. As Doc Searls has said, VRM is “personal first and social second”, so it seems to have a closer kinship with digital identity but could provide new social opportunities as well.

Each area has its unique features. But all share a common trait — differentiated app behavior depending on special aspects of you (whether this comes from attributes, claims, and transactional details in IdM; social graph data and user-generated content in social apps; or proactive requests and other personal data offered up in VRM). And to deliver on this promise they all share a common requirement — knowing more about you, with permission.

By contrast, where apps know about you through improper data gathering or aggregation, you get digital shadow effects — like direct marketing that is distinctly not permissioned or welcomed. Today, permissioning is still something of an art rather than a science, hence the title of this post.

We have a number of infrastructural options that more or less satisfy the requirements of the intersection, and later I hope to provide further thoughts on that. For now, I hope you’ll let me know what you think of this new instance of John Venn’s invention.