A post relating to this item from Finextra:
19 June 2009 | 14382 views | 0
A new initiative has been launched by a group of tech firms, including Oracle and PayPal, to promote interoperability among identity verification applications and services for Internet users.
I hope Kantara will be different but I have yet to see an identity interoperabiity initiative that properly articulates the real probelm it's trying to solve. A wise person once said something along the lines that the question is sometimes more important
than the answer. So, what precisely is meant by "interoperability" of identities?
Interoperability is surely the most slippery concept in e-business and yet one of the most beguiling. Surely, self-evidently, "interoperability" it has to be a good thing? Who could possibly argue against it?
We should start by double checking we're all on the same page. I have long heeded the
observations of PKI interoperability made by a previous head of the Australian payments regulator APCA:
"[PKI] interoperability is something of a will-o'-the-wisp. You think you understand what people mean by it, and then quickly realise that you don't. In my experience, it's possible when discussing interoperability to be at cross-purposes for all of the
time. Interoperability between members of the same PKI is axiomatic. Certificates issued by one bank should be recognisable by another. Interoperability becomes an issue when it is between different PKIs ... But this still leaves the basic question of interoperable
in respect of what?"
The same uncertainty plagues many "identity" discussions. Even when great pains are taken to define "identity" rigorously, the "interoperability" part leaves a lot to the imagination. For instance, the
Laws of Identity are expansive on the former and silent on the latter. The same goes for the recent
Proposal for a Common Identity Framework; it uses the term "interoperability", treats it as a given, but doesn't explain what it means.
There's an assumption in most federated identity initiatives that identities created in one domain really ought to be recognisable in as many other domains as posisble. But it's not like this in the real world. You cannot use your frequent flyer card or
your employee badge in an ATM to withdraw money. Famously, you can use your driver licence to open a video store account, but what happens next is interesting yet too often unremarked -- the store gives you a
new identity, in the form of a membership card. If there is anything going on here that could be called 'federation', it's actually very limited.
Many identity interoperability schemes -- especially authentication brokers, classically like the Australian banking sector's ill fated
Trust Centre -- have come unstuck, yet I don't think the underlyimg reasons have been appreciated. What we call an "identity" in a business domain is really a proxy for a complex
relationship between customer and service provider. An account number for example stands for the fact that the customer has met a set of requirements and has signed up to a set of Ts & Cs governing how they do business with an institution. If that relationship
is faciliated by electronic means like a plastic card, digital certificate or one time password generator, then there will be a detailed usage agreement, which typically
forbids re-use of certificates or OTPs with third parties. These agreements are framed very carefully according to the risk profile of the institution and the type of business it conducts; changing the agreement is not trivial and always subject to a
detailed risk analysis.
But "federation" in many cases would entail major changes to these sorts of agreements. Authentication broker schemes typically propose taking existing OTPs for instance (which get casually refered to as "identities") and allowing customers to use them
to transact with third parties having no previous relationship with the "identity" issuer. This is actually a very hard problem. Not only does it mean changing the usage agreement under which the OTP was issued; it means the issuer accepting that the OTPs
be used in unanticipated transaction scenarios. How on earth can anyone do a risk analysis of that?
So the real reason that many well intended federated identity schemes founder is this: There is no legal precedent for analysing the risks that arise when a customer with a relationship with service A tries to parlay that relationship over to new service
providers B, C and D.
For a little more detail, see my short white paper "Breaking down identity silos is harder than it looks".
So is "interoperability" self-evidently a good thing? It might seem politicallty incorrect but the answer is no, not in all circumstances. Imagine an inventor going to a bank with a gadget that would enable the bank's plastic cards to "interoperate" with
a range of third party services, so that cardholders could avail themselves of new services, all based on the bank's identification of those individuals. How would the bank respond? The only way they could respond is to get their lawyers onto the case.
The lawyers would have to carefully examine firstly any constraints in extant cardholder agreements, secondly the risks presented by the cardholders accessing new (and only loosely specified), services, and finally how the cardholder agreements could possibly
be modified to accomodate such new usage.
I am not a lawyer but I cannot see how these tasks are doable; the risks of of the unknown cannot be characterised. If a lawyer says of a new project that it has never been done before, then that's not a good sign. And therein lies the fatal flaw of so
many federated identity proposals. The much derided "silos" (or "walled gardens" in the words of the Kantara Initiative) are actually carefully constructed risk management arrangements. They govern business
relationships, not simple "identities". Breaking open these silos is an incredibly complex exercise, and is probably unbounded.