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?

5 Comments to “Close encounters of the third kind”

  1. rita 18 October 2008 at 3:38 pm #

    Oooo, App DNA! Love it.
    Clearly you have recovered…your writing is awake.

  2. Eric Norman 19 October 2008 at 2:54 am #

    So if an app reaches out to me. And I have quite a bit at risk if I let it proceed. Then I can ask the app to perform multi-factor authentication, right? I really want to have confidence I’m talking to the app I think I am.

  3. Eve 19 October 2008 at 9:57 am #

    Rita– Thanks!

    Eric– Excellent point. We already have lots of apps reach out to us in email, and of course we risk being phished this way. Mutual authentication is especially important if we’re being asked to take significant action, and there are ways to have the app authenticate to us, such showing that it knows a shared secret.

    One-time passwords sent through SMS are already used in the human-to-app pattern; I can see SMS being used pretty heavily in the reverse pattern, at least to kick off an interaction where you’re fully paying attention. E.g., for complex actions such as the longitudinal study scenario, it might ask you to call a number where you punch in answers to a list of robo-questions.

    One of the reasons I think we need to take the app-to-human pattern seriously is that it turns our decision-making — consent or not? share data or not? — into something more meaningful than the pro forma “click the I Agree button” consent we’re made to do all the time. If you set up a policy to have an app ask you for a decision at a critical moment, its logic must be prepared to do some interesting X if Yes and do some other interesting Y if No. Today, X=Give Service and Y=Refuse Service.

  4. Paul Madsen 20 October 2008 at 8:34 am #

    Hi Eve, perhaps its relevant to point out that both app-to-app and app-inititiated would typically (or always in some spaces) be preceded by a human-initiated interaction – either to get consent or for the user to facilitate setting up subsequent bits.

    Wrt Eric’s point, users are vulnerable to phishing not because they can receive unsolicited app-initiated messages, but because they bear the burden of authenticating the sender. The user’s IDP is better qualified to do this on their behalf.

    Wrt OAuth, where Ive seen it used so far, the pattern would seem to be still human-initiated, its just the message flow is app-to-app. I’ve seen Oauth used for the initial bulk transfer of attributes, but not subsequent ‘syncing’. I may well just not be looking at the right places.

    I love the point you make about today’s (forced) binary decision making for users – thereby allowing for no shades of service. It does suggest to me that apps, in addition to expressing what identity they need, should be also able to indicate the implications of their not receiving it. I dont think IGF covers this ….


    p.s. I love Interaction Service, I do. It’s just that we’re at different places right now

  5. Eve M. 20 October 2008 at 9:03 am #

    Paul– All excellent points!

    I almost wrote about that natural progression in my original post: certainly for consumer/user-driven use cases, human-initiated always precedes and authorizes app-to-app, and app-to-app precedes and authorizes app-to-human.

    You’re right that OAuth is generally used during an ongoing human-initiated session, but I think it need not, and certainly ID-WSF doesn’t assume it. Maybe it would be useful to add the “session” semantic explicitly to this framework (such as it is), to make the set of use cases more clear and maybe even inform IGF (or IGF++) work.