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

Обзор

Предупреждения в отчёте о проверке живости фиксируют каждое условие, выявленное Didit при выполнении проверки живости. Они попадают в массив warnings[] для каждого элемента liveness_checks[] (см. Отчёт о проверке живости) со значением feature, равным "LIVENESS". Каждая запись имеет стандартную структуру объекта предупреждения: feature, risk, additional_data, log_type, short_description, long_description, node_id. Каждое предупреждение имеет три уровня:
  1. Код risk — стабильный идентификатор, по которому можно выполнять сопоставление в коде (список кодов приведён ниже).
  2. Тип log_type — одно из значений: information, warning или error. Риски с автоматическим отклонением всегда содержат error. Для настраиваемых рисков он определяется настроенным действием: Без действия → information, Проверка → warning, Отклонить → error. Для рисков на основе порогов (LOW_LIVENESS_SCORE, LOW_FACE_QUALITY) устанавливается error, если значение пересекает порог отклонения, и warning, если оно пересекает только порог проверки.
  3. Влияние на решение — та же маршрутизация определяет status отчёта о проверке живости: действие «Проверка» переводит его в In Review, действие «Отклонить» (или любой риск автоматического отклонения) переводит в Declined, а «Без действия» оставляет его без изменений.
Некоторые риски формируются только в том случае, если метод проверки живости имеет значение PASSIVE (проверки количества лиц, качества и яркости). В таблицах ниже приведён полный набор кодов рисков проверки живости и уровни их критичности — других кодов рисков проверки живости не существует.

Условия автоматического отклонения

Следующие риски всегда переводят отчёт о проверке живости (и сессию) в статус Declined с log_type: "error": При срабатывании NO_FACE_DETECTED риск LOW_LIVENESS_SCORE подавляется (лицо для оценки отсутствует).

Настраиваемые параметры верификации

В консоли Didit риски проверки живости сгруппированы по следующим настройкам сценария:

Сформированные предупреждения

Основные проверки живости

Целостность канала съёмки

Сигналы инъекционных атак, передаваемые клиентом во время съёмки. В отличие от атак предъявления (артефакт перед реальной камерой), они указывают на то, что сам видеопоток с камеры был подменён или перехвачен. Каждый сигнал настраивается индивидуально для сценария и по умолчанию имеет значение отсутствие действия, поэтому включение этой функции не влияет на решения, пока вы явно её не настроите.
Браузеры не предоставляют вендорам аттестацию источника камеры на уровне ОС, поэтому в веб-среде эти сигналы служат косвенными подтверждениями, а не неопровержимым доказательством. В вебе вердикт null означает не определено (метки устройств недоступны до предоставления разрешения на доступ к камере) и никогда не инициирует риск.
Виртуальная камера идентифицируется по имени устройства, поэтому камера, которую операционная система отображает под обычным именем, не распознаётся как виртуальная. Внутри эмулятора Android переназначенная камера помечена как встроенная, поэтому случай с эмулированным оборудованием передаётся через 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

Здесь для действия при обнаружении дубликата лица установлено значение Review, поэтому предупреждение содержит 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. Диагностические данные доставки кадров, опущенные в этом примере для краткости, не приводят к обнаружению этой аномалии.

Типы предупреждений

Каждому риску присваивается уровень критичности в зависимости от конфигурации вашего приложения. Существует три уровня критичности:

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

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