HONEST COMPARISONS

How is this different from…?

The right first reaction to any trust standard is “how is this not one of the ten that already exist?” Here is the honest answer for each system Live Verify gets compared to — what it's genuinely good at, and the specific gap Live Verify sits in. Several of these are complementary; where that's true, we say so.

The one-line frame: most of these systems secure a channel, a signature, or a wallet. Live Verify secures the document itself — a printed or on-screen claim that a stranger can check against the issuer's own domain in four seconds, with no account, no app store, no key ceremony, and no coordination between issuer and verifier beforehand. The pipeline is just text → normalize → SHA-256 → GET.

W3C Verifiable Credentials & DIDs

The W3C standard for cryptographically signed claims held in a digital wallet

Verifiable Credentials (VCs) are the most serious standards effort in this space: an issuer signs a structured claim, the holder stores it in a wallet, and a verifier checks the signature against the issuer's decentralized identifier (DID). It is genuinely strong for selective disclosure (prove you're over 18 without revealing your birthdate) and for fully digital, wallet-to-verifier flows.

Where Live Verify differs: VCs assume a wallet, a signing-key infrastructure, and a verifier that speaks the same DID methods as the issuer — three coordination problems Live Verify doesn't have. A Live Verify claim is plain text on paper or a screen; the “wallet” is your camera or a text selection, and the trust root is DNS, which every party already agrees on. Live Verify gives up selective disclosure and rich signed schemas; in exchange it works on a photocopied certificate held by someone who has never heard of the standard. The two can coexist — a VC issuer could publish Live Verify hashes for the human-readable printout of the same credential.

C2PA / Content Credentials

Cryptographically signed provenance metadata embedded in media files

C2PA (the standard behind Adobe's Content Credentials) attaches a signed manifest to an image or video recording its origin and edit history. It is the right tool for “where did this photo come from and what was done to it?” and is being adopted by camera makers and AI image tools.

Where Live Verify differs: C2PA lives inside the file and answers a provenance question about media. It doesn't survive a screenshot, a printout, or a re-photograph, and it says nothing about a plain-text claim on a certificate. Live Verify binds to the readable text, so it survives print, photocopy, and re-photograph — the exact transformations that strip C2PA metadata. Different questions: C2PA asks “is this pixel history intact?”; Live Verify asks “does the named issuer stand behind this claim right now?”

DocuSign & e-signatures

Platforms for signing agreements and proving who signed what

E-signature platforms are excellent at their job: capturing legally weighty consent to a contract, with an audit trail of who signed and when. Under regulations like eIDAS and the US ESIGN Act, a qualified e-signature carries real legal force.

Where Live Verify differs: an e-signature proves a party agreed to a document; Live Verify proves the issuer currently attests to a claim — and can revoke it. A signed PDF is fixed at signing time; a Live Verify lookup is answered live, so a licence can go from verified to revoked the moment the issuer changes its records. Live Verify also needs no signing account for the person checking, and works on a paper document no one ever put through a signing workflow. They're complementary: sign the agreement with DocuSign, publish a Live Verify hash so anyone handed a copy later can confirm it's the genuine, still-valid version.

QR-code verification portals

A QR code on a document linking to an issuer's “is this real?” web page

A QR code that opens the issuer's verification page is the closest thing to Live Verify in spirit, and for many documents it's a reasonable control. It's familiar and needs no special app.

Where Live Verify differs: a QR code is a pointer, not a proof. It links to a page, but nothing ties that page to the specific text printed on the document — a forger can copy a genuine QR code onto a fake certificate and the portal still says “valid.” Live Verify hashes the actual claim text, so altering a single character breaks the match. And a QR code commits you to a live web portal per issuer; Live Verify's endpoint is a static file, and the check runs against the plain text even with no QR code present at all.

Government verification portals (E-Verify, UK Share Code, VEVO)

Official government sites for checking work eligibility, immigration, or licence status

Government portals are authoritative for what they cover — E-Verify for US work eligibility, the UK right-to-work Share Code system, Australia's VEVO for visa status. When one exists for your exact question, it is usually the right primary source.

Where Live Verify differs: these portals are per-jurisdiction, per-document-type silos, each with its own login, workflow, and coverage gaps — and most document types have no portal at all. Live Verify is one uniform gesture across every issuer that adopts it, from a national government to a one-person training provider, with the authority still rooted in each issuer's own domain. It doesn't replace E-Verify; it extends the same “check it against the source” idea to the vast majority of documents that will never get a government portal.

Certificate Transparency & Merkle Tree Certificates

The transparency-log and Merkle-proof machinery securing the web's TLS certificates

Certificate Transparency (Google's approach to making TLS certificate issuance auditable) and the newer Merkle Tree Certificates (Cloudflare, Chrome, and the IETF, for the post-quantum era) are the most credible players in web trust — and they reach for the same primitives Live Verify uses: Merkle inclusion proofs and per-issuer transparency logs. That's validation, not competition.

Where Live Verify differs: all of this machinery secures the channel — it proves you're talking to the genuine server. It says nothing about whether the document that server hands you is genuine, which is Live Verify's entire job. They're two layers: CT/MTC secure the pipe, Live Verify secures the paper that comes through it. (More detail in Merkle Tree Certificates as precedent.)

Blockchain & NFT credentials

Credentials anchored to a distributed ledger or minted as tokens

Blockchain credential schemes aim at the same goal — tamper-evident, independently checkable claims — and a ledger does give you an immutable, publicly auditable record.

Where Live Verify differs: a blockchain's permanence is the wrong property for fraud-fighting. The most important thing an issuer must be able to do is revoke a claim when someone is struck off, a licence lapses, or a document is superseded — and a live HTTPS lookup does that instantly, while a ledger entry is forever. Live Verify has no ledger, token, mining, or consensus network: a verification is a plain HTTPS GET against the issuer's own server, and the authority you trust is a domain name (gov.uk, intertek.com), not a chain. It's the boring plumbing on purpose — the document carries a link, and checking it is like checking a tracking number.

Try the ten-second demo Read the case against Live Verify Back to home

This page is print-friendly — forward it to whoever's doing the technical due diligence.

Live Verify is an open standard begun by Paul Hammant · paul@hammant.org · Source & spec on GitHub