Saltar al contenido principal

Descripción general

Las advertencias del informe de prueba de vida señalan cada condición que Didit detectó al ejecutar la comprobación de prueba de vida. Aparecen en el array warnings[] de cada elemento de liveness_checks[] (consulta Informe de prueba de vida), con feature establecido en "LIVENESS". Cada entrada sigue la estructura común del objeto de advertencia: feature, risk, additional_data, log_type, short_description, long_description, node_id. Cada advertencia tiene tres capas:
  1. El código risk: un identificador estable que puedes usar para comparar en tu código (los códigos que se indican más abajo).
  2. El log_type: uno de information, warning o error. Los riesgos de rechazo automático siempre llevan error. En los riesgos configurables se deriva de la acción configurada: Sin acción → information, Revisión → warning, Rechazar → error. En los riesgos basados en umbrales (LOW_LIVENESS_SCORE, LOW_FACE_QUALITY) es error cuando el valor cruza el umbral de rechazo y warning cuando solo cruza el umbral de revisión.
  3. El impacto en la decisión: el mismo enrutamiento determina el status del informe de prueba de vida: una acción Revisión lo pasa a In Review, una acción Rechazar (o cualquier riesgo de rechazo automático) a Declined, y Sin acción lo deja sin cambios.
Algunos riesgos solo se emiten cuando el método de prueba de vida es PASSIVE (comprobaciones de múltiples rostros, calidad y luminancia). Las tablas siguientes recogen el conjunto completo de códigos de riesgo de prueba de vida y su gravedad: no existe ningún otro código de riesgo de prueba de vida.

Condiciones de rechazo automático

Los siguientes riesgos siempre hacen que el informe de prueba de vida (y la sesión) pase a Declined, con log_type: "error": Cuando se dispara NO_FACE_DETECTED, se suprime LOW_LIVENESS_SCORE (no hay ninguna cara que puntuar).

Configuración de verificación personalizable

En la consola de Didit, los riesgos de prueba de vida se agrupan en las siguientes opciones de configuración del flujo:

Advertencias generadas

Prueba de vida principal

Integridad del canal de captura

Señales de ataque de inyección que el cliente informa en el momento de la captura. A diferencia de los ataques de presentación (un artefacto que se sostiene delante de una cámara real), estas señales indican que la propia señal de la cámara se ha sustituido o interceptado. Cada una se configura por flujo y su valor predeterminado es ninguna acción, de modo que activar la función no cambia ninguna decisión hasta que decidas aplicarla.
Los navegadores no ofrecen a ningún proveedor una atestación a nivel de sistema operativo del origen de la cámara, así que en la web estas señales son pruebas que corroboran, no pruebas concluyentes. En la web, un veredicto null significa no determinado (las etiquetas de los dispositivos no están disponibles hasta que se concede el permiso de cámara) y nunca activa un riesgo.
Una cámara virtual se identifica por el nombre del dispositivo, por lo que una cámara que el sistema operativo presenta con un nombre corriente no se reconoce de esa forma. Dentro de un emulador de Android, la cámara reasignada se etiqueta como cualquier cámara integrada; por eso el caso del hardware emulado se informa mediante FRAME_INJECTION_SUSPECTED: se detecta a partir del entorno del dispositivo (la pila de renderizado y el modelo de dispositivo indicado en el user agent) y no del nombre de la cámara. Los hallazgos generados a partir del entorno del dispositivo incluyen additional_data.reason: "emulated_capture_device", lo que los distingue del análisis de fotogramas propio del modelo de prueba de vida.
Detectar la máquina desde un navegador es una prueba indicativa, no una atestación, y un atacante decidido puede interferir en ella. Los SDK móviles nativos informan de señales de integridad más sólidas, a nivel de sistema operativo, que un navegador no puede ver (emulador, dispositivo con root o jailbreak, interceptación en tiempo de ejecución, depurador conectado), cada una con su propia acción configurable en Integridad del dispositivo y del entorno de ejecución. Estas señales encarecen considerablemente el ataque, pero por sí solas no demuestran que una captura proceda de un dispositivo genuino. Las señales de integridad del dispositivo son independientes del método de prueba de vida, por lo que se combinan con cualquiera de Passive, 3D Flash o 3D Action & Flash.

Análisis forense de coherencia de la grabación

LIVENESS_VIDEO_ANOMALY se calcula en el servidor a partir de la grabación de prueba de vida almacenada, de forma independiente del modelo de prueba de vida. Detecta una secuencia en movimiento repetida en varios ciclos, compatible con una señal en bucle. Configura la acción en tu nodo de prueba de vida o de estimación de edad: NO_ACTION registra un hallazgo informativo, REVIEW puede elevar una verificación ya decidida a En revisión y DECLINE puede elevarla a Rechazado. La comprobación se ejecuta de forma asíncrona, por lo que una escalada puede llegar después del resultado inicial. Una decisión existente más grave no se rebaja y las decisiones de revisión manual se conservan. Los hallazgos de la versión 2 incluyen forensics_version: 2, la evidencia repeated_sequence y repeated_moving_sequence en anomaly_reasons. Las mediciones de entrega como unique_frame_ratio, static_pair_ratio, decoded_fps_ratio y max_frame_gap_seconds siguen siendo diagnósticos; por sí solas no pueden demostrar una reproducción. Los hallazgos anteriores describen la versión del detector utilizada en ese momento y no se reclasifican de forma retroactiva.
Se trata de una señal adicional conservadora, no de una detección completa de contenido sintético ni de vídeo inyectado. Una grabación sin anomalías no demuestra que haya prueba de vida. Las capturas cortas o ambiguas y las capturas sin evidencia de reproducción utilizable no se marcan en esta comprobación. Las grabaciones ausentes o ilegibles no generan ningún hallazgo en esta comprobación; las demás comprobaciones de la verificación siguen aplicándose.

Coincidencia facial entre sesiones

En las coincidencias con rostros importados o rostros de entradas de lista (que no tienen sesión), los valores *_session_id, *_session_number y api_service de additional_data son null. Los rostros que pertenecen al mismo usuario (mismo vendor_data, o el mismo usuario vendor cuando está disponible) se excluyen de toda la búsqueda en el índice, tanto de la detección de duplicados como del análisis de la lista de bloqueo. El orden de prioridad de las coincidencias es: lista de bloqueo exacta → lista de permitidos exacta → duplicado exacto → lista de bloqueo posible → lista de permitidos posible → duplicado posible; solo aparece uno de estos seis códigos mutuamente excluyentes por informe. DUPLICATED_FACE_NAME_MISMATCH no forma parte de ese grupo de prioridad: es un código adicional que se emite además de DUPLICATED_FACE cuando también falla la comprobación de identidad, nunca en su lugar. additional_data.name_match_score nunca incluye los nombres comparados, solo identificadores y una puntuación, de modo que ningún dato personal (PII) llega al payload de la advertencia. Un nombre escrito en un sistema de escritura distinto en cada documento (por ejemplo, en hebreo en uno y en caracteres latinos en el otro) puede puntuar por debajo del umbral aunque ambas sesiones pertenezcan a la misma persona. Solo en ese caso, DUPLICATED_FACE_NAME_MISMATCH no se emite cuando los documentos de identidad de las dos sesiones se corroboran entre sí en todos estos puntos:
  • Ambos documentos tienen el mismo país emisor.
  • Un identificador coincide exactamente entre los dos documentos. document_number y personal_number se consideran intercambiables, porque el mismo número nacional puede figurar en cualquiera de los dos campos según el tipo de documento.
  • Cuando ambos documentos incluyen una fecha de nacimiento, es la misma fecha.
Si los nombres están en el mismo sistema de escritura, si el identificador o el país emisor difieren o faltan, o si las fechas de nacimiento se contradicen, la advertencia se sigue emitiendo como se describe arriba.

Calidad de la prueba de vida pasiva (solo cuando method = "PASSIVE")

LOW_FACE_LUMINANCE y HIGH_FACE_LUMINANCE son mutuamente excluyentes: la luminancia está por debajo del mínimo o por encima del máximo, nunca ambas cosas.

Estimación de edad (flujos adaptativos y nodos AGE_ESTIMATION)

Cadenas de descripción exactas

La API devuelve exactamente estas cadenas short_description y long_description para cada riesgo:

API independiente de prueba de vida pasiva

La API de prueba de vida independiente reutiliza los mismos códigos de riesgo, con algunas diferencias de comportamiento:
  • NO_FACE_DETECTED y LOW_LIVENESS_SCORE son mutuamente excluyentes: la comprobación de la puntuación solo se ejecuta cuando se encontró un rostro. LOW_LIVENESS_SCORE se activa según el face_liveness_score_decline_threshold de la solicitud (30 por defecto) y siempre lleva log_type: "error".
  • POSSIBLE_FACE_IN_BLOCKLIST se trata como un rechazo (log_type: "error") en lugar de una revisión.
  • MULTIPLE_FACES_DETECTED lleva log_type: "warning", mientras que los riesgos de rostro duplicado siguen siendo informativos. Solo las advertencias de nivel error cambian el status de la respuesta independiente a Declined.
  • Las entradas de advertencia de la API independiente incluyen feature, pero no node_id.

Ejemplos

Rechazo automático ante un ataque detectado

Advertencias configurables en una captura pasiva

Rostro duplicado con payload

Aquí la acción de rostro duplicado está configurada en Revisión, por lo que la advertencia lleva log_type: "warning" y el estado del informe de prueba de vida es In Review. Con el valor predeterminado (Sin acción), llevaría log_type: "information". api_service es null porque el rostro coincidente procede de una sesión de un flujo, no de una llamada independiente a la API.

Rostro duplicado con otro nombre

DUPLICATED_FACE mantiene su propia acción configurada (aquí, Sin acción: log_type: "information"), mientras que DUPLICATED_FACE_NAME_MISMATCH lleva su propia acción, que de forma predeterminada es Revisión (log_type: "warning"). El estado del informe de prueba de vida sigue la más grave de las dos: In Review en este caso, aunque la configuración de rostro duplicado por sí sola no lo habría marcado.

Anomalía de coherencia de la grabación con sus mediciones

Este ejemplo muestra la evidencia de reproducción de una grabación que contiene tres copias de una secuencia en movimiento. log_type es information porque la acción configurada es NO_ACTION. Los diagnósticos de entrega de fotogramas, omitidos en este ejemplo por brevedad, no activan el hallazgo.

Tipos de advertencia

A cada riesgo se le asigna una gravedad según la configuración de tu aplicación. Las tres gravedades son:

Relacionado

Última modificación el 1 de noviembre de 2026