Identidade digital bem feita: afirmações verificáveis sem vigilância

Atualização, 11 de fevereiro de 2026: Foi rápido. A verificação de idade do Discord, feita pela k-id e pelo parceiro faceassure, foi completamente contornada. A ferramenta, criada por xyzeva e Dziurwa (com crédito a amplitudes pelo trabalho anterior), verifica automaticamente a tua conta como adulta no Discord, no Twitch, no Kick, no Snapchat e em qualquer outra plataforma que use a k-id. Como? Porque a “estimativa facial” da k-id processa a tua cara inteiramente no dispositivo e só envia metadados para o servidor. Ou seja, podes simplesmente… enviar metadados falsos. O servidor não tem como notar a diferença. Isto não é um bug. É a consequência inevitável de construir teatro de segurança em vez de segurança a sério. Se vais verificar a idade sem uma cadeia de confiança criptográfica assente num fornecedor de identidade real, não estás a verificar nada. Estás só a acrescentar atrito que os utilizadores reais detestam e que quem quer contornar derrota num fim de semana. Tudo o que está abaixo continua a valer. Lê até ao fim.

Sou australiano. Vivo no Reino Unido. Os dois governos são igualmente responsáveis pela confusão que se está a desenrolar.

A Online Safety Act do Reino Unido abriu as hostilidades em julho de 2025, ao exigir verificação de idade “altamente eficaz” a qualquer site com conteúdo adulto (um certo portal que começa por P, um site especializado em fãs, o Reddit, a lista toda), com multas até £18 milhões ou 10% do volume de negócios global por incumprimento.¹ O Imgur olhou para os requisitos de conformidade e saiu do Reino Unido de vez.² A Online Safety Amendment Act da Austrália seguiu-se em dezembro de 2025, proibindo as redes sociais a menores de 16 anos e obrigando as plataformas a provar que o fazem cumprir.³ E alastra. A França aprovou em janeiro de 2026 uma proibição das redes sociais a menores de 15 anos.⁴ A Espanha anunciou a sua hoje, para menores de 16, com “barreiras reais que funcionam, não apenas caixas de seleção”.⁵ A proibição da Dinamarca deve passar até meados de 2026. A Grécia está a redigir a sua neste momento. O Regulamento dos Serviços Digitais da UE já exige proteções adequadas à idade em todo o bloco.⁶

Todas as grandes democracias (com exceção da da liberdade) estão a chegar à mesma conclusão: as plataformas precisam de saber a idade dos seus utilizadores. E o instinto está certo. Precisamos de proteger mentes em desenvolvimento de conteúdos nocivos. As provas sobre saúde mental dos adolescentes e exposição sem limites às redes sociais são arrasadoras, e deixar que miúdos de 12 anos se declarem maiores com uma caixa de seleção é uma farsa há vinte anos.

Mas a questão é esta. Todas as implementações até agora foram desenhadas em torno da pergunta errada. Os governos perguntam “como identificamos as pessoas?” quando deviam perguntar “como verificamos afirmações sem identificar ninguém?”

O resultado é um cenário em que verificar a idade significa enviar uma foto do passaporte para um serviço de terceiros e esperar que não sofra uma fuga de dados. Ou passar a tua cara por um modelo de IA que adivinha a tua idade pela estrutura óssea, vigilância biométrica com outro nome. A abordagem do Reino Unido ao abrigo da Online Safety Act fez o uso de VPN disparar mais de 1 400% no primeiro dia de aplicação, porque os adultos decidiram, com toda a razão, que preferiam encaminhar o tráfego pela Irlanda a entregar a carta de condução a um site especializado em fãs.

O governo devia manter-se bem longe da tua vida. Mas as empresas deviam poder confiar que não são responsabilizadas quando a verificação de idade é contornada. Um miúdo de 14 anos com uma barba farta pode muito bem enganar a estimativa facial de hoje. Um cartão de crédito emprestado derrota a verificação de pagamento. Uma VPN derrota o geo-bloqueio por completo.

Vamos então explorar: dá para desfazer este desastre?

Dá.

Já usas a maior parte desta tecnologia

O que torna esta situação tão exasperante é isto: os blocos de construção da verificação de identidade com privacidade não são um projeto de investigação distante. Estão a correr no teu telemóvel agora mesmo… enquanto lês isto.

Sempre que entras num site e ele se lembra de quem és sem te pedir a palavra-passe outra vez, há boas hipóteses de um JSON Web Token (JWT) estar a fazer o trabalho pesado.⁷ Um JWT é apenas um bloco de informação assinado. Tem três partes: um cabeçalho que diz como foi feito (assinado), um conteúdo cheio de “afirmações” (quem és e que tipo de saco de carne és) e uma assinatura que prova que o conjunto não foi adulterado.

Isto é o conteúdo típico de um JWT quando entras, por exemplo, no teu banco:

{
  "sub": "user_38291",
  "name": "Will Hackett",
  "email": "will@example.com",
  "iat": 1706918400
}

Vês o campo sub? É um identificador único. É assim que o banco sabe que és tu. E isso está bem para um banco, porque a lei obriga-o a saber quem és. Mas olha agora para o que todos os sistemas de verificação de idade fazem: pegam neste mesmo padrão e enfiam lá dentro a tua identidade inteira só para responder à pergunta “esta pessoa tem idade suficiente?”

É como pedir o passaporte a alguém porque queres saber se prefere chá ou café.

E se o token fosse assim?

{
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "iat": 1706918400
}

Sem sub. Sem nome. Sem email. Sem data de nascimento. Apenas as respostas às perguntas que realmente importam, assinadas por alguém em quem confias. O serviço pergunta “tens mais de 18 anos?” e recebe de volta um true criptográfico. Nunca fica a saber o teu nome, o teu aniversário, a tua morada, nem que és um australiano de 30 e tal anos a viver em Londres que continua a comer queijo apesar do que ele lhe faz.

Este é o conceito todo. O resto do artigo é sobre torná-lo real.

Como funcionam as assinaturas (sem precisares de um curso de matemática)

Um token assinado é inútil se não puderes verificar quem o assinou. É aqui que entram os JSON Web Key Sets (JWKS).⁸ Parece complicado, mas a ideia é simples: quem assina publica a sua chave pública num endereço, e qualquer pessoa que receba um token assinado pode confirmá-lo com essa chave.

{
  "keys": [{
    "kty": "EC",
    "kid": "uk-gov-age-verification-2026",
    "use": "sig",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
  }]
}

Imagina que o governo do Reino Unido publica uma destas em gov.uk/.well-known/jwks.json. Agora, quando um site especializado em fãs recebe um token de verificação de idade a dizer que tens mais de 18 anos, não tem de confiar em ti. Não tem de telefonar ao governo. Vai buscar a chave pública, verifica a assinatura e a matemática bate certo ou não bate. Sem telefonar para casa. Sem chamada a nenhuma API. Sem “deixa-me só confirmar com a HMRC (a autoridade tributária)”. A chave pública é pública. A assinatura é matemática. Pronto.

É assim que todos os logins OAuth já funcionam. Quando clicas em “Iniciar sessão com o Google”, o site onde estás a entrar não liga ao Google para ver se o teu token é legítimo. Vai buscar o JWKS publicado pelo Google e verifica a assinatura localmente.

Fazemos isto há mais de uma década. A infraestrutura está literalmente ali parada, aborrecida.

Calma aí, entusiasta… já chegamos à parte da privacidade.

E se mostrarmos só parte do token?

Os JWT normais têm um problema: a assinatura cobre o conteúdo todo. Não podes arrancar os campos que não queres partilhar sem estragar a assinatura. Se o governo assina um token com os teus escalões etários, o hash do teu nome e o teu modelo biométrico, tens de apresentar tudo ou nada.

Entram os JWT de Divulgação Seletiva (SD-JWT).⁹ O conceito é gloriosamente simples. O emissor assina a credencial completa, mas cada afirmação tem a sua própria divulgação. O titular, ou seja, tu, no teu telemóvel, pode escolher que afirmações revela. As restantes ficam escondidas, mas a assinatura continua a validar.

Portanto o governo emite-te isto:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_13": true,
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "name_hash": "sha256:a1b2c3d4...",
  "biometric_template": "...",
  "nationality": "AU"
}

Mas quando o site especializado em fãs pede a verificação de idade, o teu dispositivo apresenta apenas isto:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_18": true
}

A assinatura continua a ser válida. O site obtém a sua resposta. E nunca fica a saber o teu nome, a tua nacionalidade, nem o facto, francamente embaraçoso, de ainda não teres 21 anos em qualquer jurisdição que ainda se importe com isso.

As Verifiable Credentials do W3C vão ainda mais longe com provas de conhecimento zero, métodos criptográficos que te permitem provar que uma afirmação é verdadeira sem revelar de todo os dados subjacentes.¹⁰ “Esta pessoa tem mais de 18 anos?” deixa de ser uma divulgação de dados e passa a ser uma prova matemática. O site não recebe "over_18": true. Recebe uma prova de que a afirmação é verdadeira, sem dados anexados.

É como um segurança que consegue, sei lá como, confirmar a tua idade olhando para um envelope selado sem o abrir. Os criptógrafos são gente estranha e maravilhosa.

Como isto devia funcionar no teu telemóvel

Muito bem, vamos juntar tudo. Prometo que é menos complicado do que o processo atual de enviar uma selfie a segurar o passaporte para um serviço de verificação de terceiros que pode ou não ser adquirido no próximo ano por uma empresa de que nunca ouviste falar.

Passo 1: Obtém a tua credencial (uma vez). O teu dispositivo oferece um quadro para gerir afirmações verificáveis. Autenticas-te uma vez junto do fornecedor de identidade do teu governo, no próprio dispositivo. Na Estónia, é o teu eID. Na UE, até ao fim de 2026, será a tua EUDI Wallet.¹¹ No Reino Unido, pode ser o GOV.UK One Login ou o que vier a substituí-lo. O fornecedor de identidade do governo emite uma credencial verificável para o teu dispositivo (escalões etários, hash do nome, modelo biométrico), assinada com a chave do governo e verificável no endpoint JWKS que ele publica.

Fica guardada no secure enclave do teu dispositivo. Fazes isto uma vez. Depois esqueces.

Passo 2: A plataforma embrulha-a. O fornecedor da tua plataforma (Apple, Google) funciona como emissor intermediário. Pega na credencial assinada pelo governo e emite-a de novo com uma assinatura dupla: a original do governo mais a da própria plataforma. Um serviço verificador consegue agora confirmar duas coisas: a afirmação veio de um fornecedor de identidade governamental real e está a ser apresentada através de uma plataforma legítima. É crucial que nem o governo nem a plataforma fiquem a saber a que serviço estás a apresentá-la. O governo vê “a Apple pediu uma credencial”. A Apple vê “uma credencial foi guardada”.

Nenhum deles vê “o Will está a tentar aceder a um site especializado em fãs às 2 da manhã de uma terça-feira”. O que é importante. Não para mim, pessoalmente… mas em geral.

Passo 3: Responde a perguntas, não a pedidos de dados. Quando um serviço precisa de verificar uma afirmação, a troca é assim:

Fans specialist → Your device: "Is this user over 18?"
Your device → Secure Enclave: [biometric check, signature generation]
Your device → Fans specialist: { "over_18": true, "sig": "..." }

Neste caso, o “Fans specialist” é… o serviço a que estás a tentar aceder…

O serviço faz uma pergunta. O teu dispositivo responde. O serviço recebe um sim ou não criptográfico. Mais nada. Não “qual é a tua data de nascimento?” mas “tens mais de 18 anos?”. Não “qual é o teu nome?” mas “este hash SHA-256 corresponde?”. Não “mostra-me a tua cara” mas “a verificação biométrica no dispositivo passou?”

Para verificar o nome, um serviço submete um hash, o SHA-256 do primeiro nome, dos nomes do meio e do apelido, e a credencial devolve se corresponde. O serviço nunca vê o teu nome verdadeiro. Para verificar a foto, a credencial inclui um modelo biométrico (uma representação matemática, não uma foto). A verificação corre localmente no teu dispositivo. O resultado, correspondência ou não, é assinado e devolvido. Os dados biométricos nunca saem do teu dispositivo. Nunca.

A Estónia acertou na arquitetura. Pena o âmbito.

Já escrevi antes sobre o sistema de identidade digital da Estónia.¹² Eles têm eID nacionais desde 2002, com o X-Road como espinha dorsal de interoperabilidade, a ligar mais de 450 organizações.¹³ Todos os cidadãos com mais de 15 anos têm uma identidade digital. 99% dos serviços públicos estão online. O sistema poupa cerca de 2% do PIB por ano.¹⁴ É genuinamente impressionante. Se alguma vez quiseres sentir-te mal com o GOV.UK, passa uma tarde a ler como os estónios entregam os impostos.

Mas o sistema da Estónia é um ecossistema fechado. Funciona de forma brilhante para serviços estónios (governo, banca, saúde, impostos) porque toda a pilha é estónia. Não podes usar o teu eID estónio para verificar a tua idade no Instagram, e o Instagram não tem absolutamente nenhuma razão para se integrar no X-Road da Estónia por causa de um país com 1,3 milhões de habitantes. Compreensível.

A Carteira de Identidade Digital da UE, imposta pelo eIDAS 2.0 para entrar em funcionamento até ao fim de 2026, foi pensada para colmatar esta lacuna.¹⁵ Todos os Estados-Membros têm de fornecer pelo menos uma EUDI Wallet. As plataformas em linha de muito grande dimensão têm de a aceitar para autenticação forte. A carteira usa credenciais verificáveis do W3C com divulgação seletiva incorporada.¹⁶ Isto está mais perto do modelo certo. Mas continua a posicionar a carteira como uma ferramenta de identidade e não como uma ferramenta de afirmações. A mudança que tem de acontecer é passar de “prova quem és” para “responde a esta pergunta específica”. É uma distinção subtil, mas é o jogo todo.

A Apple e a Google estão a 90% do caminho

Isto não é só um problema dos governos. Os fornecedores de plataformas têm de construir a camada de integração, e a boa notícia é que já construíram quase tudo, quase por acidente.

A Apple gere o Secure Enclave, um processador isolado em hardware, desenhado especificamente para operações criptográficas e dados biométricos.¹⁷ As passkeys, assentes na norma FIDO2/WebAuthn, já usam exatamente esta infraestrutura para autenticação sem palavra-passe.¹⁸ A chave privada nunca sai do dispositivo. A verificação biométrica acontece localmente. O servidor só vê uma prova criptográfica. Soa-te familiar? É o mesmo padrão.

Estender isto às afirmações verificáveis é, em termos de arquitetura, simples. A Apple fornece um quadro. Autenticas-te junto do fornecedor de identidade do teu governo através desse quadro. A credencial fica guardada no Secure Enclave ao lado das tuas passkeys. Quando um serviço pede uma afirmação, o fluxo é idêntico a uma autenticação com passkey: verificação biométrica no dispositivo, prova criptográfica enviada ao servidor. O serviço sabe que a afirmação é válida. Não sabe quem és. O Android tem capacidades equivalentes com o StrongBox e o Trusted Execution Environment.

Os fabricantes de browsers têm de estender o WebAuthn ou criar uma norma paralela para a verificação de afirmações. Um site devia poder pedir uma afirmação verificada tão facilmente como pede uma passkey. Mesmo padrão de API. Mesma experiência. Mesmo modelo de segurança. A canalização existe. Só falta alguém que a ligue. Dado que a Apple, a Google e a FIDO Alliance já provaram que conseguem coordenar-se nas passkeys, o que foi em si um pequeno milagre de cooperação empresarial, isto não é tão inverosímil como parece.

O que ninguém consegue ver

Deixa-me ser concreto sobre as garantias de privacidade, porque é aqui que a maioria das propostas de identificação digital cai por terra e as pessoas começam, com razão, a resmungar sobre estados de vigilância.

O teu governo nunca fica a saber que serviços usas. O fornecedor da plataforma encaminha os pedidos ao fornecedor de identidade do governo com as suas próprias chaves. O governo vê “a Apple pediu uma credencial”. Não vê “o Will visitou um site especializado em fãs”. Isto importa.

Os serviços nunca veem os teus dados. Recebem respostas criptográficas a perguntas específicas. Não o teu nome. Não a tua data de nascimento. Não a tua foto. Um sim ou não assinado por uma cadeia de emissores de confiança. É só isso.

Sem identificadores únicos por omissão. A credencial contém afirmações, não identificadores. Não há um ID de utilizador que os serviços possam cruzar entre plataformas. És um conjunto de factos verificados, não uma entidade rastreável. Podes provar que tens mais de 18 anos em cinquenta sites diferentes e nenhum consegue perceber que é a mesma pessoa. Experimenta fazer isso com o upload de um passaporte.

Para os serviços que precisam mesmo de te identificar (banca, autoridades policiais, setores regulados), o sistema suporta uma classe especial de credencial com um identificador emitido pelo governo. Mas esse identificador só pode ser resolvido quando o fornecedor da plataforma e o governo cooperam, através de um mecanismo de divisão de chaves que exige as duas partes. Uma chave sozinha é inútil. Isto torna a vigilância em massa estruturalmente impossível, preservando a identificação legítima nos casos regulados. É o equivalente criptográfico de precisar de duas chaves para lançar um míssil nuclear, só que em vez de acabar com o mundo, estás a verificar a identidade de alguém para um pedido de crédito à habitação. Muito menos dramático. A mesma matemática.

Tudo acontece no dispositivo. As chaves do verificador nunca saem do secure enclave. Nenhum servidor central processa os teus dados biométricos. Nenhum serviço na nuvem vê as tuas credenciais governamentais. A prova é gerada localmente e transmitida ao serviço. Mais nada se move.

O que tem de acontecer

A tecnologia está pronta. As normas existem. O hardware está instalado em milhares de milhões de dispositivos. Falta a vontade de coordenar, o que, tratando-se de governos, fornecedores de plataformas e organismos de normalização, deve levar apenas… sejamos otimistas e digamos cinco anos… ou cem no Reino Unido.

Os governos têm de publicar chaves para os seus fornecedores de identidade e emitir credenciais verificáveis com suporte para divulgação seletiva. A Estónia já fez a parte difícil. A UE está a impor carteiras até 2026. O Reino Unido está a explorar a identidade digital. A Austrália está… bem, a Austrália está a tentar descobrir como impedir miúdos de 14 anos de criarem contas no TikTok, o que talvez ganhasse com um sistema decente de verificação de idade em vez de apenas ameaçar as plataformas com multas. Os compromissos de infraestrutura estão em marcha. Falta alguém fazê-los falar uns com os outros.

Os fornecedores de plataformas têm de construir a camada de enquadramento: gestão de credenciais no dispositivo, emissão por intermediário, integração com o secure enclave para verificação de afirmações. A Apple e a Google estão a 90% com as passkeys. Os 10% que faltam são estender a mesma arquitetura às afirmações verificáveis. Dado que ambas as empresas gostariam muito de ser as guardiãs da tua identidade digital (e cobrar uma taxa modesta pelo privilégio), suspeito que o incentivo comercial existe.

Os fabricantes de browsers têm de estender o WebAuthn ou criar uma norma paralela para a verificação de afirmações. Um site devia poder pedir uma afirmação verificada tão facilmente como pede uma autenticação com passkey. Mesmo padrão de API. Mesma experiência. Mesmo modelo de segurança.

E os serviços têm de deixar de pedir documentos e começar a fazer perguntas. “Este utilizador tem mais de 16 anos?” é uma pergunta de sim ou não. Não devia exigir um passaporte. Não devia exigir uma selfie. Não devia exigir o envio de uma foto da tua carta de condução para uma empresa sediada numa jurisdição que não consegues soletrar. Exige um único booleano assinado, verificado com uma chave pública publicada.

Passámos vinte anos a construir sistemas de identidade que tratam a vigilância como uma funcionalidade. É altura de construir um que trate a privacidade como arquitetura.

Da próxima vez que alguém te pedir para enviares o passaporte para provares que tens idade para ver memes, lembra-te: a tecnologia para fazer isto como deve ser já existe. Foi testada em batalha durante uma década. Está a correr no teu telemóvel agora mesmo. A única coisa que nos trava é o mesmo que trava a maioria das boas ideias em tecnologia: pôr três grupos de pessoas que não se podem ver uns aos outros a concordar numa norma.

Portanto, basicamente, qualquer dia…

UK Online Safety Act 2023 ↩
The Register: Imgur exits the UK as parent company faces fine, bloqueou todos os utilizadores do Reino Unido a partir de 30 de setembro de 2025 em vez de cumprir os requisitos de verificação de idade da Online Safety Act ↩
Australian Government eSafety Commissioner: Social Media Age Restrictions ↩
Al Jazeera: French MPs approve law seeking ban on social media for children below 15, aprovada em janeiro de 2026 por 116 votos contra 23 ↩
Euronews: Spain to ban social media platforms for children under 16, anunciada a 3 de fevereiro de 2026 na World Government Summit ↩
European Commission: The Digital Services Act ↩
IETF RFC 7519: JSON Web Token (JWT) ↩
IETF RFC 7517: JSON Web Key (JWK) ↩
IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC) ↩
W3C: Verifiable Credentials Data Model v2.0 ↩
European Commission: European Digital Identity, impõe EUDI Wallets a todos os Estados-Membros até ao fim de 2026 ↩
Will Hackett: Reclaiming the commons: the case for an accountable internet ↩
e-Estonia: X-Road interoperability platform, liga mais de 450 organizações através de uma troca de dados descentralizada e de código aberto ↩
University of Liverpool: As the UK plans to introduce digital IDs, what can it learn from pioneer Estonia? ↩
eIDAS 2.0 Regulation (EU) 2024/1183, entrou em vigor em maio de 2024, carteiras previstas até ao fim de 2026 ↩
W3C: Verifiable Credentials Implementation Guidelines, Selective Disclosure and Zero-Knowledge Proofs ↩
Apple: About the security of passkeys, as passkeys usam o Secure Enclave para gerar chaves e para a verificação biométrica ↩
FIDO Alliance: Passkeys, norma FIDO2/WebAuthn para autenticação sem palavra-passe ↩