Saltar al contingut principal

Visió general

L’informe de verificació NFC recull el que Didit ha llegit i validat del xip NFC d’un document: un passaport electrònic, un document d’identitat electrònic o un altre document electrònic segons la norma ICAO 9303. Inclou les dades biogràfiques del xip, comprovacions d’integritat criptogràfica (SOD i resums dels Data Groups) i un resum del Document Signer Certificate (DSC) utilitzat pel país emissor. L’informe es genera després que l’usuari completi el pas d’NFC en un flux de treball. Didit llegeix els Data Groups del xip al dispositiu de l’usuari, verifica la signatura del Document Security Object (SOD) amb el certificat CSCA del país emissor, comprova cada resum de Data Group amb els valors signats pel SOD i compara l’MRZ del xip amb l’MRZ extret per OCR de la part visible del document. La targeta My Number del Japó es llegeix mitjançant JPKI (chip_protocol: "jpki"): el seu informe inclou les comprovacions de certificat, signatura, revocació i dades del titular sota jpki, i els camps d’ICAO es mantenen com a null. Consulta Japan My Number Card (JPKI). Cada informe inclou el seu propi status —independent de l’estat global de la sessió— que reflecteix com s’ha resolt el pas d’NFC de manera aïllada:
  • Aprovat — el xip s’ha llegit i cap de les advertències que s’han generat està configurada per dirigir el pas a revisió o rebutjar-lo.
  • En Revisió — s’ha activat com a mínim una advertència que té configurada l’acció Revisió (per exemple, NFC_CHIP_NOT_VERIFIED o NFC_TRUST_ANCHOR_MISSING quan l’acció per a xip no verificat està configurada com a Revisió, o JPKI_REVOCATION_UNCHECKED amb la seva acció per defecte).
  • Rebutjat — s’ha activat com a mínim una advertència que té configurada l’acció Rebutjar (per exemple, NFC_AND_OCR_DATA_NOT_SAME quan l’acció d’inconsistència de dades està configurada com a Rebutjar).
  • No finalitzat — l’usuari no ha completat mai el pas d’NFC; la lectura del xip s’ha abandonat o el dispositiu no era compatible amb NFC.
  • Nova tramesa sol·licitada — un revisor ha demanat a l’usuari que torni a enviar la informació; l’informe se substituirà per un nou intent.

On apareix a les respostes de l’API

L’informe d’NFC s’inclou dins de l’array nfc_verifications[] —sempre un array JSON, mai un objecte nfc singular. Apareixen diverses entrades quan un flux de treball executa NFC més d’una vegada (per exemple, en un flux step-up); cada entrada inclou el seu propi node_id.
  • API de decisió de la sessió — apareix com a nfc_verifications[] al nivell superior de GET /v3/session/{sessionId}/decision/. Consulta Obtenir la decisió de la sessió.
  • Webhooks — els payloads de status.updated inclouen el mateix array nfc_verifications[] un cop el pas d’NFC ha generat dades. Consulta Webhooks.
  • NFC independent — per a l’enviament directe del xip, consulta la Visió general d’NFC.
Quan el teu flux de treball inclou un pas d’NFC que s’ha omès o evitat, el payload de decisió també inclou un camp de nivell superior nfc_skip_reason que indica exactament el motiu: el document no té xip, el certificat del país emissor no està disponible, el dispositiu no disposa de lector NFC, la verificació s’ha executat sense un SDK natiu (sense accés a NFC des d’un navegador), la clau d’accés al xip no s’ha pogut derivar de l’MRZ, una targeta My Number no s’ha pogut llegir mitjançant JPKI o l’usuari ha decidit ometre el pas. Es manté com a null per a resultats fora d’aquesta taxonomia; el cas més habitual és un usuari que ha abandonat a mig intent (estat de l’informe Not Finished) o una sessió on l’NFC encara està pendent. Consulta Motius d’omissió per conèixer els valors exactes.
La documentació anterior feia referència a un camp singular nfc. Aquesta estructura no existeix a l’endpoint de decisió v3: només apareix en destinacions fixades explícitament als webhooks V2, on també inclou chip_protocol i jpki. Llegeix sempre response.nfc_verifications[0] i itera sobre l’array.

Esquema

L’esquema canònic camp per camp es troba a la pàgina de referència Models de dades. Els camps següents reflecteixen aquest esquema canònic.

Valors d’estat

Les dues advertències de certificat (DSC_CERTIFICATE_REVOKED, DSC_CERTIFICATE_EXPIRED) són informatives: apareixen a warnings[], però per si soles mai canvien l’status d’NFC. Consulta Advertències d’NFC per veure la matriu completa de comportament.

Exemples

Approved: xip llegit i criptogràficament vàlid

Declined: discrepància entre OCR i xip

Japan My Number Card (JPKI)

Una Japan My Number Card es llegeix a través de JPKI en els SDK natius: la persona introdueix el PIN de la targeta i la targeta signa un repte d’un sol ús (consulta com funciona). El seu informe té chip_protocol: "jpki" i inclou les evidències a jpki. portrait_image, signature_image, chip_data, authenticity i certificate_summary són null, perquè la targeta no conté dades ICAO.
La lectura de la My Number Card a través de JPKI encara no està activada a producció. Fins que ho estigui, una My Number Card omet el pas NFC amb el motiu d’omissió JPKI_UNAVAILABLE.

Camps JPKI

L’informe mai conté els certificats en si, els seus números de sèrie, les signatures o el Número Individual (My Number) de 12 xifres de la targeta, que el pas NFC mai llegeix.

Exemple: lectura de My Number Card

Quan la comprovació de revocació no està disponible per a una lectura, el mateix informe té revocation_status: "unchecked", una advertència JPKI_REVOCATION_UNCHECKED i status: "In Review" amb la configuració per defecte. Consulta les advertències d’NFC.

Nota de seguretat

Les dades del xip NFC estan signades per l’autoritat emissora, de manera que un informe aprovat amb sod_integrity: true i dg_integrity: true és la prova d’identitat més sòlida possible que Didit pot generar. Tracta els URL d’imatge signats (portrait_image, signature_image) com a recursos de curta durada: descarrega’ls ràpidament i no els emmagatzemis en memòria cau pública; torna a sol·licitar la decisió quan necessitis enllaços actualitzats.

Relacionat

Darrera modificació el 7 de novembre del 2026