Digital identity in a low-trust environment

The standard identity design assumes three things: a document that can be trusted, a register that can confirm it, and a connection good enough to ask. Remove any one of them and most of the design still limps along. In several of the markets we build for, all three are unreliable at the same time, and the design has to start somewhere else.

When we built the banking applications for Zain Islamic Bank in Iraq, customers could open an account from the app, and an administrator console still existed to action each request in person. That was the correct answer rather than a compromise. In a market where the branch was the default, the document carried less certainty than the officer examining it, and no amount of software changes that ordering.

Identity as a confidence level

A system that models identity as true or false has exactly two moves available, accept and reject. In a low-trust environment both errors are frequent and both are expensive. Turning away a legitimate citizen from a service they cannot obtain anywhere else is a serious failure, and a citizen cannot shop around for a different provider. Admitting a fabricated identity is the other kind of serious failure, and it is the one that ends up in a newspaper.

A score with declared thresholds gives a third move: grant limited access now and require more later. Open the account with a capped balance. Allow the claim and flag it for a field visit. Issue the credential with a shorter expiry. The rules become explicit, reviewable and adjustable by policy rather than by a code change, which is what an auditor wants to see in any case.

Several weak signals, each with its provenance

Where the national register is patchy, verification gets assembled out of things that are individually unconvincing. A document. A biometric captured at enrolment. An introducer already known to the system. A mobile number with a usage history. An address confirmed by a field officer who signed for it. None of these is proof on its own. Weighted honestly, together they support a decision that can be defended.

The property that matters more than the score is the record behind it. Which signals were used, when each was captured, by whom, and what the threshold was on that day. Thresholds change. When a case is challenged three years later, the system has to reconstruct the decision as it stood at the time, and that reconstruction is the entire defence. A system that stores only the conclusion has nothing to say for itself.

Assume the connection fails

Enrolment happens where the people are, which is frequently where the network is worst. That means local capture with records signed on the device, deferred synchronisation, and a stated rule for what happens when two officers enrol the same person in different districts on the same afternoon. Duplicate resolution is a policy question with a technical implementation, and it is worth settling before the first pilot rather than after the first audit.

Devices get shared, lost and occasionally seized, so any key material held on one needs a revocation path that does not depend on that device being available to revoke it. On the citizen side, verification screens run on a cheap phone over a weak connection. Page weight becomes a security control in that setting, because a screen that times out sends the citizen to a counter where somebody will perform the check informally and record nothing.

The temptation is to wait for the register to improve and then build the clean version. Registers improve slowly and services are needed now. The systems that hold up are the ones that carry uncertainty explicitly, write down where it came from, and reduce it as better signals arrive. They are harder to draw on a whiteboard. They have the compensating advantage of being honest about what they actually know.