Designing out identification uncertainty

A few of us have been debating Levels of Assurance on Twitter. It seems crucial that we look at authentication at enrolment or registration time separately from authentication at transaction time, as Jim Fenton touched on in his comment at https://lockstep.com.au/blog/2011/03/11/nstic-and-banking.

A big problem in the discourse is that the process of checking identity at enrollment/registration time and at transaction time are both called “authentication” .

I contend that using quaternary LOAs to gauge someone we’re about to transact with is a very big change from the way we do routine business today, and that any major change to business liability arrangements, even if it is worthwhile, introduces such legal complexities that it can kill federated identity initiatives. Interestingly, lots of others also say LOAs are a big change but for different reasons! Paul Madsen @paulmadsen and Phil Hunt @independentid argue that trust in the real world is analogue, that it is determined on a continuum, and that we are never 100% sure of who some really is.

That’s true, and it’s crucial to consider the uncertainty when authenticating someone at enrollment time. But I think it’s a moot point when we authenticate a counter-party at transaction time. During a great many routine transactions, the counter-party is either authorised to deal or they are not. The question becomes binary, not analogue and not even quaternary! When a pharmacist processes a prescription, they want to know if it was signed by a doctor, or not. When I withdraw money at the bank, the teller checks if I am account holder, or not. The authority to sign purchase orders, tax returns, audit reports, legal advice, radiology reports, insurance loss estimates, survey reports etc. etc. is always binary. When the Relying Parties to any of these sorts of transactions process them, I do not believe that they spend any time at all pondering the analogue trustworthiness of the sender, or the percentage probability that the sender is not really who they say they are.

So what’s going on here? I admit there is uncertainty at the time of registration, but where has it gone by the time RPs make their real time binary decisions to accept or not? The answer is that uncertainty and its consequences are calculated in advance at design time and factored into enrollment protocols and other systemic risk management mechanisms, in such a way that during routine transactions, the RP need not worry.

In detail, consider doctors’ registration. The process for credentialing doctors is not perfect; let’s say 0.1% of doctors out there are frauds of some sort, carrying an authority that is not true. I contend that all those relying on a doctor’s credentials for routine transactions (these are pharmacists, pathologists, other doctors, hospital administrators, health insurers etc.) authenticate the doctor on a binary basis, by checking if they seem to hold a valid credential. If the doctor holds a credential, the RP simply assumes it’s genuine (naturally the RP will need to check for revocation, and tampering, but if the credential is mechanically valid, then the RP assumes it’s genuine). This ‘blind’ assumption by the RP results in a finite system-wide error rate in prescriptions, insurance claims and so on. There are system-wide quality control mechanisms that in effect monitor this error rate and initiates corrections when it gets too high (or when the odd spectacular screw up occurs like a fraudulent doctor kills a patient).

So there is a cascade of identification risk decisions being made at different points in the identity life cycle:

My experience is that a great many economically important transactions can be accepted /rejected based on a very small number of assertions (usually just one) that the Subject can present directly to the RP. There need not be any real time Q&A back and forth between the RP and the Subject’s IdP at transaction time. For example, a doctor’s Provider Number can be baked into a digital certificate issued by a recognised authority and asserted for each transaction via digital signature; RPs don’t need to know anything else about a doctor in order to accept or reject the vast majority of e-health communications. If a revocation check is necessary, it should be done at the medical credential issuer; an independent IdP adds no value here. Anyone remember a company called Valicert? They tried to inter-mediate status checks for digital certificates, but they failed to deliver any real value; RPs found they were better off going direct to a CA to check if a certificate was valid.