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.

Practical human-centering and VRM

Previously, I argued that people are not going to sit still for the heavyweight login-and-consent processes that we IdM professionals are starting to pile on them. They will find ways of getting around the onerous series of screens, clicks, and what-have-you we’re imposing.

True confession time: I’m probably the biggest user of Sun’s OpenID Provider in the company. I use it to log in to the Project Concordia wiki, and I’ve been trying to be a good do-bee and use it consistently. A while back, the Sun OpenID server went down temporarily, and I had edits to make. What to do? I discovered that a local login, set up for me when we were getting the wiki ready to go live, was still around and the cookie was still working, so it would auto-fill my username and password. Ooh, I can hit Return once, no redirects, no having to say that I really do want to send my info to that RP… It’s like crack. Even I have a hard time going back to the “better” OpenID.

I also argued that people currently have little power in setting up data-sharing relationships with sites, because there’s no window for them to do anything but accept the data-sharing terms offered (or reject them and not get to use the service).

The Vendor Relationship Management folks were really the first to bring this issue out of the closet. Yes, Liberty ID-WSF tries to enable a marketplace in privacy-respecting personalized services, but it tackles plumbing — whereas VRM digs into individuals’ needs in an evocative way that flips an “I want that!” switch in people’s heads. Suspecting that few people in the NZ conference audience were familiar with VRM, in my talk I essayed a quick explanation using a two-part diagram that will be familiar to devotees:

A few people actually gasped and applauded when I got to the green arrows — so I hereby pass the kudos on to Doc Searls and the entire Project VRM gang! (And congrats on the recent EIC Special Award as well.)

There’s a point about timing that I touched on before but wanted to dive deeper on.

The times when I’m motivated to log in to an online service have a not-hugely-strong relationship to (a) the times when the service needs to do something interesting on my behalf (such as determining whether to allow Bob into my calendar to see or add information — he’s logged in, but why should anyone expect me to be?) and (b) the times when important info about me changes (such as when I move house).

Project VRM has developed “change of address” as one of its seminal use cases, and this temporal mismatch helps explain its appeal. Having to do a regular login process to tell fifty online services you’ve moved is the worst possible architectural choice if we care about usability or fairness or data freshness.

This issue lays more of the groundwork for the requirements I proposed earlier:

• Services that can provide aggregate value to us even when given a small and disjoint set of our info to work with for privacy reasons
• Services that operate according to our data-sharing and -usage preferences all the time without bothering us, but know how to contact us in extraordinary circumstances
• A relationship-forging stage or function or ceremony, apart from routine login-time, at which we can craft such policies and get them to stick

(Paul, I knew I could count on you to steal my extremely delayed thunder. :-) Continue to steal away while I work on one last post…)

Another cake of type “Birthday”

Cool! And this one’s even got I18N support…

(Thanks to Paul Bryan for the tip! If you’re curious, my old one is here.)

Imperatives driving human-centered identity

In my recent talk on everyday identity, I suggested that login-time consent to data sharing is not a great example of human-centered design.

Even if we had already figured out the perfect ceremony for real-time consent or developed the best login interfaces, individuals still tend to be disadvantaged in the federated identity balance of power — that big flashing “I Agree, Here’s My Data” button might as well read “I’m Over a Barrel, So Go Ahead and Take It Anyway”.

David Weinberger has this analysis (do read the whole thing):

Since just about every vendor on the Web would like to know more about you rather than less, why won’t just about every vendor ask for more information rather than less? It’s all just a button press.

The golfer use case in my slides highlights this issue as well, using InfoCard flows. In real life, my boss was actually asked for his Social Security Number (!) as a prerequisite for starting a new account while trying to book a tee time over the phone. In that communication mode it’s easier to just say “no, thanks” and hang up the phone; with an information card many people might just press Return to get it all over with.

So how do we get to truly human-centered design? We take into account people’s real tendencies and desires, and try to bake these into identity ecosystems in a way that redresses the power balance.

Here are three common tendencies: new-relationship energy (the conscious effort you’re willing to invest when something is new vs. familiar), the efficiency imperative (the impatience with annoying multi-step interactions that makes you stop paying attention), and the self-revelation imperative (accepting that it’s legitimate to choose to share data about yourself when it gets you something of value).

Based on these, here’s what I suggest:

• Let’s reduce the routine gathering of data-sharing consent at login time — it doesn’t materially empower individuals and, as a bonus, it annoys them. Instead, we should find a way to let people configure data usage policies at the time of establishing relationships with online partners; without this, people are stuck with accepting others’ terms and have no window in which to impose any of their own. In essence, we need to be thinking about the game theory of identity! To quote David Weinberger again:

  [I]f we’re going to make it easy to give out our personal information, we ought to be thinking about the norms, market forces, or rules that would make it harder to ask for that information.

• We also need to enable applications to get something useful done when handed only a tiny slice of someone’s personally identifiable information, and use pseudonyms and other privacy measures zealously when coordinating among applications. If we can’t enable this, we’ll continue to be asked for way too much information because it’s the apps’ path of least resistance.

• Finally, we should reserve user-approval loops for extraordinary circumstances, ideally those dictated by people’s own preference settings — which allows identity-based app behavior to go on in the background (e.g., while we’re sleeping, windsurfing, or whatever) as appropriate and to grab our attention when we need it.

(More thoughts soon on some solution opportunities in all this…)