Phil Becker on the failure of oversimplification

Phil Becker of Digital ID World (DIDW) had this to say about Dave Kearns’ recent post on InfoCards (my comments here).

It may be mostly true “that there's nothing new here except” the decentralized and heterogeneous aspects of this approach. But then, that's exactly what it has taken a decade to fully understand is actually the only vitally important part of the task.

Until this problem was recognized to unavoidably be (and thus looked at and designed for as) a decentralized distributed problem spread across multiple administrative domains and extremely heterogeneous technology and platforms, it was doomed to repeat Einstein's “failure of oversimplification.” (“We must make this as simple as possible, but no simpler.”)

Elegant simplicity is always the most difficult thing to find, and the most difficult to appreciate as significantly different from what has gone before when it is found. Are we there yet? Probably not. But we are at last on the road to getting there instead of just standing aroung in the bus station complaining about how everyone fails to understand.

This is a very dense and immeasurably deep comment. I hope Phil will be able to explain this widely as he has so many other things.

Bridging the chasm

The recent piece in which Hubert Le Van Gong began looking at InfoCards attracted a number of comments from the Liberty and SAML side of the house. I'm glad to see them joining with those of us already in this discussion to look at what we might accomplish together.

First up was Robin Wilton of Sun, who saw InfoCards as being, “…an interesting dimension of the whole ‘thin client/fat client’ tension”. For those who don't follow this kind of thing, a thin client is, at its most extreme, a display and keyboard with little local computing power and no state (no storage) – essentially a window onto a mainframe – er, I mean onto a powerful network-based server.

More often than not, local processing power comes in handy for some applications, so the term ‘thin client’ is used in practice to describe an approach to delivering specific applications. Generally, it refers to using a browser as a stateless window onto a server-based application. What would it mean to introduce InfoCards into such a world?

Let's remember that “InfoCards” are visual representations of identity providers (and sets of claims) that can be controlled through an “Identity Selector” crafted for choosing between “Digital Identities”.

These Digital Identities can emanate from anywhere (and from any platform) so are architecturally distinct from the client (and don't “fatten” it).

The Identity Selector itself does need to be part of the platform – in order to increase the safety and usability of the identity system by offering a consistent experience and making it very much harder for attackers to subvert than is the case with current applications and the browser-based technology.

However, there is nothing in the architecture to imply that the Identity Selector needs to store state on the thin client.

I can imagine “ultra thin” implementations of an Identity Selector store in which the card collection would be hosted by a distant web service, for example. Or better still, I can see many advantages to hosting the card collection and authentication information in some kind of dongle, or iPod, or mobile phone or wearable computer. The essential thing is that these decisions be under the control of those using the system.

So yes, we need to add identity selection as a capability required by any end point. But it would be an error to see this as requiring storage of state on the client, or as a matter of fat versus thin.

Moving on, we come to this comment on Hubert's blog by Chuck Mortimore:

At this point, Microsoft's intentions seem to be to only support the WS-* protocol stack. Requests have been made to make this pluggable, but all indications are that this will enter the market using only ws-trust and its dependent specs.

Scott Cantor, the key editor of the SAML 2.0 spec, then adds:

I can relate from conversations at DIDW that it is 100% a constraint that this InfoCard model for identity provider “discovery”, as the SAML spec refers to the process, is completely tied to WS-Trust and they do not intend that it support any other authentication protocol.

Scott goes on to (accurately) report my view as being:

…that multiple protocols introduce insecurity to the client, and are a deployment problem because of the need to keep each client up to date with each protocol. He drew the analogy of that being like “putting a router in the desktop”.

He has a point, but I'll only say that WS-Trust includes (as it must) extensibility to deal with the kinds of challenge/response behavior required to use certain kinds of tokens…

But in any case, you can certainly ask him what he means by “SAML and Liberty can work in this framework”. But I'm pretty sure he just means that SAML assertions are supported.

Here is my thinking. I do want InfoCards to be “pluggable”. I want users to be able to plug in InfoCards that represent multiple operators, and multiple security technologies, including SAML. This is the translation of the crucial fifth law into a working system. Little is more important to me that delivering on this requirement. But the real question is one of how to best make InfoCards pluggable. Should the complexity be on the client, or should it be quarantined on specialized servers?

And now, we enter the twilight zone. As strange as some may find it, I am on the “thin client” side of the ensuing discussion. I want to achieve manageability and reduce the client security attack surface by supporting a single protocol stack between the client and security token servers. Meanwhile my friends Hubert and Scott have wandered onto the fat client side – they want to add multiple parallel protocol stacks to what will likely be the most attacked client system ever deployed.

I urge them to reconsider. We should collaborate to minimize the vulnerability of what will eventually (if we are successful) be deployed on billions of clients. If we limit the identity protocol between client and server to WS-Trust (making it at least possible to test it), it by no means limits the overall protocol options available to Scott and Hubert. The server can bridge WS-Trust to whatever other protocols it wants. The system is then eminently pluggable at a protocol level, but in managed environments, rather than in a chaos impossible to defend from attack.

Clearly, this call for minimalism on the client means the WS-Trust protocol should allow any security content to be carried by it - effective freedom of choice. It must transport any type of token. It must also allow the conversion of any set of claims into any other. It must be the meta in the metasystem.

WS-Trust is precisely such a protocol. For those who don't follow these things, it was designed as a way to build a “security token service” – a service whose very purpose is to exchange one security token for another.

I therefore hope all in this conversation will understand that I am not asking anyone to lay down their protocols! I am asking them to consider adding a token exchanger (aka Security Token Service, or STS) to their implementation, and to use the WS-Trust protocol as the way to implement this one piece of the puzzle.

We can imagine many synergistic outcomes. For example, one could have a client using InfoCard (and WS-Trust) to authenticate to the WS-Trust “head” on a portal server which is part of a Liberty federation, even though that server interacts with its partner sites using Liberty protocols. One can also imagine building a generic STS which works much like an “identity bridge”, converting SAML and Liberty identity and attribute providers into a WS-Trust InfoCard identity provider. I was thinking of these opportunities when I said, “SAML and Liberty implementations can easily interwork with this proposal – it may require some extensions to current capabilities but nothing very significant.”

One thing all of us can agree on is to be wary when an architect says, “nothing very significant”. But on this one occasion I think I can get away with it. Ping has already demonstrated that those who already have the technology necessary to do SAML or Liberty can easily add the functionality implied by WS-Trust. After all, Andre Durand was able to demonstrate such a service at the recent DIDW conference – easily interworking with InfoCards. Other providers of hardware and software are already far along in developing this capability as well.

Dave Kearns on InfoCards

Dave Kearn has been posting up a storm – a good storm – including his comment on Johannes Ernst‘s What is Microsoft InfoCard? He says:

The explanation is a good, if somewhat convoluted, one. But could be simplified.

InfoCard is simply Novell's old DigitalME decentralized (as Novell's personal directory intended it to be) and hopped up on Web Services SOA.

In many ways, it could also be described as Passport without the Big Brother implications of “Hailstorm“, hopped up on SOA.

The important thing to remember, I think, is that there's nothing new here except the joining together of the personal directory with the panoply of specs and protocols that make up Service Oriented Architectures. That's no small accomplishment, of course, especially for a company as vilified for it's security and privacy policies as Microsoft is.

It has certainly been my intention to invent as little as possible, so I thank Dave for pointing out my lack of a contribution in this regard.

Decentralization is certainly a big part of what is being proposed. The ablility to support multiple (and evolving) underlying security technologies is also a key property. So is the new approach to integrating the user into the experience and keeping it consistent across contexts and technologies. Finally the project employs various technologies which raise the bar on resisting phishing and pharming attacks.

Bob Wyman on identity

Here are some comments on the Laws by Bob Wyman, co-founder and CTO of pubsub.com.

I strongly support Hubert Le Van Gong‘s concern about the confusion between the “provision of identity versus the provision of attributes.” In fact, I go further to say that I am concerned that your Laws and the many discussions around them seem to be constantly conflating at least the three distinct issues of identity, attributes, and permissions or rights management.

I don't think ‘conflating’ is the right word, as I will explain. But it is true I am proposing that these things are more closely interrelated than many have thought.

Phrases such as “an identity provider is a claims provider in addition to whatever other services it might want to offer” are particularly confusing. Clearly, you see that this thing you call an “identity provider” is much more than just an “identity provider” yet you seem to insist on refusing to name it as such.

I apologize if I've been confusing. I see the provision of identity as the provision of claims. I was simply indicating that an identity provider might offer other related services as well – for example, auditing of usage, or management of authentication mechanisms. And so on.

In fact, what you often seem to view as a single service is actually a system of services composed as a conjunction of at least the three services mentioned above. It may be that your work has led you to “to think of a digital identity as a set of claims made by one digital subject about itself or another digital subject.” However, while this may be a natural simplification for someone who has worked long and hard on directory services — which are concerned with the issue of associating attributes with identities, it is not a useful or clear definition for those who work in other areas.

I appreciate Bob's gentlemanly gesture in explaining my myopia as a side-effect of excessive exposure to directory – certainly a possibility. But I've also built security systems for almost as long as I have been involved in directory, so I can't really claim overspecialization as an excuse. This aside, Bob continues to discuss keys in a way that I quite like, though I don't think it is the only truth:

Developing a solid and flexible architecture requires a more rigorous distinction between services. The problem here reminds me very much of the “Myth of Certificates.” We've been taught by the sellers of Certificate that keys aren't useful unless you have a certificate that binds the key to some person. The result is a nice little industry which specializes in tying claims of person-ness to key pairs that otherwise could be generated for free… Yet, the reality is that computer programs care little about “person-ness” and usually treat the keys themselves (or evidence of control over the keys) as the identifiers of unique entities.

Now here is the nub. Bob is describing a subset of computer programs, not all or even most computer programs.

There is almost always at least one cryptographic key involved in identity. But a key can be used in many different ways.

In some scenarios, the relying party knows the key of the party being identified. It can then use “evidence of control over the key” as evidence that it is “dealing with” that party. This has the advantage of being simple if there aren't too many keys involved, but in other cases has the drawback that the relying party needs to know a very large number of keys, and possibly who has them, and when they have changed or been lost or stolen. As Bob knows, this can get really complicated, and has all kinds of information leakage problems when there are large numbers of resources.

To avoid this complexity and vulnerability, other usages of keys have evolved appropriate to other scenarios. For example, the relying party may just know the key of some authority, and allow the authority to then provides a “claim” about the party being identified.

Consider Kerberos (and similar systems), since it is very widely deployed and relatively easy to manage. In Kerberos, no resource needs to know the key of everyone who can access it. The resource just needs to share a single key with the Key Distribution Center (KDC). There is thus no information leakage about other keys or identities in the system. The KDC creates a set of claims about the party being identified and packages it up so only the identified entity can present it to the resource. So such a KDC is an Identity Provider in exactly the sense I am using. Kerberos systems have been making claims about their users for more than a decade. In Windows systems employed in a great many enterprises, these claims include an identifier for the user and the identifiers of a list of groups to which the user belongs.

Now the question becomes “what is an identifier”. And again, I suspect Bob has notions about this which are restrictive. I don't. In my view, it is up to the relying party to decide how it wants to distinguish between potential users. In some scenarios, it may make a lot of sense to have some uniquely identifying claim – like an email address, or an identification number, or a guid, or a unique personal key. In others, it may be fine just to be able to determine that an authority known to me uses its key to say the subject is of a given age, or works for a given employer, or lives at a given address, or knows a given secret, or belongs to some club. And in yet others an authority might say that the digital subject possesses a given key, or combine this claim with others. What is wrong with this if it is the kind of identification required by the relying party?

Let's pop up the stack a bit. Let's go back to the Oxford English Dictionary (OED):

“Identity – The fact of being who or what a thing or person is.

  • The characteristics determining this: he wanted to develop a more distinctive Scottish Tory identity.
  • Serving to establish who the holder, owner or wearer is by bearing their name and often other details such as a signature or photograph: an identity card

A distinctive Scottish Tory identity is certainly not a unique identifier – rather it represents a certain class of user (!) – yet still an identity. The details referred to in the subsequent bullet (name, signature, photograph) are to my way of thinking precisely examples of claims being made in order to establish identity.

If I am guilty of conflation between “identity” and “attributes”, I am no more so than the authors of the OED just cited.

Code only “cares” that whatever entity it interacts with is able to distinguish itself from other entities. “Identity” lies in that ability to distinguish one thing from another. Names, permissions, addresses, etc. are not “identity” — rather they are claims which are bound to or associated with identities.

The problem here is one of vocabulary but it appears to be influencing design. We've got an “Identity Industry” that seems to be very focused on “personal information management” or claims processing but very little concerned with Identity itself. The result is systems that are more complex and less well defined than is necessary.

As respectful as I am of Bob Wyman's contribution to computing, I believe he is holding to a definition of identity which is overly narrow and has nothing to do with normal usage of the word. By reverting to a more usual use of the idea, and allowing claims to be unique identifiers or tuples of meaning or whatever the relying party would like to see, we can actually get a lot closer to building a unifying identity metasystem, because then the implementation details of different systems recede as well they should.

Bob also brings up the issue of permissions and grants, another interesting topic to which I will return as I explore the issues of the relying party in more detail.

Introducing Bob Blakley

When we were at DIDW my friend Bob Blakley and I got into some deep discussions about identity, and decided to pursue the conversation here since it might be of interest to others. When I asked how to introduce him, Bob suggested I explain he is in the “Drama Department at IBM”, which is, for all who know him, an understatement. Our goal is to make it clear that this isn't a discussion between companies, but between people deeply interested in identity issues. Since we're both pretty busy, this conversation will likely go on intermittently for quite a while, and I look forward to it. So without further ado, here is the rest of Bob's CV:

I was trained as a Classicist.

I don't have my own blog, nor even a webpage. I'm deeply suspicious of such things, because I prefer REAL things. When I say REAL, I mean this:

A thing is REAL if its existence and properties are not contingent upon our agreement or belief (“reality is that which continues to exist after we stop believing in it”).

A thing is REAL if it lasts a long time all by itself.

A thing is REAL if it does not require batteries.

A REAL thing is fixed, not discarded, when it is damaged or broken.

I'd rather have a REAL discussion about identity with REAL people, as you and I so often have late into the evening, than type things into a blog. But neither of us has a REAL living room of the requisite size, so the blog will have to suffice.

I think a breath is REAL, though it may be ephemeral, and a word is REAL, even just a whisper from a lover. So too this blog is REAL, though its mission is pragmatic. So I will draw this introduction to a close – and we'll take it from here.

Welcoming Hubert to the discussion

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.

Hubert continues:

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.

Dick Hardt and Identity 2.0

Dick Hardt has moved the identity part of his blog to Identity 2.0. Identity 2.0 is his meme for differentiating user-centric identity from what came before it. I like it.

Dick gave an absolutely fantastic presentation on identity at DIDW last week. It was intensely visual and direct – and really got his point across. Everyone who saw it came out a changed person. So I wonder if it's possible for him to put together a flash animation that we could all point our friends to…

Brainstorm on the Identity Big Bang

Speaking of Johannes, at the bottoms up identity meeting preceeding DIDW he made some really good points about the need to brainstorm deeply on what we mean by an identity big bang. How will applications change? What new applications will appear? I think Johannes is right on target when he calls on us to turn the discussion in this direction. So let's all start ruminating… and then get to work on this.