On 1 September 2026, KrebsOnSecurity reported that a dark web service was selling scans of more than 153 million driver's licences from the US and Canada, alongside identity cards, travel documents and medical cards.
The reporting traced the likely source to an identity verification vendor that processes over 21 million verifications per month across 20,000+ locations. The operators claimed they had been exfiltrating continuously for over a year. The FBI has opened an investigation.
I want to skip the outrage and look at the architecture, because the architecture is the story.
The shape of the failure
Consider what each verification event actually needed to establish:
- Car rental: this person holds a valid licence, and is the person on it
- Cannabis dispensary: this person is over 21
- Alcohol delivery: this person is over 21
- Hotel check-in: this person is who they claim to be
Every one of those is a predicate. A boolean. The answer is one bit.
What was transmitted and retained instead: name, address, date of birth, document number, portrait, signature, issue and expiry dates, plus infrared and ultraviolet captures of the physical document.
A one-bit question was answered with a multi-megabyte artefact, which was then persisted by a third party.
That persistence is the vulnerability. Not the network perimeter, not the access controls, not whatever the forensic firm eventually finds. Those are proximate causes.
The root cause is that a system was designed so that verification implies collection.
Why this class of data is uniquely bad
Credentials have a rotation story. Passwords get changed, keys get rotated, tokens expire. The blast radius of a leak is bounded by how fast you can rotate.
Identity documents have no rotation story.
- Date of birth is immutable
- Biometric portrait is effectively immutable
- Address history is append-only
- Even reissuing a licence gives you a new number attached to the same underlying person
So the correct mental model for a leaked ID scan is not a compromised credential. It is a permanent capability grant to anyone who buys it.
And the reporting notes the data includes people in witness protection and people who have fled domestic violence, for whom the threat model is not financial.
The minimisation argument, stated precisely
A system cannot lose data it does not hold.
This sounds trite until you treat it as a design constraint rather than a platitude.
Under a collection model, your security posture is a function of every control you maintain, forever, across every vendor and subprocessor who touches the data. It degrades over time. It requires perpetual investment. It fails eventually, on a long enough timeline, for everyone.
Under a proof model, there is no data at rest to protect. The verifier's breach exposure for that class of data approaches zero, because the class of data was never created.
This is not a claim that proof systems are unbreakable. It is a claim that they move the failure mode from inevitable and catastrophic to bounded.
How verifying without collecting actually works
The primitive is a zero-knowledge proof: prove a statement is true without revealing the data that makes it true.
The practical flow:
- A trusted issuer (DMV, bank, government service) verifies your identity once and issues a credential you hold on your own device
- A verifier needs to check something specific
- Your device generates a proof of that predicate only
- The verifier checks the proof against the issuer's signature
Traditional:
user ──[ full licence scan ]──> verifier ──> storage ──> breach
Proof-based:
user ──[ proof: age >= 21 ]──> verifier ──> (nothing to store)
Prove age over 21 without revealing date of birth. Prove licence validity without revealing licence number. Prove residency without revealing address.
The verifier gets a cryptographically sound yes or no. It receives, and therefore stores, nothing else.
The privacy property is not policy. It is not a promise in a data processing agreement. The verifier cannot leak your date of birth because it never received your date of birth.
Where Midnight fits, and where it doesn't
I build on Midnight, so I'll declare the bias up front.
Midnight is a blockchain designed around this idea rather than retrofitted for it. It maintains separate public and private state, so sensitive data stays on the user's device and never reaches the chain. Its smart contract language, Compact, enforces the boundary at compile time. Attempting to move a private value into public state is a compilation error, not a lint warning:
potential witness-value disclosure must be declared but is not:
witness value potentially disclosed:
the return value of witness get_amount at line 8 char 1
nature of the disclosure:
ledger operation might disclose the witness value
That last detail matters more than it sounds. In most systems, data minimisation is a policy that a tired developer can violate on a Tuesday. Making it a compiler error changes who has to remember.
What I am not claiming: that this is deployed at rental counters today. It is not. There is no path right now where you present a ZK proof to a clerk with a document scanner and a vendor contract. The infrastructure gap is real and large.
The claim is narrower, and I think harder to dispute: the failure here was architectural, not operational. The alternative architecture exists and works. What is missing is the incentive to adopt it.
The incentive question
Collection persists because it is currently cheap and proof is currently expensive, in integration effort, not compute.
Three things change that calculation:
- Liability. If holding identity documents becomes an uninsurable risk, holding them stops being free
- Regulation. Data minimisation is already law in several jurisdictions, but enforcement targets breach response rather than collection design
- Standards. Verification is a solved problem cryptographically and an unsolved problem in plumbing. Whoever makes the integration trivial wins
Engineers reading this have more leverage on the third than anyone else does.
The takeaway
The next time you specify an identity check, ask what predicate you actually need to satisfy. Then ask what you are about to store, for how long, and who inherits the liability.
If those two answers are wildly different sizes, you are building a honeypot. It may not leak on your watch. On a long enough timeline it leaks on somebody's.
153 million people answered a yes-or-no question by handing over everything.
The technology to just say yes already exists.
Top comments (0)