COMPREHENSIVE MARKET

Use cases for issuer-attested verification

Live Verify: the next logical step up from the iPhone's Live Text.

Live Verify turns a printed claim into a trustable handshake: snap the document, OCR locally, hash it, and confirm the issuer domain still serves that hash. Think of it as a trust primitive for the physical world: readable text that can also be checked.

Industries

Use Cases

with

Further Derivations

Snap → OCR → hash → check

Documents carry a verify: line that points to the issuer’s domain. Live Verify automates the rest: capture, OCR, normalization rules, SHA-256, then GET the issuer URL with the hash. The app flashes “Claim Verified” only if that domain currently vows to that exact text hash.

Snap
Use the camera app to frame the verification mark.

OCR + normalize
Text is normalized on-device (rules only) before hashing.

SHA-256
Hash the normalized text, not the image.

Verify
GET https://issuer.example.com/claims/<sha256>; 404 = not found, 200 = status returned (OK / REVOKED / etc.).

Example verification line:
verify:issuer.example.com/claims ... implies a lookup at ...
https://issuer.example.com/claims/<sha256>
The phone trusts the domain only if the hash matches and the issuer returns an affirming status (e.g., “OK”). Status meanings can be described in verification-meta.json.

What “Verified” means

The issuer domain now attests to the same exact normalized text hash.
The issuer stands by the claim while it remains “OK”; if they don’t, they change it (e.g., “REVOKED”) or delete the record entirely.
You decide whether that domain is an authority for the claim.
Look out for lookalike/typosquatted domains: verifiers should see the domain clearly before trusting it.

Verifications are revocable

Revocation is part of trust. If an ID is stolen, a license suspended, or a credential withdrawn, the issuer can change the response so verifiers stop treating the printed claim as current. Some issuers may return an operational instruction, e.g. Stolen ID — please retain/cut in half and contact <policy URL> (quoting reference Nnnnnnn).

Sovereign, no gatekeeper

Issuers keep authority by publishing from their own domains, and verifiers choose what they trust. There’s no single global registry to control access—at the cheapest end, a static web server can host the hash lookups.

The result is anti-fraud without friction: the familiar camera flow becomes “Snap → Verified / Denied” at the point of use.

Privacy

OCR, normalization, and SHA-256 run entirely on-device, and the only outbound call is the hash lookup. Learn why one-way hashes are safe to publish via our one-way hash explainer and see the full protocol in the Privacy Declaration.