Right, let's build the thing properly
Nobody asked me to design a national identity system, but let's have a go.
Last week I wrote about how Britain has managed to simultaneously create two problems - age verification and digital ID - that are actually one problem with a thirty-year-old solution sitting in plain sight. The response - since the Government started making statements about social media - has been good with many agreeing and others saying I don’t care about the children, which I have decided to take as a win.
A few people have asked, quite reasonably, what “properly” would actually look like. Not the vague hand-wavy version. The real one. The one you could hand to a decent team of engineers on a Monday and get a prototype working quickly, assuming they’d consumed enough Red Bull and were not expected to use SharePoint for anything.
So. Let’s have a go.
The thing everyone gets wrong first
The standard political brain, confronted with the words “national digital identity”, immediately reaches for a database. A BIG one, ideally. With everyone in it. Centralised somewhere reassuringly permanent-sounding, like Swindon. This is wrong in a way that is so fundamental it’s almost impressive.
You don’t need a database of who people are. You need a system that can answer one question - is this person who they say they are - without storing the answer anywhere afterwards.
This distinction matters enormously and is almost never made in any government policy specification document ever written, which tells you something about government policy specification documents.
The technical term for what we want is zero-knowledge proof.
You prove you know something - your age, your nationality, your driving licence status - without revealing the underlying thing itself. Think of it like proving you know a password without ever saying the password out loud. Cryptographers have had this working since the 1980s, which is, once again, before most of the politicians who’d be responsible for implementing this could reliably operate a fax machine.
The architecture, for those who like that sort of thing
Here’s what the good version looks like, in terms an engineer would recognise and a politician hopefully wouldn’t immediately try to “enhance” into uselessness.
Layer one: the people who vouch for you.
Not one government database. A federation of institutions that are already legally required to know who you are - banks, the DVLA, the NHS, your GP, the Post Office. Each of them can issue you a cryptographic credential. Think of it like a signed letter, except the signature is maths rather than ink, and maths is rather harder to forge. These institutions don’t talk to each other. They don’t need to. They each just sign their bit.
Layer two: a ledger nobody owns.
There’s a distributed record - not a blockchain in the Bitcoin sense before anyone starts - that records only which institutions are trusted vouchers and which credentials have been revoked. No names. No personal data. Just: “here are the valid keys, here are the invalid ones.” As it’s distributed this one can be run by a multi-party group that would legally require a super majority to change anything, not that they could anyway because it is distributed. It would not rest in the hands of a single Secretary of State.
Layer three: your phone.
The credential lives on your device. In the secure chip - the part of your phone that not even the OS can reach. Not in the cloud, not in Swindon, not on a USB stick left on a train. When you need to prove something, the phone generates a proof locally and shows it to whoever’s asking. They check it against the published keys. In you go. The phone knows what you did. Nobody else does.
Here’s the bit about recovery, before someone asks
“But what if I lose my phone?”
Yes. Good. This is the right question and I’m glad you’re paying attention.
The answer turns out to be more elegant than you’d expect. You take an approach that I borrowed i.e. nicked, from a password manager called 2FAS - a startup that clearly gave this more thought than most - and combine it with something that sounds counter-intuitive but actually works rather well.
When you set up your credential ergo ID, you set your own passphrase and you get 15 words. Random words, generated on your device, that together with the passphrase can reconstruct your key. You print them out. You put them in the fireproof box with your passport and other things that you know you need to keep safe. The encrypted version of your credential goes somewhere reliable - could be your own cloud storage, or, and here’s the interesting bit, it could even be government servers.
Yes. The government holds a backup. Now, before you write an angry comment: they can’t read it. That’s the point.
The backup is encrypted with your passphrase and your random 15 words before it ever leaves your device. All the government sees is a blob of noise. Without your passphrase and words, it is computationally irretrievable - meaning the universe will have ended before anyone brute-forces it, and that’s not a metaphor, that’s a calculation.
Better yet, when you retrieve it, you don’t even log in. You use a zero-knowledge proof - again, honestly these things are useful - to prove you know the words without revealing which blob is yours.
Before anyone asks: no, you do not type fifteen words every time you want to check your self assessment. Nobody is suggesting that. The fifteen words live in your fireproof box for the same reason your passport does - not because you present them daily, but because the day you need them you really need them.
Day to day, this looks exactly like unlocking your banking app. Your face, or your finger, or your PIN if you’re the cautious type. The credential sits in your phone’s secure chip, unlocked by biometrics or PIN, and generates a fresh proof locally in the background while you’re still moving the phone to a comfortable reading angle. Sub-second. Nothing typed. Nothing transmitted except the proof itself, which as previously established reveals nothing useful to anyone.
The government’s servers register that a retrieval happened. They do not register whose retrieval it was. The audit log says “47 people recovered credentials today.” That’s it. That’s all it says.
The government actually makes a fantastic storage provider, because it doesn’t lose things (generally) and doesn’t go bust. It makes a terrible key holder, because it’s the government. This system gives it the first job and not the second. Which is roughly the correct division of labour for most things in life, now I think about it.
The objections, and why they’re wrong (mostly)
“What about people without smartphones?”
Again, the Post Office. Next.
“What if someone steals the 15 words?”
They also need the encrypted blob, which lives somewhere else entirely. Without both, they have nothing. Two things in two places needing to be stolen simultaneously is, as security properties go, considerably better than what we have now, which is your mother’s maiden name and the name of your first pet.
“What if you lose the 15 words?”
Fair point. This one I’ll give you, because it’s the only objection in this list that’s actually correct.
The 15 words are what cryptographers call a bearer instrument. Whoever holds them, wins. That’s fine when they’re sitting in your fireproof box in the spare bedroom. It’s less fine when the spare bedroom is on fire, or when the person with access to your spare bedroom is someone you’re trying to get away from. Domestic abuse situations in particular are a scenario where “something you wrote down at home” is a genuinely terrible recovery mechanism, and anyone who waves that away hasn’t thought about it seriously.
So, mitigations in ascending order of inconvenience if you lose your 15 words:
The words alone aren’t enough - you also need the encrypted blob, which lives somewhere else. Stealing the words without the blob is like stealing half a key. Annoying, but harmless. That’s already better than most systems.
For anything above “prove I’m an adult to watch a film,” you can require that re-binding the credential to a new device happens in person, with a biometric check, at a trust anchor - your bank, your GP, the Post Office. The words get you the blob. They don’t get you back into the system without also physically being you. Remote theft of your words, by someone who isn’t standing in front of a Post Office counter with your face, gets them nothing.
For the things that genuinely matter - your voting rights, anything that touches government services with real consequences - the correct answer is that there is no remote recovery at all. Words, cloud backup, none of it. You lose your device, you come in person, you prove who you are, you get reissued. Yes, that’s a trip to somewhere inconvenient. So is identity fraud. Pick one.
The 15-word model is the right answer for the low-stakes end of the system. For the high-stakes end, the inconvenience of in-person re-issuance isn’t a design flaw, it’s actually a security feature.
“The government will just pass a law requiring backdoors.”
Yes, a government could do that. Which is why the governance structure matters - super majority for change, and distribution of ledger nodes, open source everything so that adding a backdoor is immediately visible. You make the backdoor technically difficult and politically costly at the same time. Perfect? No. Better than a centralised database with one minister holding the master key? Considerably.
“Isn’t this just GOV.UK Verify?”
I wondered when someone would get there. The answer is: same postcode, different house.
Verify got the federation bit right - private sector providers, government not holding the credentials, identity checked by people who are already regulated to check identity. Directionally correct. Then it went wrong in almost every other direction simultaneously, which is an achievement of sorts.
The providers knew which government services you were using. The hub in the middle logged it. So there was absolutely a record somewhere that you’d visited HMRC on a Tuesday, which rather defeats the point of not having a central database if you’ve just distributed the surveillance across several smaller ones. Unlinkability wasn’t a design goal. It showed.
The credentials lived on Verify’s servers, not on your device. There were no zero-knowledge proofs - you weren’t proving you were over 18 or held a valid licence, you were proving you, which is a much blunter instrument and inherently reveals more than it needs to.
It also tried to be one system for all assurance levels, which meant it was too heavy for low-stakes use and not trusted enough for high-stakes use. As a result government departments refused to integrate it, so nobody got it, so departments had less reason to integrate it, and round and round until the whole thing quietly expired in 2023 having cost somewhere north of £130 million.
What I’m describing fixes the specific things Verify got wrong. Device-held credentials. Genuine unlinkability by design, not by accident. Zero Knowledge proofs so you reveal an attribute rather than an identity. A tiered model that doesn’t attempt to use the same mechanism for watching a film and accessing your medical records.
Verify was the rough draft. Rough drafts are useful. They tell you what not to do next time, assuming anyone bothers to read them.
“But surely the government can just join up HMRC, DWP and the DVLA and see everything anyway?”
Yes. They largely can already. That’s rather the point.
HMRC knows your tax history. DWP knows your benefits history. The DVLA knows your driving history. They share data under existing legislation, through existing data matching programmes, using your National Insurance number and name and date of birth as the join keys. None of that is new, none of it requires a digital identity system, and none of what is being proposed here changes it in either direction.
If you were worried about Whitehall cross-referencing your records before reading this, you were right to be, and you should probably still be. That’s a policy and legal problem, not a cryptographic one, and cryptography is not going to unwire twenty years of data sharing agreements.
What we’re talking about here is something different. Something that doesn’t exist yet but will, if the GOV.UK Wallet goes the way everyone with pattern recognition suspects it will.
A centralised identity layer that sits across every government service creates something that doesn't currently exist: a single choke point that logs not just what each department knows about you, but the fact of every digital interaction you have with the state, timestamped, cross-referenced, and queryable in one place.
HMRC knowing your tax history is one thing. A master spine that knows you checked your tax code on Tuesday, renewed your driving licence on Thursday, queried your Child Benefit on Friday, and booked a GP appointment on Saturday - and links all of those events to a single identity token - is a qualitatively different thing.
That's the surveillance infrastructure that doesn't currently exist and that we should be very reluctant to build.
The system I’m describing doesn't prevent DWP and HMRC cross-referencing your records through the means they already have. It can't and it doesn't claim to. What it does prevent is the identity layer itself becoming that master spine - because the proofs are unlinkable across services, the identity infrastructure logs nothing useful, and the new centralised choke point therefore never gets built.
The risk we’re already living with is real and needs addressing through law and policy. The risk we’re trying to prevent is the one we’d be building from scratch, on purpose, and handing the keys to whoever happens to be in office at the time.
One of those problems is hard. The other one we can just choose not to create.
“Won’t someone think of the children?”
This is, in fact, the entire original problem we were trying to solve. The age verification use case is the easiest one. You get a credential that says “over 18” - nothing else, not your name, not your address, not anything - and you use it. The website sees “adult: yes.” Done. No passport uploaded to a company registered in Gibraltar you’ve never heard of. No algorithm staring at your face trying to decide if you’re old enough to read Reddit. Simples!
Why this won’t happen, and what might instead
There’s a version of this that’s technically perfect and politically impossible, and a version that’s technically adequate and has a fighting chance.
The technically perfect version requires the government to do several things it is constitutionally averse to:
Not building a database,
Not owning the system,
Distributing power to institutions it doesn’t control, and
Trusting maths over ministerial assurance.
The current Whitehall disposition on all four of these is, to put it diplomatically, hostile.
The version with a fighting chance is to start with one use case - age verification - using existing bank infrastructure with blind group signatures, get it working, and build the rest around it.
You don’t need to boil the ocean on day one.
You need one thing that works and that people actually use, which creates enough of a constituency to defend it when the inevitable redesign consultation appears eighteen months later.
The summary, for people who skipped to the end
What you want is:
Banks and similar institutions sign credentials.
Credentials live on your phone.
Zero-knowledge proofs let you prove things without revealing things.
A distributed ledger nobody owns records only validity - no personal data.
Recovery uses a passphrase and secret words - 15, possibly more, the cryptographers can argue about it - to create an encrypted blob that can be stored by the government but cannot be read by them.
No central identity database exists.
No central database means nothing for a hostile government or a hostile foreign power to exploit.
The cryptography for all of this is mature, tested, and boring in the best possible way. Boring cryptography is good cryptography. Exciting cryptography is the kind that ends up on a security researcher’s conference talk three years later with the word “catastrophic” in the title.
The political will to build it is, I concede, currently somewhere between “negligible” and “there’s a more promising avenue in the Mariana Trench.” But the correct response to that is not to build something worse. The correct response is to be annoying about it in public until the right people get embarrassed enough to do it properly.
I’ve been doing that since 2005. I have plenty of stamina.
Note: If your eyes are glazing over, be thankful this is not a paper that covers things like time-locked revocation, N-of-M word sharding, federated notary custody, and about fifteen other scenarios a threat model probably doesn't need. This is not that document, but I might be working on it.