Diff for The challenge for Kantara -- It's not for nothing we call 'em "silos"!

Stephen Wilson's Babysteps

Ideas to demystify identity, privacy, authentication and safety online.

Wed, 07/08/2009 - 04:09 by Stephen.WilsonMon, 07/13/2009 - 05:05 by Stephen.Wilson
Changes to Body
Line 3Line 3
 
I hope Kantara will be
 
I hope Kantara will be
 
different but I have yet to see an "identity interoperabiity" initiative
 
different but I have yet to see an "identity interoperabiity" initiative
-
that properly articulates the real probelm it's trying to solve.  A
+
that properly articulates the real problem it's trying to solve.  Sometimes the question is
-
wise person once said something along the lines that the question is
+
more important than the answer.  So we need to start with a precise framing of what it means to have "interoperability" of identities.
-
sometimes more important than the answer.  So we need to start with a precise framing of what it means to have "interoperability" of identities.
+
 
</p>
 
</p>
 
<p>
 
<p>
Current revision:

Stephen Wilson's Babysteps

The challenge for Kantara -- It's not for nothing we call 'em "silos"!

I hope Kantara will be different but I have yet to see an "identity interoperabiity" initiative that properly articulates the real problem it's trying to solve.  Sometimes the question is more important than the answer.  So we need to start with a precise framing of what it means to have "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 meaning of identity but entirely silent on interoperability [maybe there's a tacit understanding that in the paradigm of identity plurality, interoperability might often be moot!] . The same goes for the recent Proposal for a Common Identity Framework; it casually uses the term "interoperability", treats it as a given, but doesn't ever 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 OTP 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 rather too casually get re-defined 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 I think the answer is no, not in all circumstances anyways.  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 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 closed business relationships, not simple "identities".  Breaking open these silos is an incredibly complex exercise, and is probably unbounded.

It's not for nothing that we call identity domains "silos".  I wonder when and why "silo" became a dirty word in our business.  Grain silos are wonderful things -- architecturally elegant, strong, protective, critical infrastructure for farmers, landmarks on many a rural landscape. 

So let's close with a thought experiment.  Imagine a wheat farmer being approached one day by their corn-growing neighbour with the following proposition: why not, in the name of efficiency, break open, join up and share their silos for their different products? I cannot believe that anyone would spend more than a minute before rejecting the idea out of hand.  If the corn grower needs more capacity, it seems very obvious to me that instead of re-engineering the entire storage and handling system, and striking up new arrangements with all customers in anticipation of the new risks, it would be simpler, cheaper and quicker to just build another silo! 

Stephen Wilson, Lockstep Technologies.

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I