# 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, verifies the Document Signer signature, and checks that the signer chains to a trusted issuing state's certificate (CSCA). The client never decides authenticity; a chip that positively fails authentication is proven tampered and the verification fails with `chip_not_authentic`.

A chip is **authentic only when its signer chains to a trusted issuer**. The signing certificate travels inside the chip data the applicant submits, so a valid signature alone proves only that some key signed it. A chip whose issuing country is not on Myaza's trusted issuer list comes back `inconclusive`: the verification falls back to the document and government database checks, with no `chip` assurance level, no chip photo and no face match against the chip photo.

A chip-verified document earns the strongest [assurance level](https://trust.myaza.co/documentation/id-types/markdown#assurance-levels), `chip`, when a copied chip is also ruled out: the chip proves it is the original (Active Authentication, below), or it has no such feature and the live selfie matches the photo stored on the chip. Genuine chip data without that proof gets the next level (`gov_db` or `document`). Where the ID is also checked against a government database (a Nigerian passport, for example), the selfie is compared with the government's photo rather than the chip's, so on that path a chip reaches `chip` only through Active Authentication.

> **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

Two things decide whether the chip step appears for an ID:

- **The document carries a chip.** A passport carries one in every country, while national identity cards depend on whether that country issues an ICAO-compliant chip card. Driver's licences never carry a readable chip.
- **Myaza holds the issuing country's certificate (CSCA).** A chip can only be confirmed genuine against the certificate of the country that issued it, so the step is offered only for countries on Myaza's certificate list. The list is built from the certificate lists the German, Dutch and Italian governments publish, and covers 138 countries, including Nigeria, Ghana, Kenya, Egypt, Ethiopia and Senegal. Documents from a country not on it skip the chip step and are checked by their document and, where available, the government database. South Africa does not issue chipped passports yet.

The authoritative list for your account is [`GET /config`](https://trust.myaza.co/documentation/api-config/markdown), whose ID types each carry `supportsNfc`: true only when both conditions hold. A chip is also checked against the country its own data names as the issuer, so a chip signed under one country's certificate that claims to be another country's document is never treated as genuine.

The table below shows which documents carry a readable chip. The chip step runs only where Myaza also holds the issuing country's certificate, as described above, so a tick for a country not on that list does not mean the chip step is offered there yet.

```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, which must chain to a trusted issuing state's CSCA certificate for the chip to count as authentic. 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. Used only from an authentic chip (above): 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.

- `cloneCheck`: how a copied chip was ruled out: `active_auth` (the chip answered our one-time challenge with its own private key), `face_bound` (the chip has no such key and the selfie matched its photo) or `none`.
- `sod.signerRevoked`: `true` when the issuing country has cancelled the certificate that signed the chip (such a chip is never treated as genuine), `false` when its cancellation list was checked, `null` when we hold no current list for that country. A `null` chip is still accepted as genuine; see "Passport signer's cancellation status unknown" below if you would rather review or decline it.

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

### Passport signer's cancellation status unknown

Countries publish lists of the signing certificates they have cancelled, for example after a key leak. We check them, but not every country publishes one, and a list can be unreachable or out of date. When that happens for a chip that is otherwise genuine, `verification.nfcSignerCancellationUnknown` is `true`. These chips are **accepted by default**. To review or decline them instead, open the NFC step's **Rules** tab and add the suggested rule "Passport signer's cancellation status unknown". The field is `false` once the list was checked and empty (`null`) when the chip is not from a trusted issuer at all.

## 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, and that includes a chip that fails Active Authentication: a copy of a genuine chip cannot answer the challenge with the original's private key. A chip without Active Authentication is not a failure, and nor is a chip whose answer never reached us, a submission that leaves out the chip's key, or an answer we could not read: none of those proves a copy, so the chip simply does not count towards `chip`. `activeAuth.reason` says which it was. So `status: verified` (and the `verification.nfcAuthentic` decision field) says the chip's data is genuine, not that the chip is the original: route on `verification.nfcCloneCheck` for that.
- 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.