I’m very happy to hear this from Kim Cameron at Microsoft today:
We don’t live in a one-size-fits-all world. Identity involves different - and even contradictory - use cases. Rather than some monolithic answer, we need a metasystem in which the cost (in complexity or money) of using identity is proportional to the value of the asset being protected. OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages. But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.
While I’d quibble with him about how far OpenID can go, anybody who’s heard me speak or has read this blog over some period of time knows that I very much agree with the sentiment: many people have invented (and deployed!) really interesting and useful technologies in this industry, and it simply would be disingenous for anybody to claim that any one such approach meets all requirements, both technical and economic. Fortunately, while such claims were fairly common a year ago, more and people are coming around to the same idea.
He continues to mention the intriguing possibility that the WS-based stack of protocols, the SAML-based protocols and the OpenID-based protocols could merge. Which, of course, has been the whole idea behind an Open Source Identity System, an effort co-initiated by Microsoft and now involving most large technology vendors and a host of startups (including NetMesh). I assume that he means merge-by-plugging, rather than merge-by-requiring-all-of-them-simultaneously so everything and everybody can focus on what they are best at (technically and economically) while getting interoperability all the same.
Having grown up in Germany and living in the US, I continue to be intrigued (amused?) by the differences in the way things are done in these still relatively close cultures. (Bhutan anyone? But I disgress.) One of the differences is when applying for a job:
In Germany, you typically get (or at least try to get) letters of recommendation from your old employer, satisfied customers etc. You then take those letters (or don’t, if you don’t like what they say) to your prospective new employer and present them to bolster your claims about your talents.
In the US, or at least in Silicon Valley, the prospective new employer asks you for references, such as your old boss at your old employer. The prospective new employer then contacts your references, and also often other people who know you but whom you did not specify as reference, and asks them whatever the prospective new employer feels like asking.
The goal is the same, to increase the prospective new employer’s confidence that the impression you made is consistent with those of others who have known you for longer than the prospective new employer. But these two approaches have made different trade-off’s:
In the Recommendation Letter model, you, the prospective employee, are in full control of the information that you present to your prospective new employer. The disadvantage is that the new employer will have no way of ever obtaining negative information about you (in fact, if I recall that correctly, you can get sued as an employer in Germany if you write a too-negative letter; in response, an entire new sublanguage has developed among Human Resources professionals through which they say negative things without the use of any negative words; quite an accomplishment). As the employee, this may please you a lot, but leaves a lot of employers unhappy because they only get part of the picture about you.
In the Reference Check Model, the employer can get as much information as they like; however, the employee has no control over, and often no knowledge of the information exchanged in the conversations between the prospective new employer and the references. That’s clearly less privacy-protecting.
No, I’m not writing this because I’m looking for a job
we’re plenty busy at NetMesh these days. I’m writing this because both of these data flows are valid models for accessing the knowledge that third parties may have about an entity. The constellation of entities in the hiring scenario is the exact same as the constellation at the heart of many digitial identity scenarios: a Relying Party (the prospective new employer) wishing to obtain third-party information aka claims about a User (the employee).
When putting digital identity technologies in place, we have the same choice to make: either, all third-party information about the user has to flow through the user (the Recommendation Letter Model), or some of the third-party information flows through channels other than the user (the Reference Check Model). And just as there are at least these two models for hiring a new employee, chances are that there are at least the same two models for digital identity. Let’s keep this in mind before we get to zealous arguing that it always must be one of those two and never the other…
Side note: the attack vector are also different; forging of a Recommendation Letter, vs. impersonation of a reference.