Sem Verificação de Retorno ao Emissor: Por Que o Futuro PIC Digital Não Deve Contactar o Emissor em Cada Utilização

A revogação é o problema mais difícil em qualquer futuro Permis Internacional de Condução (PIC) digital. A forma mais fácil de o resolver é também a mais perigosa: tornar o emissor participante em cada apresentação individual. Uma credencial de condução transfronteiriça moderna deve recusar este atalho por defeito.

Quase todas as propostas de identidade digital contêm a mesma frase tranquilizadora:

“A credencial pode ser verificada instantaneamente.”

Por vezes, essa frase descreve um progresso genuíno. Por vezes, descreve vigilância com uma interface de utilizador mais amigável.

As normas publicadas atualmente já deixam claro que um verificador não precisa de contactar o emissor cada vez que uma credencial é apresentada:

• A arquitetura mDL atual do NIST afirma que um verificador pode validar a autenticidade e integridade confiando na assinatura e chaves públicas do emissor, sem qualquer contacto direto com o emissor.
• A AAMVA confirma que a norma ISO/IEC 18013-5 exige suporte para recuperação no dispositivo e apenas opcionalmente permite a recuperação no servidor.
• A AAMVA também adverte que, na recuperação pelo servidor, a autoridade emissora está envolvida em tempo real em cada utilização — o que significa que pode tecnicamente registar quando a credencial é utilizada, que dados são partilhados, e até inferir a localização através da análise de IP.

Isto não é uma nota de rodapé menor. É a questão central de design para a próxima geração de credenciais de condução transfronteiriças.

O Atalho Perigoso: Colapsar Quatro Questões Numa Única Chamada de Rede

As más arquiteturas agrupam quatro questões muito diferentes numa única chamada ao vivo ao emissor:

1. Esta credencial é autêntica?
2. A pessoa que a apresenta é o titular legítimo?
3. A própria credencial ainda é válida?
4. O direito de condução nacional subjacente ainda está em vigor?

Um sistema mal concebido responde a todas as quatro através de uma chamada ao emissor em tempo real. Um sistema bem concebido separa-as — porque não são o mesmo problema e não devem partilhar um mecanismo.

A Autenticidade Deve Ser Verificada Localmente, Não Através da Rede

Uma credencial pode ser criptograficamente genuína sem que o emissor alguma vez observe a transação.

• O modelo de confiança mDL do NIST afirma que a autenticidade e integridade são validadas a partir da assinatura e chaves públicas do emissor — sem necessidade de contacto ao vivo com o emissor.
• O Serviço de Confiança Digital da AAMVA existe precisamente para dar aos verificadores acesso a chaves públicas válidas do emissor sem callbacks por transação.

Princípio de Design 1: Não utilize conectividade ao vivo para resolver um problema que as assinaturas já resolvem.

Se um verificador detém chaves de emissor de confiança e recebe uma apresentação conforme com as normas, a autenticidade é uma verificação criptográfica local, não uma dependência de rede.

A Vinculação ao Titular Deve Ser Provada Localmente, Não Reportada Globalmente

A segunda questão — será este o titular legítimo? — também tem uma resposta que não depende de rede.

A arquitetura EUDI atual exige a vinculação ao dispositivo para PIDs e atestados ISO/IEC 18013-5. O verificador pede à carteira que assine um desafio novo usando a chave privada correspondente à chave pública incorporada na credencial:

• Na norma ISO/IEC 18013-5, isto denomina-se autenticação mdoc.
• Na norma SD-JWT VC, denomina-se vinculação de chave.

Em ambos os casos, a posse é provada localmente e criptograficamente. Nenhum dado pessoal precisa de chegar ao emissor.

Princípio de Design 2: Prove a posse localmente. Não prove a identidade globalmente.

Um futuro PIC deve esgotar a vinculação ao dispositivo, a autenticação local do titular e a resposta a desafios do verificador antes de considerar qualquer mecanismo do lado do emissor.

O Estado da Credencial e o Estado do Direito de Condução São Duas Coisas Diferentes

Muitos designs de identidade digital confundem esta distinção, e é aí que erram.

A especificação Bitstring Status List do W3C é clara a este respeito: a informação de estado associada a uma credencial verificável aplica-se à própria credencial verificável — não necessariamente ao direito real subjacente no mundo real. Uma credencial digital pode ser revogada porque o seu mecanismo de assinatura foi comprometido, enquanto o direito de condução subjacente permanece perfeitamente válido.

Um futuro PIC necessita, portanto, de duas camadas de estado distintas:

• Camada de estado da credencial — para a própria credencial digital ou canal de apresentação.
• Camada do direito de condução — para o direito nacional subjacente de conduzir.

Por vezes estas mudam em conjunto. Frequentemente não mudam. Um sistema que as confunde irá reagir em excesso, expor mais dados do que o necessário, ou ambos.

O Comprometimento da Carteira Deve Propagar-se Através do Estado — Não Desencadear Callbacks nos Verificadores

Um futuro PIC também precisa de uma resposta clara para o que acontece quando uma carteira é comprometida.

A arquitetura EUDI fornece uma:

• O fornecedor de carteira emite Atestados de Unidade de Carteira contendo informação de revogação.
• A integridade da carteira é reverificada ao longo do tempo; se uma carteira deixar de ser segura, o seu atestado é revogado.
• Os fornecedores de PID devem verificar regularmente se a carteira foi revogada. Se sim, revogam o PID.
• Ao verificar o estado do PID, a parte confiante verifica implicitamente o estado da carteira.

Esta é a estrutura em camadas que um futuro PIC deve adotar. Não peça a cada verificador que verifique independentemente o fornecedor de carteira. Deixe que o comprometimento da carteira se propague pelo pipeline de estado de credencial existente, e deixe que os verificadores consultem esse único canal que preserva a privacidade.

Três Padrões de Revogação Funcionais (Sem Callbacks Necessários)

A EUDI exige que os fornecedores utilizem um de três métodos de revogação:

• Atestados de curta duração — válidos por 24 horas ou menos, tornando a revogação desnecessária.
• Lista de Estado de Atestado — uma lista publicada que os verificadores podem consultar.
• Lista de Revogação de Atestado — uma lista explícita de credenciais revogadas.

Para atestados válidos por mais de 24 horas, a EUDI exige a incorporação de informação de revogação que inclua:

• Um URL onde as partes confiantes possam obter a lista de estado.
• Um identificador que localiza a credencial dentro dessa lista.

Se a informação de revogação fiável não estiver disponível — por exemplo, quando a parte confiante estiver offline — a EUDI orienta a parte confiante a realizar uma análise de risco antes de aceitar ou recusar a credencial.

A conclusão: a revogação não é um mecanismo único e, certamente, não é uma justificação para callbacks obrigatórios ao emissor.

Curta Duração por Defeito, Longa Duração Apenas Onde Necessário

Uma das medidas de privacidade mais eficazes em toda a pilha é também a mais simples: manter o que é apresentado com curta duração.

• A EUDI afirma que os atestados válidos por 24 horas ou menos não requerem infraestrutura de revogação — expiram antes de a revogação ser relevante.
• O W3C afirma que as apresentações verificáveis são tipicamente de curta duração e não foram concebidas para armazenamento a longo prazo.
• O NIST adverte explicitamente contra a transmissão repetida de identificadores reutilizáveis para uso quotidiano. A autenticação do dia-a-dia deve basear-se em tecnologias concebidas para esse fim, como as passkeys, e não na apresentação repetida de uma credencial rica em identidade.
• O NIST também escolheu a autenticação local no dispositivo em detrimento da correspondência biométrica no servidor, especificamente porque a autenticação local preserva a privacidade e é operacionalmente mais eficiente.

Princípio de Design 3: A credencial base pode ter um período de validade médio, mas a própria apresentação deve ser de curta duração, específica do verificador e não reutilizável.

As Listas de Estado São o Mecanismo Padrão Correto

Quando não se pode tornar tudo de curta duração, é necessária uma infraestrutura de estado — e a lista de estado é o padrão correto.

A Bitstring Status List v1.0 do W3C descreve um mecanismo que preserva a privacidade, é eficiente em termos de espaço e de alto desempenho para publicar dados de estado como suspensão ou revogação. As principais propriedades incluem:

• Cada emissor gere uma lista para as credenciais que emitiu.
• O formato comprime bem, uma vez que a maioria das credenciais permanece não revogada.
• O tamanho de lista padrão é de 131.072 entradas, que o W3C afirma proporcionar privacidade de grupo adequada no caso médio.
• Podem ser utilizadas listas maiores onde é necessária uma privacidade de grupo mais forte.

Isto desloca a questão de:

“Posso perguntar ao emissor sobre este utilizador agora?”

para:

“Já tenho uma lista de estado que preserva a privacidade suficientemente recente para decidir localmente?”

Esta é uma questão muito melhor — tanto técnica como politicamente.

“Sem Retorno ao Emissor” É um Padrão de Transferência, Não um Slogan

A regra mais importante nas orientações de privacidade da EUDI é processual, não filosófica.

As partes confiantes não devem solicitar a lista de estado cada vez que uma credencial é apresentada. Em vez disso, devem:

• Transferir cada nova versão da lista uma única vez.
• Fazê-lo num momento e a partir de um local não relacionados com qualquer apresentação de utilizador.
• Distribuir a lista internamente dentro da organização da parte confiante.
• Obter a lista sem autenticar a parte confiante.

Este é o núcleo operacional da verificação sem retorno ao emissor: atualizar o estado separadamente das apresentações dos utilizadores — nunca por pessoa, nunca por transação.

Esta única escolha de design impede o emissor ou fornecedor de estado de saber qual verificador consultou qual credencial em que momento.

Privacidade de Grupo: O Requisito que a Maioria dos Designs Esquece

Muitos sistemas proclamam a divulgação seletiva dentro da própria apresentação, ignorando depois silenciosamente a privacidade das consultas de estado. Esta é uma lacuna significativa.

Os requisitos de privacidade da EUDI especificam que:

• Os índices nas listas de estado devem ser atribuídos aleatoriamente, para que o índice em si nunca se torne um sinal de rastreamento.
• Cada lista deve cobrir um número suficientemente grande de credenciais para garantir a privacidade de grupo.
• Se uma lista for de outra forma demasiado pequena, os fornecedores devem adicionar entradas não utilizadas para ocultar a contagem real de credenciais.

Um futuro PIC não pode afirmar ser protetor da privacidade apenas com base na divulgação seletiva. Se o mecanismo de revogação revelar o evento de apresentação, o design de privacidade está incompleto.

A Operação Offline Não É um Caso Marginal — É um Requisito Central

Qualquer sistema de viagens que assuma conectividade perfeita está mal concebido.

• A AAMVA confirma que a recuperação no dispositivo funciona sem conectividade externa tanto para o dispositivo do titular como para o leitor, e que a norma ISO/IEC 18013-5 exige que os mDLs suportem a recuperação no dispositivo.
• A EUDI aceita que as partes confiantes possam estar offline e não ter uma lista de estado em cache, caso em que recomenda uma análise de risco antes de decidir.

Aceite esta cedência desde cedo:

Não se pode ter operação offline perfeita e atualização em tempo real perfeita ao mesmo tempo.

Qualquer arquitetura que prometa ambas sem compromisso é imprecisa ou está silenciosamente a reintroduzir vigilância. A resposta correta é tornar a atualização um parâmetro de política, não uma dependência de rede universal.

Os Registos São Onde a Privacidade Falha Silenciosamente

Mesmo uma excelente arquitetura de estado pode ser comprometida por registos descuidados.

• A EUDI exige que as instâncias das partes confiantes descartem elementos únicos e marcas temporais assim que deixem de ser necessários, e proíbe o seu reencaminhamento.
• A AAMVA proíbe as partes interessadas de rastrear titulares de mDL ou a utilização de mDL exceto onde exigido por lei, exige que as autoridades emissoras minimizem a partilha de metadados estáticos ou de longa duração, e restringe o acesso ao registo de atividade ao titular.
• A AAMVA também exige que a eliminação no dispositivo remova informações de registo e metadados que possam revelar o histórico de utilização — e que esta eliminação seja possível offline.

Isto é comportamento de protocolo, não gestão administrativa. Um futuro PIC deve tratar identificadores de longa duração, marcas temporais e registos como potenciais ferramentas de rastreamento, salvo prova explícita em contrário.

Uma Arquitetura Concreta Sem Retorno ao Emissor para o Futuro PIC

Reunindo os princípios, eis o que o sistema deve efetivamente fazer:

1. Emitir uma credencial base vinculada ao dispositivo. Vincular a credencial a chaves protegidas no ambiente seguro da carteira — obrigatório sob a EUDI para PIDs e atestados ISO/IEC 18013-5.
2. Solicitar apenas o que é necessário, com um desafio novo. Numa transação OpenID4VP, uma consulta DCQL permite à carteira mostrar ao titular quais os atributos que estão a ser solicitados, e o verificador emite um desafio para prevenir a repetição (segundo a arquitetura mDL atual do NIST).
3. Gerar uma apresentação de curta duração, não um identificador reutilizável. Cada apresentação deve ser específica ao verificador, ao pedido e ao momento.
4. Verificar a autenticidade localmente. Validar as assinaturas do emissor e as chaves públicas offline; o serviço de confiança da AAMVA foi criado exatamente para este fim.
5. Verificar o estado a partir de listas em cache, atualizadas separadamente. Quando as credenciais têm demasiada longevidade para dispensar a revogação, utilizar listas de estado em cache localmente, atualizadas segundo um calendário não relacionado com as apresentações dos utilizadores.
6. Aplicar uma política de risco quando a atualização não está disponível. Tornar as decisões offline uma política explícita do verificador, não uma suposição não estruturada.
7. Eliminar dados de rastreamento de forma agressiva. Descartar elementos únicos de transação e marcas temporais quando já não forem necessários; não reter registos que possam reconstruir o histórico de deslocações.

É assim que parece uma arquitetura séria sem retorno ao emissor — em camadas, que preserva a privacidade, criptograficamente local e operacionalmente honesta quanto à realidade offline.

Três Padrões Que Devem Ser Proibidos por Design

Um ecossistema maduro de PIC futuro deve tratar estes casos como falhas de arquitetura, não como escolhas de otimização:

• Callbacks obrigatórios ao emissor em cada apresentação. As próprias orientações de privacidade da AAMVA explicam por que isto é prejudicial.
• Utilizar a credencial de condução como autenticação de rotina. O NIST adverte explicitamente contra a apresentação repetida de credenciais com identidade para autenticação diária.
• Reter identificadores, marcas temporais e registos que possam reconstruir o histórico de apresentações. Tanto a EUDI como a AAMVA exigem o oposto.

O Argumento Central Numa Frase

A verificação instantânea não deve tornar-se uma autorização para vigilância do lado do emissor.

Um futuro PIC deve ser capaz de:

• Provar a autenticidade localmente.
• Provar a posse localmente.
• Verificar a atualização de forma privada.
• Tolerar a realidade offline.
• Funcionar graciosamente quando a informação perfeita não está disponível.

Nada disto torna o sistema mais fraco. Torna-o digno de ser implementado em escala.

No momento em que uma credencial de condução se torna uma ferramenta para registar quem mostrou o quê, onde e quando, deixa de ser uma versão mais segura do papel. Torna-se infraestrutura de observação.

É exatamente o que o futuro PIC deve recusar-se a tornar-se.

Perguntas Frequentes

O que é a “verificação de retorno ao emissor”?
É qualquer design em que um verificador contacta o emissor em tempo real para validar uma credencial. Embora resolva simultaneamente a autenticidade e a revogação, também permite ao emissor observar cada evento de apresentação.

A norma ISO/IEC 18013-5 exige contacto online com o emissor?
Não. A AAMVA confirma que a norma ISO/IEC 18013-5 exige suporte para recuperação no dispositivo e apenas opcionalmente permite a recuperação no servidor.

Como pode a revogação funcionar sem contactar o emissor?
Através de credenciais de curta duração, listas de estado de atestado ou listas de revogação de atestado — idealmente com a parte confiante a transferir os dados de estado separadamente das apresentações dos utilizadores.

Por que é que a “privacidade de grupo” é importante para as listas de estado?
Se uma lista de estado for demasiado pequena ou os seus índices forem previsíveis, um pedido de estado pode revelar qual credencial específica foi acabada de apresentar. Índices aleatórios e listas grandes previnem isto.

A verificação offline é realmente prática?
Sim — e os organismos de normalização, incluindo a AAMVA e a EUDI, exigem-na explicitamente. A cedência é que a atualização perfeita em tempo real é incompatível com a operação offline perfeita, pelo que a atualização deve tornar-se uma decisão de política, não uma dependência rígida.