Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesVisão geral
Os avisos no relatório de prova de vida assinalam todas as condições observadas pela Didit durante a execução da verificação de prova de vida. Ficam registados no arraywarnings[] em cada item de liveness_checks[] (consulte Relatório de prova de vida), com o campo feature definido como "LIVENESS". Cada entrada segue a estrutura partilhada do objeto de aviso: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Cada aviso tem três camadas:
- O código
risk— um identificador estável que pode utilizar no seu código para fazer correspondências (os códigos listados abaixo). - O
log_type— um deinformation,warningouerror. Os riscos de recusa automática têm sempreerror. Para riscos configuráveis, é derivado da ação configurada: Sem ação →information, Revisão →warning, Recusar →error. Para riscos baseados em limiares (LOW_LIVENESS_SCORE,LOW_FACE_QUALITY), éerrorquando o valor atinge ou fica abaixo do limiar de recusa ewarningquando atinge ou fica abaixo apenas do limiar de revisão. - O impacto na decisão — o mesmo encaminhamento define o
statusdo relatório de prova de vida: uma ação de Revisão move-o paraIn Review, uma ação de recusa (ou qualquer risco de recusa automática) paraDeclined, e Sem ação deixa-o 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 as respetivas gravidades — não existem outros códigos de risco de prova de vida.
Condições de recusa automática
Os seguintes riscos forçam sempre o relatório de prova de vida (e a sessão) paraDeclined, com log_type: "error":
Quando
NO_FACE_DETECTED é acionado, LOW_LIVENESS_SCORE é suprimido (não há nenhum rosto ao qual atribuir uma pontuação).
Definições de verificação configuráveis
Na consola da Didit, os riscos de prova de vida estão agrupados sob as seguintes definições do fluxo:Avisos produzidos
Prova de vida principal
Integridade do canal de captura
Sinais de ataques de injeção reportados pelo cliente no momento da captura. Ao contrário dos ataques de apresentação (um artefacto colocado em frente a uma câmara real), estes descrevem a substituição ou interceção do próprio fluxo de vídeo da câmara. Cada um é configurável por fluxo e tem como predefinição nenhuma ação, pelo que ativar a funcionalidade não altera quaisquer decisões até que opte por fazê-lo.Os navegadores não disponibilizam atestação da fonte da câmara ao nível do SO a nenhum fornecedor, pelo que na web estes sinais são evidências corroborantes e não provas cabais. Na web, um veredito de
null significa não determinado (as etiquetas do dispositivo não estão disponíveis até que a permissão da câmara seja concedida) e nunca aciona um risco.FRAME_INJECTION_SUSPECTED: é detetado a partir do ambiente do dispositivo - a pilha de renderização e o modelo do dispositivo indicado pelo agente do utilizador - em vez do nome da câmara. As constatações baseadas no ambiente do dispositivo incluem additional_data.reason: "emulated_capture_device", distinguindo-as da análise de fotogramas do próprio modelo de prova de vida.
Detetar a máquina a partir de um navegador é uma evidência, não uma atestação, e um atacante determinado pode interferir com ela. Os SDKs móveis nativos reportam sinais de integridade ao nível do sistema operativo mais fortes, que um navegador não consegue ver (emulador, dispositivo com root ou jailbreak, interceção em tempo de execução, depurador associado), cada um com a sua própria ação configurável em Integridade do dispositivo e do ambiente de execução. Estes sinais aumentam consideravelmente o custo do atacante, mas por si só não provam 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, pelo que se combinam com qualquer um de Passivo, 3D Flash ou 3D Action & Flash.
Análise forense da integridade da gravação
LIVENESS_VIDEO_ANOMALY é calculado no servidor na gravação de prova de vida armazenada, independentemente do modelo de prova de vida. Deteta uma sequência em movimento repetida ao longo de múltiplos ciclos, consistente com um fluxo de vídeo em loop.
Defina a ação no seu nó de Prova de vida ou Estimativa de idade:
NO_ACTION regista uma constatação informativa, REVIEW pode escalar uma verificação decidida para Em análise, e DECLINE pode escalá-la para Recusada. A verificação é executada de forma assíncrona, pelo que uma escalada pode chegar após o resultado inicial. Uma decisão existente mais grave não é despromovida, e as decisões de revisão manual são preservadas.
As constatações da versão 2 incluem forensics_version: 2, evidência repeated_sequence e repeated_moving_sequence em anomaly_reasons. As medições de entrega como unique_frame_ratio, static_pair_ratio, decoded_fps_ratio e max_frame_gap_seconds permanecem como diagnósticos; não conseguem, por si só, provar uma reprodução. As constatações mais antigas descrevem a versão do detetor utilizada na altura e não são reclassificadas retroativamente.
Este é um sinal adicional conservador, não uma deteção completa de conteúdos sintéticos ou vídeo injetado. Uma gravação sem anomalias não é prova de vida. Capturas curtas ou ambíguas e capturas sem evidências utilizáveis de reprodução permanecem não assinaladas por esta verificação. Gravações em falta ou ilegíveis não produzem constatações a partir desta verificação; outras verificações continuam a aplicar-se.
Correspondência facial entre sessões
Para correspondências com rostos importados ou rostos em entradas de lista (que não possuem sessão), os valores de
*_session_id, *_session_number e api_service em additional_data são null.
Os rostos pertencentes ao mesmo utilizador (mesmo vendor_data, ou o mesmo utilizador de fornecedor quando disponível) são excluídos de toda a pesquisa no índice — tanto da deteção de duplicados como da triagem na lista de bloqueio. A precedência de correspondência é: lista de bloqueio exata → lista de permissões exata → duplicado exato → lista de bloqueio possível → lista de permissões possível → duplicado possível — apenas um destes 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 em substituição deste. additional_data.name_match_score nunca inclui os nomes que estão a ser comparados — apenas IDs e uma pontuação, para que nenhum dado pessoal (PII) chegue ao payload do aviso.
Um nome escrito num sistema de escrita diferente em cada documento (por exemplo, hebraico num e latino no outro) pode obter uma pontuação abaixo do limiar, mesmo quando ambas as sessões pertencem à mesma pessoa. Nesse caso específico, DUPLICATED_FACE_NAME_MISMATCH não é emitido quando os documentos de identificação de ambas as sessões se corroboram mutuamente em todos os seguintes pontos:
- Ambos os documentos apresentam o mesmo estado emissor.
- Um identificador coincide exatamente nos dois documentos.
document_numberepersonal_numbersão considerados equivalentes, porque o mesmo número nacional pode constar em qualquer um dos campos, dependendo do tipo de documento. - Onde ambos os documentos contêm uma data de nascimento, trata-se da mesma data.
Qualidade da prova de vida passiva (apenas quando method = "PASSIVE")
LOW_FACE_LUMINANCE e HIGH_FACE_LUMINANCE são mutuamente exclusivos — a luminância ou está abaixo do mínimo ou acima do máximo, nunca ambos.
Estimativa de idade (fluxos adaptativos e nós AGE_ESTIMATION)
Strings de descrição exatas
A API devolve exatamente estas stringsshort_description e long_description para cada risco:
API autónoma de prova de vida passiva
A API de Prova de Vida autónoma 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é acionado quando é atingido oface_liveness_score_decline_thresholddo pedido (predefinição 30) e inclui semprelog_type: "error".POSSIBLE_FACE_IN_BLOCKLISTé tratado como uma recusa (log_type: "error") em vez de revisão.MULTIPLE_FACES_DETECTEDincluilog_type: "warning", enquanto os riscos de rostos duplicados permanecem informativos. Apenas os avisos de nívelerroralteram ostatusda resposta autónoma paraDeclined.- As entradas de aviso autónomas incluem
feature, mas nãonode_id.
Exemplos
Recusa automática em caso de ataque detetado
Avisos configuráveis numa captura passiva
Rosto duplicado com payload
log_type: "warning" e o estado do relatório de prova de vida é In Review. Com a predefinição (No action), incluiria log_type: "information". api_service é null porque o rosto correspondente teve origem numa sessão de fluxo, e não numa chamada de API autónoma.
Rosto duplicado sob um nome diferente
DUPLICATED_FACE mantém a sua própria ação configurada (aqui, No action — log_type: "information"), enquanto DUPLICATED_FACE_NAME_MISMATCH inclui a sua própria ação, cuja predefinição é Review (log_type: "warning"). O estado do relatório de prova de vida segue a mais grave das duas: neste caso, In Review, mesmo que a definição simples de rosto duplicado por si só não o tivesse sinalizado.
Anomalia de integridade da gravação com as suas medições
log_type é information porque a ação configurada é NO_ACTION. O diagnóstico de entrega de fotogramas, omitido deste exemplo por brevidade, não desencadeia a deteção.
Tipos de aviso
A cada risco é atribuída uma gravidade com base na configuração da sua aplicação. As três gravidades são:Relacionado
- Relatório de prova de vida — esquema completo do relatório e estados.
- Avisos de correspondência facial — avisos complementares de correspondência facial 1:1.
- Webhooks —
session.status.updatedinclui os avisos assim que o passo de prova de vida for concluído. - Modelos de dados — Verificação de prova de vida — esquema canónico com todos os campos.
- Modelos de dados — Objeto de aviso — a estrutura de cada entrada em
warnings[].