NFC Seals

NFC Seals

🇬🇧 English · 🇷🇺 Русский

A physical seal ties the passport to the physical object. ODP supports numbered tamper-evident seals (checked by eye) and NFC crypto chips — currently NXP NTAG 424 DNA and its TagTamper variant (detects if the seal was ever peeled off).

Since v0.6 a seal is optional. The mandatory identification for a physical object is the anchor minimum — photo + dimensions + materials + distinguishing features (see Object ID Profile). A seal is an additional anchor (nfc or numbered_seal) on top of that minimum, recommended for high-value objects. Its data lives in the passport's anchors[] block and is integrity-anchored on-chain via dataHash / anchorsHash — there are no dedicated on-chain seal fields anymore.

What an NFC check actually proves (be honest with yourself)

The v0.6 verification model is published-key symmetric challenge-response: the chip's 16-byte EV2 application key is published inside the integrity-anchored nfc anchor, and the verifier's phone runs NTAG 424 DNA's native mutual authentication (EV2) with that key.

A PASS means	A PASS does not mean
A live chip holding the anchored key is physically present — not just a copied URL or QR	That the chip is unique: the key is public, so a determined forger can program another NTAG 424 with the same key
The chip answered a fresh challenge (not a replayed recording)	That the object is authentic — that's what the identification anchors and human expertise are for
With TagTamper: the seal loop has never been opened (permanent TAMPERED flag otherwise)	That a thief with the original object and seal can be detected

What the check does block: URL-only fake tags, wrong chips carrying another key, and physically opened TagTamper seals. Before reporting a scan as high assurance, a verifier must additionally confirm an authenticated UID match and an INTACT TagTamper state.

Rule of thumb: treat an NFC PASS as one strong anchor among several, never as "authentic" by itself — a verifier that claims authenticity from a chip check alone is overselling. Full model and its honest limits: SPEC §6 — Physical Seal.

Phone support

⚠️ No ODP app can do the cryptographic chip check today — on any platform. Of every anchor type ODP defines, nfc is the only one with nothing you can install. If you are deciding whether to buy NTAG 424 DNA tags for a run, weigh that before you order.

What works right now, with no app at all: the chip carries an ordinary URL, so tapping the object opens the Verify page with the passport's on-chain record. iPhone XS and newer read tags in the background; Android does the same. That gives you the document-level check — hashes, card, anchors — which is most of what a buyer needs and is already more than most objects carry.

What does not work yet: EV2 challenge-response, TagTamper status, and writing keys to a chip. All three need a native app with low-level chip access.

The state of each platform

• iPhone — the reference implementation is in development as the ODP app for iOS. The platform is capable: Core NFC has given apps ISO 7816 APDU access since iOS 13. Safari has no Web NFC, so a browser-only flow is impossible and an app is the only route.
• Android — the platform is equally capable, and Chrome even supports Web NFC for simple reads. An ODP Android verifier was started and never finished; it is not published and is not the reference implementation of anything.
• Mac — no Mac has ever shipped an NFC reader, so a Mac cannot scan a seal at all. In the iOS app's design the phone scans and the Mac receives the verified result over a local transfer.

Provisioning a chip

There is no ODP tool for it yet on any platform. NXP's own apps get part of the way — TagWriter writes the carrier URL, Tag TrustLink can authenticate a chip — but neither binds the chip to an ODP passport, which is the step that matters and the step that is missing.

For issuers: the required order

1. Provision the chip before minting (load the EV2 key, enable TagTamper if used).
2. Scan the live chip and import its data into the passport form — this prevents publishing a wrong UID or key on-chain.
3. Mint; then write the verify URL onto the chip.

Full walkthrough: ISSUER_NFC_FLOW.md.