The three faces of user centricity

I had a dilemma this year when putting together my XML Summer School talk on federated identity technologies. Many of the delegates are IT-savvy but not familiar with modern notions of digital identity, much less with the bleeding edge of technology development and exploration, so I wanted to give them a useful sense of what’s necessary, what’s cool, and what’s still — or now especially — tricky when you sling identity across domains.

At this point, one can’t do justice to this topic without tackling “user centricity”. But since the term is used so imprecisely, I felt compelled to try and add some extra rigor so that delegates could measure their own situations against the state of the art. The exercise of observing how people wield “user centricity” led me to develop three use-case types.

(This post was getting wicked long, so I put the details after the jump. I’ve also uploaded the rather large PDF of my slides, which expand on many of the points I’m only touching on briefly here.)

Here are the three types, each with a handy nickname.

1. Me generation: The metaphor governing this one is user as web resource, taking part in identity-based interactions as a first-class web (Web 2.0! Participation Age!) citizen. You become the ultimate arbiter of your own digital identity by hosting it on a website of your choosing, which might include even a website whose every aspect you personally own and control (a feature that brings interesting trust challenges), to the point where your “handle” is a URI and the resource it resolves to is “you” in some sense.

2. Trust no one: Here the metaphor is user as client device. For the ultimate opportunity to control data sharing and limit it even when talking to your own identity provider (for example, disallowing your IdP from knowing which service providers you patronize), all information about you flows through the hub of a physical thing that you personally control. This one resonates most strongly with Rich Salz’s point that “You are your key”, since such a device with your private key provisioned on it represents you directly, though this can get gummed up a bit when there’s a many-to-many relationship between people and the devices (and keys) they use.

3. Do what I mean: This one is broader and more philosophical, with simply user as human being the closest metaphor. Computer applications ultimately exist to serve us and should ask about and respect our wishes around sharing and privacy while they provide worthwhile services — even when we can’t or don’t want to be online. This is achieved at least partly by “nontechnical” means (for instance, whether a service provider actually adheres to its stated privacy policy once it has gotten hold of some of your attributes).

I also presented a variety of more mundane use cases involving federated identity, such as single sign-on and its variants. And I explored a series of challenges, including both first-order “negative use cases” such as the problem of web authentication weakness, and second-order consequences of other choices such as the problem of identity provider discovery when single sign-on is initiated at the relying party.

I then gave quick tutorials on SAML, OpenID, and CardSpace and analyzed them against the full set of use cases and challenges, offering the modified Venn diagram below — as captured live by Paul Downey! — in summary. (Here’s the original Venn if you want to compare them.)

Okay. That was what I presented (well, that and way more detail in 73 slides than I could fit into my allotted 90 minutes). Here are additional thoughts.

Terms and concepts: Each of these faces of “user centricity” could honestly qualify for the term. However, while type 3, being more abstract, might be compatible with each of types 1 and 2, the first two types will tend to struggle for dominance — something that’s true regardless of the particular technologies that might meet the use cases.

What makes the situation more confusing is that OpenID pretty much claims to define what I’ve called type 1 user centricity (that’s why I used the phrase “the very definition” in the Venn), and likewise CardSpace claims to define type 2, and a lot of “user centricity” sightings in the wild tend to stick stubbornly to one interpretation or the other without explanation. Many other “user centricity” invocations silently lump together the two meanings, seemingly in a bid not to offend either technology by leaving it out. Oddly, not as many people seem to mind offending the SAML or Liberty technologies :-), even though they’re strong contenders for solving “user centricity” use cases and challenges in their own right.

Assessing technologies against use cases: It’s still good practice to figure out what goals you have before selecting technologies. Looking more closely at CardSpace, for example, my analysis would say it specializes in two things: “trust no one” (type 2) user centricity and solving the web authentication challenge. The latter is orthogonal to user centricity concerns — everyone’s got this challenge, even if they’re an evil, scum-sucking, account-jealous web app managing local identities. And even for web app and community providers that are prepared for their users to be central-for-some-definition-of-central, “trust no one” (which is pretty tricky to achieve) may not apply to the needs of all concerned — but CardSpace could still be useful in their circumstance for phishing resistance.

Self-asserted cards do, of course, give CardSpace capabilities that are “me-generation” like, though a client-based identity selector isn’t set up to function as a first-class web citizen as far as I can tell. The Liberty Alliance’s Advanced Client specs (which I didn’t cover in my preso) seems to get closer to covering such ground.

User as offline device: Paul Madsen covered Liberty Web Services as part of his talk, covering the notion of app-to-app interaction in which your identity plays a part. The ID-WSF framework offers various clever identity services for this, and accepts the notion of pre-set policy to make these services accede to your wishes. One of these services, the Interaction Service, stimulated a fair amount of interest; this is the personalized service in which a user sets up ways for services to contact her — like texting a particular phone number — when she’s otherwise offline, in case her consent or other information is needed. I remarked that it could be described as user centricity by polling. :-)

The struggle for primacy: The metaphorical tension between the user as a web resource and the user as a client device expresses itself architecturally. If you don’t take a lot of care and think through what you’re trying to do, mixing technologies that work in these two ways may lead to user confusion and maybe even limitations on the ability of the solution as a whole to meet the use cases you have. Since a lot of folks are working right now to mix technologies, this is a big consideration. Here are some real-life examples to illustrate the point (with no criticism or disrespect meant).

• Project Higgins is building support for hosted identity selectors (shades of “me generation”), requiring a user — as far as I can see — to trust the web app that hosts the selector. Does this meet “trust no one”, with its strict unlinkability requirements? Anyone who wants this use case solved will have very rigorous privacy and security needs (which I’m not even sure Microsoft’s CardSpace implementation achieves spotlessly yet), and such folks would want to see a full accounting of these before deploying this as a solution.

• SignOn.com is allowing CardSpace authentication (so far with self-asserted cards only) into an OpenID account. This looks a lot closer to using CardSpace only for phishing resistance in simplified sign-on, kind of like getting one of those OpenIDs that provisions a self-signed cert into your browser, rather than “trust no one”, since any actual use of a SignOn.com identity would expose your relying-party activities to that IdP in the normal OpenID way. But there are hints of “user as client device” here, in that the card you use is holding some of your attributes — so which one “is” the user, to a first approximation? Is this just a case of federating two accounts where both are equal? Things would get even more interesting in the case of managed cards, where the identities associated with the originating identity provider would be in a much more bounded identifier namespace and the IdP might even be subject to privacy regulations. What would it mean for a user to unilaterally choose to federate such an identity with an OpenID one?

To summarize, users and deployers really do need to know what you’re talking about when you promise or invoke “user centricity”, and we’d all be better off qualifying the term every time we’re tempted to use it. (Now, don’t go matching Eve White, Eve Black, and Jane to the different types… :-) ) The danger is that, by substituting a quick technology decision-by-proxy where a use case selection process should go, we may drift away from solving the largest possible intersection of users’ wishes with providers’ requirements, obligations, and abilities.