Private, open source ID verification

The Problem #

Governments around the world are pushing age verification mandates under the banner of child safety. The intention sounds reasonable — but the implementations being proposed almost universally require centralized identity submission to private companies or government databases.

This creates two serious risks:

1. Surveillance infrastructure disguised as protection. Once a central ID verification system exists, it becomes trivially easy for corrupt or authoritarian governments to repurpose it for mass surveillance, censorship, and control. The infrastructure is the threat, regardless of the stated intent.

2. Catastrophic breach potential. Any centralized store of government IDs is a honeypot. When (not if) it gets breached, millions of people have their identity documents leaked permanently. You can’t rotate a passport number the way you rotate a password.

Meanwhile, effective tools for protecting children already exist: built-in parental controls at the OS level, device-level content filtering, and family account management, all of which work without requiring every adult on the internet to hand over their identity to a third party.

The Proposal #

An open-source, locally-run application that:

1. Accepts a government-issued ID document (scan or photo).
2. Verifies the document’s authenticity on-device (using local AI / document verification models).
3. Extracts only two data points: whether the person is over or under 18, and the date of verification.
4. Produces a signed, cryptographic proof containing only those two fields.
5. Destroys all raw ID data immediately after proof generation. No image, no name, no document number is retained.
6. Outputs a reusable proof token that any compatible app or service can accept.

That’s it. No server. No upload. No central database. No company holding your ID. The proof is yours, stored on your device, shared only when you choose. And other apps and services accept this proof as age verification.

High-Level Architecture #

Key Design Principles #

Nothing leaves the device #

The raw identity document is processed entirely on-device. No image is uploaded. No OCR result is sent to a server. The verification model runs locally. After the proof is generated, the source material is wiped.

The proof reveals the minimum possible #

The signed token contains:

• Age bracket: over 18, or under 18. Not the birth date. Not the exact age.
• Verification date: so services can decide how fresh they need the proof to be.

That’s all. No name. No photo. No document number. No nationality. Nothing linkable to a specific person.

Open source and reproducibly built #

The entire application — AI model, verification logic, cryptographic signing — must be open source. Anyone can audit the code, compile it independently, and verify that the binary distributed through app stores matches the public source.

For mobile platforms (Android, iOS) where sideloading is impractical for most users, this means:

• Public CI/CD pipelines that produce the store builds.
• Reproducible builds so that anyone can compile from source and get a byte-identical output.
• Supply chain attestation (e.g., SLSA, Sigstore) to prove the published artifact came from the audited source.

Re-verification, not perpetual tokens #

Proofs should have a configurable expiry. Services can require re-verification periodically (e.g., every 6 or 12 months). This keeps the system fresh without requiring a persistent identity link.

Users can re-verify at any time by repeating the process with their ID document. Each re-verification is independent — no history is kept.

Proof access is controlled by the user #

The proof token lives in the user’s secure device storage, protected by the same PIN, biometrics, or lock screen that protects the device itself. A parent who wants to prevent a minor from accessing their proof simply keeps their device locked — no additional mechanism needed.

No single point of control #

There is no company that “runs” this system. The app is open source. The proof format is an open standard. Any service can choose to accept proofs. No single entity can be pressured by a government to add backdoors, logging, or identity correlation — because there is no central entity to pressure.

How Services Integrate #

Services that want to gate content by age simply:

1. Accept the open proof format.
2. Verify the cryptographic signature.
3. Check the age bracket and verification freshness.
4. Grant or deny access.

They never see the user’s name, face, document, or any other identifying information. They don’t need to. The only question they’re answering is: “Is this person old enough?” — and the proof answers exactly that, nothing more.

What About Hardware Companies? #

Companies that sell hardware compatible with Linux have an even simpler path: ship hardware with no OS, or with an open-source OS that includes parental controls at the system level. No age verification infrastructure needed — the parent controls the device directly.

The harder case is software companies — game platforms like Valve, social media services, content platforms. For them, this proof-based system is the answer: they don’t need to verify identity themselves. They just need to accept a proof that someone else’s device already generated locally.

What This Prevents #

What This Does NOT Do #

This is not a silver bullet. It does not:

• Replace good parenting and OS-level device controls, which remain the first and best line of defense.
• Solve the problem of services that want to collect identity data for their own purposes (ad targeting, profiling). Those services will resist this approach precisely because it gives them less data, not more.

But it does solve the core policy problem: it gives lawmakers a technically sound, privacy-respecting answer to “how do we verify age online?” that doesn’t require building surveillance infrastructure.

Call to Action #

This is an open proposal. If you’re a cryptographer, a mobile developer, an open-source maintainer, a policy advocate, or just someone who cares about both child safety and civil liberties — this needs your input, your code, and your voice.

The worst outcome is that we let “protect the children” become the argument that ends privacy for everyone. The best outcome is that we build the tool that proves it was never a necessary trade-off.

If you’re working on something related or want to collaborate, reach out. This idea is free to take, fork, and build on. No permission needed.