Standards

Real documents. Checked, not claimed.

Acme reads the chip in a passport and verifies the signature a State put there. It carries a driving licence as an ISO mDL and presents it to a reader over Bluetooth. It asks DVLA what DVLA’s own record says. And it issues credentials in the formats the rest of the world is converging on — with the identifiers written down, so anyone can check us against the specification rather than against our adjectives.

SD-JWTRFC 9901
SD-JWT VCdraft-ietf-oauth-sd-jwt-vc-19
W3C VCData Model 2.0
ISO mdoc / mDLISO/IEC 18013-5:2021
Photo IDISO/IEC TS 23220-4
ePassportICAO Doc 9303
DTC-VC Type 1ICAO TRIP Guide
OpenID4VCI1.0 final
OpenID4VP1.0 final
Token Status Listdraft-ietf-oauth-status-list-21

How a document earns belief

Three routes, and they are not interchangeable.

Everything else a phone can do to a document — read the print, watch a hologram flash, measure the card — reasons about an object, and a good forgery passes all of it. These three are the routes that reach past the object to somebody accountable.

Read the chip

Attested by The issuing State

A passport or chipped ID card carries a security object its national authority signed. We copy it, we check it, and we keep it — we never re-sign it.

The MRZ is read from the data page and unlocks the chip (ICAO Doc 9303 Part 11).
Every data group the chip declares is read over an encrypted session.
Passive Authentication: the hashes match, the signature verifies, the signer chains to a country root ICAO publishes.
The security object and the data groups are stored, so any check can be redone later.

What it cannot doPassive Authentication verifies data, not hardware. A byte-perfect clone of a real passport passes every check here. Chip Authentication is what addresses that, and it is not built.

Ask the authority

Attested by The issuing authority, on request

A UK photocard has no chip. The holder gets a check code from DVLA, and the verifier redeems it at DVLA under their own name.

The holder signs in to DVLA and generates a check code.
The wallet stores the code as a bearer secret and hands it to a verifier when asked.
The verifier reads DVLA’s own record. The platform is not in that request and learns nothing from it.
What the camera read off the plastic is cross-checked against the record the holder can see.

What it cannot doA record the wallet read off a web page is the holder’s own copy, not an attestation. It corrects OCR; it never replaces the verifier’s own lookup.

Have it reviewed

Attested by An authorised issuer

For everything with no chip and no register — a degree, a membership, a role — evidence goes to a reviewer who is authorised for that specific credential type.

The holder claims, and attaches evidence: documents, a chip read, a records match.
Automated checks run. A check is an input to a policy, never a conclusion.
A reviewer authorised for that credential type decides, and is accountable for it.
Policy decides whether that approval is sufficient, and only then is a credential issued.

What it cannot doA self-assertion never silently becomes issuer-verified. Assurance can rise, but an issued credential’s assurance is frozen — raising it means re-issuance, never a quiet edit.

Chip documents · ICAO Doc 9303

The State already signed it. We copy it, and check the signature.

A passport chip stores each data group separately and one signed object listing a hash of each. That object is signed by a national Document Signer whose certificate travels inside it, and that signer was certified by the country’s own root. Passive Authentication is those three facts, checked in order and reported separately — because they fail for different reasons and mean different things.

Two trust stores, on the phone

907 country signing certificates, whole, so a chain can actually be verified — and 31,866 document-signer fingerprints, because 45 MB of certificates will not fit on a phone and recognising a published signer is an honest, weaker statement.

The evidence is kept, not summarised

The security object and the data groups are stored, so a verifier — or this app after a trust-store update — can redo the whole check from scratch. A stored verdict is a claim about the past that nothing can re-examine.

Completeness decides what it may be called

ICAO’s bar for a Digital Travel Credential is an exact copy of the chip. Read a useful subset and you have a micro-credential, not a DTC — so the wallet reads what EF.COM declares, and names the difference when something is missing.

What opened the chip is recorded

Basic Access Control derives its key from three fields printed on the data page. That is perhaps 50 bits of entropy and it has been breakable since 2007. Whatever a chip was read with is shown, so nobody is told their credential is stronger than the mechanism behind it.

A national ID card is not a passport

Chipped identity cards read through the same machinery and are presented as their own kind of document. Two things that verify differently must never render identically.

And a clone would pass

Passive Authentication verifies data, not hardware. A byte-perfect copy of a real passport satisfies every check on this page. Chip Authentication is what addresses that, and it is not built — so nothing here says “genuine passport”.

ISO/IEC 18013-5 · device retrieval

A licence, shown to a reader, with no network on either side.

The holder’s phone shows a QR code; the reader connects over Bluetooth Low Energy; both derive session keys from a transcript of that exchange. The reader names the elements it wants and receives only those — the rest stay in the document as salted digests, so it remains complete and the verifier learns nothing it did not ask for.

Five questions, five answers, and no sixth that sums them

Issuer signature

Was this document signed by the certificate it carries?

COSE_Sign1 over the Mobile Security Object, verified with the document signer’s key.

Issuer trust

Is that signer one we have any reason to believe?

A chain to an IACA root the deployer supplied. With no anchor supplied it reads NOT CHECKED, never PASSED.

Data integrity

Do the elements we received match the digests that were signed?

Every disclosed element is re-hashed with its salt and compared against the MSO.

Validity

Is the document within its signed validity window?

The MSO’s own validity info, not the reader’s idea of when it was issued.

Holder binding

Did this phone take part in this exchange?

A device signature over the session transcript. It binds the response to this conversation — not to somebody who once held the document.

A reader that returned one boolean would have to decide, on your behalf, that an unknown issuer and an altered element are the same kind of problem. They are not — one means find out who this is, the other means these bytes were changed. And “could not check” is never a middle ground between pass and fail.

What this does on real devices

Not a list of standards we support — a list of things that happen with two phones on a table. Anything that is not yet real is further down the page, under its own heading.

Phone to phone, in both directions
A driving licence leaves one phone over Bluetooth and is read by another. iOS and Android each act as the holder and as the reader, with no network, no accounts and no server in the middle.
Read by software we did not write
An independent reference reader — someone else’s implementation of the standard, not ours — engages our wallet, decrypts the response, parses it and checks every element digest against the signed object.
A passport verified on the device
The chip is read over NFC and Passive Authentication runs on the phone: the data groups are hashed against the signed security object, the signature is checked, and the signer is chained to a country root. The trust stores travel with the app, so nothing is sent anywhere to do it.
Checked against the standard’s own examples
The worked examples published with ISO 18013-5 decode through the same code that reads a real document — so the wire format is pinned to the specification itself, not to our own reading of it.

What we issue

The credential, and the standard it answers to.

Meaning and representation are separated all the way down: a credential type says what is being asserted, and a representation profile says how it is carried. The same membership credential is issued as an SD-JWT VC and as a W3C VC, and nothing in the workflow knows which.

SD-JWT VC

RFC 9901 · draft-ietf-oauth-sd-jwt-vc-19

dc+sd-jwt

The default representation. Each claim is hidden behind its own salted digest, so a holder discloses three fields and proves the other four were in the signed document without revealing them.

Signature: ES256
Selective disclosure: Per-claim, salted
Holder binding: Required — cnf + kb+jwt
Status: IETF Token Status List

W3C Verifiable Credential

VC Data Model 2.0

VCDM-2.0

The representation you can download as a file and keep. VCDM 2.0 has no selective disclosure of its own, and this profile does not add a scheme that would give it one — so the page says so rather than implying parity with SD-JWT VC.

Signature: ES256
Selective disclosure: Not in this profile
Holder binding: In the proof
Status: Bitstring Status List

ISO mdoc (mDL)

ISO/IEC 18013-5:2021

org.iso.18013.5.1.mDL

Built for proximity: a Mobile Security Object listing a digest per element, presented over Bluetooth with a session-bound device signature. Undisclosed elements stay digested, so the document remains complete and the verifier learns only what was sent.

Signature: ES256, COSE_Sign1
Selective disclosure: Per element, 16-byte salts
Holder binding: DeviceKey in the MSO
Status: Not carried

Photo ID

ISO/IEC TS 23220-4

org.iso.23220.photoid.1

A passport read, expressed as an mdoc so a conformant third-party reader can ask for it. The envelope is ours; the State’s signature travels untouched inside the data-group namespace.

Signature: ES256, COSE_Sign1
Selective disclosure: Per element, 16-byte salts
Holder binding: Fresh device key per presentation
Status: Not carried

Digital Travel Credential

ICAO DTC-VC Type 1

DTC-VC (virtual component)

Nobody issues this. The holder’s phone derives it from their own passport, and its trust is entirely the chip’s security object. ICAO’s bar is completeness: a useful subset is a micro-credential, not a DTC, and the wallet enforces that distinction rather than describing it.

Signature: The State’s own, unmodified
Selective disclosure: Not applicable
Holder binding: Not applicable
Status: Not applicable

How they travel

OpenID4VCI 1.0

Final specification

How a credential reaches a wallet. A pre-authorised offer carries its own authorisation and a transaction code as its second factor; both native wallets collect over it and keep what they collected across a restart.

OpenID4VP 1.0

Final specification, approved 10 July 2025

How a verifier asks. Signed request objects, single-use response pointers, replay refusal, and a result reported as separate dimensions that are never collapsed into a boolean.

ISO 18013-5 device retrieval

QR engagement over BLE

How a phone shows a document to a reader standing in front of it, with no network on either side. Session keys are derived from the transcript of this exchange, so a response cannot be replayed into another one.

Apple Wallet · Google Wallet

Companion passes

The everyday surface. An Apple pass is assembled at the edge and its manifest signed by the core, which refuses to sign anything that is not one; a Google object is signed as a JWT. A pass is a convenience representation, never the credential — the verifiable object stays in the wallet, and a device-bound credential gets no pass at all.

The authoritative source

A UK licence, confirmed by DVLA — without us in the middle.

A photocard has no chip, so every measurement the wallet can make shares one ceiling: a card invented from scratch, with a number computed to match the name beside it, passes all of them. A DVLA check code does not measure the card. It reaches the authority that issued it.

What we deliberately did not build

The wallet never redeems the code. DVLA’s Access to Driver Data would let us redeem it programmatically — and that would put our server in the path of every check, so we would learn each time somebody’s licence was looked at. The code goes to the verifier, and the verifier asks DVLA under their own name. We see nothing.

Confirmed, not verified

What the wallet reads off the holder’s own signed-in page is the holder’s copy. It catches an OCR slip or a transposed digit; it is not an attestation, and the product refuses to let it become one.

Endorsements are cut out structurally

The record page carries penalty points and convictions. “We do not look at that part” is a promise one careless change turns into a lie, so the section is removed before any matching runs at all.

The code is a bearer secret

Redeemed, it discloses more than the card in your pocket does. So it is stored like a secret, shown deliberately rather than incidentally, and it leaves the wallet when it expires.

Why it is secure

Six properties, each with the reason it exists.

Keys stay on the device, and we measure which kind

Holder keys live in the Secure Enclave on iOS and in StrongBox, the TEE or software on Android — whichever the phone actually gave us. The badge on a credential reports that measurement per credential, so an emulator reads NOT DEVICE-BOUND rather than borrowing the best case.

We never hold an issuer’s signing key

An organisation signs with its own key — software, KMS or HSM. The credential engine never touches raw private key material, including inside the third-party libraries we adopt.

A digest reveals nothing without its salt

Every mdoc element carries 16 bytes of random. Without them, an undisclosed "sex" or date of birth could be recovered by hashing every candidate, because the digest itself is public in the signed object.

Checking status must not become a beacon

Status lists are downloaded whole and the bit is read on the device. There is no "is this one revoked?" request, because a per-credential endpoint tells whoever serves it exactly which card was looked at, and when.

Evidence stays with the holder

A verifier receives the claim that was issued, not the passport scan, the selfie or the bank statement behind it. Credentials, keys, presentations and evidence are never logged.

No single word for a verification

A result is seven dimensions — signature, status, validity period, holder binding, issuer trust, assurance, subject presence — plus a record check when the document has an authority to ask. There is no overall boolean, and the type system rejects one.

What we do not claim

The part of a standards page that is usually missing.

Every line below is enforced somewhere in the product rather than promised here. It is also the reason the rest of this page can be taken at face value.

Nothing here is certified

No conformity process has been run — not EUDI, not HAIP, not ISO. We implement the published texts and test against other people’s implementations. That is a different claim from certification, and we will not make the stronger one until a certificate exists.

A self-issued document is signed by the phone, not by an authority

When you turn your own licence into an mDL, the signer is a key your phone generated. Every conformant verifier will report an unknown issuer — and that is the correct answer, not a bug to work around. It proves the format, not the fact.

A verified chip is not a verified person

"Data verified by Spain" is exactly what Passive Authentication establishes: a Spanish authority signed these bytes and they have not changed. It says nothing about who is holding the phone.

A Digital Travel Credential gets you through no gate

No airline or border accepts one today. It is a prototype of a format the industry is moving toward, and presenting it as anything else would be a lie told to the one person who cannot check it.

mdoc over the internet is not built

Proximity means the verifier knows the phone is in the room. Carrying the same document over the web needs ISO 18013-7’s handover, and tunnelling the proximity bytes over TLS would produce four green checks and one that cannot be checked — which looks like success and is not.

Revocation is not checked by the wallet at presentation time

A card that has performed no status check reads NOT CHECKED rather than ACTIVE. Checking at presentation time would tell the issuer that the card was used, and roughly where; that check belongs to the verifier.

See it for yourself

Check a credential, or read the code.

The whole platform is Apache 2.0 — the engine, the wallets, the readers and the specification they were built from. Nothing on this page is a feature you have to take our word for.

Check a credential Get started