Further to my recent post questioning whether Open Identity is really “open”.
Every endeavour needs simplifying assumptions. Physicists, mathematicians and economists can only develop workable models of the world by making assumptions (and documenting them). Risk managers and lawyers make assumptions when crafting arrangements, leading to terms & conditions for use.
Modern identity movements seem riddled with complicating generalisations … about trust assurance levels, identity providers etc. This is not the language of customary business. These concepts might appeal in the blogosphere but they tend to confuse conventional business people who are seeking to leverage the Internet primarily to make their operations faster and more efficient.
Let’s aim at characterising 90% of routine e-business, where the ROI is all about cost reductions from going paperless, efficiencies from digital delivery, and increased market share from reaching more customers. These benefits are achievable with only incremental changes to work flows and business processes.
Assumption: There aren’t many total strangers in business
The core concern with ‘stranger-to-stranger’ e-business implicit in so much of the new identity work is misplaced. E-commerce is mostly about automating routine transactions between parties that already know each other, or who have existing arrangements in communities of interest that confer authority.
In formulating digital identities, it’s important to recognise existing authorisations, and the Ts&Cs that govern traditional transactions, and to ensure that those authorisations etc. are faithfully represented online. A minimal, lowest risk approach is to preserve existing business processes and liability arrangements as far as possible.
It’s often said that ‘technology is not the major challenge’ in going digital. This is true. The biggest cost in going digital is usually the change in business processes and legal arrangements necessitated by joining new parties in novel transactional arrangements. Experience shows that simplicity is best; mature proven arrangements should not be changed unless there is a very good reason.
Assumption: There are no shades of grey
A major preoccupation in online identity frameworks is “assurance levels”. The received wisdom has become entrenched: transactions are to be rated according to risk level, and authentication solutions are to be rated at matching “trust levels”. I hypothesise that this frame originated in defence, where they think in terms of Protected, Secret, Top-Secret etc. But I don’t see that it corresponds to any normal business reality.
In my view, when you transact with an authorised party, they are either qualified to deal, or they are not. There are no shades of grey. A person either has the necessary authority required to sign a prescription, or a Schedule 9 narcotics prescription, or an audit report, or a credit card transaction, or a P.O. for a company, or a property deed, or they do not. In the context of each business transaction, possession of the appropriate credential is binary.
Consider an ATM. If you inserted your frequent flyer card by mistake, then in theory the machine could try to negotiate with you to transact at some reduced “trust level”, maybe restricting you to balance-only transactions, or cutting your withdrawal limit. But no, in practice we apply the simplifying assumption that all legitimate ATM customers must have a bank card.
For every ‘serious’ e-business transaction, at design time we work out what the appropriate form of authorisation is, and when we transact, all we need to do is check that the sender has that authorisation. The business rules are simple, reasonably static, and as such can readily be written into the software.
Assumption: Relying Party and “Identity Issuer” are often the same
This simplifying assumption is offered in contrast to the generalisation central to the Identity Metasystem that Identity Providers are independent from Service Providers or Relying Parties. I understand this separation intellectually but I don’t see that it gets us very far in practice.
There is a widespread intuition that government agencies that today “issue identities” could cut costs (and increase usability) by using identities issued to their customers by other entities. This seems to be the core driver behind the US Trust Framework Program. I’ve been involved with numerous similar federation proposals, including the Australian banking sector “Trust Centre”.
The practical problem that sunk the Trust Centre and others is that when you take an id outside of its original context, and try to make sense of it in other contexts, then you break the original Ts&Cs. The id loses its meaning (a situation that is expressly acknowledged by Identity 2.0). 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 bank-issued ids, then how can the bank manage its risks?
This problem reminds me of one of the conundrums of early PKI: the lack of contractual “privity” between CAs and Relying Parties. Many top legal minds struggled with this. But in “closed PKI” the problem goes away, which is why closed PKI works and “open” doesn’t.
Open identity advocates might look to sophisticated assertion languages like XACML to provide the means for parties to negotiate risk and trust levels, but these real-time measures only work after designers, risk managers and lawyers have re-architected their systems and re-written their user agreements. The sheer cost of re-engineering time-honoured risk management arrangements is a show stopper.
Assumption: There are no surprise credentials
This assumption is in contrast to the marketing claims made for one particular identity product that it allows you to “prove unanticipated properties of protected identity assertions”. To solve this purported problem, novel zero knowledge proof algorithms have been developed.
The vast majority of identity assertions of interest in mainstream routine business are not in fact “unanticipated”. When you go shopping, the merchant anticipates you will present a credit card number. 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 provider number.
In almost all cases, the transaction context pre-defines what identity assertion will be relevant, and you 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 exactly like a merchant saying “Sorry, we don’t accept American Express here”. Yet a great deal of the open identity thinking caters for the idea that transacting parties have no prior arrangements, they haven’t anticipated what credentials are needed to support a transaction, and they will instead undertake some real time negotiation to establish sufficient “trust”. It seems to be a huge (possibly unbounded) amount of effort, which is readily avoided by assuming ahead of time that only certain credentials and assertions are relevant to the transaction at hand.