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 arraywarnings[] 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:
- O código
risk: um identificador estável que você pode usar para correspondência no seu código (os códigos listados abaixo). - O
log_type: um dentreinformation,warningouerror. Os riscos de recusa automática sempre têmerror. 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 éerrorquando o valor ultrapassa o limiar de recusa ewarningquando ultrapassa apenas o limiar de revisão. - O impacto na decisão: o mesmo roteamento define o
statusdo relatório de prova de vida: uma ação de Revisão o move paraIn Review, uma ação de Recusar (ou qualquer risco de recusa automática) paraDeclined, e Sem ação o mantém inalterado.
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 paraDeclined, 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.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_numberepersonal_numbercontam 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.
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 deshort_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_DETECTEDeLOW_LIVENESS_SCOREsão mutuamente exclusivos: a verificação da pontuação só é executada quando um rosto é encontrado.LOW_LIVENESS_SCOREé disparado com base noface_liveness_score_decline_thresholdda requisição (padrão 30) e sempre vem comlog_type: "error".POSSIBLE_FACE_IN_BLOCKLISTé tratado como recusa (log_type: "error"), e não como revisão.MULTIPLE_FACES_DETECTEDvem comlog_type: "warning", enquanto os riscos de rosto duplicado continuam apenas informativos. Somente avisos de nívelerrormudam ostatusda resposta independente paraDeclined.- As entradas de aviso da API independente incluem
feature, mas nãonode_id.
Exemplos
Recusa automática por ataque detectado
Avisos configuráveis em uma captura passiva
Rosto duplicado com payload
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
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
- Relatório de prova de vida: esquema completo do relatório e status.
- Avisos de correspondência facial: avisos complementares de correspondência facial 1:1.
- Webhooks:
session.status.updatedtraz os avisos assim que a etapa de prova de vida termina. - Modelos de dados: verificação de prova de vida: esquema canônico com todos os campos.
- Modelos de dados: objeto de aviso: o formato de cada entrada em
warnings[].