Kim Cameron Responds to Critique of Identity Federation
Microsoft's Kim Cameron responds on his Identity Blog to recent criticism of the concept of identity federation:
in a recent piece at The Federal Circle, Earl Smith II, managing partner, comes out “all guns blazing” against identity federation and the “weird and wonderful” Laws of Identity.
Earl wishes he could “simplify” digital identity, rejecting identity federation as being too abstract to solve digital identity problems. Unfortunately, his view of things mixes up architecture and the way real live systems are deployed, and he creates a straw man out of particular deployment assumptions. The resulting explanation demonstrates that once confused about this, things can look stranger and stranger:
All such “federated identity” models start with the intuitively appealing premise that if an individual has already been identified by one service provider, then that identification should be made available to other services, to save time, streamline processes, reduce costs, and open up new business channels. It’s a potent mix of supposed benefits, and yet strangely unachievable.
True, we can now enjoy the convenience of logging onto multiple blogs and social sites with an OpenID, or an unverified Twitter account. But higher risk services like banking, e-health and government welfare stand apart, still maintaining their own identifiers and sovereign registration processes.
To my mind, the fashionable open identity approach is ironically lumbered with the same lofty ambitions that killed off traditional Big PKI. The express aim is to create “trust frameworks” sufficient to enable business to be conducted amongst strangers. To this end, federated identity proponents implore banks and government agencies to re-invent themselves as “Identity Providers” in accordance with the weird and wonderful Laws of Identity.
The Laws of Identity embody some powerful ideas, especially the view that when we go about our business, each of us exercises a plurality of virtual identities. In different settings we present different identities, each standing as a proxy for a complex and bounded relationship. We have different relationships with various entities and services: banks, government agencies, health services, employers, stores, professional associations, social networks and so on. Each identity is context dependent, and can lose its meaning when taken out of context…
But for the most part, the Laws of Identity and the new ecosystem model are chockfull of unfamiliar abstractions. They deconstruct identities, attributes and services, and imagine that when two parties meet for the first time with a desire to transact, they start from scratch to negotiate a set of attributes that confer mutual trust. In practice, it is rare for parties in business to start from such a low base. Instead, merchants assume that shoppers come with credit cards, patients assume that doctors come with medical qualifications, and banks assume that customers have accounts. If you don’t have the right credential for the transaction at hand, then you simply can’t play (and you have to go back, out of band, and get yourself appropriately registered).
Perhaps the most distracting generalisation in the new identity ecosystem is that Service Providers, Identity Providers and Attribute Providers are all different entities. In reality, these roles are all fulfilled simultaneously and inseparably by banks, governments, social networks and so on.
To put order into this nest of ideas, let’s begin with what Earl calls ”the most distracting generalization in the new ecosystem”: that Service Providers, Identity Providers and Attribute Providers are all different entities.
In fact, Earl, I made no such statement in the Laws of Identity or anywhere else, despite my support for an identity ecosystem.
The Laws of Identity refers to an Identity Provider as issuing “claims”, a Relying Party as ”depending on” claims, and a Subject as “presenting” claims, but makes no statement that if you do one you can’t do the others. Why? Identity Provider, Subject and Relying Party are architectural roles. A single entity can play any combination of those roles. One particular combination is complete separation of the roles, but in most cases every entity plays more than one.
For example, today’s large web sites (like the MSN’s, Googles and Yahoos) are composed of thousands of individual services. Without having to be conscious of it, people log in to a site’s Identity Provider service, which issues claims that are consumed by each of the composite Relying Party services that make up the site. So the ”decomposition” which Earl sees as “deconstructed unfamiliar abstractions” is, at the architectural level, a MUST in order to have large scalable sites, and this is as key to the current web as to the metasystem model which is just standardizing and extending it.
I refer Earl and others to the User-Centric Identity Metasystem paper for more details. Section 6.2 states:
6.2 ACTORS PARTICIPATING IN THE METASYSTEM
The actors participating in the Identity Metasystem can be classified by role, taking into consideration that any individual actor or set of actors can play multiple roles (both at the same time and at different times).
(6.2 goes on to define roles such as Subject, Claims Issuer, Relying Party, etc).
That paper is not simple-minded in its presentation, but its goal is to lay out a model for precisely understanding the way identity systems actually work and can work in the future, not to do mass pedagogy. People using Facebook or Google or Windows Live never think about the decomposition of services within the identity fabric, yet depend every day on that very decomposition.
Continuing to unwind Earl’s comments, let’s factor out what he says about Trust Frameworks. Here I’m not unsympathetic to the points he is making, though I think they are only part of the story. I agree that most initial usage of the architecture is, as in the examples I’ve given here, within tightly bounded trust contexts. But I also think that once the technology framework is in place (e.g. now…) we will see more and more examples of federation within wider contexts where it makes sense. The question is simply, “what makes sense”?
If I could use my banking identity to log into the IRS, would that make sense to me? Yes, because I don’t access the IRS site often enough that I can ever remember an IRS credential. Would it make sense to Earl? Maybe not. So that very potential divergence leads us to posit the need for an ecology with choices - one of which would be the IRS itself for those who don’t relate to bridging of contexts.
Earl calls upon us to agree on a few simplifying assumtions:
- There aren’t many strangers in real life business
- Relying Party and “Identity Provider” are often the same
- There are no surprise credentials
These are all good points, but don’t diminish the utility of federation. For example, in the case of using a banking identity to access the IRS, I’m not a stranger to the IRS, nor is the bank. And my banking credential is not a surprise. I just don’t want the IRS to make me manage an extra credential for once-a-year use. Requiring me to do this is not a simplifying assumption!
Paradoxically the next piece by Earl at The Federal Circle is called Will Cost Savings Continue to be a Significant Driver for Cloud Computing? But Earl never asks how an enterprise or government organization that runs some of its services in the cloud handles the resulting identity problems without increasing its costs…
Would he suggest two credentials, one for inside the enterprise and one to get to the cloud? Two helpdesks? Two authorization systems? Or would he agree we should be able to reuse a single credential across these two contexts?
Bingo. Wouldn’t it be nice if Cloud services could rely on (dare I say be a Relying Party for) identities provided by the enterprise or government? The point is that if I build my identity systems today in keeping with an architecture that allows various roles to be played wherever it makes most sense, I set myself up for a future that is unfolding in ways I can’t always predict.
I hope that as someone advising people on how to grow and future-proof their organizations, Earl looks at the issues involved in federation one more time. The ability to cross technological and organization boundaries - which is called federation - is central to our ability to evolve with the agility Earl rightly sees as necessary.
Once Earl comes to see that federation architecture is completely consistent with the assumptions he puts forward, I have the feeling he will have an interesting perspective on the kinds of cross-context claims that make sense in various business and government contexts.