Passport chip verification, over NFC, verified fully offline.

A modern passport carries a chip that the issuing state signed. JERIX reads it over NFC, verifies the signature chain to that state’s national root with the network interface down, and matches the live selfie against the photograph the state itself signed. A forged image needs a graphics model. A chip signature needs the state’s private key.

The eMRTD chip, ICAO 9303, and what the signature actually proves.

An eMRTD is the standard name for a passport with a chip in it, and ICAO 9303 is the specification those chips follow. The useful consequence of a standard is that the check does not depend on the vendor's opinion of a photograph.

The chip is read over NFC, on the device

The phone holds the chip and reads it over NFC. What comes back is the holder’s data and the holder’s photograph, carried under a signature produced by the issuing state. Nothing about that read is a judgement call, which is the point of using it.

Passive authentication: the chain to a national CSCA root

The signature on the chip is checked back through the state’s document signer to its national CSCA root. That is the mechanism the standard calls passive authentication, and what it establishes is narrow and worth stating precisely: the data on that chip was signed by the state that issued the document. We claim that, and we do not dress it up as anything wider.

An unknown issuer is refused, not downgraded

If the chain cannot be built to a root in the store on the machine, the chip is refused. It is not accepted with a caveat attached, and it does not silently fall back to reading the printed page as though the chip had never been presented.

The matched face comes from the chip, not from the page

The photograph used for matching is taken from the chip’s own state-signed data, server-side, and compared against the live selfie. A printed photograph substituted on the data page is not the thing being matched.

Verified offline — the whole of it

588: certificates in the local trust store
112: countries covered by them
0: network calls, CRL fetches or OCSP lookups

Chip verification, the trust chain, face matching and OCR all run offline once the deployment is provisioned. Nobody is told that a passport was checked, because there is nobody to ask.

The Israeli ID card: that chip cannot be read.

This is the first question asked on the home market, so it is answered here rather than in the third meeting. The answer does not improve on a later page.

The chip in an Israeli ID card is government-locked. It cannot be read by JERIX, and it cannot be read by anyone outside the state’s own systems. No integration, no entitlement and no commercial arrangement changes that, and a vendor who tells you otherwise is describing something else.

So an Israeli ID card is a photo-only verification. The printed page is read and the face is matched against the live selfie, and the result does not earn the chip-backed assurance level, because no state signature was ever verified. That is a weaker check than a passport read, and it is better labelled than blurred.

If your population is Israeli and your duty needs the chip-backed level, the document that gets you there is a passport. That is a scoping conversation worth having in week one.

What each document path can and cannot establish
Document	Chip	What the result rests on
passport	Read over NFC.	A state signature verified to a national CSCA root, and a face taken from the signed data.
israeli id card	Not readable. Government-locked.	The printed page and a face match. Photo-only. No state signature is verified.

Assurance levels are declared by your server and enforced by ours, so a photo-only verification cannot be configured into the chip-backed level by either side. The full level table sits on the gaming page →

The vocabulary, so the terms mean the same thing on both sides of the call.

Four words do most of the work in this conversation, and they are routinely used loosely in this market.

Terms used on this page
Term	What it means here
emrtd	A travel document with a chip in it — the standard name for a modern passport.
icao 9303	The specification an eMRTD chip follows, which is why one reader works across issuing states.
csca	A country's signing authority at the top of its own certificate chain. This is the root the chain is verified to.
passive authentication	Verifying the issuing state's signature over the data on the chip. It establishes that the state signed that data.

What the chip read is wrapped in.

The chip settles the document. Two further mechanisms settle the capture, and neither is an opinion about how good a picture looks.

A capture manifest signed on the device

Every capture is hashed and signed on the device as it is taken, against a single-use nonce issued for that session. A frame cannot be substituted afterwards, and a manifest cannot be replayed into a second session, because the nonce is spent.

Apple App Attest, on iOS

On iOS the app proves to the server that it is a genuine, unmodified build on real Apple hardware before a capture is accepted at the attested levels. Android is the limit here, and it has its own entry in the annex below.

And then the images are gone

The chip data, the document image and the face image are used inside the request and are not kept. The correct claim is zero retention on images and biometrics, verified on disk — not that we keep nothing, which would be false. Name, national ID and date of birth are retained encrypted, and two face-derived hashes live 30 and 7 days.

The complete retention table, row by row →

What offline does not mean.

The offline property is the real one, and it is also the one most easily overread. Here is the shape of it, including the part that is your operational responsibility rather than ours.

The trust store is installed, and has to be kept current

Verifying with no network call means the certificates have to be on the machine already. The store is installed per deployment, and states issue new signing certificates over time — so keeping it current is a standing operational task. A store that is allowed to go stale does not produce a wrong answer; it produces a refusal on a chip it should have accepted, which is the failure direction we prefer but still a failure you will feel.

A browser cannot read a chip

A hosted page in a mobile browser cannot read NFC and cannot attest the device, so the chip path needs a native capture — the JERIX app, or your own app through the React Native or Flutter SDK. That is a real ceiling and it is better read here than discovered in week three. Separately, a returning person in a mobile browser is sent through full verification rather than a quick re-recognition, so verify once and log in anywhere is not a claim we make.

Android captures carry no hardware attestation

The Android app ships and the capture manifest signs on it. Hardware attestation is not configured, so an Android capture does not carry the device proof an App Attest capture carries.

Not shippedAndroid hardware attestation. Blocked on provisioning, not on architecture.

Spoof detection is measured and decides nothing

Liveness and the movement ceremony are measured and recorded on every capture, and they do not gate a verdict. We do not claim the system blocks a spoofed selfie or detects a printed or on-screen copy. What rejects a swapped or replayed frame is the signed capture manifest; what rejects a forged document is the state signature on the chip.

Not shippedScreen and print detection as an enforcing control; liveness enforcement. Blocked on a false-reject rate we are willing to publish.

No certification stands behind any of this yet

No SOC 2, no ISO 27001, no third-party penetration test and no iBeta presentation-attack evaluation. The offline chain is a mechanism you can test in twenty minutes, which is the form of evidence we actually have.

Not shippedSOC 2, ISO 27001, penetration test, iBeta ISO 30107-3. On-premises packaging — architecturally supported, zero reference installations.

How to check the chip path yourself.

None of this needs to be believed. Bring a passport to a walkthrough and the whole argument is testable in front of you.

Claim, and your own test for it
Claim	Your test
offline trust chain	Disconnect the machine and read a passport chip. The chain still resolves, or the chip is refused.
unknown issuer refused	Present a chip signed outside the certificate store and watch it refuse rather than downgrade.
face from the chip	Alter the printed photograph on the data page. The match is against the chip's signed image, not the page.
single-use nonce	Replay a capture manifest into a second session. It is refused.
zero retention on images	Inspect the disk after a completed verification, with us watching.
israeli id card	Try the chip. It does not read, and the verification is labelled photo-only.

The verification, step by step →Real request and response shapes →The architecture, and what is missing from it →

Bring a passport and watch the chain resolve with the cable out.

Twenty minutes, a real chip, and the network interface down. If your population carries Israeli ID cards, bring one of those too — the honest answer is part of the demonstration.

Request a walkthrough