I have criticised federated identity for being over-engineered, and described the Laws of Identity as "weird and wonderful" for being overly abstract. It's not that the Laws are wrong; they speak of deep truths to do with identity. I prize them as a seminal contribution to the field. But I believe that in practice, they haven't done as much as we had hoped to help resolve the urgent issues of identity security.
The Laws of Identity call implicitly for conventional e-business actors like banks and government agencies to take on broader generalised roles as open Identity Providers, and to insert themselves into otherwise bilateral transactions between Customers and Service Providers. It's a big call! The Identity Metasystem architecture fundamentally changes business relationships and risk management mechanisms. Most of these arrangements are expressed in legal contracts; some are actually legislated, as in banks' Know Your Customer rules. These contracts and laws are not easily varied. So full blown Federated Identity fundamentally changes the business world.
So I believe instead of complicating generalisations about identity provision and the like, we need a fresh set of simplifying assumptions. Federation has a lot to offer in the new pure play digital activities like blogging and social networking, but in hybrid and high risk services like banking and healthcare, it's much tougher. A new set of assumptions might help us tell the difference, to avoid expensive project failures, and create a stronger more graduated bridge from today's bricks-and-mortar conventions to the world of the Laws of Identity.
Here's a hopeful start.
Assumption: There aren't many strangers in real life business
The idea of 'stranger-to-stranger' transactions is implicit in open identity theory. Yet most e-business automates routine transactions between parties that have already signed up to an over-arching set of arrangements, like a credit card agreement or a supplier contract. The first and foremost aim of most digital identities should be to faithfully represent existing real world credentials, allowing them to be exercised online without changing their meaning or their terms & conditions.
Assumption: Relying Party and "Identity Provider" are often the same
The central generalisation in the Identity Metasystem, and its progeny like the Open Identity Exchange (OIX) Framework and the National Strategy for Trusted Identities in Cyberspace, is that Identity Providers are separate from Service Providers. This may be perfectly true in the abstract, but it plays into the flawed intuition that the identity I have with one bank for instance should be readily recognisable by another.
When you take an identity outside of its original context and try to make sense of it in other contexts, then you break its original Ts&Cs. Worse, you undercut any risk analysis that was done on the issuance process. If a bank doesn't know how its customers are going to use their ids, how can it manage its risks?
In reality, when the Relying Party is the Identity Provider, they retain closed-loop control over identification risk management and transaction risk management. This is the natural state of affairs in business and it does not yield easily to earnest efforts to 'break down the silos'. In many cases it will streamline digital identity (and minimise total cost of ownership) if we simply let certain Relying Parties continue to act as siloed Identity Providers.
Assumption: There are no surprise credentials
One of the leading new identity technologies, U-Prove, has the objective of proving "unanticipated properties of protected identity assertions". That is, two strangers can use this solution to work out what they need to know about each other in real time before they transact. That's obviously very powerful but less obviously perhaps, it's not what we really need right now.
Unanticipated identity assertions are quite academic. The vast majority of assertions in mainstream business are in fact anticipated, and are completely worked out in advance of designing and implementing the transaction system. When you go shopping for instance, the merchant anticipates you will present a credit card number, so much so that they invest thousands of dollars in card processing infrastructure. When you log onto the corporate network, the relevant identity assertion is anticipated to be your employee number. When a doctor signs a prescription, the relevant assertion is their medical provider number, and pharmacists anticipate that number (after all, they can't read the typical doctor's signature!). Just think for a moment of the huge cost and tiny benefit of reengineering the doctor-pharmacist arrangement so that some alternative unanticipated assertion could be presented in place of a medical provider number to authorise a prescription.
In almost all cases, the transaction context pre-defines what identity will be relevant, and we arrange ahead of time for the parties to be equipped with the right credentials. There may be interesting use cases where strangers can use U-Prove to strike up new relationships in cyberspace, but I simply argue that for most routine economically important e-business today, the practical identity needs are more prosaic and more simply solved.