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…)
