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.
2 thoughts on “A confused critique of identity federation”
Ironically there's been a case of mistaken identity (if not identity takeover). The blog post attributed to Earl Smith was actually mine. It was originally and is still at http://finextra.com/community/fullblog.aspx?blogid=439.
I've wriitten more recently and more extensively at my new blog site; see e.g. http://lockstep.com.au/blog/2011/02/24/identity-not-dead-yet.
My problem with the Identity Metasystem and The Laws of Identity is that they over-abstract the way people transact in the real world.
To be clear, I agree with all the deep truths in the Laws, especially that banks, governments, telcos, schools issue identities. The Laws also properly stress the plurality of ids, and their context dependence. In my view, the idea that we each exercise plural identities is the most important lesson in the Laws (yet tragically this fact of life is ignored by some who wrongly intuit that an uber identity or Internet passport is what we “really need”).
The practical difficulty I see quite often is that many take the Laws of Identity as licence to federate identities arbitrarily. People naively assume that an identity issued by a university for example can be used at a bank … as if they're equivalent but that flies in the face of the Laws [the student use case is actually front and centre in the Whitehouse's NSTIC press release].
A related problem is the decomposition of banks and governments into IdPs and RPs. As I noted in my blog, today each bank is both IdP and RP. The Identity Metasystem encourages banks to re-imagine themselves as RPs and IdPs separately, so that (a) they can act as IdP to other RPs, and (b) then can act as RPs to accept externally issued identities. Both of these directions are radical departures from how banks work today. With regards to (a), banks struggle with the implications of underwriting misidentification related risks when IDs they issue are used outside their silos; re (b) banking KYC regulations today generally demand that banks do their own identity proofing. The legal complexity swamps the benefits that might be gained from extra revenue streams and shrunken identity proofing.
To put that another way, while we all agree that banks are IdPs and governments are IdPs, it is not the case that they can be identical or interchangeable IdPs. For a bank to have its identities accepted by other organisations necessitates some modification of those identities. Even the most minor change to the way a bank vets its customers, and to the detail of the customers’ Ts&Cs, has legal ramifications. These sorts of silo-busting changes are unprecedented in banking. I've heard banks’ lawyers say “Ok, we'll look at it, but we've never done anything like this before”. Not what you want to hear from a commercial lawyer!
Finally, I think the context-dependency of identities is chronically underestimated. In Australia at least we've seen four identity federations or broker systems fail to launch, because they couldn't deal with the legal complexity of having identities issued for one purpose re-used for other purposes. Good strong identities turn out to be brittle; they cannot be bent arbitrarily to fit other contexts.
To fix the identity crisis, we need more simplifying assumptions rather than complicating generalisations. The Laws are not wrong, and my suggested simplifications are as you say Kim consistent with the Laws. Nevetheless,I find that the Laws of Identity as they stand are not helping in practice to solve the problems.
Moving forward, I'd like to see more work so the Laws of Identity lead to a clearer understanding of what identities do federate and which do not. The much derided identity silos are a natural result of the way risk management evolves in existing business ecosystems. “Silo” is a bad word. A more politically correct, progressive and insightful word is ecological “niche”. Some identities are difficult to federate, for the same reasons as some organisms do not cope when you take them out of their natural habitat and drop them into another. The highly evolved, highly specialised identities like bank IDs are the most difficult to federate, a fact that can be explained through evolutionary/ecological thinking.
I am presenting a paper on this line of inquiry at the AusCERT conference in Queensland in May. I hope it fosters some fresh discussion and new progress on identity federation.
Steve Wilson, Lockstep.
Kim, you wrote of my point that there aren�t many strangers in real life business: “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”. We need to unpack the relationships between you and the bank, and the bank and the IRS.
The bank knows you in a very specific context. The identity they issue you is not simply a statement of your name, but rather it is a proxy for a relationship they have with you for a specific purpose — banking. The “identity” is an abstraction that hides a host of formal complexities, like the identification protocol, and the terms & conditions for operating an account, that have been fine tuned to the banking context. There is always a finite risk that the bank has misidentified you; they understand the ramifications of that risk down to several decimal points, and manage it accordingly within their silo. Are these arrangements congruent with the relationship you have with the IRS? Despite some similarities, no they're not. The crucial shortfall is that a bank warrants to itself certain things about its customers, and it manages the risks of that warranty failing occasionally, but they are not at all accustomed to warranting much about its customers to parties outside the silo. The work involved in revising identification protocols and crafting new legal arrangements with customers and with external RPs has in my experience killed off at least four otherwise carefully founded federations in Australia. The simplest project was for banks only, and even then they couldn�t face the legal complexities of re-casting customer contracts, and striking new contracts amongst themselves, despite the fact that the legislated identification protocols for all retail institutions are identical!
Kim, you also countered: “And my banking credential is not a surprise”. The sort of surprise I was alluding to is the �unanticipated identity assertion� covered by U-Prove. I contend that in the vast majority of economically important routine transactions, there are no unanticipated assertions. When I buy online, the merchant anticipates I will use a credit card; when I log on to my corporate VPN, the server anticipates an employee ID and OTP; when a doctor signs a prescription, the pharmacist anticipates a Provider Number; when I log onto my airline site, they anticipate my frequent flyer number, and so on. I fear that so much of the Identity Metasystem has been over-engineered to cope with fringe stranger-to-stranger use cases, and that much simpler the demands of routine transaction authentication can be better met using decentralised, local architectures, such as closed loop PKI.
Steve Wilson, Lockstep.
Comments are closed.