Saltar al contingut principal

Visió general

Les advertències de l’informe de prova de vida assenyalen cada condició que Didit ha observat en executar la comprovació de prova de vida. S’inclouen a la matriu warnings[] de cada element de liveness_checks[] (consulta l’informe de prova de vida), amb feature establert a "LIVENESS". Cada entrada segueix l’estructura compartida de l’objecte d’advertència: feature, risk, additional_data, log_type, short_description, long_description, node_id. Cada advertència té tres capes:
  1. El codi risk: un identificador estable amb què pots fer una coincidència al teu codi (els codis llistats a continuació).
  2. El log_type: un dels següents valors: information, warning o error. Els riscos de rebuig automàtic sempre porten error. Per als riscos configurables, es deriva de l’acció configurada: Sense acció → information, Revisió → warning, Rebutjar → error. Per als riscos basats en llindars (LOW_LIVENESS_SCORE, LOW_FACE_QUALITY), és error quan el valor creua el llindar de rebuig i warning quan només creua el llindar de revisió.
  3. L’impacte en la decisió: el mateix encaminament determina el status de l’informe de prova de vida: una acció de Revisió el passa a In Review, una acció de rebuig (o qualsevol risc de rebuig automàtic) a Declined, i Sense acció el deixa sense canvis.
Alguns riscos només s’emeten quan el mètode de prova de vida és PASSIVE (comprovacions de múltiples cares, de qualitat i de luminància). Les taules següents mostren el conjunt complet de codis de risc de prova de vida i les seves severitats; no hi ha altres codis de risc de prova de vida.

Condicions de rebuig automàtic

Els riscos següents sempre forcen l’informe de prova de vida (i la sessió) a Declined, amb log_type: "error": Quan s’activa NO_FACE_DETECTED, LOW_LIVENESS_SCORE se suprimeix (no hi ha cap cara per puntuar).

Configuració de verificació

A la consola de Didit, els riscos de prova de vida s’agrupen sota les configuracions del flux de treball següents:

Advertències generades

Prova de vida principal

Integritat del canal de captura

Senyals d’atac d’injecció notificats pel client en el moment de la captura. A diferència dels atacs de presentació (un artefacte sostingut davant d’una càmera real), aquests descriuen la substitució o intercepció del propi senyal de la càmera. Cadascun és configurable per flux de treball i té per defecte el valor sense acció, de manera que activar la funcionalitat no canvia cap decisió fins que ho configuris expressament.
Els navegadors no exposen cap atestació de l’origen de la càmera a nivell de sistema operatiu a cap proveïdor, de manera que a la web aquests senyals són proves corroborants i no pas una prova. A la web, un veredicte de null significa no determinat (les etiquetes dels dispositius no estan disponibles fins que no s’atorga el permís de la càmera) i mai no activa cap risc.
Una càmera virtual s’identifica pel nom del seu dispositiu, de manera que una càmera que el sistema operatiu presenta amb un nom ordinari no es reconeix d’aquesta manera. Dins d’un emulador d’Android, la càmera reassignada s’etiqueta com una càmera integrada, motiu pel qual el cas de maquinari emulat es notifica a través de FRAME_INJECTION_SUSPECTED: es detecta a partir de l’entorn del dispositiu (la pila de renderització i el model de dispositiu notificat a l’agent d’usuari) en lloc del nom de la càmera. Les troballes generades a partir de l’entorn del dispositiu inclouen additional_data.reason: "emulated_capture_device", diferenciant-se així de l’anàlisi de fotogrames propi del model de prova de vida.
Detectar la màquina des d’un navegador és un indici, no una atestació, i un atacant decidit hi pot interferir. Els SDK natius per a mòbils reporten senyals d’integritat més sòlids a nivell de sistema operatiu que un navegador no pot veure (emulador, dispositiu amb root o jailbreak, hooking en temps d’execució, depurador connectat), cadascun amb la seva pròpia acció configurable a Integritat del dispositiu i del temps d’execució. Aquests senyals incrementen considerablement el cost per a l’atacant, però per si sols no demostren que una captura provingui d’un dispositiu genuí. Els senyals d’integritat del dispositiu són independents del mètode de prova de vida, per la qual cosa es combinen amb qualsevol de Passive, 3D Flash o 3D Action & Flash.

Anàlisi forense de la integritat de la gravació

LIVENESS_VIDEO_ANOMALY es calcula al servidor a partir de la gravació de prova de vida emmagatzemada, de manera independent del model de prova de vida. Detecta una seqüència en moviment repetida al llarg de múltiples cicles, coherent amb un senyal en bucle. Configura l’acció al teu node de Prova de vida o d’Estimació d’edat: NO_ACTION registra una troballa informativa, REVIEW pot escalar una verificació ja decidida a En revisió, i DECLINE pot escalar-la a Rebutjada. La comprovació s’executa de manera asíncrona, de manera que una escalada pot arribar després del resultat inicial. Una decisió existent més greu no es degrada, i les decisions de revisió manual es mantenen. Les troballes de la versió 2 inclouen forensics_version: 2, l’evidència repeated_sequence i repeated_moving_sequence a anomaly_reasons. Les mètriques de lliurament com ara unique_frame_ratio, static_pair_ratio, decoded_fps_ratio i max_frame_gap_seconds continuen sent diagnòstics; no poden establir una reproducció per si soles. Les troballes més antigues descriuen la versió del detector utilitzada en aquell moment i no es reclassifiquen retroactivament.
Aquest és un senyal addicional conservador, no una detecció exhaustiva de mitjans sintètics o vídeo injectat. Una gravació sense anomalies no és una prova concloent de vida. Les captures curtes o ambigües i les captures sense proves de reproducció utilitzables no són marcades per aquesta comprovació. Les gravacions que falten o són il·legibles no produeixen cap troballa d’aquesta comprovació; la resta de comprovacions de verificació continuen aplicant-se.

Coincidència facial entre sessions

Per a coincidències amb cares importades o cares que són entrades de llista (que no tenen cap sessió), els valors de *_session_id, *_session_number i api_service a additional_data són null. Les cares que pertanyen al mateix usuari (mateix vendor_data, o el mateix usuari del proveïdor quan estigui disponible) s’exclouen de tota la cerca a l’índex: tant de la detecció de duplicats com del cribratge de llistes de bloqueig. La precedència de coincidència és: llista de bloqueig exacta → llista de permesos exacta → duplicat exacte → llista de bloqueig possible → llista de permesos possible → duplicat possible; només un d’aquests sis codis mútuament excloents apareix per informe. DUPLICATED_FACE_NAME_MISMATCH no forma part d’aquest grup de precedència: és un codi addicional que s’emet a més de DUPLICATED_FACE quan la comprovació d’identitat també falla, mai en el seu lloc. additional_data.name_match_score mai conté els noms que es comparen; només identificadors i una puntuació, de manera que cap informació d’identificació personal (PII) arriba al payload de l’advertència. Un nom escrit en un sistema d’escriptura diferent en cada document (per exemple en hebreu en un i en llatí en l’altre) pot obtenir una puntuació inferior al llindar fins i tot quan ambdues sessions pertanyen a la mateixa persona. En aquest únic cas, DUPLICATED_FACE_NAME_MISMATCH no s’emet quan els documents d’identitat de les dues sessions es corroboren mútuament en tots aquests punts:
  • Ambdós documents indiquen el mateix estat emissor.
  • Un identificador coincideix exactament entre els dos documents. document_number i personal_number compten indistintament, ja que el mateix número nacional pot aparèixer en qualsevol dels dos camps segons el tipus de document.
  • Quan ambdós documents inclouen una data de naixement, és la mateixa data.
Si els noms estan en el mateix sistema d’escriptura, si l’identificador o l’estat emissor difereix o falta, o si les dates de naixement es contradiuen, l’advertència s’emet igualment tal com s’ha descrit anteriorment.

Qualitat de la prova de vida passiva (només quan method = "PASSIVE")

LOW_FACE_LUMINANCE i HIGH_FACE_LUMINANCE són mútuament excloents: la lluminositat està per sota del mínim o per sobre del màxim, mai ambdues coses a la vegada.

Estimació d’edat (fluxos de treball adaptatius i nodes AGE_ESTIMATION)

Cadenes de descripció exactes

L’API retorna exactament aquestes cadenes de short_description i long_description per a cada risc:

API independent de prova de vida passiva

L’API de prova de vida independent reutilitza els mateixos codis de risc amb algunes diferències de comportament:
  • NO_FACE_DETECTED i LOW_LIVENESS_SCORE són mútuament excloents: la comprovació de la puntuació només s’executa quan s’ha trobat una cara. LOW_LIVENESS_SCORE s’activa en funció del face_liveness_score_decline_threshold de la sol·licitud (30 per defecte) i sempre inclou log_type: "error".
  • POSSIBLE_FACE_IN_BLOCKLIST es tracta com un rebuig (log_type: "error") en lloc d’una revisió.
  • MULTIPLE_FACES_DETECTED inclou log_type: "warning", mentre que els riscos de cares duplicades es mantenen com a informatius. Només les advertències de nivell error canvien l’status de la resposta independent a Declined.
  • Les entrades d’advertència independents inclouen feature, però no node_id.

Exemples

Rebuig automàtic per atac detectat

Advertències configurables en una captura passiva

Cara duplicada amb payload

Aquí l’acció per a cara duplicada està configurada a Review, de manera que l’advertència inclou log_type: "warning" i l’estat de l’informe de prova de vida és In Review. Amb el valor per defecte (No action) inclouria log_type: "information". api_service és null perquè la cara coincident prové d’una sessió de flux de treball, no pas d’una crida d’API independent.

Cara duplicada sota un nom diferent

DUPLICATED_FACE es manté en la seva pròpia acció configurada (aquí, No action — log_type: "information") mentre que DUPLICATED_FACE_NAME_MISMATCH inclou la seva pròpia acció, que per defecte és Review (log_type: "warning"). L’estat de l’informe de prova de vida adopta la més greu de les dues: aquí In Review, tot i que la configuració bàsica de cara duplicada per si sola no l’hauria marcat.

Anomalia de coherència de la gravació amb les seves mesures

Aquest exemple mostra les proves de reproducció d’una gravació que conté tres còpies d’una seqüència en moviment. log_type és information perquè l’acció configurada és NO_ACTION. Els diagnòstics de lliurament de fotogrames, omesos en aquest exemple per brevetat, no activen aquesta detecció.

Tipus d’advertència

A cada risc se li assigna una gravetat basada en la configuració de la teva aplicació. Les tres gravetats són:

Relacionat

Darrera modificació el 7 de novembre del 2026