While a lot of us are greatly energised by the National Strategy for Secure Online Transactions (NS-SOT) and the opportunities it provides for the identity industry, I’m not entirely convinced by the mapping that has been done from the identity metasystem onto government authentication requirements.
A really fundamental concern I have is the use of the word “open” in “open identity”. As opposed to phrases like open standards and open government, which are obviously good things and where the meaning is clear, what exactly is “open” supposed to mean in open identity?
There is a strong implication in open identity that identities issued by different organisations should potentially be treated as equals. Yet most ‘serious’ identities used to transact with business or government only have one natural issuer. Consider that banks issue bank accounts and credit card numbers, health agencies issue health identifiers, employers issue employee IDs, medical registration bodies issue doctors’ credentials. So I can’t see that these types of identities are actually “open”. And that leads me to conclude that the Open Identity Trust Framework may be over-engineered.
One of the headline objectives for at least one vendor in this space has been to enable users to prove “unanticipated identity assertions” about themselves. That certainly sounds like “openness” but I question its practical necessity. The vast majority of identity assertions of interest in mainstream routine business are not in fact “unanticipated”. When for instance you go shopping, the merchant anticipates you will present a credit card number and provides tailored user interfaces accordingly. When you log onto your 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. When you access your airline account, it’s your frequent flyer number.
In almost all serious cases I can think of, the e-business transaction context pre-defines what identity asssertion will be relevant, and we can arrange ahead of time for the parties to be equipped with the right credentials. If you try to transact without the right credentials, then the software simply refuses you. It’s akin to “sorry, we don’t accept American Express here”. Yet it strikes me that a lot of the open identity framework caters for an imagined scenario in which transacting parties have no prior arrangements, they haven’t anticipated what credentials are needed to support a transaction, and they will instead undertake some sort of real time negotiation to establish sufficient “trust” from scratch.
The identity metasystem introduces new ways for players to think about themselves. The abstraction of Identity Issuer is fine for say a bank; it’s very useful indeed to think about a bank account as being a distinct digital identity. But to then take that identity out of its original context and try to exercise it in a new context is a deeper problem than most realise. In fact, to push the extensibility of identities too far is actually to deny some of the Laws of Identity, which reflect the reality that digital identities are context-dependent.
So when it comes to building identity infrastructure like the NS-SOT, we urgently need more simplifying assumptions and fewer complicating generalisations.
For one thing, the Relying Party and the Identity Issuer in so many cases are one and the same, yet the identity metasystem is built on them being separate. Intellectually I understand the generalised separation. Yet when it comes to implementing priority e-business applications, like health records, banking, payments, government service delivery, superannuation and pension funds management, e-conveyancing etc., we should be looking for simplification. The new generalisations are only theoretically elegant; in practice, they have significant impact on institutions’ business models, which are built on simplifying assumptions. For example, think about why the Ts&Cs for most bank’s OTP tokens today forbid re-using those tokens for non-banking applications. It’s to keep their model simple. The identity metasystem may lay the technical groundwork with which parties can exercise identity assertions outside their original context, but for the issuer, there remains a huge and unbounded amount of legal work to be done to support identities being used in unanticipated applications over which the issuer has no control.
[At this point, those with long memories may recall the contractual "privity" problem in Big PKI, where there was no relationship between a CA and the Relying Party. It was pretty well fatal. One reason that PKI works best in closed environments is that they bring contractual privity. It's not sexy, but "closed" is sometimes a good thing!]
A final thought for now is that the intuitions that underpin a lot of open identity might well be wrong. It’s really only a hunch that government agencies can reduce costs by using as their own the identities issued by others. The total cost of ownership can actually go up when we try to federate multiple identities into one; see my one page paper “In defence of identity silos“. My harsh experience in three important federated id programs in Australia was that the business process re-engineering and legal work can far outweigh any benefits when one institution tries to use another’s identities to save having to issue their own.
Identity silos are harder to break open than first appears, and we shouldn’t be surprised, when we consider that most serious digital identities are proxies for carefully crafted context-rich business relationships.
Steve Wilson, Lockstep Group, Australia.
One of my themes is to question use of the word “open” in “open identity”. While
/Open standards /and /open government/ are obviously good things, what is “open” supposed to mean in
/open identity/?
There is a strong implication in open identity that identities issued by different entities should potentially be treated equally. Yet most ‘serious’ identities used to transact with with business or government only have one natural issuer. For instance, Banks issue bank accounts and credit card numbers; health agencies issue health identifiers; employers issue employee IDs; medical registration bodies issue doctors’ credentials.
So I cannot see that these types of identities aren’t actually “open”. And a great deal of the Open Identity Trust Framework therefore looks over engineered.
I also think these new frameworks need to be built on simplifying assumptions rather than fewer complicating generalisations. For one thing, in so many cases the Relying Party and the Identity Issuer are one and the same, yet the identity metasystem is built on them being separate. Intellectually I do understand the generalised separation, but when it comes to implementing priority e-business applications, like health records, banking, payments, government service delivery, superannuation management, e-conveyancing etc., we should ne encouraging simplification, and not new generalisations that have the effect of changing institutions’ business models. By that I mean, why try to convince a bank to become a generalised “identity issuer” when the identities they issue to their customers are so context specific that parlaying them into other non-banking settings runs counter to all traditional banking risk management ploys.
A final thought for now is that the intuitions that underpin a lot of open identity might well be wrong. It’s only really a hunch that government agencies can reduce costs by using as their own the identities issued by other entities. The total cost of ownership can actually go up when we try to federate multiple identities into one; see my one page paper “In defence of identity silos” at http://bit.ly/dsbMEI. My harsh experience in three important federated id programs in Oz is that the business process re-engineering and legal work can far outweigh any benefits when one institution tries to use another institution’s identities to save having to issue their own.
Subscribe in a RSS reader • Subscribe via Email
