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

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

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?

As Scott Cantor observed in the recent Project Concordia workshop, we’re getting to the point where browser-based single sign-on Just Works. Now it’s going faster, and faster, and faster… (Hey, don’t some G’n'R tunes do that?)

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.”]

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

(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.

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…