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?