Mobile: +61 (0) 414 488 851
Email: swilson@lockstep.com.au

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 http://lockstep.com.au/blog/2011/03/11/nstic-and-banking#comments.

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:

  • 1. At design time, health system managers, policy makers and regulators work out what the averaged consequences are of misidentifying doctors, and create processes and rules to manage the risk. These include up front credentialing procedures, as well as downstream safety nets, and ongoing monitoring and review of the rules.
  • 2. At registration time (when they get through college), candidate doctors are evaluated against those rules. Many different inputs will be involved; some, like reference checks, might be near-analogue. The process will be judgement based, and usually iterative, to deal with exceptions like overseas trained doctors, and may take time to execute. Yet it results in an authority to practice that is black-and-white [actually doctors typically carry a portfolio of specific b&w authorisations, pertaining to e.g. writing a prescription, writing a prescription for narcotics, carrying out certain operations, filing a public health insurance claim, admitting rights to a given private hospital, signing a pathology report etc.]
  • 3. At transaction time, when a doctor asserts their claim to be a doctor, the RP will make a go/no go decision, usually entirely automatically. If the RP follows all the rules of the transaction system they will generally bear no liability if a mis-identification has occurred upstream. RPs really want transaction-time authentication to be a highly mechanical process, with as little human intervention as possible; pharmacists for example don’t ever want to be in a position of having to make a fresh judgement on each and every routine prescription about the trustworthiness of the doctor.

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.

Posted in Trust, Security, Identity


Jim FentonSat 2 Apr 2011, 8:54am

"When a Subject joins a circle they need to prove their bona fides before being issued an identifier." In the model I use, identifiers are associated with every service that I do business with: my amazon.com identifier would be different from my llbean.com identifier, for example (and both identifiers would be opaque). My identity provider authenticates me at a given LOA and then asserts my identifier, and the authentication LOA, to the relying party.

When it comes to anything beyond proving that I'm a "repeat customer", attribute providers take part. My identity provider asserts an identifier (yet another one) to the attribute provider, and it's the attribute provider that makes any meaningful assertions about me: my name, whether I'm an adult, whether I live in the United States, etc. Those assertions also have LOAs associated with them.

I can picture a particular service requiring different LOAs for different values (risk) of transaction. My bank already practices this by allowing me to make a certain value withdrawal at an ATM, but requiring me to talk to a person if I want more money than that. Pharmacies do the same when they require more identification to pick up a prescription that is likely to be abused than one that isn't. I believe that they require more documentation from the prescribing physician as well.

So yes, trust is binary for a given transaction. But the quarternary system is a reasonable compromise between "yes/no" and a continuous spectrum that our systems don't deal with well.

Post a comment

If you are a registered user, Please click here to Sign In

Your Name*

Your Email Address* required, but won't be displayed on this site

To help prevent spam in our blog comments, please type in "identification" (without the quotation marks) below*