Перейти к основному содержанию

Обзор

Отчёт об NFC-верификации фиксирует данные, которые Didit считал и проверил с NFC-чипа документа — электронного паспорта (ePassport), электронного удостоверения личности (eID) или другого электронного документа стандарта ICAO 9303. Он включает биографические данные с чипа, криптографические проверки целостности (хэши SOD и Data Groups), а также сводные сведения о сертификате подписанта документа (DSC), использованном страной выдачи. Отчёт формируется после того, как пользователь завершает шаг NFC в сценарии. Didit считывает Data Groups чипа на устройстве пользователя, проверяет подпись объекта безопасности документа (Document Security Object, SOD) по CSCA-сертификату страны выдачи, сверяет хэш каждой Data Group со значениями, подписанными в SOD, и сопоставляет MRZ с чипа с MRZ, распознанной с помощью OCR с видимой стороны документа. Японская карта My Number считывается через JPKI (chip_protocol: "jpki"): её отчёт содержит проверки сертификата, подписи, статуса отзыва и данных владельца в объекте jpki, а поля ICAO остаются со значением null. См. Japan My Number Card (JPKI). Каждый отчёт имеет собственный статус status — независимо от общего статуса сессии — отражающий результат выполнения только шага NFC:
  • Одобрено — чип был считан, и ни одно из сработавших предупреждений не настроено так, чтобы направить шаг на проверку или отклонить его.
  • На проверке — сработало как минимум одно предупреждение, для которого настроено действие Проверка (например, NFC_CHIP_NOT_VERIFIED или NFC_TRUST_ANCHOR_MISSING, когда действие для непроверенного чипа настроено как «Проверка», либо JPKI_REVOCATION_UNCHECKED со стандартным действием).
  • Отклонено — сработало как минимум одно предупреждение, для которого настроено действие Отклонить (например, NFC_AND_OCR_DATA_NOT_SAME, когда действие для несоответствия данных настроено как «Отклонить»).
  • Не завершено — пользователь не завершил шаг NFC; считывание чипа было прервано либо устройство не поддерживает NFC.
  • Запрошена повторная отправка — проверяющий запросил повторную отправку у пользователя; отчёт будет заменён отчётом о новой попытке.

Где отчёт появляется в ответах API

Отчёт NFC передаётся внутри массива nfc_verifications[] — всегда в виде JSON-массива, а не единичного объекта nfc. Несколько записей появляются, когда сценарий выполняет NFC более одного раза (например, в сценарии усиленной проверки); каждая запись содержит собственный node_id.
  • API решения по сессии — передаётся как nfc_verifications[] на верхнем уровне ответа GET /v3/session/{sessionId}/decision/. См. Получение решения по сессии.
  • Webhooks — payload события status.updated содержит тот же массив nfc_verifications[], как только шаг NFC сформирует данные. См. Вебхуки.
  • Автономный NFC — для прямой отправки данных чипа см. Обзор NFC.
Если ваш сценарий включает шаг NFC, который был пропущен или обойдён, payload решения также содержит поле верхнего уровня nfc_skip_reason, указывающее точную причину — у документа нет чипа, сертификат страны выдачи недоступен, у устройства нет NFC-считывателя, верификация выполнялась без нативного SDK (нет доступа к NFC из браузера), ключ доступа к чипу не удалось вычислить на основе MRZ, карту My Number не удалось считать через JPKI или пользователь решил пропустить этот шаг. Оно остаётся со значением null для исходов вне этой классификации — чаще всего это пользователь, прервавший процесс посреди попытки (статус отчёта Not Finished), или сессия, где шаг NFC всё ещё ожидает выполнения. См. Причины пропуска для получения точных значений.
В более ранней документации упоминалось отдельное поле nfc. Такой структуры нет на endpoint решения v3 — она появляется только для адресов назначения, явно привязанных к webhook V2, где также передаются chip_protocol и jpki. Всегда считывайте response.nfc_verifications[0] и выполняйте итерацию по массиву.

Схема

Каноническая схема с описанием каждого поля находится на справочной странице Модели данных. Поля ниже полностью соответствуют этой канонической схеме.

Значения статуса

Два предупреждения по сертификатам (DSC_CERTIFICATE_REVOKED, DSC_CERTIFICATE_EXPIRED) являются информационными: они появляются в warnings[], но сами по себе никогда не меняют status NFC. Полную матрицу поведения см. в разделе NFC-предупреждения.

Примеры

Одобрено — чип прочитан и криптографически валиден

Отклонено — несоответствие между OCR и чипом

Японская карта My Number (JPKI)

Японская карта My Number считывается через JPKI в нативных SDK: человек вводит PIN-код карты, и карта подписывает одноразовый челлендж (см. как это работает). Её отчёт содержит chip_protocol: "jpki" и включает подтверждающие данные в объекте jpki. Поля portrait_image, signature_image, chip_data, authenticity и certificate_summary имеют значение null, поскольку карта не содержит данных ICAO.
Считывание карт My Number через JPKI пока не включено в продакшене. До его включения карта My Number пропускает шаг NFC с причиной пропуска JPKI_UNAVAILABLE.

Поля JPKI

Отчёт никогда не содержит сами сертификаты, их серийные номера, подписи или 12-значный индивидуальный номер (My Number), который шаг NFC никогда не считывает.

Пример: считывание карты My Number

Если проверка отзыва недоступна при считывании, тот же отчёт имеет revocation_status: "unchecked", предупреждение JPKI_REVOCATION_UNCHECKED и status: "In Review" при настройках по умолчанию. См. предупреждения NFC.

Примечание о безопасности

Данные чипа NFC подписаны органом выдачи, поэтому отчёт со статусом «Одобрен» с sod_integrity: true и dg_integrity: true представляет собой самое сильное возможное подтверждение личности, которое может предоставить Didit. Относитесь к подписанным URL-адресам изображений (portrait_image, signature_image) как к кратковременным: своевременно скачивайте их и не кэшируйте публично — запросите решение повторно, если вам потребуются свежие ссылки.

Связанные разделы

Последнее изменение 7 ноября 2026 г.