Обзор
Предупреждения в отчёте о проверке живости фиксируют каждое условие, выявленное Didit при выполнении проверки живости. Они попадают в массивwarnings[] для каждого элемента liveness_checks[] (см. Отчёт о проверке живости) со значением feature, равным "LIVENESS". Каждая запись имеет стандартную структуру объекта предупреждения: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Каждое предупреждение имеет три уровня:
- Код
risk— стабильный идентификатор, по которому можно выполнять сопоставление в коде (список кодов приведён ниже). - Тип
log_type— одно из значений:information,warningилиerror. Риски с автоматическим отклонением всегда содержатerror. Для настраиваемых рисков он определяется настроенным действием: Без действия →information, Проверка →warning, Отклонить →error. Для рисков на основе порогов (LOW_LIVENESS_SCORE,LOW_FACE_QUALITY) устанавливаетсяerror, если значение пересекает порог отклонения, иwarning, если оно пересекает только порог проверки. - Влияние на решение — та же маршрутизация определяет
statusотчёта о проверке живости: действие «Проверка» переводит его вIn Review, действие «Отклонить» (или любой риск автоматического отклонения) переводит вDeclined, а «Без действия» оставляет его без изменений.
PASSIVE (проверки количества лиц, качества и яркости). В таблицах ниже приведён полный набор кодов рисков проверки живости и уровни их критичности — других кодов рисков проверки живости не существует.
Условия автоматического отклонения
Следующие риски всегда переводят отчёт о проверке живости (и сессию) в статусDeclined с log_type: "error":
При срабатывании
NO_FACE_DETECTED риск LOW_LIVENESS_SCORE подавляется (лицо для оценки отсутствует).
Настраиваемые параметры верификации
В консоли Didit риски проверки живости сгруппированы по следующим настройкам сценария:Сформированные предупреждения
Основные проверки живости
Целостность канала съёмки
Сигналы инъекционных атак, передаваемые клиентом во время съёмки. В отличие от атак предъявления (артефакт перед реальной камерой), они указывают на то, что сам видеопоток с камеры был подменён или перехвачен. Каждый сигнал настраивается индивидуально для сценария и по умолчанию имеет значение отсутствие действия, поэтому включение этой функции не влияет на решения, пока вы явно её не настроите.Браузеры не предоставляют вендорам аттестацию источника камеры на уровне ОС, поэтому в веб-среде эти сигналы служат косвенными подтверждениями, а не неопровержимым доказательством. В вебе вердикт
null означает не определено (метки устройств недоступны до предоставления разрешения на доступ к камере) и никогда не инициирует риск.FRAME_INJECTION_SUSPECTED: он определяется по окружению устройства (стеку рендеринга и модели устройства, указанной в агенте пользователя), а не по названию камеры. Результаты, выявленные на основе окружения устройства, содержат additional_data.reason: "emulated_capture_device", что отличает их от собственного покадрового анализа модели проверки живости.
Определение параметров системы из браузера является лишь косвенным свидетельством, а не аттестацией, и подготовленный злоумышленник может повлиять на эти данные. Нативные мобильные SDK передают более надёжные сигналы целостности на уровне операционной системы, которые браузер увидеть не может (эмулятор, устройство с root-доступом или джейлбрейком, перехват вызовов во время выполнения, подключённый отладчик). Для каждого из них предусмотрено собственное настраиваемое действие в разделе Целостность устройства и среды выполнения. Эти сигналы существенно повышают затраты злоумышленника, но сами по себе не доказывают, что съёмка была выполнена с подлинного устройства. Сигналы целостности устройства не зависят от метода проверки живости, поэтому они сочетаются с любым из методов: Passive, 3D Flash или 3D Action & Flash.
Криминалистический анализ видеозаписи
LIVENESS_VIDEO_ANOMALY вычисляется на стороне сервера по сохранённой видеозаписи проверки живости, независимо от модели проверки живости. Механизм выявляет повторяющуюся последовательность движений в течение нескольких циклов, характерную для зацикленного видеопотока.
Задайте действие в вашем узле Проверки живости или Оценки возраста:
NO_ACTION фиксирует информационное событие, REVIEW может перевести верификацию с вынесенным решением в статус «на проверке», а DECLINE может перевести её в статус «отклонена». Проверка выполняется асинхронно, поэтому изменение статуса на более строгий может произойти после получения первоначального результата. Более строгое существующее решение не понижается, а решения ручной проверки сохраняются.
Результаты версии 2 включают forensics_version: 2, доказательства repeated_sequence и значение repeated_moving_sequence в anomaly_reasons. Параметры доставки, такие как unique_frame_ratio, static_pair_ratio, decoded_fps_ratio и max_frame_gap_seconds, остаются диагностическими данными; они не могут подтвердить факт воспроизведения записи сами по себе. Более ранние результаты содержат описание версии детектора, использовавшейся на тот момент, и не подлежат ретроактивной реклассификации.
Это консервативный дополнительный сигнал, а не исчерпывающий механизм обнаружения синтетического медиаконтента или инъецированного видео. Запись без аномалий не является гарантированным подтверждением живости. Короткие или неоднозначные съёмки, а также съёмки без пригодных доказательств повторного воспроизведения не помечаются этой проверкой. Отсутствующие или нечитаемые записи не приводят к обнаружению в рамках этой проверки; остальные проверки верификации продолжают действовать.
Межсессионное сравнение лиц
При совпадениях с импортированными лицами или записями из списков (у которых нет сессии) значения
*_session_id, *_session_number и api_service в additional_data равны null.
Лица, принадлежащие одному и тому же пользователю (одинаковые vendor_data или один и тот же пользователь вендора при наличии), исключаются из всего поиска по индексу — как из обнаружения дубликатов, так и из проверки по спискам блокировки. Приоритет совпадений следующий: точное совпадение со списком блокировки → точное совпадение со списком разрешений → точный дубликат → возможное совпадение со списком блокировки → возможное совпадение со списком разрешений → возможный дубликат — в одном отчете появляется только один из этих шести взаимоисключающих кодов. DUPLICATED_FACE_NAME_MISMATCH не входит в эту группу приоритетов: это дополнительный код, который выдается поверх DUPLICATED_FACE, если проверка личности также не прошла, и никогда вместо него. В additional_data.name_match_score никогда не передаются сравниваемые имена — только идентификаторы и оценка, поэтому персональные данные (PII) не попадают в payload предупреждения.
Имя, написанное в разной системе письма на каждом документе (например, на иврите в одном и латиницей в другом), может получить оценку ниже пороговой, даже если обе сессии принадлежат одному человеку. В этом единственном случае DUPLICATED_FACE_NAME_MISMATCH не выдается, если документы, удостоверяющие личность, из обеих сессий подтверждают друг друга по всем следующим пунктам:
- В обоих документах указана одна и та же страна выдачи.
- Идентификатор в обоих документах точно совпадает. Поля
document_numberиpersonal_numberвзаимозаменяемы, так как один и тот же национальный номер может находиться в любом из них в зависимости от типа документа. - Если в обоих документах указана дата рождения, она совпадает.
Качество пассивной проверки живости (только при method = "PASSIVE")
LOW_FACE_LUMINANCE и HIGH_FACE_LUMINANCE взаимоисключают друг друга — яркость находится либо ниже минимума, либо выше максимума, но никогда одновременно.
Оценка возраста (адаптивные сценарии и узлы AGE_ESTIMATION)
Точные строки описания
API возвращает следующие точные строкиshort_description и long_description для каждого риска:
Отдельный API пассивной проверки живости
Отдельный API проверки живости повторно использует те же коды рисков со следующими отличиями в поведении:NO_FACE_DETECTEDиLOW_LIVENESS_SCOREвзаимно исключают друг друга — проверка оценки живости выполняется только тогда, когда лицо было найдено.LOW_LIVENESS_SCOREсрабатывает в соответствии со значениемface_liveness_score_decline_thresholdиз запроса (по умолчанию 30) и всегда сопровождаетсяlog_type: "error".POSSIBLE_FACE_IN_BLOCKLISTобрабатывается как отклонение (log_type: "error"), а не отправка на проверку.MULTIPLE_FACES_DETECTEDсопровождаетсяlog_type: "warning", в то время как риски дублирования лица остаются информационными. Только предупреждения уровняerrorпереводятstatusв ответе отдельного API вDeclined.- Записи предупреждений в отдельном API содержат
feature, но не содержатnode_id.
Примеры
Автоматическое отклонение при обнаружении атаки
Настраиваемые предупреждения при пассивной съемке
Дубликат лица с payload
log_type: "warning", а статус отчёта о проверке живости имеет значение In Review. При значении по умолчанию (No action) оно содержало бы log_type: "information". Поле api_service имеет значение null, поскольку совпавшее лицо было получено из сессии сценария, а не из отдельного вызова API.
Дубликат лица под другим именем
DUPLICATED_FACE сохраняется собственное настроенное действие (здесь No action — log_type: "information"), тогда как DUPLICATED_FACE_NAME_MISMATCH имеет отдельное действие, по умолчанию Review (log_type: "warning"). Статус отчёта о проверке живости определяется наиболее строгим из двух: здесь In Review, даже если одна лишь базовая настройка дубликата лица не привела бы к выставлению флага.
Аномалия целостности записи с измерениями
log_type имеет значение information, так как настроенным действием является NO_ACTION. Диагностические данные доставки кадров, опущенные в этом примере для краткости, не приводят к обнаружению этой аномалии.
Типы предупреждений
Каждому риску присваивается уровень критичности в зависимости от конфигурации вашего приложения. Существует три уровня критичности:Связанные разделы
- Отчёт о проверке живости — полная схема отчёта и статусы.
- Предупреждения при сравнении лиц — сопутствующие предупреждения при сравнении лиц 1:1.
- webhook — событие
session.status.updatedпередаёт предупреждения сразу после завершения шага проверки живости. - Модели данных — Проверка живости — каноническая схема со всеми полями.
- Модели данных — Объект предупреждения — структура каждого элемента в
warnings[].