Pular para o conteúdo principal

Visão geral

Os avisos do relatório de prova de vida sinalizam cada condição que a Didit observou ao executar a verificação de prova de vida. Eles aparecem no array warnings[] de cada item de liveness_checks[] (consulte o relatório de prova de vida), com feature definido como "LIVENESS". Cada entrada segue o formato compartilhado do objeto de aviso: feature, risk, additional_data, log_type, short_description, long_description, node_id. Todo aviso tem três camadas:
  1. O código risk: um identificador estável que você pode usar para correspondência no seu código (os códigos listados abaixo).
  2. O log_type: um dentre information, warning ou error. Os riscos de recusa automática sempre têm error. Para riscos configuráveis, ele é derivado da ação configurada: No action → information, Review → warning, Decline → error. Para riscos baseados em limiar (LOW_LIVENESS_SCORE, LOW_FACE_QUALITY), ele é error quando o valor ultrapassa o limiar de recusa e warning quando ultrapassa apenas o limiar de revisão.
  3. O impacto na decisão: o mesmo roteamento define o status do relatório de prova de vida: uma ação de Revisão o move para In Review, uma ação de Recusar (ou qualquer risco de recusa automática) para Declined, e Sem ação o mantém inalterado.
Alguns riscos são emitidos apenas quando o método de prova de vida é PASSIVE (verificações de múltiplos rostos, qualidade e luminância). As tabelas abaixo listam o conjunto completo de códigos de risco de prova de vida e suas severidades; não existem outros códigos de risco de prova de vida.

Condições de recusa automática

Os riscos a seguir sempre fazem com que o relatório de prova de vida (e a sessão) passe para Declined, com log_type: "error": Quando NO_FACE_DETECTED é disparado, LOW_LIVENESS_SCORE é suprimido (não há rosto para pontuar).

Configurações de verificação ajustáveis

No console da Didit, os riscos de prova de vida são agrupados nas seguintes configurações do fluxo de verificação (workflow):

Avisos gerados

Prova de vida principal

Integridade do canal de captura

Sinais de ataque de injeção informados pelo cliente no momento da captura. Diferentemente dos ataques de apresentação (um artefato exibido diante de uma câmera real), eles indicam que o próprio feed da câmera foi substituído ou interceptado. Cada um é configurável por fluxo e tem como padrão nenhuma ação, então ativar o recurso não altera nenhuma decisão até que você opte por isso.
Os navegadores não oferecem a nenhum fornecedor atestação da origem da câmera no nível do sistema operacional, então, na web, esses sinais são evidências complementares, e não constituem prova. Na web, um veredito null significa não determinado (os rótulos dos dispositivos ficam indisponíveis até que a permissão da câmera seja concedida) e nunca dispara um risco.
Uma câmera virtual é identificada pelo nome do dispositivo, então uma câmera que o sistema operacional apresenta com um nome comum não é reconhecida dessa forma. Dentro de um emulador Android, a câmera remapeada recebe um rótulo igual ao de qualquer câmera integrada, e é por isso que o caso de hardware emulado é informado por meio de FRAME_INJECTION_SUSPECTED: ele é detectado a partir do ambiente do dispositivo (a pilha de renderização e o modelo do dispositivo informado no user agent), e não pelo nome da câmera. As ocorrências geradas a partir do ambiente do dispositivo trazem additional_data.reason: "emulated_capture_device", o que as distingue da análise de frames feita pelo próprio modelo de prova de vida.
Detectar a máquina a partir de um navegador é uma evidência, não uma atestação, e um invasor determinado pode interferir nisso. Os SDKs mobile nativos informam sinais de integridade mais fortes, no nível do sistema operacional, que um navegador não consegue ver (emulador, dispositivo com root ou jailbreak, hooking em tempo de execução, depurador conectado), cada um com sua própria ação configurável em Integridade do dispositivo e do ambiente de execução. Esses sinais aumentam consideravelmente o custo para o invasor, mas, sozinhos, não comprovam que uma captura veio de um dispositivo genuíno. Os sinais de integridade do dispositivo são independentes do método de prova de vida, então podem ser combinados com qualquer um dos métodos Passive, 3D Flash ou 3D Action & Flash.

Análise forense de consistência da gravação

LIVENESS_VIDEO_ANOMALY é calculado no servidor, sobre a gravação de prova de vida armazenada, de forma independente do modelo de prova de vida. Ele detecta uma sequência em movimento repetida em vários ciclos, compatível com um feed em loop. Defina a ação no seu nó de Liveness ou de Age Estimation: NO_ACTION registra uma ocorrência informativa, REVIEW pode escalar uma verificação cuja decisão já foi tomada para Em revisão e DECLINE pode escalá-la para Recusado. A verificação é executada de forma assíncrona, então uma escalada pode chegar depois do resultado inicial. Uma decisão existente mais severa não é rebaixada, e as decisões de revisão manual são preservadas. As ocorrências da versão 2 incluem forensics_version: 2, a evidência repeated_sequence e repeated_moving_sequence em anomaly_reasons. Medições de entrega, como unique_frame_ratio, static_pair_ratio, decoded_fps_ratio e max_frame_gap_seconds, continuam sendo diagnósticas; sozinhas, elas não conseguem comprovar uma reprodução. As ocorrências mais antigas descrevem a versão do detector usada na época e não são reclassificadas retroativamente.
Este é um sinal adicional conservador, e não uma detecção completa de mídia sintética ou de vídeo injetado. Uma gravação sem anomalia não é prova de vida. Capturas curtas ou ambíguas e capturas sem evidência utilizável de reprodução não são sinalizadas por esta verificação. Gravações ausentes ou ilegíveis não geram ocorrência nesta verificação; as demais verificações continuam valendo.

Correspondência facial entre sessões

Para correspondências com rostos importados ou rostos de entradas de lista (que não têm sessão), os valores *_session_id, *_session_number e api_service em additional_data são null. Rostos que pertencem ao mesmo usuário (mesmo vendor_data, ou o mesmo usuário vendor quando disponível) são excluídos de toda a busca no índice — tanto da detecção de duplicatas quanto da triagem na lista de bloqueio. A ordem de precedência das correspondências é: lista de bloqueio exata → lista de permissões exata → duplicata exata → lista de bloqueio possível → lista de permissões possível → duplicata possível — apenas um desses seis códigos mutuamente exclusivos aparece por relatório. DUPLICATED_FACE_NAME_MISMATCH não faz parte desse grupo de precedência: é um código adicional emitido além de DUPLICATED_FACE quando a verificação de identidade também falha, nunca no lugar dele. additional_data.name_match_score nunca contém os nomes comparados — apenas IDs e uma pontuação, para que nenhum dado pessoal (PII) chegue ao payload do aviso. Um nome escrito em um sistema de escrita diferente em cada documento (por exemplo, hebraico em um e latino no outro) pode ficar abaixo do limiar mesmo quando as duas sessões pertencem à mesma pessoa. Somente nesse caso, DUPLICATED_FACE_NAME_MISMATCH não é emitido quando os documentos de identidade das duas sessões se corroboram em todos estes pontos:
  • Os dois documentos têm o mesmo país emissor.
  • Um identificador coincide exatamente entre os dois documentos. document_number e personal_number contam de forma intercambiável, porque o mesmo número nacional pode estar em qualquer um dos dois campos, dependendo do tipo de documento.
  • Quando os dois documentos têm data de nascimento, ela é a mesma.
Se os nomes estiverem no mesmo sistema de escrita, se o identificador ou o país emissor for diferente ou estiver ausente, ou se as datas de nascimento se contradisserem, o aviso continua sendo emitido conforme descrito acima.

Qualidade da prova de vida passiva (somente quando method = "PASSIVE")

LOW_FACE_LUMINANCE e HIGH_FACE_LUMINANCE são mutuamente exclusivos — a luminância está abaixo do mínimo ou acima do máximo, nunca as duas coisas.

Estimativa de idade (fluxos adaptativos e nós AGE_ESTIMATION)

Strings exatas de descrição

A API retorna exatamente estas strings de short_description e long_description para cada risco:

API de prova de vida passiva independente

A API de prova de vida independente reutiliza os mesmos códigos de risco, com algumas diferenças de comportamento:
  • NO_FACE_DETECTED e LOW_LIVENESS_SCORE são mutuamente exclusivos: a verificação da pontuação só é executada quando um rosto é encontrado. LOW_LIVENESS_SCORE é disparado com base no face_liveness_score_decline_threshold da requisição (padrão 30) e sempre vem com log_type: "error".
  • POSSIBLE_FACE_IN_BLOCKLIST é tratado como recusa (log_type: "error"), e não como revisão.
  • MULTIPLE_FACES_DETECTED vem com log_type: "warning", enquanto os riscos de rosto duplicado continuam apenas informativos. Somente avisos de nível error mudam o status da resposta independente para Declined.
  • As entradas de aviso da API independente incluem feature, mas não node_id.

Exemplos

Recusa automática por ataque detectado

Avisos configuráveis em uma captura passiva

Rosto duplicado com payload

Aqui, a ação para rosto duplicado está definida como Revisão, então o aviso traz log_type: "warning" e o status do relatório de prova de vida é In Review. Com o padrão (Nenhuma ação), ele traria log_type: "information". api_service é null porque o rosto correspondente veio de uma sessão de fluxo de verificação (workflow), e não de uma chamada avulsa à API.

Rosto duplicado com outro nome

DUPLICATED_FACE mantém a própria ação configurada (aqui, Nenhuma ação, com log_type: "information"), enquanto DUPLICATED_FACE_NAME_MISMATCH tem a própria ação, que por padrão é Revisão (log_type: "warning"). O status do relatório de prova de vida segue a mais severa das duas: In Review neste caso, embora a configuração de rosto duplicado sozinha não o tivesse sinalizado.

Anomalia de integridade da gravação com suas medições

Este exemplo mostra as evidências de replay de uma gravação que contém três cópias de uma sequência em movimento. log_type é information porque a ação configurada é NO_ACTION. Os diagnósticos de entrega de frames, omitidos deste exemplo por questões de concisão, não acionam a detecção.

Tipos de aviso

Cada risco recebe um nível de severidade com base na configuração da sua aplicação. As três severidades são:

Relacionados

Última modificação em 1 de novembro de 2026