# NFC chip verification

Modern passports (every country) and some national ID cards carry an **eMRTD chip** following the ICAO 9303 standard. On NFC-capable phones, the mobile SDKs read the chip over its secure channel and submit the data with the verification. The server then runs **passive authentication**: it re-computes each data group's hash against the chip's signed security object and verifies the issuing state's Document Signer signature. The client never decides authenticity; a chip that positively fails authentication is proven tampered and the verification fails with `chip_not_authentic`.

A chip-verified document earns the strongest [assurance level](https://trust.myaza.co/documentation/id-types/markdown#assurance-levels), `chip`.

> **Native SDKs only.** Reading a chip requires low-level NFC access (ISO-DEP) that only native apps get, so chip verification is available in the **[React Native](https://trust.myaza.co/documentation/sdk-react-native/markdown)** and **[Flutter](https://trust.myaza.co/documentation/sdk-flutter/markdown)** SDKs and is **not supported in the web SDK**: no browser API can talk to a passport chip. Web integrations that want `chip` assurance should route users through one of the mobile SDKs. Phones without an NFC radio skip the step automatically, and skipping never fails a verification.

## Supported documents

Chip capability is a property of the document, not the country: **a passport reads everywhere**, while national identity cards depend on whether that country issues an ICAO-compliant chip card. Driver's licences never carry a readable chip. The authoritative list for your account is [`GET /config`](https://trust.myaza.co/documentation/api-config/markdown), whose ID types each carry `supportsNfc`.

```nfc-countries
```

Some well-known ID cards carry chips that are **not** ICAO eMRTDs and cannot be read this way, by any vendor: the South African smart ID card, the Emirates ID, Malaysia's MyKad, and the smart cards of Singapore, Hong Kong, Japan and China all use proprietary chip applications. Those documents still verify through Document Intelligence; they simply cannot reach `chip` assurance.

Three things to know:

- The chip's secure channel is unlocked with a key derived from the document's **MRZ** (BAC or PACE), so the chip step always runs after the document scan that reads it.
- **Chip capability follows each document's current issuance generation.** Older chipless generations still in circulation pass through unaffected: chip presence is a bonus signal, and a chipless card simply completes on the document checks at the assurance tier it can reach.
- Which chip-capable IDs actually offer the step, whether users may skip it manually, and whether the chip portrait is face-matched are all configured per workflow in the builder's NFC panel.

## Data extraction

The system reads and verifies the following data groups:

| Data group | Contents | What we do |
|---|---|---|
| `SOD` | Document Security Object | Read in full and verified server-side: the signed hash of every data group plus the Document Signer signature, optionally chained to the issuing state's CSCA certificate. This is what makes everything else trustworthy. |
| `DG1` | Personal data (MRZ) | Name, document number, nationality, birth date, expiry date. Hash-verified against the SOD, every ICAO check digit validated, and cross-checked against the details submitted with the verification. |
| `DG2` | Facial image | The government-issued portrait stored on the chip. Hash-verified against the SOD and, on document-only verifications, face-matched against the live selfie. |
| `DG7` | Signature | The holder's displayed signature image. Read when the chip carries one and hash-verified against the SOD. |
| `DG11` | Additional personal details | Full name, personal number, full date of birth, place of birth, address, telephone and profession, where the issuer populated them. Hash-verified against the SOD. |
| `DG12` | Additional document details | Issuing authority and date of issue. Hash-verified against the SOD. |

Two honesty notes, because chip capabilities are widely overstated:

- **DG3 (fingerprints) and DG4 (iris) cannot be read by any commercial system.** They sit behind Extended Access Control: only government inspection systems holding terminal-authentication certificates issued by each state can decrypt them. A vendor claiming to extract fingerprints or iris scans from a passport chip is describing something the standard does not permit them to do.
- **DG7, DG11 and DG12 are optional by standard.** Many issuers do not write them at all, so their absence is normal and never a risk signal. The SDK checks the chip's own table of contents (EF.COM) and reads only the groups the document declares.

## Where the results surface

The full result lands on the verification record and the [webhook](https://trust.myaza.co/documentation/webhooks/markdown) payload as `data.nfc`:

- `status` (`verified` / `not_authentic` / `data_mismatch` / `inconclusive` / `unreadable`), `chipAuthentic`, `dataMatch`, `checkDigitsValid` and the parsed `mrz`.
- `sod`, `dg2`, `dg7`, `dg11`, `dg12` sub-objects, each carrying `hashValid`: whether that group's bytes match the signed hash in the SOD. Parsed DG11/DG12 fields are included alongside, with `hashValid` telling you how much to trust them.
- On document-only verifications, `dg2.faceMatch` and `dg2.faceMatchConfidence` report the live selfie against the authenticated chip portrait.

In workflow [decisioning](https://trust.myaza.co/documentation/decisioning/markdown) you can branch on `verification.nfcStatus`, `verification.nfcAuthentic`, `verification.nfcDataMatch`, `verification.nfcFacialMatch` and `verification.assuranceLevel`.

## Behaviour and availability

- A missing, unreadable or inconclusive chip **never fails a verification**; it simply falls back to the document checks. Only a proven-tampered chip (`not_authentic`) hard-fails.
- The optional detail groups (DG7/DG11/DG12) are read by the React Native SDK today, with Flutter following; the core groups (DG1, DG2, SOD) are read by both mobile SDKs.
- On [sandbox keys](https://trust.myaza.co/documentation/sandbox-testing/markdown), a chip payload on a test ID returns a canned authentic result, so you can exercise the full contract at no cost.