- Conventional verification collects far more than the question required, then stores it indefinitely.
- ProntoID keeps credentials on your device and releases proofs — a platform learns the answer, not the document.
- Selective disclosure, the on-device vault and peer-to-peer verification links are live today.
- The consent dashboard is in build; passkeys and card protection are on the roadmap and clearly marked as such.
Who is the system actually for?
Think about the last time you verified your age online. You probably photographed a passport — a document containing your full name, date of birth, nationality, document number, place of birth and a machine-readable zone — to answer a question with two possible values.
Everything beyond that boolean was surplus. It was collected because the form was built to collect it, stored because deleting things is harder than keeping them, and secured to whatever standard that particular company happens to manage. Multiply by every service you have ever signed up to, and your passport now exists in a few hundred places, each one a target, none of which you can inspect.
This is not anyone's villainy. It is the natural output of building verification tools for the party with the compliance obligation. The platform is the customer, so the platform's convenience shapes the design, and the person handing over the document is treated as an input to be processed.
ProntoID is built to act for the individual. Your credentials stay in a vault you control, and what leaves it is a proof answering a specific question — not a copy of the document that could answer any question.
That single change cascades. If platforms never receive raw documents, there is no honeypot to breach. If proofs are scoped to a question, there is nothing surplus to monetise. And if every disclosure is recorded on your side, consent becomes something you can review and withdraw rather than something you agreed to once and forgot.
The vault, end to end
Six capabilities make up the picture. Three are live, one is in build, and two are still ahead of us — marked honestly below, because a roadmap presented in the present tense is just a different kind of over-collection.
What each one does
Prove the fact, not the document
Available nowWhat it does A platform asks whether you are over 18, or whether you are a real person. ProntoID answers that question and nothing else — no birthdate, no full name, no address, no document number.
Why it matters to you Most over-collection is habit rather than requirement. An age gate needs a boolean; it receives a passport scan because that is what the form was built to accept. Answering the actual question satisfies the obligation without adding your documents to another marketing database.
Your credentials stay on your device
Available nowWhat it does Verified credentials are sealed into your phone's secure enclave. Access is gated by your device biometrics. Presenting a credential produces a proof; it does not produce a copy of your ID.
Why it matters to you Every organisation holding a scan of your passport is a place your passport can leak from. Keeping the original on one device you control, and distributing only proofs, removes you from a long list of databases you never chose to be on.
Prove you are real to another person
Available nowWhat it does Generate a shareable link or QR code that confirms you are a verified human — for a marketplace handover, a dating match, a first meeting with a client.
Why it matters to you The usual way to reassure a stranger is to hand over something you cannot take back: a phone number, a social profile, a photo of your ID. A verification link proves the thing that matters and leaks nothing that does not.
See who asked, and shut it off
In buildWhat it does One audit trail covering every platform, app and person that has requested a verification from you — with a per-platform revoke control.
Why it matters to you Rights you cannot exercise are not much use. Knowing exactly which services hold a live permission, and being able to withdraw one in a tap, turns an abstract legal entitlement into something you can actually do on a Tuesday evening.
Logins bound to you, not to a password
On the roadmapWhat it does A portable FIDO2 passkey keychain, unlocked by a local face check, replacing passwords and SMS codes across the sites you use.
Why it matters to you Passwords leak in bulk and SMS codes can be intercepted or socially engineered away. Passkeys are bound to the site that issued them, which removes phishing as a category rather than asking you to spot it.
A face check before the money moves
On the roadmapWhat it does Link a card to your verified identity so that high-value online purchases require a two-second local biometric check before an authorisation token is released.
Why it matters to you Card-not-present fraud works because card numbers travel and the cardholder does not. Requiring something that cannot be copied out of a breached database — you, present, right now — closes that gap at the point it matters.
Two models, side by side
The difference is easier to see as a set of trade-offs than as a manifesto.
| Category | Conventional verification | The ProntoID model |
|---|---|---|
| Who holds the ID | Each platform takes a full copy and retains it on central infrastructure. | You do. The original stays encrypted on your device; platforms receive a result. |
| What gets shared | Everything on the document, because the document is the unit of exchange. | Only the specific claim requested — "over 18", "verified human", "name matches". |
| Breach exposure | Hundreds of separate databases hold your passport. Any one of them can leak it. | No central store of document scans to breach in the first place. |
| Who it is designed for | The platform's legal team. You are the input being processed. | You. The platform gets a clean answer; you keep everything else. |
| Withdrawing consent | Buried in settings, if it exists at all, with no record of who asked. | A running list of every request, with a revoke control against each one. |
What this model does not solve
It would be easy to end here, but a privacy claim is only worth as much as the caveats attached to it. Three things are worth stating plainly.
- Revocation is not erasure. Cutting off a platform's permission stops future disclosures. It does not reach into data that platform already holds, some of which it is legally required to retain. What you get is the evidence trail to make an erasure request properly.
- Some checks genuinely need more than a boolean. A regulated bank running anti-money-laundering checks has statutory duties that a yes-or-no proof cannot discharge. Minimisation means sharing what the obligation actually requires — which is sometimes more than nothing.
- On-device storage shifts the recovery problem to you. There is no server-side copy of your credentials, so a lost phone means re-verifying rather than restoring. That is a deliberate trade: a copy that can be restored can also be taken.
We would rather publish those constraints than have you discover them later. A tool that oversells its guarantees is a tool you will trust in exactly the situation where you should not.
Where this is heading
The near-term work is the consent dashboard: a single view of every request made of you, with revocation attached. It is the piece that turns the rest of the vault from a set of features into something you can hold a platform to.
After that, the passkey keychain and card protection extend the same idea from proving who you are to authorising what you do. The pattern is identical in both cases — keep the secret on the device, release a scoped, single-purpose token, and make the thing an attacker would need to steal something that cannot be copied out of a database.
Verification is not going away; regulation is heading firmly in the other direction. The open question is whether the person being verified ends up with more exposure or less. We are building for the second answer.