Visão geral
O relatório de verificação de identidade reúne tudo o que a Didit extraiu e validou de um documento de identidade emitido pelo governo: passaportes, carteiras de identidade, carteiras de motorista e autorizações de residência. Ele agrupa os campos biográficos e do documento obtidos por OCR, URLs assinadas para as mídias capturadas, dados de endereço interpretados e geolocalizados, pontuações de qualidade de imagem de cada lado do documento, o conteúdo da MRZ, detalhamentos por sistema de escrita (latino / não latino) e correspondências de documentos entre sessões. O relatório é gerado depois que o usuário conclui a etapa de captura do documento em um fluxo de verificação (workflow) ou chama o endpoint de OCR independente. A Didit identifica o tipo de documento, executa o OCR, valida a MRZ, o código de barras ou o QR code, interpreta o endereço, verifica sinais de adulteração (captura de tela, cópia impressa, manipulação do retrato) e compara o documento com todos os outros documentos capturados na sua aplicação. Cada relatório tem seu própriostatus, independente do status geral da sessão, que reflete como a etapa de identidade foi resolvida isoladamente:
- Aprovado: documento reconhecido, todos os campos obrigatórios extraídos e nenhum aviso direcionado à recusa foi disparado.
- Em Revisão: um ou mais avisos foram disparados e o seu fluxo os direciona para revisão.
- Recusado: uma condição de recusa automática foi disparada (documento não suportado, documento expirado, retrato ausente, ocorrência na lista de bloqueio, falha na verificação adaptativa de idade) ou foi disparado um aviso cuja ação configurada é Decline (as condições de idade mínima/máxima usam Decline por padrão).
- Expirado: a
expiration_datedo documento venceu após a verificação. O monitoramento contínuo de validade da Didit muda o relatório deApprovedparaExpired, adiciona um avisoDOCUMENT_EXPIREDe move uma sessão aprovada para o status de sessãoKyc Expired. - Não concluído: o usuário nunca concluiu a etapa de captura.
Onde ele aparece nas respostas da API
O relatório de identidade é entregue dentro do arrayid_verifications[], que é sempre um array JSON e nunca um objeto id_verification singular. Aparecem várias entradas quando um fluxo executa mais de uma etapa de documento (por exemplo, um documento de identidade principal mais uma verificação adicional).
- API de decisão da sessão:
GET /v3/session/{sessionId}/decision/retornaid_verifications[]no nível superior. Consulte Obter a decisão da sessão. - Webhooks: os payloads de
session.status.updatedincluem o mesmo arrayid_verifications[]assim que a etapa tiver gerado dados. Consulte Webhooks. - API de OCR independente: o envio direto de documentos retorna um objeto
id_verificationsingular com os mesmos campos. Consulte API de OCR independente.
Leia
response.id_verifications[0] e percorra o array. A estrutura individual de id_verification existe apenas na API de OCR independente e não existe no endpoint de decisão v3.Esquema
O esquema canônico, campo a campo, está na página de referência Modelos de dados. Os campos abaixo vêm diretamente deIDVerificationV3Serializer, que estende IDVerificationV2Serializer e adiciona node_id, o array matches[] de correspondências entre sessões e o array document_selfie_face_matches[] do Silent Capture.
Campos de nível superior
issuing_state é sempre de nível nacional, nunca subnacional. Para todo
tipo de documento, incluindo carteiras de motorista emitidas por um estado ou província
(Austrália, Estados Unidos, Canadá), issuing_state e
issuing_state_name informam o país (por exemplo AUS /
Australia), e não o estado. O valor subnacional, quando o documento
o contém, fica disponível separadamente em parsed_address.region (com
extra_fields.state como alternativa em alguns tipos de documento). A visão geral da sessão no Business
Console exibe esse valor como uma linha Region abaixo de
Issuing state, quando presente.Carteiras de motorista com dois números (Austrália). As carteiras australianas
trazem impressos tanto um número da licença, que identifica a habilitação do
titular para dirigir e permanece o mesmo quando o cartão é substituído, quanto um número do cartão,
que identifica o cartão físico e muda a cada nova emissão. Para essas
carteiras, a Didit sempre mapeia os números da mesma forma:
personal_number— o número da licençadocument_number— o número do cartão
document_number quanto em personal_number, de modo que document_number sempre contém
um identificador quando a verificação é concluída. personal_number é o
número da licença em ambos os casos. Em outros tipos de documento, document_number continua
sendo o número principal extraído por OCR e pode ser, ele próprio, um identificador do titular.O CUIL argentino é
extra_fields.tax_number, nunca personal_number.
Os documentos argentinos imprimem o CUIL (o identificador de 11 dígitos usado
como chave pela AFIP, pela ANSES e pelos birôs de crédito) em um lugar diferente
em cada documento, e o DNI imprime um segundo número de 11 dígitos ao lado dele:- na carteira de motorista, o CUIL é o que
personal_numbercontém; - no DNI,
personal_numbercontém o número de trámite, que identifica a solicitação do cartão e não é um identificador do titular. O CUIL do DNI é lido no próprio campo impresso.
personal_number não é um CUIL confiável para a Argentina: em um DNI, ele é
um número de 11 dígitos que, silenciosamente, não retornará nenhum resultado em nenhum registro.
Leia extra_fields.tax_number em vez disso. A Didit só o informa quando o valor
é validado como um CUIL real (prefixo de pessoa mais o dígito verificador módulo 11), em
dígitos canônicos sem separadores (27111111117), qualquer que seja o documento
argentino apresentado pelo titular. Quando o CUIL do cartão não pôde ser lido, a
chave fica ausente em vez de ser preenchida com um número que não é um CUIL. Para
atender esses usuários, capture a carteira de motorista como segundo documento ou colete o CUIL por meio de uma
resposta de Questionário ou do metadata da sessão.Pontuações de qualidade da imagem
front_image_quality_score e back_image_quality_score retornam, cada um:
Pontuações de prova de vida do documento
document_liveness informa o que a verificação de prova de vida do documento mediu, tenha ela gerado um aviso ou não. Um aviso só existe quando uma pontuação ficou abaixo de um dos limiares do fluxo; por isso, antes deste campo, um documento aprovado não trazia nenhuma evidência de prova de vida. É com este campo que você audita uma sessão aprovada. Ele é null quando a verificação não foi executada (por exemplo, em um método que não é de documento ou em uma indisponibilidade do modelo registrada nos logs da sessão).
Ele contém um objeto por tipo de fraude (portrait_replace, printed_copy e screen_replay), cada um com:
bucket são null. As configurações atuais do fluxo nunca são usadas para reconstruir um resultado histórico. O mesmo se aplica a uma captura cuja avaliação do documento ainda não foi concluída.
O Business Console mostra as mesmas três linhas no bloco Document liveness da seção de Verificação de identidade da sessão.
Correspondências entre sessões
matches[] lista até 5 outros documentos na sua aplicação que correspondem a este: mesma data de nascimento, mesmo país emissor e um nome completo muito semelhante. Documentos na lista de bloqueio exigem, além disso, uma correspondência exata do número do documento. Sessões que pertencem ao mesmo usuário (mesmo vendor_data) são excluídas.
Cada entrada inclui session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted (true quando o documento foi adicionado à sua lista de bloqueio), api_service e uma front_image_url assinada.
Valores de status
Documentos com múltiplos sistemas de escrita (latino / não latino)
Alguns documentos, como os do Quirguistão, Cazaquistão, Rússia, Japão, Coreia, China, países árabes, Tailândia e outros, imprimem o nome, o endereço ou o local de nascimento do titular tanto em uma transliteração latina quanto no sistema de escrita local. Você escolhe qual sistema de escrita preenche os campos de nível superior com a configuraçãopreferred_characters do fluxo (ou da API independente):
Os valores no sistema de escrita alternativo ficam dentro de
extra_fields, em chaves com sufixo: first_name_non_latin, last_name_non_latin, middle_name_non_latin, full_name_non_latin, address_non_latin, place_of_birth_non_latin (ou as variantes _latin correspondentes).
Quando os campos de sistema de escrita alternativo aparecem
- Somente quando os dois sistemas de escrita estão realmente presentes no documento. Se um campo de OCR nominalmente rotulado como “Surname-Kyrgyz (Cyrillic)” for extraído como texto em escrita latina (homóglifos ou uma transliteração latina), ele não se qualifica como alternativa não latina e essa chave é omitida.
full_name_non_latin(efull_name_latin) são sempre reconstruídos a partir dos componentes individuais de nome, nome do meio e sobrenome quando ambos os sistemas de escrita estão disponíveis. O campo bruto “Full Name” do OCR é ignorado por questão de consistência.- Quando
preferred_characters=latin, mas o documento contém apenas texto não latino (de modo que os campos de nível superior acabam ficando em sistema de escrita não latino), a Didit executa uma etapa de transliteração e expõefirst_name_latin,last_name_latin,middle_name_latin,full_name_latin,place_of_birth_latineaddress_latincomo alternativa em escrita latina.
last_name_non_latin está ausente porque, nesta amostra, o campo “Surname (Cyrillic)” do documento retornou em caracteres latinos: não havia um sobrenome genuinamente não latino para extrair.
Exemplos
Approved: documento de identidade espanhol sem problemas (todos os campos)
In Review: QR não detectado em um documento que deveria ter um
Resumido: uma resposta real sempre traz o conjunto completo de campos mostrado acima.Nota de segurança
As URLs assinadas retornadas para imagens e vídeos de documentos são temporárias: elas expiram após um período de validade limitado. Trate-as como de curta duração: baixe o que precisar imediatamente e não as armazene em cache nem as exponha publicamente. Normalmente, sua aplicação só precisa destatus, de alguns campos biográficos e dos avisos. Armazene o mínimo possível para reduzir a superfície de exposição em caso de futura violação.
Relacionados
- Avisos da verificação de identidade: lista completa de avisos, causas e correções.
- Monitoramento de documentos: como a Didit detecta adulterações e duplicatas entre sessões.
- Documentos suportados: quais tipos de documento e países são cobertos.
- Subtipos de documento: lista completa de códigos
document_subtype, incluindo a distinção entre carteiras de motorista comerciais e padrão dos EUA. - Webhooks: monitore
session.status.updatedpara receber o relatório. - Modelos de dados: verificação de identidade: esquema canônico com todos os campos.