> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Vérification NFC : API passeport électronique et puce eID

> Vérifiez passeports et eID par puce NFC avec Didit. Validation cryptographique et sécurité maximale. Paiement à l'appel à $0.15.

L'authentification basée sur le NFC vous permet de vérifier des documents d'identité en lisant la puce sécurisée intégrée aux passeports et cartes d'identité modernes à l'aide des fonctionnalités NFC d'un téléphone mobile. Cela offre le **niveau de sécurité le plus élevé disponible** pour la Vérification d'identité.

Prompt d'intégration de la vérification NFC
        Copier le prompt dans le presse-papiers



      
      

\<pre>

\````# Goal
Integrate Didit NFC Verification — cryptographic ePassport / eID chip read — into your app.

\# Delivery mode
NFC is **session-only**. There is no standalone /v3/nfc/ endpoint. The chip is read by the Didit Web/Mobile SDK during a hosted session, which uses the device's NFC radio.

\# Steps
1\. Create a workflow that includes the NFC feature (Business Console or POST /v3/workflows/). NFC normally runs alongside ID Verification: the user first photographs the document so the SDK derives BAC/PACE keys from the MRZ, then taps the chip.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open the returned session.url on a mobile device with NFC (iOS 13+/Android with NFC enabled), or mount the native SDK in your app.
4\. After completion fetch the decision — GET /v3/session/{sessionId}/decision/ (or subscribe to session.status.updated).

curl (create session):
\```bash
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-123",
"callback": "https://yourapp.com/post-kyc"
}'
\```

\# Decision shape
The NFC result is returned under the plural array `nfc_verifications[]` on the decision payload.

\> Heads-up: the V3 schema deliberately keeps the **plural-array** name `nfc_verifications[]` even though early integrators occasionally hit a singular `nfc_verification` key. Always read from the plural array — it is the canonical, multi-instance shape and matches every other feature.

\# Status enum (per nfc_verifications[].status)
"Not Started" | "In Progress" | "Approved" | "In Review" | "Declined" | "Abandoned" | "Kyc Expired"

\# Warnings (LogWarningChoices.NFC)
The warnings[] array on each nfc_verification includes risk codes such as:
NFC_NOT_READ, NFC_DATA_INVALID, NFC_DATA_DOES_NOT_MATCH_OCR, NFC_BAC_FAILED, NFC_PASSIVE_AUTHENTICATION_FAILED, NFC_ACTIVE_AUTHENTICATION_FAILED, NFC_CHIP_CLONED, NFC_DOCUMENT_REVOKED.
Full catalogue: /core-technology/nfc-verification/warnings-nfc-verification.

\# Failure modes to handle
\- Device has no NFC chip or NFC is disabled — the SDK falls back to OCR + face match; nfc_verifications[] will be empty.
\- The user fails to hold the chip long enough — status="Declined" with NFC_NOT_READ or NFC_BAC_FAILED. Allow a retry.
\- nfc_verifications[].status="Declined" with NFC_DATA_DOES_NOT_MATCH_OCR — the chip and the printed data disagree (likely tampered document). Do not approve.
\- Passive Authentication failed — the chip's signing certificate did not chain back to a trusted CSCA. Stop the flow.

\# Japan My Number Card (JPKI)
\- The My Number Card is read through JPKI, not ICAO 9303: native SDKs only, and the person enters the card PIN. Its item has chip_protocol "jpki", its evidence under jpki (chain_valid, signature_valid, revocation_status good | revoked | unchecked, attributes, attributes_match_ocr), and null ICAO fields (chip_data, authenticity, certificate_summary).
\- iOS host apps add D392F000260100000001 to com.apple.developer.nfc.readersession.iso7816.select-identifiers.
\- Not enabled in production yet: until it is, a My Number Card in a native SDK on an NFC phone skips NFC with nfc_skip_reason JPKI_UNAVAILABLE.

\# See also
\- Canonical schema: /reference/data-models#nfc-verification
\- Per-feature report: /core-technology/nfc-verification/report-nfc-verification
\- Risk catalogue: /core-technology/nfc-verification/warnings-nfc-verification
\- Supported documents: /core-technology/nfc-verification/supported-documents-nfc-verification
\- Full integration playbook: /integration/integration-prompt````

\</pre>



      
      

Coller dans

![NFC Interaction](https://didit-public-assets.s3.eu-west-1.amazonaws.com/icons/docs/nfc-id.gif)***## Principaux avantages| Avantage | Description |
| - | - |
| **Sécurité maximale** | Vérifie les signatures cryptographiques directement auprès des émetteurs gouvernementaux |
| **Facile à utiliser** | Fonctionne automatiquement avec n'importe quel téléphone compatible NFC |
| **Infalsifiable** | Détecte les manipulations de documents invisibles à l'œil nu |
| **Données exhaustives** | Extrait des données supplémentaires non accessibles par le seul OCR |
| **Repli flexible** | Bascule de manière fluide vers la vérification standard si le NFC n'est pas disponible |***## Comment activer la vérification NFC### Intégration via SDK natif (recommandé)La vérification NFC est disponible via nos **SDK natifs**, qui offrent un accès complet aux fonctionnalités NFC de l'appareil :| Plateforme | Prise en charge NFC | Documentation |
| - | - | - |
| **iOS** | ✅ Prise en charge complète | [Documentation du SDK iOS](https://docs.didit.me/fr/integration/native-sdks/ios-sdk.md) |
| **Android** | ✅ Prise en charge complète | [Documentation du SDK Android](https://docs.didit.me/fr/integration/native-sdks/android-sdk.md) |Le SDK iOS gère automatiquement toute la configuration NFC, notamment :- Les identifiants d'application ISO7816 pour les passeports électroniques
- La configuration des droits et des fonctionnalités
- La lecture de la puce en temps réel avec retour visuel### Intégration web> ⚠️ **Limitations des navigateurs**
>
> La vérification NFC n'est **pas disponible dans les navigateurs web** en raison des restrictions de la plateforme :
>
> | Navigateur | Prise en charge NFC |
> | - | - |
> | **Chrome (Android)** | API Web NFC expérimentale - instable, nécessite des autorisations explicites |
> | **Safari (iOS)** | Aucune prise en charge de l'API Web NFC |
> | **Autres navigateurs** | Aucune prise en charge |
>
> Pour les intégrations web, la vérification NFC est automatiquement ignorée et les utilisateurs poursuivent avec la vérification standard du document et du selfie.***## Comment cela fonctionne**1. Initialisation de la session**L'utilisateur lance le processus de vérification depuis votre application ou votre plateforme :- **SDK natif** : lancez le flux de vérification directement dans votre application
- **Web / Web mobile** : l'utilisateur est guidé vers l'application Didit pour une vérification compatible NFC, ou poursuit avec une vérification standard**2. Capture de la photo du document**L'utilisateur prend en photo sa pièce d'identité, permettant de capturer :- La **MRZ** (Machine Readable Zone) — utilisée pour dériver les clés d'accès à la puce
- Les **photos recto et verso du document** — données visuelles et éléments de sécurité
- Les **éléments visuels de sécurité** — hologrammes, filigranes, micro-impressions**3. Détection de la prise en charge NFC**Le système vérifie automatiquement la compatibilité de l'appareil et du document :| Vérification | Description |
| - | - |
| **Type de document** | S'agit-il d'un passeport électronique / d'une carte d'identité électronique doté(e) d'une puce NFC ? |
| **Capacité de l'appareil** | Le téléphone prend-il en charge la lecture NFC ? |
| **Autorisations** | Les autorisations NFC nécessaires sont-elles accordées ? |> [!NOTE]
>
> Si le NFC n'est pas disponible, la vérification se poursuit de manière fluide avec la vérification standard du document et la vérification biométrique.**4. Lecture de la puce NFC**Pour les appareils et documents compatibles :1) L'utilisateur est guidé pour positionner son document près du lecteur NFC du téléphone
2) Un retour visuel indique la progression de la lecture en temps réel
3) Une communication sécurisée est établie avec la puce à l'aide des protocoles PACE/BAC**5. Extraction des données**Le système extrait des données complètes depuis la puce conformément aux normes **OACI 9303** :| Groupe de données | Contenu | Description |
| - | - | - |
| **SOD** | Objet de sécurité du document | Signatures numériques pour tous les groupes de données |
| **DG1** | Données personnelles | Nom, numéro de document, date de naissance, date d'expiration |
| **DG2** | Image faciale | Photo numérique haute résolution du titulaire |
| **DG7** | Signature | Représentation numérique de la signature du titulaire |
| **DG11-14** | Données supplémentaires | Peut inclure des empreintes digitales, des scans de l'iris (s'ils sont enregistrés) |**6. Vérification cryptographique**Les données extraites font l'objet d'une vérification cryptographique rigoureuse :> [accordion] Vérification de la signature numérique
>
> Le hash de chaque groupe de données est vérifié par rapport aux signatures enregistrées dans le SOD, garantissant l'intégrité des données.> [accordion] Validation de la chaîne de certificats
>
> La chaîne de confiance est validée : **Certificat du document → AC signataire du pays → Racine ICAO PKD**, avec contrôle par rapport aux listes maîtresses CSCA et au répertoire de clés publiques de l'OACI (ICAO PKD).> [accordion] Vérification de la révocation du certificat
>
> Les certificats sont vérifiés par rapport aux listes de révocation de certificats (CRL) pour s'assurer qu'ils n'ont pas été révoqués et que le document n'a pas été signalé comme volé ou compromis.> [accordion] Validation croisée
>
> Les données extraites par NFC font l'objet d'une validation croisée avec les données OCR issues des photos du document, d'une comparaison biométrique faciale et de la vérification de la somme de contrôle de la MRZ.**7. Résultat et score de confiance**Le résultat final de la vérification comprend :| Sortie | Description |
| - | - |
| **Statut de vérification NFC** | Réussi, échoué ou ignoré |
| **Score de cohérence des données** | Niveau de concordance entre les données NFC et les données visuelles |
| **Validation du certificat** | Statut de vérification de l'ensemble de la chaîne |
| **Hausse de la confiance** | Le NFC renforce significativement la confiance globale dans la vérification |***## Documents pris en chargeLa vérification NFC fonctionne avec les **passeports électroniques** et les **cartes d'identité électroniques** qui contiennent une puce NFC, généralement signalée par ce symbole sur le document :![ePassport Logo](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/epassport-logo.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=89cd90281e6ff1cd96f5a3d6a2200cad)La plupart des passeports délivrés après 2006 contiennent des puces NFC. La couverture varie selon les pays pour les cartes nationales d'identité. Consultez tous les [documents pris en charge](https://docs.didit.me/fr/core-technology/nfc-verification/supported-documents-nfc-verification.md).La My Number Card japonaise possède un type de puce différent, lue via JPKI au lieu de l'OACI 9303. Consultez [Japan My Number Card (JPKI)](#carte-my-number-japonaise-jpki).***## Carte My Number japonaise (JPKI)La carte My Number japonaise (マイナンバーカード) possède une puce, mais pas une puce ICAO 9303. Elle contient des certificats délivrés dans le cadre de JPKI, l'infrastructure à clés publiques du Japon, ainsi que des clés privées qui ne signent qu'après la saisie du code PIN par le titulaire de la carte. Didit la lit au cours de la même étape NFC, via JPKI au lieu de l'ICAO 9303, et chaque résultat NFC indique le protocole utilisé dans `chip_protocol` (`icao` ou `jpki`).> [!WARNING]
>
> **Pas encore disponible.** La lecture de la carte My Number via JPKI n'est pas activée en production. D'ici là, une carte My Number capturée dans un SDK natif ignore l'étape NFC avec le motif de saut `JPKI_UNAVAILABLE`, et la carte est vérifiée par capture de document et correspondance faciale comme auparavant.### Prérequis| Prérequis | Détail |
| - | - |
| **Document** | La carte My Number japonaise uniquement. Les passeports japonais conservent la lecture de puce ICAO 9303. |
| **Intégration** | Une version du SDK natif capable de lire les cartes My Number (iOS, Android ou les SDK React Native et Flutter basés sur ceux-ci). Le SDK indique à Didit qu'il peut lire JPKI ; une version plus ancienne ignore l'étape avec `JPKI_UNAVAILABLE`. Les intégrations Web et WebView l'ignorent avec `INTEGRATION_WITHOUT_NFC_ACCESS`. |
| **Appareil** | Un téléphone équipé d'un lecteur NFC. Sans celui-ci, l'étape est ignorée avec `DEVICE_WITHOUT_NFC`. |
| **Application hôte iOS** | `D392F000260100000001` dans les identifiants de sélection ISO7816 de l'application. Consultez [Configuration NFC sur iOS](https://docs.didit.me/fr/integration/native-sdks/ios-sdk.md#configuration-nfc). |
| **Personne** | Doit connaître le code PIN à 4 chiffres de la carte, ainsi que son mot de passe de signature lorsque votre workflow demande les données du titulaire. |### Ce que fait la personne**1. Photographier la carte**La personne capture la carte My Number lors de l'étape de vérification d'identité, comme pour n'importe quel document. Didit reconnaît la carte et envoie une étape NFC JPKI au lieu d'une lecture de puce de passeport.**2. Saisir le code PIN de la carte**Le SDK demande le code PIN à 4 chiffres de la carte (利用者証明用電子証明書の暗証番号). Lorsque le paramètre `jpki_request_attributes` du nœud NFC est activé (par défaut), il demande également le mot de passe de signature, également appelé code PIN de signature (署名用電子証明書の暗証番号, 6 à 16 lettres majuscules et chiffres).**3. Approcher la carte du téléphone**Le SDK lit les certificats de la carte, et la carte signe un défi à usage unique émis par Didit avec sa propre clé. Le SDK téléverse les certificats et les signatures. Les codes PIN sont uniquement transmis à la carte, jamais à Didit.> [!NOTE]
>
> La carte compte les saisies incorrectes : elle bloque le code PIN à 4 chiffres après 3 erreurs consécutives et le mot de passe de signature après 5 erreurs, et un code bloqué doit être réinitialisé auprès de la mairie du titulaire. Après une saisie erronée, le SDK indique le nombre d'essais restants. Il ne réalise jamais la dernière tentative : lorsqu'il ne reste qu'un seul essai, il s'arrête et indique à la personne où le réinitialiser. Invitez les utilisateurs à préparer leur code PIN et leur mot de passe de signature avant de commencer.### Ce que vérifie Didit| Vérification | Ce que vérifie Didit | Avertissement en cas d'échec (action par défaut) |
| - | - | - |
| **Chaîne de certificats** | Chaque certificat remonte jusqu'à l'autorité de certification JPKI de son type, se situe dans sa période de validité et correspond à un certificat de carte My Number (`jpki.chain_valid`). | `JPKI_CERTIFICATE_INVALID` (Refuser) |
| **Carte et code PIN** | La signature du défi à usage unique par la carte est vérifiée à l'aide de son certificat (`jpki.signature_valid`). La carte ne signe qu'après la saisie de son code PIN, ce qui prouve que la personne détient la carte et connaît le code PIN. | `JPKI_SIGNATURE_INVALID` (Refuser) |
| **Révocation** | Aucun certificat n'a été révoqué (`jpki.revocation_status`). | `JPKI_CERTIFICATE_REVOKED` en cas de `revoked` (Refuser), `JPKI_REVOCATION_UNCHECKED` en cas de `unchecked` (Examen) |
| **Données du titulaire** | Le nom, la date de naissance, le sexe et l'adresse figurant sur le certificat de signature correspondent aux données lues sur la photo de la même carte (`jpki.attributes_match_ocr`, `jpki.mismatched_attributes`). | `JPKI_AND_OCR_DATA_NOT_SAME` (Examen) |Chaque action est un paramètre du nœud NFC, vous pouvez donc la modifier pour définir **Aucune action**, **Examen** ou **Refuser**. Consultez les [avertissements NFC](https://docs.didit.me/fr/core-technology/nfc-verification/warnings-nfc-verification.md#japan-my-number-card-jpki) et la [configuration de la fonctionnalité NFC](https://docs.didit.me/fr/management-api/workflows/feature-configs.md#nfc-/-epassport).### Ce que signifie un statut de révocation non vérifié`revocation_status: "unchecked"` signifie que Didit a vérifié la chaîne de certificats et la signature de la carte, mais n'a obtenu aucune réponse quant à la révocation éventuelle d'un certificat. Un certificat est révoqué lorsque, par exemple, la carte est signalée comme perdue. Puisqu'il est impossible d'exclure qu'une carte soit révoquée, `unchecked` n'est jamais traité comme `good`. Cela déclenche `JPKI_REVOCATION_UNCHECKED`, ce qui envoie par défaut l'étape NFC en examen. Choisissez une autre action avec `jpki_revocation_unchecked_action`.Lorsque la chaîne de certificats ou la signature n'est pas valide, Didit ne vérifie pas la révocation : le statut reste `unchecked` et seul l'avertissement relatif à la chaîne ou à la signature est émis.### Données du titulaire et confidentialité- Lorsque `jpki_request_attributes` est activé, la décision inclut le nom, la date de naissance, le sexe et l'adresse du titulaire issus du certificat de signature sous `jpki.attributes`. Lorsqu'il est désactivé, la personne saisit uniquement le code PIN à 4 chiffres : la lecture prouve toujours la carte et le code PIN, mais ne transporte aucune donnée du titulaire et n'est pas comparée avec la photo de la carte.
- L'étape NFC ne lit jamais le numéro individuel à 12 chiffres (My Number) de la carte depuis la puce.
- La décision indique ce que la carte a prouvé, jamais les certificats eux-mêmes, leurs numéros de série ou les signatures.Le résultat complet est détaillé dans le [rapport de vérification NFC](https://docs.didit.me/fr/core-technology/nfc-verification/report-nfc-verification.md#carte-my-number-japonaise-jpki).***## Exemples d'intégration### SDK iOS (disponible dès maintenant)```swift theme={null}
import DiditSdk

// NFC is automatically enabled when the document supports it
let config = DiditSdk.Configuration(
    // NFC configuration is handled automatically
    // Just ensure your app has the required entitlements
)

let result = try await DiditSdk.shared.startVerification(
    with: sessionId,
    configuration: config
)
```**[Documentation complète du SDK iOS →](https://docs.didit.me/fr/integration/native-sdks/ios-sdk.md)**### SDK Android (disponible dès maintenant)```kotlin theme={null}
import me.didit.sdk.DiditSdk

// NFC is automatically enabled when the document supports it
DiditSdk.startVerification(
    token = "your-session-token"
) { result ->
    handleResult(result)
}
```**[Documentation du SDK Android →](https://docs.didit.me/fr/integration/native-sdks/android-sdk.md)*****## Architecture de sécurité```
┌─────────────────────────────────────────────────────────────┐
│                    NFC Verification Flow                     │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────┐    ┌──────────┐    ┌──────────────────────┐  │
│  │ Document │───▶│  Phone   │───▶│   Didit Backend      │  │
│  │ NFC Chip │    │ NFC Read │    │                      │  │
│  └──────────┘    └──────────┘    │  ┌────────────────┐  │  │
│                                   │  │ ICAO PKD       │  │  │
│                                   │  │ Validation     │  │  │
│                                   │  └────────────────┘  │  │
│                                   │  ┌────────────────┐  │  │
│                                   │  │ CSCA Master    │  │  │
│                                   │  │ List Check     │  │  │
│                                   │  └────────────────┘  │  │
│                                   │  ┌────────────────┐  │  │
│                                   │  │ CRL Revocation │  │  │
│                                   │  │ Check          │  │  │
│                                   │  └────────────────┘  │  │
│                                   └──────────────────────┘  │
│                                              │               │
│                                              ▼               │
│                                   ┌──────────────────────┐  │
│                                   │  Verification Result │  │
│                                   │  + Confidence Score  │  │
│                                   └──────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
```***## FAQ<details>
  <summary>**Que se passe-t-il si le téléphone de l'utilisateur ne prend pas en charge le NFC ?**</summary>

  Le flux de vérification détecte automatiquement la compatibilité NFC. Si elle n'est pas disponible, les utilisateurs poursuivent avec la vérification standard document + selfie. La vérification reste sécurisée, simplement sans le gain de confiance supplémentaire apporté par le NFC.
</details><details>
  <summary>**Que se passe-t-il si le document ne possède pas de puce NFC ?**</summary>

  De nombreux documents (en particulier les passeports plus anciens et certaines cartes nationales d'identité) ne disposent pas de puce NFC. Le système le détecte et poursuit de manière fluide avec la vérification standard.
</details><details>
  <summary>**À quel point la vérification NFC améliore-t-elle la précision ?**</summary>

  La vérification NFC fournit une preuve cryptographique de l'authenticité du document directement issue du gouvernement émetteur. Cela augmente considérablement le niveau de confiance dans le résultat de la vérification et permet de détecter des contrefaçons sophistiquées qui pourraient passer une inspection visuelle.
</details><details>
  <summary>**La vérification NFC est-elle obligatoire ?**</summary>

  Non. Le NFC est une amélioration, pas une obligation. Votre workflow de vérification peut être configuré pour exiger le NFC, le privilégier lorsqu'il est disponible, ou l'ignorer totalement selon votre tolérance au risque.
</details>***


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.