Most identity products give you a link that asks their server whether something is real. We give you a file that answers the question by itself — offline, in twenty years, whether or not ProntoID still exists.
This page explains how that works, and what it does and does not prove.
Almost everything on this page follows from one distinction. Once you have it, the rest of the design explains itself.
The credential carries a reference — a link, a code, an identifier. To learn whether it is real, you must ask the issuer's server. The answer exists only for as long as somebody keeps that server running and honest.
The company folds, the domain lapses, the database is edited — and every credential ever issued becomes worthless, silently.
Everything needed to check the credential is captured into it at the moment it is created, and never needed again. The issuer was involved once, at the start, and is then out of the picture permanently.
A dependency that has already been satisfied cannot fail later. That is the whole trick.
Vendors describing their credentials as tamper-proof or immutable usually mean the first kind. The claim is technically true and practically hollow: nobody can alter the record, because only the vendor can read it. Ask which server is contacted when a third party checks a credential. If the answer is the vendor's, the credential is a lookup with extra steps.
If you travelled in Europe between 2021 and 2023, you carried a credential built almost exactly this way — and you watched it being verified, probably hundreds of times.
The Covid certificate was not a link to a database. The QR code contained the signed information. Verifier apps kept a cached copy of every country's public keys, so an Italian app could check a German certificate with no contact between the two countries, no account, and often no signal at all.
That system was retired in 2023 and its architecture was adopted by the World Health Organization for global use. The design outlived the law that created it — which is the strongest possible argument for choosing this shape rather than inventing one.
Five stages happen at ProntoID. Everything after the line happens without us.
The person photographs their identity document and completes a liveness check. The document is read, its machine-readable zone parsed and check-digit validated, and the live face compared against the portrait on the credential.
The results become a fixed set of statements. Names and dates are taken from the document's machine-readable zone, never from anything the person typed. The claim set is then serialised into one exact, reproducible sequence of bytes.
A cryptographic seal is applied over those bytes, together with a trusted timestamp recording when it happened. Any later change to any character produces a different result, and the seal stops matching.
The sealed claims are wrapped for their audience: a signed PDF for people and courts, a machine-readable file for software, and a wallet credential for the person themselves. One set of facts, three envelopes.
The full record goes to whoever needs to keep it — the relying party, the person, or both. ProntoID keeps only a fingerprint of it, which is enough to prove the record is unaltered and not enough to reconstruct it.
Everything below happens with no contact with ProntoID of any kind. If the company closed this afternoon, nothing beneath this line would change.
The recipient opens the file. Their software recomputes the seal over the bytes in front of it and compares. A match means nothing has changed since the moment of sealing; a mismatch means something has, down to a single character.
The same sealed facts travel in three envelopes, because a court, a server and a phone need different things from the same truth.
A sealed PDF. It opens in any reader, shows the checks in plain language, and displays a validated seal without any additional software. This is the form that goes into a case file or a professional archive.
The claims as structured data with a detached signature, attached to the PDF so the two never separate. Any system can read the facts and check them independently, in any programming language.
A wallet credential held on their own device and bound to a key only they control. They can prove a single fact — that they are over eighteen, say — without revealing the rest.
A sealed document proves something about a person. It does nothing to stop somebody else presenting a copy of it. That is fine where a professional is looking at the client while they read it, and useless for a credential carried in a pocket. Binding the credential to a key on the holder's own device is what turns a well-sealed document into an identity credential.
Each of these removes a feature a customer has, at some point, asked for. Each is load-bearing: add the feature back and the portability quietly disappears, usually without anyone noticing until it matters.
We would rather explain a limitation now than have it discovered later by someone relying on the result.
A credential says that specified checks were run at a specified moment and produced specified results. That does not stop being true later. Building a way to withdraw it would mean every verifier had to ask us whether it still counts — which is the dependency we removed. Where current status matters, that is a different question and a separate service.
A person types their name into a field; the credential records what the machine-readable zone of their passport says. Where the two differ, the document wins and the discrepancy is reported. A claim that can be typed is a claim that can be chosen.
ProntoID retains enough to prove a credential is unaltered, and not enough to reconstruct what it said. The record itself lives with whoever is obliged to keep it. If you stop working with us, nothing of yours leaves with us — it was never here.
The specification and a working verifier are published under an open licence, so a credential can be checked by software we did not write and will never see. A format that only its author can read is not portable, however good the cryptography.
Cryptography is unusually good at persuading people it has settled questions it has not touched. Two things are worth separating.
If a face-matching model is miscalibrated, the seal preserves the wrong answer perfectly and permanently. Closing that gap is a matter of process and independent audit — certification, published accuracy rates, external assessment — and no amount of mathematics substitutes for it. Anyone claiming otherwise is selling the wrong thing.
That a third party can confirm a credential is genuine and unaltered using only the file in front of them, a public trust list, and ordinary software. No account with ProntoID, no API call, no network connection, and no permission from us. If any of those are required, the credential is not portable — it is a lookup.
A link like verify.example.com/abc123 proves only that a server answered. It tells you nothing if the server is offline, the company is gone, or the record has been quietly edited. A signature is arithmetic performed over the actual bytes of the document: it either matches or it does not, and it gives the same answer in ten years on a laptop with the network cable pulled out.
Architecturally, very close. The Covid certificate carried its own signed payload and was checked offline against a cached list of national public keys, which is why an Italian app could verify a German certificate with no contact between the two countries. We use the same shape, with two additions it did not need: long-term validation, so credentials stay verifiable for decades rather than months, and selective disclosure, so a verifier can be shown one fact rather than the whole record.
Nothing changes for credentials already issued. The trust anchor is a public register maintained by state authorities, not by us. The specification and the reference verifier are published under an open licence. No key, server, or cooperation of ours is involved in verification, so our absence is not detectable from the verification side.
Deliberately not. A credential records that specified checks were run at a specified moment and produced specified results. That statement does not stop being true later. Building a revocation list would mean every verifier had to contact us to check current status — which reintroduces exactly the dependency the design removes. Where a relying party needs current status rather than historical fact, that is a separate question and a separate service.
Two things: the credential has not been altered since sealing, and it was sealed by the holder of the named key. It does not prove that the checks it records were correctly performed. That is a matter of process and audit, evidenced by certification and published accuracy rates, and no amount of cryptography can substitute for it.
Yes, where the credential is issued to a person rather than to a relying party. It is bound to a key held on their device, so presenting it requires proving possession of that key. A copied file is not enough. This is what distinguishes an identity credential from a document that merely mentions someone.
It would reintroduce the dependency we set out to remove: verification would require that a particular chain still exists, is still queryable, and that the verifier has access to it. It also carries no legal weight in Switzerland or the EU, where a qualified timestamp already benefits from a statutory presumption of accuracy. It is more moving parts for a weaker result.
The format, the canonical byte rules and a working verifier are published openly. The best way to trust this is not to take our word for it.
Swiss-operated · Open specification · Offline verification