Apresentar uma credencial na carteira não é “mandar um QR code com um JWT”. É um protocolo entre emissor, carteira da pessoa e serviço verificador, com regras de confiança, consentimento, minimização, status e interoperabilidade que o backend precisa validar de forma deliberada.
O framework europeu de identidade digital (EUDI) está avançando de especificações e pilotos para implementações nacionais e testes do ecossistema. Os Estados-membros devem disponibilizar carteiras até o fim de 2026. Em 2026, os testes da Comissão reúnem equipes de carteiras, emissores, serviços verificadores e laboratórios para testar interoperabilidade real, incluindo OpenID for Verifiable Credential Issuance (OpenID4VCI), OpenID for Verifiable Presentations (OpenID4VP) e apresentações por proximidade com base na ISO/IEC 18013-5.
Para times de aplicação, a mudança é arquitetural: os dados de identidade ficam em uma carteira controlada pela pessoa; o serviço que os solicita deve se autenticar, pedir apenas atributos registrados e justificados, validar a apresentação e decidir para uma finalidade específica. Validar uma assinatura não prova, por si só, que todas as demais condições de confiança foram cumpridas.
Emissor, provedor da carteira e entidade verificadora são papéis de segurança distintos. Uma declaração do emissor não se torna confiável só por estar armazenada na carteira. O verificador precisa de uma estrutura de confiança para emissores e tipos de credencial, e deve validar a vinculação criptográfica ao titular ou à unidade da carteira conforme o formato e perfil escolhidos.
Na emissão, a carteira recebe uma oferta ou autorização, autentica-se conforme necessário, recebe a credencial do emissor e a armazena sob as proteções da carteira. Na apresentação, o serviço verificador cria uma solicitação com nonce, audiência e atributos; a pessoa revisa finalidade e dados; a carteira retorna uma prova; e o backend verifica chaves confiáveis, metadados do emissor, status e contexto da transação.
OpenID4VCI e OpenID4VP são famílias de protocolo com perfis e detalhes de implementação. Siga o Architecture and Reference Framework (ARF) da EUDI, os atos de execução aplicáveis e o perfil de interoperabilidade usado na implantação. Um perfil de piloto, um rascunho técnico e uma configuração de produção legalmente exigida não são equivalentes.
Uma boa tela de consentimento não corrige uma solicitação ampla demais. Se o serviço só precisa saber se alguém tem idade acima de um limite, peça uma prova dessa condição ou o atributo mais restrito suportado, em vez da data de nascimento e identidade completa. As regras do ecossistema preveem avisos claros quando o verificador pede atributos além dos cobertos por seu certificado de acesso registrado; silêncio ou caixa pré-marcada não substituem aprovação explícita.
O backend deve definir finalidade, atributos, retenção, base legal e uso posterior antes de montar a solicitação. Quando possível, armazene o resultado da decisão de negócio em vez de copiar a credencial inteira para o cadastro. Minimize logs: ID da transação, cadastro do verificador, resultado e tipo de credencial podem bastar; evite registrar a apresentação bruta, prova ou atributos pessoais por padrão.
| Caso de uso | Padrão de coleta excessiva | Pedido/resultado melhor |
|---|---|---|
| Serviço com restrição etária | Data de nascimento completa, endereço e número do documento. | Solicitar prova do limite etário e guardar apenas elegibilidade e referência de auditoria. |
| Qualificação profissional | Copiar a credencial inteira e atributos sem relação para o CRM. | Validar emissor, qualificação e validade; reter somente evidência necessária à decisão. |
| Abertura de conta | Reutilizar identidade para analytics ou marketing sem avaliar outra finalidade. | Separar verificação de identidade de perfil opcional e preferências de marketing. |
| Pagamento ou viagem | Guardar indefinidamente todos os atributos por conveniência do suporte. | Definir retenção por campo e manter comprovante transacional sem excesso de dados. |
Listas de confiança e dados de cadastro são dependências operacionais: use cache com validade limitada, monitore falhas de atualização e defina o que ocorre quando a fonte fica indisponível. Falhar aberto pode aceitar declarações não confiáveis; falhar fechado pode impedir acesso. A resposta depende do risco da transação e deve ser deliberada, documentada e observável.
Divulgação seletiva não é sinônimo de impossibilidade de correlação. Reutilizar identificadores estáveis, cruzar horários, coletar metadados do dispositivo ou consultar emissor/status a cada apresentação pode vincular transações. Avalie o que carteira, verificador, emissor, operador de listas, serviço de status e analytics conseguem observar em conjunto. Prefira identificadores específicos por relação quando suportados, IDs transacionais curtos, telemetria mínima e limites claros de retenção.
Status da credencial também exige equilíbrio: é preciso saber se está válida sem transformar a consulta em mecanismo de rastreamento. Siga o perfil aplicável, entenda as propriedades de privacidade e evite callbacks extras. Inclua capturas de tela, exportações de suporte, crash reports e ferramentas antifraude no mesmo mapa de dados pessoais.
Colocaria um gateway verificador na frente dos serviços de negócio. Ele autenticaria a configuração do serviço, criaria solicitações permitidas a partir de políticas versionadas, trataria callbacks, validaria provas, confiança do emissor, status e replay e retornaria um comprovante compacto e assinado da decisão. Esse comprovante poderia conter ID da transação, versão da política, tipo de credencial, referência do emissor, resultado e horário, mas não a credencial completa sem necessidade legítima específica.
Testes de contrato cobririam provas malformadas, credenciais vencidas/revogadas, audiência errada, nonce repetido, emissor não confiável, pedido excessivo, lista desatualizada e indisponibilidade do serviço de status. Use credenciais sintéticas em testes. Trate atualizações de protocolos e bibliotecas de confiança como mudanças explícitas e valide a interoperabilidade com implementações de referência e ambientes de aceitação atuais.
| Falha | Sinal | Controle |
|---|---|---|
| Assinatura válida, emissor não confiável | O backend aceita credencial correta criptograficamente, mas de origem não autorizada. | Valide cadeia de confiança, autorização do emissor, tipo e política. |
| Replay da apresentação | Resposta capturada antes é aceita em nova transação. | Vincule nonce e audiência, aplique expiração e proteção contra replay. |
| Pedido inclui atributos extras | A solicitação excede cadastro ou finalidade declarada. | Compare com o registro e exija aviso claro e ação explícita quando aplicável. |
| Dados de confiança/status antigos | Chaves ou estado de revogação em cache ultrapassam validade permitida. | Limite cache, alerte falhas e adote comportamento por risco durante indisponibilidade. |
| Credencial aparece nos logs | Atributos pessoais surgem em traces, analytics ou tickets. | Redija por padrão, use dados sintéticos e procure campos proibidos na telemetria. |
Integrar carteiras EUDI significa operar um protocolo distribuído de confiança, com consentimento compreensível e obrigações no backend. Separe os papéis de emissor, carteira e verificador; solicite os atributos mínimos; valide prova, emissor, status e contexto; e não replique credenciais completas em logs ou cadastros por padrão. Testes de interoperabilidade são parte da implementação: revelam onde as premissas de confiança falham.
Nota editorial: Especificações e implantação do ecossistema evoluem. Este artigo reflete materiais oficiais consultados em 28 de setembro de 2026 e não é aconselhamento jurídico, certificação nem validação de identidade. Siga o framework, atos de execução e orientações nacionais vigentes em cada integração.