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 arraywarnings[] 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:
- 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). - El
log_type: uno deinformation,warningoerror. Los riesgos de rechazo automático siempre llevanerror. 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) eserrorcuando el valor cruza el umbral de rechazo ywarningcuando solo cruza el umbral de revisión. - El impacto en la decisión: el mismo enrutamiento determina el
statusdel informe de prueba de vida: una acción Revisión lo pasa aIn Review, una acción Rechazar (o cualquier riesgo de rechazo automático) aDeclined, y Sin acción lo deja sin cambios.
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 aDeclined, 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.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_numberypersonal_numberse 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.
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 cadenasshort_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_DETECTEDyLOW_LIVENESS_SCOREson mutuamente excluyentes: la comprobación de la puntuación solo se ejecuta cuando se encontró un rostro.LOW_LIVENESS_SCOREse activa según elface_liveness_score_decline_thresholdde la solicitud (30 por defecto) y siempre llevalog_type: "error".POSSIBLE_FACE_IN_BLOCKLISTse trata como un rechazo (log_type: "error") en lugar de una revisión.MULTIPLE_FACES_DETECTEDllevalog_type: "warning", mientras que los riesgos de rostro duplicado siguen siendo informativos. Solo las advertencias de nivelerrorcambian elstatusde la respuesta independiente aDeclined.- Las entradas de advertencia de la API independiente incluyen
feature, pero nonode_id.
Ejemplos
Rechazo automático ante un ataque detectado
Advertencias configurables en una captura pasiva
Rostro duplicado con payload
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
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
- Informe de prueba de vida: esquema completo del informe y sus estados.
- Advertencias de coincidencia facial: advertencias complementarias de coincidencia facial 1:1.
- Webhooks:
session.status.updatedincluye las advertencias en cuanto termina el paso de prueba de vida. - Modelos de datos: comprobación de prueba de vida: esquema canónico con todos los campos.
- Modelos de datos: objeto de advertencia: la estructura de cada entrada de
warnings[].