Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesComo um template é criado
A retenção exige uma âncora de Utilizador. Uma sessão criada sem
vendor_data não tem Utilizador e, por isso, não pode reter um template. A eliminação devolve ineligible_no_vendor_user e o embedding é eliminado com a sessão.
O que um template contém
Os templates têm âmbito limitado à sua organização e são utilizados apenas por instrução sua, dentro da sua aplicação: deteção de rostos duplicados e de várias contas, Autenticação biométrica e as suas próprias listas faciais. Nunca são usados para treino de modelos, análises, correspondência entre organizações, sinais partilhados das Redes ou para o processamento independente de fraude da Didit.
Objeto template
Estado
Como são utilizados os modelos na correspondência
Um modeloactive participa exatamente na mesma correspondência que um rosto de uma sessão em direto: deteção automática de duplicados durante novas sessões, a API de Pesquisa facial independente, Autenticação biométrica e as suas listas de rostos. Uma correspondência com um modelo retido é reportada com source: "retained_template", o vendor_user_id e vendor_data do utilizador titular, e o biometric_template_id. Nunca inclui um ID de sessão, uma imagem de comparação, dados de identidade ou um estado, porque a sessão que produziu o rosto já não existe. Consulte Relatório de Pesquisa facial.
Um modelo retido nunca é colocado numa lista de bloqueio. Se o rosto da sessão eliminada estava numa lista de bloqueio de rostos, essa entrada da lista mantém a sua própria entrada biométrica independente e o seu próprio ciclo de vida: remover a entrada da lista elimina a entrada da lista de bloqueio, e eliminar o modelo não afeta a lista.
Pontos de eliminação
Todos os casos seguintes removem o modelo da correspondência e eliminam o modelo armazenado:
Repor a política da aplicação para
delete_with_session impede a criação de novos modelos, mas não elimina os existentes. Elimine-os explicitamente.
As eliminações apagam primeiro o modelo armazenado e só depois marcam o modelo como eliminado. Assim, uma eliminação que devolve 503 deixa o modelo em purge_failed, já excluído da correspondência, e pode ser repetida em segurança. Uma eliminação repetida de um modelo já eliminado devolve already_purged.
Registo de auditoria
Cada tentativa de retenção e de eliminação, incluindo falhas e resultados não elegíveis, é registada com o principal que atua (retained_by / principal de eliminação e tipo), instruction_class, instruction_source, instruction_id, provenance_reference e o resultado. Envie o seu próprio instruction_id nas eliminações para poder correlacionar o registo de auditoria da Didit com o seu registo de eliminações. As entradas de auditoria nunca contêm imagens, vetores, campos de identidade nem endereços de correio eletrónico.
Retenções legais
Uma retenção legal é uma exceção, nunca um modo de retenção. A Didit não aplica retenções por iniciativa própria; uma retenção só pode seguir uma instrução documentada ao abrigo do seu Acordo de Tratamento de Dados ou uma ordem vinculativa de uma autoridade competente. Enquanto uma retenção estiver em vigor, o modelo é marcado comoheld_out_of_use: fica excluído de todos os tipos de correspondência e da recuperação de rotina, e nunca é pesquisável. Não existe nenhuma API para criar ou levantar retenções. Contacte o seu representante da Didit se receber uma ordem que afete modelos retidos.
Permissões e autenticação
Os endpoints de templates biométricos aceitam apenas chaves de API da aplicação (x-api-key). Os tokens de utilizador da Business Console são rejeitados com 403. Os utilizadores da Consola gerem os modelos em Listas → Templates biométricos com as suas permissões de lists.