Pushing String

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.

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

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

The Managing Identity in New Zealand conference has been an amazing experience. The organizers did a superb job constructing a uniquely valuable event, reflecting the thoughtfulness that’s present everywhere in the NZ government’s approach to its citizens’ identity.

I hope to have more time very soon to put together lots more thoughts on the many talks and conversations, but for now I just wanted to share the slides for the keynote I presented on Tuesday: The Design of Everyday Identity.

And one additional thought for now: I’m extremely sympathetic to the views of Doc and Adriana regarding the oddity of the phrase “user-centric”. I’ve remarked many times on the problems with assuming that people are always online and in front of a user agent (that is, “users”), and the very word describes people relative to the systems that are supposed to be helping them, which seems backwards — especially since the systems don’t seem to be too inclined to actually help them do what they want to do!

My research for this talk led me back to the classic ideas in Don Norman’s usability work, where he invoked the phrase “human-centered design” starting back in the 80’s. I would happily switch to “human-centered” from “user-centric”, and I suspect it would help us all be more open to the many ways to achieve this goal, particularly if Don Norman’s cautionary tale is kept in mind.

(As always, you can find my presos and papers and such linked from my Publications page. See that page if you want a more extensive bibliography for the talk, and keep an eye out for the conference proceedings paper I’ll be finishing in the next couple of weeks.)

It’s that time again — we’re just a month away from the deadline for the ACM Workshop on Digital Identity Management call for papers.

The theme, as always for this series, is timely: “Services and Identity”. Might Pat et al. be interested in submitting something on accessing attribute services in SOAP and REST environments?

In keeping with its pragmatic approach to identity, the New Zealand State Services Commission is making its identity services friendlier and more responsive to people’s real needs. Part of this is a rebranding effort around “igovt”. Good stuff!

I’ve had the pleasure of working with Colin Wallis, Bill Young, and Danny Mollan of the SSC on various efforts, such as the recent Project Concordia workshop activity. I’m really looking forward to the identity conference in Wellington, NZ next week — not only ’cause I get to experience the locale (though who could resist that??) but also because I’ll get to meet up with these folks and meet many others I know only as disembodied voices or by reputation.

The only potential downside: I heard today that I might not be able to carry knitting needles onto the plane. I can’t seem to verify that with an online source; it looks like they’re allowed. If anyone can confirm or deny, let me know! I should probably take heed of this Plan-B advice…

[UPDATE: Arrgh. Right on my itinerary it says “In the interest of security and safety we would like to advise customers that sharp items and cutting implements of all types and sizes such as pocket knives, scissors, nail files, corkscrews, letter openers, knitting needles, realistic toy imitation weapons, razor blades etc, must be carried in checked luggage only.”]

(BUMPED because the free online copy of the article is now available. Entry originally posted April 10, 2008 @ 10:02 am.)

Drummond Reed and I undertook a fun and productive collaboration over the last few months, co-writing an article on The Venn of Identity for the new special issue of IEEE Security and Privacy magazine (here’s IEEE S&P subscription info).

The issue as a whole looks to be full of juicy stuff, with a good flow from more general topics (our article is a level-setter) to more specific and technical ones. Also, don’t miss the additional perspective Patrick Harding offers on his “dynamic SAML” article.

By special arrangement between Sun and IEEE, I’m able to make the Venn article available without fee. I haven’t gotten a final PDF copy back yet — the publishers are busy at the RSA conference this week! — so if you’re interested to snag it, note that I’ll update this entry — as well as my Publications page — when I get the file. (Update: Here you go!)

(And one more UPDATE to acknowledge the forebears of the Venn diagram since these wouldn’t fit in the article: Gary Ellison, Johannes Ernst, and Paul Madsen. More details on this history can be found in my initial post on the subject. Thanks, guys!)

It’s surprising which “worlds” can work together given a chance:

(See whole photo essay here)

Paul is onto something with the notion of Project Concordia supporting the formation of creoles where we’ve been having to make do with pidgin.

It’s as if the kids, impatient with the limitations of the pidgin, decide to create a real language on their own.

If you were at the recent Concordia workshop, you might have noticed the palpable impatience on the part of deployers there. (If you couldn’t attend, you can have that special being-there experience by checking out the complete workshop notes, which I finally finished typing up last night after returning from my Honolulu Hiatus…)

We’ve got a next-steps telecon tomorrow, and if you were thinking about taking part in Concordia discussions, now’s a great time. So be akamai and check out the wiki for call info and how to join the email list.

Clemens and Gerry comment on a remarkable event: Microsoft shipping sample code…in Java…using a runtime stack the likes of which you have never seen before in a Microsoft product. It’ll be four years this week since the historic Sun-Microsoft agreement, and this sort of collaboration and proven interop is something the teams in both companies can really be proud of.

I tried to comment this morning on Dave Kearns’s post on my “identity bus” musings, but it hasn’t shown up for some reason, so I’ll say a few words here. (Later: Damn, how come I can never manage to say just a few words? Must…channel…Paul…)

I appreciate Dave’s confirmation of the overall goal; good to know I’m not crazy. But “going all Microsoft”?? :-) If I were advocating a particular protocol, I don’t even think that would be a bad thing, but advocacy of that sort wasn’t actually my intent.

I did observe that SAML tokens have had success at meeting one big criterion for an identity-bus-qua-message-bus. SAML tokens are used in lots of places, often with protocols other than SAML’s own. And when it came to another criterion, I “indicted” the SAML assertion query protocol pretty even-handedly with WS-Trust if they’re each considered all by their lonesome. While mentioning services of the sort that add helpful interop smarts (including ID-WSF ones), I even pointed out InfoCard as an great example.

If you choose a common data model for your identity layer, as many have done, there’s a whole bunch of “transform[ing of] protocols and data from one system and schema to another” you can avoid. In this sense, SAML’s “hub format” and a WS-Trust “hub service” are opposite approaches: the more you use an agreed-on format, the less you need transformations for the mere sake of syntactic conformance to another system’s needs. I will cop to advocating SAML2 tokens on this basis!

You might still need token exchanges for lots of other reasons, obviously. A quick test of whether you’ve got a nontrivial one: Would it still be useful for parties that use the same token format all around? In this case, I just observed that writing down those semantics will help get us to a successful identity bus. Imagine the chaos if you asked “RST?” and got any old “RSTR” back.

So, back to music and world peace! Yes, I admit it, I would like to teach the world to sing. But I must also admit that my accompaniment of choice would be (acceptable) piano or (really bad) ukulele, since guitar-playing is not among my skills…