You could take this theme pretty far. Does SAML-OAuth bridging have any elements of arbitrage about it? Is assurance leakage in protocol translation like the lousy currency exchange rates at those little van kiosks in airports? Maybe that’s far enough…

Later: Neat, it’s been cross-posted to the CSO Online blog as well.

Intersection A ∩ C ∩ U might be a video that starts playing the moment you visit a site with sound you can’t turn off … showing you a marketing message that seems eerily connected to your ongoing search for a new car … when you realize the video is of yourself at home looking at car reviews online.

(Cue dramatic music.)

My very first Venn of Identity blog post also included a second diagram, covering something like “identity in web services”. It was little-noticed, I think, because the deployment of the more esoteric pieces of WS-* and ID-WSF was pretty low. I’ve been itching to add OAuth to it, given its wildfire-esque spread. Last week gave me my excuse, and with further feedback (thanks Paul and Dom!), I’ve continued to revise it. So here’s a new version for your perusal (click to enlarge).

As with the original version, the relative heights and sizes are significant: they indicate roughly how voluminous, vertically applicable, and far away from “plumbing” each solution gets. (Unlike the original, however, this one seems to give off a Jetsons vibe.)

Some thoughts from space-age 2009:

OAuth is helping many app developers meet their security and access goals with minimal fuss (80/20 point, anyone?), and by providing for user mediation of service permissions, it is easily as “user-centric” as any other technology claiming the title. It’s these lovable qualities that led the ProtectServe/User-Managed Access effort to use OAuth as a substrate.

ID-WSF still provides identity services functionality that nothing else does, and some folks I’ve been talking to lately still chafe at the lack of more widespread support for these features. But obviously it’s still a “rich” solution vs. a “reach” one.

WS-*, ah yes, what to say?… It uniquely solves certain issues, but do all of them really need solving? My Summer School trackmate Paul Downey had some choice words about this, and his WS-TopTrumps class exercise proved that the star in WS-* really does match everything possible — that’s too much. And trackmate Marc Hadley pointed out lots of benefits you get “for free” with a REST approach, which it was hard not to notice when we all chose to design REST interfaces for his class exercise despite having a SOAP option.

To be fair, Paul and Marc and also trackmate Rich Salz — who has an uncanny ability to explain complex security concepts simply — stressed the value of the core pieces for message security if you’re using SOAP. It would be interesting indeed if OAuth, or extensions to it with the same pure-HTTP design center, were to “grow leftward” to accommodate the use cases covered by the WS-*/ID-WSF intersection.

(Anyone think the new REST-* effort will win in this space anytime soon? I’m a bit dubious, myself. Its name sure didn’t inspire any love in our lecture room.)

So said my colleague Ashish recently, as I agonized over some tweaks to the Venn of Identity diagram. The editing started out as a quick fix to the figure that appears in the IEEE Security and Privacy article of the same name; the diagram text was exactly what Drummond and I had specified — but the graphic emerged from the publication process visually “broken”, with no intersection lines.

But of course technologies and understandings and use cases evolve, and it began to seem like a good time to update the text too. What with the new U.S. federal government effort around Open Identity Solutions for Open Government (and PayPal’s involvement in same), I thought maybe I could do a better job of capturing the main strengths OpenID, InfoCard, and SAML bring to today’s table.

In that Zen-like and Concordic spirit, I hereby present a new — date-stamped — version of the Venn (click for the full-size .png):

I hope this new version can continue to support productive discussions that help solve real-world identity problems.

If you’re wondering whether it’s okay to pick up and reuse the diagram — go for it! Just please note the Creative Commons license below. I’ll keep VennOfIdentity.org pointed to the new Venn category on my blog so that people who see propagated copies can keep up with updates if they like.

The Venn of Identity – September 2009 by Eve Maler is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

p.s. Thanks to “W.” of the Tech and Law blog for our great email exchange this week on Venn-shaped matters, which sparked even more edits…

I’ve been trying this out on folks for a while now, and used it in a couple of recent talks, particularly my Gnomedex 8.0 one. Here’s my thinking behind it. (This is more than a straight Venn because of the metaphorical shadow thingie. Couldn’t resist! My web services Venn “cheated” too.)

Digital identity management is, at base, about identification so app usage can be correlated and audited, authorization to provide secure controlled access, and personalization, all counterbalanced by privacy. It has a strong individual (single-human-to-app) bent, though sometimes it involves Shibboleth-style scenarios where you mostly track anonymous group members rather than unique people.

Social networking is about building feelings of connectedness and offering the benefits of collaboration, such as crowdsourcing. Social apps focus on human-to-human relationships, but to provide infrastructure for this, they have to do plenty of the human-to-app variety. Social networking today stresses revelation of personal details (the OpenSocial best practices doc is one example) much more than it stresses privacy, though the latter is an increasing concern.

VRM partly involves what could be called restriction of data flow — undoing vendors’ grip on users’ info in a way that’s familiar to proponents of privacy-enhanced and user-controlled IdM. But other VRM scenarios involve enhancement of individuals’ opportunities to share personal information, for example by issuing a personal RFP to potential vendors. As Doc Searls has said, VRM is “personal first and social second”, so it seems to have a closer kinship with digital identity but could provide new social opportunities as well.

Each area has its unique features. But all share a common trait — differentiated app behavior depending on special aspects of you (whether this comes from attributes, claims, and transactional details in IdM; social graph data and user-generated content in social apps; or proactive requests and other personal data offered up in VRM). And to deliver on this promise they all share a common requirement — knowing more about you, with permission.

By contrast, where apps know about you through improper data gathering or aggregation, you get digital shadow effects — like direct marketing that is distinctly not permissioned or welcomed. Today, permissioning is still something of an art rather than a science, hence the title of this post.

We have a number of infrastructural options that more or less satisfy the requirements of the intersection, and later I hope to provide further thoughts on that. For now, I hope you’ll let me know what you think of this new instance of John Venn’s invention.

This is the Venn of Identity article, Wordled (Wordlified? Wordlimicated?). Can you find the “SPs” in this picture?… At least the “user” is well represented!

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

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.

To learn about my main contribution to the festivities, click to enlarge this all-important “Venn of identity parodies” diagram. (Who do I think I am — Paul Madsen?)

Here are the lyrics to the related ditty I performed, with apologies to Maria Muldaur (and the fine folks at OASIS!).

Midnight at the Organization for the Advancement of Structured Information Standards
(original lyrics here)

Midnight at OASIS
Send your SAML to bed
Touching all of the bases
Graces schedules up ahead
Madsen‘s working the website
Formatting’s gone bust
Let’s just separate MAY, SHOULD,
SHALL NOT, RECOMMEND, and MUST

Come on, Kavi is our friend
It’ll upload the spec
Come on till the ballot ends
Till the ballot ends
You don’t have to answer
You can just abstain
Mary‘s tally keeper
Deeper, to get us through the week

Gerry Beuchelt has already blogged another tune he and I warbled.

One last goodie: Click on the slide below to see a “singing presentation” that Gerry, Paul Bryan, and I prepared, with apologies to Dick Hardt…

Tag: iiw2007