Lista de permissão sem atalho: menos atrito para o cliente conhecido, sem dispensar a identidade

Todo produto que verifica identidade recebe, cedo ou tarde, o mesmo pedido da equipe de operação: esse cliente já passou dez vezes, por que ele precisa fazer o desafio inteiro de novo? O pedido é legítimo. Atrito demais derruba conversão, e o cliente recorrente que abandona a jornada no meio é o prejuízo mais caro do funil, porque é justamente o cliente que a empresa já sabe que é bom.

A resposta comum é uma lista de permissão, e é aí que mora o risco. Uma lista mal desenhada vira um atalho que pula a verificação inteira para quem está nela. Quem descobre como entrar na lista, ou quem toma a conta de alguém que já está nela, passa sem ser visto.

Este artigo trata de como separar as duas coisas: reduzir o atrito de quem já é conhecido sem dispensar nenhuma das checagens que dizem se a pessoa é quem afirma ser.

Atrito é risco legítimo, e a norma reconhece

A série SP 800-63-4, as Digital Identity Guidelines publicadas pelo National Institute of Standards and Technology (NIST) dos Estados Unidos em 2025, trata a experiência de quem usa o serviço como parte da gestão de risco, e não como concessão. O volume base orienta as organizações a ajustar os controles (o que a norma chama de tailoring) com base em avaliação de risco contínua, incluindo usabilidade, e manda considerar o impacto de usuários legítimos que desistem do serviço por atrito ou frustração com o sistema de identidade.

O volume de verificação de identidade da mesma série, o SP 800-63A-4, repete a ideia ao falar da experiência do cliente, pedindo soluções seguras que minimizem atrito e frustração desnecessários. O mesmo volume, porém, não trata a detecção de ataque de apresentação como opcional quando a comparação biométrica é remota: é ela que confirma a presença genuína de uma pessoa viva diante da câmera.

Essa é a linha que uma lista de permissão precisa respeitar. Dá para reduzir o esforço pedido a quem já é conhecido. Não dá para desligar o que distingue o titular de alguém se passando por ele.

O que a permissão pode mudar, e o que nunca muda

Numa verificação com prova de vida, há duas camadas que costumam ser confundidas:

• O tamanho do desafio: quantas ações a pessoa faz diante da câmera antes da captura. É aqui que mora o atrito que o cliente recorrente sente.
• A decisão de identidade: comparação do rosto com o documento, análise do documento, prova de vida, os módulos do fluxo, lista de bloqueio, situação cadastral, sanções e pessoas politicamente expostas.

Uma lista de permissão bem desenhada mexe só na primeira camada. A decisão de identidade roda inteira, com os mesmos critérios e a mesma cobrança, e sai igual com ou sem a permissão. Se o rosto não bate, a verificação não é aprovada.

Duas regras completam o desenho:

• A lista de bloqueio sempre vence. Um titular bloqueado não recebe permissão, e um titular permitido que é bloqueado depois é barrado normalmente. O artigo sobre lista de bloqueio interna discute quando bloquear e por quanto tempo.
• A permissão não desliga as outras defesas da prova de vida, e vale só para o próprio titular, no contexto em que ele já foi verificado. Fora dele, o desafio é o de sempre. É isso que impede que a conta tomada de um cliente permitido vire um atalho.

A chave certa: quem escolhe a identidade

Uma lista precisa de uma chave, e a escolha dela decide quem consegue entrar. Se a chave for algo que o próprio titular digita na tela, como um número de documento, qualquer pessoa pode escrever o número de um cliente permitido e herdar o alívio.

A chave segura é a referência do cliente no sistema da empresa: o identificador que o servidor da empresa envia ao abrir a verificação, com a credencial do servidor. O titular não a escolhe nem a vê. E a referência não fica guardada em claro: a lista guarda apenas um resumo que não permite reconstruí-la, e uma empresa nunca enxerga a lista de outra.

Quem pode conceder, e por quanto tempo

A permissão é o ponto em que um operador alivia a verificação de outra pessoa. Isso a torna alvo natural de quem rouba a conta de um operador. Três controles fecham esse caminho:

1. Capacidade própria. Conceder não vem junto com o papel de administrador: é uma capacidade separada, dada por quem é dono da conta e retirada a qualquer momento.
2. Segundo fator em toda concessão. O volume de autenticação da série, o SP 800-63B-4, descreve a autenticação de elevação (step-up), que eleva o nível de garantia de uma sessão já autenticada quando a operação pede mais. Conceder permissão é exatamente esse caso. O artigo sobre segundo fator obrigatório no painel trata de como exigir sem trancar a equipe.
3. Validade curta e obrigatória. A permissão nasce com prazo e vence sozinha. O prazo nunca passa do tempo de guarda da evidência que a justificou: se a selfie e o vídeo da verificação de origem já foram apagados, a permissão não sobrevive a eles.

A concessão também só nasce da linha de uma verificação aprovada, nunca de um valor digitado no painel. Assim, a permissão sempre aponta para uma prova concreta de que aquele titular já foi verificado.

Trilha e minimização

A Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) pede, no art. 6º, inciso III, que o tratamento se limite ao mínimo necessário para a finalidade, e, no art. 37, que controlador e operador mantenham registro das operações de tratamento. As duas regras se encaixam bem numa lista de permissão:

• A trilha registra quem concedeu, quem revogou, quando venceu e em que alcance, sem dado pessoal. É o registro que responde quem aliviou a verificação desta pessoa, e por quê.
• O motivo é um código de uma lista fechada, com um comentário opcional que não deve conter dado do titular.
• Um pedido de exclusão do titular encerra a permissão e apaga a etiqueta e o comentário.

A trilha só serve se não puder ser reescrita. O artigo sobre log de auditoria imutável mostra por que a imutabilidade precisa ser garantida pelo banco de dados, e não por convenção.

Um roteiro para avaliar a sua lista

Antes de ligar uma lista de permissão, vale responder:

• Quais checagens ela pula? A resposta certa é nenhuma de identidade, só o tamanho do desafio.
• Quem escolhe a chave? Se o titular consegue escolher, a lista é uma porta aberta.
• Quem concede, e com que prova? Papel sozinho não basta: conceder deve pedir capacidade própria e segundo fator.
• Quanto tempo dura? Sem vencimento, uma permissão esquecida vira atalho permanente.
• A lista de bloqueio vence? Se não vence, bloquear um fraudador depende de lembrar de tirá-lo da outra lista.
• Existe uma trilha que não se reescreve?

Na UNIFOKAL, por exemplo, a lista de permissão segue essas regras, vale só nos fluxos com fricção adaptativa e está descrita na documentação da lista de permissão.

Fontes citadas

• National Institute of Standards and Technology (NIST). SP 800-63-4, Digital Identity Guidelines, 2025.
• NIST. SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment, 2025.
• NIST. SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, 2025.
• Brasil. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais), art. 6º, inciso III, e art. 37.