Pat Patterson has introduced me to one of his friends from Sun's CTO office. He's a new blogger called Hubert Le Van Gong. Hubert has started thinking pretty deeply about our metasystem proposal. Here's his posting:
Microsoft recently shed more light on their new identity project called the Identity Metasystem. A core component of it is InfoCard. Actually InfoCard is composed of 2 elements:
Identity selector: it will reside on the PC and will act as a sort of broker for the user by negotiating between the identity providers and the relying party. Note that the term identity provider has a quite different meaning that the one used in other identity framework (like Liberty). In Microsoft's Identity Metasystem, an identity provider issues digital identities that are relevant to the business it is in. For instance, a credit card provider would issue identities that enable payment (so credit card number info or whatever is needed for a payment). To me such identity provider is more of an attribute provider but maybe I sent too much time working on Liberty? The relying party is a service provider that is also InfoCard enabled.
I don't know if I'd call the Identity Selector a “broker” – in the sense that it is operated by the user rather than some other organization or agency. I don't want to start thinking of myself as “brokering” my own interactions – my life is complicated enough already. And I'll bet Hubert feels the same way.
The selector is actually engineered as a highly tuned control surface through which the user can establish an unambiguous and safe channel to the digital world. Through this surface the user is able to evaluate the authenticity of those with whom he or she is interacting, decide what provider should be used in a given context, and approve (or prevent) information being released to a relying party.
Within this kind of a system, does an Identity Provider (IP) know what the user's decisions are? That depends.
An IP never knows what a user has disclosed using another IP. So there is complete segregation of providers. This allows complete segregation of identity contexts.
Further, a given IP may or may not know who the user is divulging information to. In other words there can be both “auditing” and “non-auditing” identity providers. Our study of the laws led us to conclude that in some contexts, auditing by the provider may be considered a good thing, whereas in others it may not. Our goal is to provide a platform for expressing all aspects and variations of identity.
A non-auditing identity provider is significantly different from what an IP does in Liberty. But an auditing provider seems to me to be totally consistent with the concept of a Liberty IP (which knows about the information releases a user has approved, including what information has been – or should be – released to whom).
Hubert's comment about provision of identity versus the provision of attributes is interesting. As explained in the Laws whitepaper and elsewhere, my work has led me to think of a digital identity as a set of claims made by one digital subject about itself or another digital subject. So an identity provider is a claims provider in addition to whatever other services it might want to offer.
Self-issued identity provider: a PC will be able to store some of the user's personal information in a secure area of the operating system. The InfoCard client application (on the PC) can then provide these data to relying parties. Microsoft says that the data stored on the PC cannot be sensitive information (e.g. social security numbers…). While this is an interesting concept, storing locally personal attributes is raising the issue of availability: unlike digital identities stored on an identity provider the self-issued digital identities are only available when you're using your PC.
This is true. The self-issued identity provider won't be able to do some of the cool things that a “managed” provider can do. It's not intended to compete with them. We look at it as a way of bootstrapping the metasystem. Virtually the entire consumer web works today with self-issued identities (that people have created by pouring their personal details into forms). The self-issued provider does this “out-of-the-box”, so everyone can “play” in the InfoCard world without purchasing a service or making any kind of commitment. Our thinking is that as people understand the benefits and issues, they will become informed about the benefits that “managed” providers can provide. They can then upgrade their experience. So the self-issued identity provider is a way to get the ecology moving. And for some purposes, a self-issued identity is probably fine.
I should point out that we will also be creating a managed Identity Provider for Active Directory (AD) that can be used in the InfoCard Identity Selector. Enterprise customers who use AD will have the option of giving their employees InfoCards that represent a professional identity. (They will also be able to control whether InfoCard Selectors are enabled in machines which they manage).
We also see Indigo as being very closely integrated with the InfoCard proposal since Indigo programs can support InfoCards with no special coding.
I want to make it crystal clear that if Pat and Hubert like the idea of working together in a metasystem, Sun could provide an InfoCard representation for identities managed by Sun technologies, and those could appear in a Windows InfoCard Selector alongside or instead of, for example, an AD InfoCard. Further, Sun workstations could include their own Identity Selector. Same for all the other platforms and identity systems people come up with.
I congratulate Hubert for putting together a swim lane:
Gathering as much info as I could, I have created the following diagram to illustrate how InfoCard would actually work. I'd be happy to hear any comment on it (or corrections if I got something wrong).
Now an interesting question is how this is going to work with other identity frameworks? Microsoft called this architecture Identity Metasystem since it is supposed to be above (and play nicely with) existing systems. I could imagine this being used on top of SAML2.0 or Liberty ID-FF1.2 but obviously this architecture is in direct competition with Liberty's ID-WSF framework.
I'm sure I'll come back to this.
This is a good first approximation of what our swim-lanes look like. I'll post something more detailed on this site pretty soon. All this stuff will be published in excruciating detail within a few weeks – we're just trying to make sure it is as accurate as possible.
Hubert also asks a good question about the details of interworking with other systems. It has been pretty clear to me that SAML and Liberty implementations can easily interwork with this proposal – it may require some extensions to current capabilities but nothing very significant. So really, it's a question of whether we want (as an industry) to make this proposed metasystem work or not. As an identity guy I certainly hope so since I think it is win-win for all players, including the individual – who, as Doc Searls so convincingly pointed out at DIDW, will increasingly move toward the center of economic activity as the world continues to collide with cyberspace.
In terms of the ID-WSF framework, I'm not an expert on this. But from my viewpoint, InfoCards in no way dictate what protocols are used for all kinds of web services and all kinds of scenarios, so I don't understand the “direct competition” point. Maybe Hubert can explain. InfoCards are, basically, a proposal for giving the user control, supporting multiple technologies and operators within a unified context, and upping the bar on safety and user integration – doing all the things necessary to building a metasystem that is consistent with the laws of identity outlined here.