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

Atualização, 11 fev 2026: Que rápido. A verificação de idade do Discord, feita pela k-id e sua parceira faceassure, foi completamente burlada. A ferramenta, criada por xyzeva e Dziurwa (com crédito a amplitudes pelo trabalho anterior), verifica automaticamente sua conta como adulta no Discord, Twitch, Kick, Snapchat e em qualquer outra plataforma que use a k-id. Como? Porque a “estimativa facial” da k-id processa seu rosto inteiramente no dispositivo e só manda metadados pro servidor. Ou seja, dá pra simplesmente mandar metadados falsos. O servidor não tem como notar a diferença. Isso não é um bug. É a consequência inevitável de construir teatro de segurança em vez de segurança de verdade. Se você vai verificar idade sem uma cadeia de confiança criptográfica ancorada num provedor de identidade real, você não está verificando nada. Está só criando um atrito que os usuários reais odeiam e que quem quer burlar derruba num fim de semana. Tudo o que está abaixo continua valendo. Continue lendo.

Sou australiano. Moro no Reino Unido. Os dois governos têm a mesma parcela de culpa na bagunça que está rolando agora.

A Online Safety Act do Reino Unido deu a largada em julho de 2025, exigindo verificação de idade “altamente eficaz” em qualquer site com conteúdo adulto (um certo hub que começa com P, um site especializado em fãs, o Reddit, todo mundo), com multas de até £18 milhões ou 10% do faturamento global em caso de descumprimento.¹ O Imgur olhou os requisitos de conformidade e saiu do Reino Unido de vez.² A Online Safety Amendment Act da Austrália veio em dezembro de 2025, proibindo menores de 16 anos nas redes sociais e obrigando as plataformas a provar que estão aplicando a regra.³ E isso está se espalhando. A França aprovou em janeiro de 2026 a proibição das redes sociais para menores de 15.⁴ A Espanha anunciou a sua hoje: menores de 16, com “barreiras reais que funcionam, não só caixinhas de marcar”.⁵ A proibição da Dinamarca deve passar até meados de 2026. A Grécia está redigindo a dela agora. A Lei de Serviços Digitais da UE já exige proteções adequadas à idade em todo o bloco.⁶

Toda grande democracia (menos a da liberdade) está chegando à mesma conclusão: as plataformas precisam saber a idade dos usuários. E o instinto está certo. Precisamos proteger mentes em formação de conteúdo nocivo. As evidências sobre saúde mental de adolescentes e exposição irrestrita às redes sociais são devastadoras, e o status quo de deixar uma criança de 12 anos passar por uma caixinha de marcar se declarando maior de idade é uma farsa há vinte anos.

Mas olha só. Toda implementação até agora foi desenhada em torno da pergunta errada. Os governos estão perguntando “como identificamos as pessoas?” quando deveriam perguntar “como verificamos afirmações sem identificar ninguém?”

O resultado é um cenário em que verificar a idade significa enviar uma foto do seu passaporte pra um serviço de terceiros e torcer pra ele não ser invadido. Ou passar seu rosto por um modelo de IA que adivinha sua idade pela estrutura óssea, o que é vigilância biométrica com outro nome. A abordagem do Reino Unido sob a Online Safety Act fez o uso de VPN subir mais de 1.400% no primeiro dia de vigência, porque adultos decidiram, com toda a razão, que preferiam rotear seu tráfego pela Irlanda a entregar a carteira de motorista pra um site especializado em fãs.

O governo deveria ficar bem longe da sua vida. Mas as empresas deveriam ter segurança de que não serão responsabilizadas quando a verificação de idade for contornada. Um garoto de 14 anos com uma barba cheia talvez engane a estimativa facial de hoje. Um cartão de crédito emprestado engana a checagem de pagamento. Uma VPN engana a geolocalização por completo.

Então vamos explorar: dá pra consertar essa porra?

Dá.

Você já usa quase toda essa tecnologia

Isso é o que torna a situação tão irritante: os blocos de construção da verificação de identidade que preserva a privacidade não são um projeto de pesquisa distante. Eles estão rodando no seu celular agora mesmo, enquanto você lê isto.

Toda vez que você entra num site e ele se lembra de quem você é sem pedir a senha de novo, há uma boa chance de um JSON Web Token (JWT) estar fazendo o trabalho pesado.⁷ Um JWT é só um bloco de informação assinado. Tem três partes: um cabeçalho que diz como ele foi feito (assinado), um payload cheio de “afirmações” (quem você é e que tipo de saco de carne você é) e uma assinatura que prova que nada foi adulterado.

Veja como é o payload de um JWT típico quando você entra, digamos, no seu banco:

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

Está vendo esse campo sub? É um identificador único. É assim que o banco sabe que você é você. E isso é normal num banco, que por lei precisa saber quem você é. Mas agora olhe o que todo sistema de verificação de idade faz: pega esse mesmo padrão e enfia sua identidade inteira nele só pra responder à pergunta “essa pessoa tem idade suficiente?”

É como pedir o passaporte de alguém porque você quer saber se a pessoa 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 e-mail. Sem data de nascimento. Só as respostas às perguntas que realmente importam, assinadas por alguém em quem você confia. O serviço pergunta “você tem mais de 18?” e recebe de volta um true criptográfico. Ele nunca fica sabendo seu nome, seu aniversário, seu endereço, nem que você é um australiano de 30 e poucos anos morando em Londres que ainda come queijo apesar do que isso faz com ele.

Esse é o conceito inteiro. O resto do artigo é sobre tornar isso real.

Como as assinaturas funcionam de verdade (sem precisar de diploma de matemática)

Um token assinado é inútil se você não consegue verificar quem o assinou. É aí que entram os JSON Web Key Sets (JWKS).⁸ É um nome chique pra uma ideia simples: quem assina publica a chave pública num endereço, e qualquer um que receba um token assinado pode conferi-lo com essa chave.

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

Imagine que o governo do Reino Unido publica uma dessas em gov.uk/.well-known/jwks.json. Agora, quando um site especializado em fãs recebe um token de verificação de idade dizendo que você tem mais de 18, ele não precisa confiar em você. Não precisa ligar pro governo. Busca a chave pública, confere a assinatura, e ou a matemática fecha ou não fecha. Sem ligar pra casa. Sem chamada de API. Sem “deixa eu confirmar com a HMRC (a Receita deles)”. A chave pública é pública. A assinatura é matemática. Pronto.

É assim que todo login via OAuth já funciona. Quando você clica em “Entrar com o Google”, o site em que você está entrando não liga pro Google pra checar se seu token é legítimo. Ele pega o JWKS publicado pelo Google e verifica a assinatura localmente.

Fazemos isso há mais de uma década. A infraestrutura está literalmente lá, entediada.

Calma, ansioso… já já a gente chega na parte da privacidade.

Mas e se mostrarmos só uma parte do token?

JWTs comuns têm um problema: a assinatura cobre o payload inteiro. Você não pode arrancar os campos que não quer compartilhar sem quebrar a assinatura. Se o governo assina um token com suas faixas de idade, o hash do seu nome e seu modelo biométrico, você precisa apresentar tudo ou nada.

Entram os Selective Disclosure JWTs (SD-JWTs).⁹ O conceito é gloriosamente simples. O emissor assina a credencial completa, mas cada afirmação tem sua própria divulgação. O portador, que é você, no seu celular, escolhe quais afirmações revelar. O resto fica escondido, mas a assinatura continua válida.

Então o governo te emite 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, seu dispositivo apresenta só isto:

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

A assinatura continua batendo. O site recebe sua resposta. E nunca fica sabendo seu nome, sua nacionalidade, nem o fato francamente constrangedor de que você ainda não tem 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 deixam você provar que uma afirmação é verdadeira sem revelar os dados por trás dela.¹⁰ “Essa pessoa tem mais de 18?” deixa de ser uma divulgação de dados e vira uma prova matemática. O site não recebe "over_18": true. Recebe uma prova de que a afirmação é verdadeira, sem nenhum dado anexado.

É como um segurança de balada que consegue verificar sua idade olhando um envelope lacrado sem abrir. Criptógrafos são gente esquisita e maravilhosa.

Como isso deveria funcionar no seu celular

Certo, vamos juntar tudo. Prometo que é menos complicado do que o processo atual de enviar uma selfie segurando o passaporte pra um serviço de verificação de terceiros que pode ou não ser comprado no ano que vem por uma empresa de que você nunca ouviu falar.

Passo 1: Pegue sua credencial (uma vez). Seu dispositivo oferece uma estrutura pra gerenciar afirmações verificáveis. Você se autentica uma vez no provedor de identidade do seu governo, no próprio aparelho. Na Estônia, é o seu eID. Na UE, até o fim de 2026, será a sua EUDI Wallet.¹¹ No Reino Unido, poderia ser o GOV.UK One Login ou o que vier a substituí-lo. O IdP do governo emite uma credencial verificável pro seu dispositivo (faixas de idade, hash do nome, modelo biométrico), assinada pela chave do governo e verificável contra o endpoint JWKS publicado por ele.

Ela fica no enclave seguro do seu dispositivo. Você faz isso uma vez. Depois esquece.

Passo 2: A plataforma empacota. O provedor da sua plataforma (Apple, Google) atua como emissor intermediário. Ele pega a credencial assinada pelo governo e a reemite com assinatura dupla: a original do governo mais a da própria plataforma. Um serviço verificador agora consegue confirmar duas coisas: a afirmação veio de um IdP governamental de verdade e está sendo apresentada por uma plataforma legítima. O ponto crucial é que nem o governo nem a plataforma ficam sabendo pra qual serviço você está apresentando. O governo vê “a Apple pediu uma credencial”. A Apple vê “uma credencial foi armazenada”.

Nenhum dos dois vê “o Will está tentando acessar um site especializado em fãs às 2h da manhã de uma terça”. O que é importante. Não pra mim, pessoalmente… mas em geral.

Passo 3: Responda perguntas, não pedidos de dados. Quando um serviço precisa verificar uma afirmação, a troca fica 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": "..." }

Nesse caso, o “Fans specialist” é… o serviço que você está tentando acessar…

O serviço faz uma pergunta. Seu dispositivo responde. O serviço recebe um sim ou não criptográfico. Nada além disso. Não “qual é sua data de nascimento?”, e sim “você tem mais de 18?”. Não “qual é seu nome?”, e sim “esse hash SHA-256 bate?”. Não “mostre seu rosto”, e sim “a checagem biométrica no dispositivo passa?”

Na verificação de nome, o serviço envia um hash (SHA-256 do primeiro nome, do nome do meio e do sobrenome) e a credencial devolve se ele confere. O serviço nunca vê seu nome de verdade. Na verificação por foto, a credencial inclui um modelo biométrico (uma representação matemática, não uma foto). A checagem roda localmente no seu dispositivo. O resultado, confere ou não confere, é assinado e devolvido. Os dados biométricos nunca saem do seu dispositivo. Nunca.

A Estônia acertou a arquitetura. Pena o escopo.

Já escrevi antes sobre o sistema de identidade digital da Estônia.¹² Eles têm eIDs nacionais desde 2002, com o X-Road como espinha dorsal de interoperabilidade conectando mais de 450 organizações.¹³ Todo cidadão com mais de 15 anos tem uma identidade digital. 99% dos serviços do governo são online. O sistema economiza cerca de 2% do PIB por ano.¹⁴ É genuinamente impressionante. Se um dia quiser se sentir mal com o GOV.UK, passe uma tarde lendo como os estonianos declaram imposto de renda.

Mas o sistema da Estônia é um ecossistema fechado. Funciona de forma brilhante pros serviços estonianos (governo, bancos, saúde, impostos) porque a pilha inteira é estoniana. Você não consegue usar seu eID estoniano pra verificar sua idade no Instagram, e o Instagram não tem absolutamente nenhum motivo pra se integrar ao X-Road da Estônia por causa de um país de 1,3 milhão de habitantes. Justo.

A Carteira de Identidade Digital da UE, exigida pela eIDAS 2.0 pra implantação até o fim de 2026, foi desenhada pra fechar essa lacuna.¹⁵ Todo Estado-membro precisa oferecer pelo menos uma EUDI Wallet. As plataformas online muito grandes precisam aceitá-la pra autenticação forte. A carteira usa credenciais verificáveis do W3C com divulgação seletiva embutida.¹⁶ Esse é um modelo mais próximo do certo. Mas ele ainda posiciona a carteira como uma ferramenta de identidade e não de afirmações. A mudança necessária é sair de “prove quem você é” pra “responda a esta pergunta específica”. É uma distinção sutil, mas é o jogo inteiro.

Apple e Google estão 90% do caminho

Isso não é só um problema do governo. Os provedores de plataforma precisam construir a camada de integração, e a boa notícia é que eles quase sem querer já construíram a maior parte dela.

A Apple gerencia o Secure Enclave, um processador isolado em hardware projetado especificamente para operações criptográficas e dados biométricos.¹⁷ As passkeys, baseadas no padrão FIDO2/WebAuthn, já usam exatamente essa infraestrutura pra autenticação sem senha.¹⁸ A chave privada nunca sai do dispositivo. A verificação biométrica acontece localmente. O servidor só vê uma prova criptográfica. Soa familiar? É o mesmo padrão.

Estender isso pra afirmações verificáveis é arquitetonicamente simples. A Apple oferece uma estrutura. Você se autentica no IdP do seu governo por meio dela. A credencial é guardada no Secure Enclave ao lado das suas passkeys. Quando um serviço pede uma afirmação, o fluxo é idêntico ao de uma autenticação por passkey: checagem biométrica no dispositivo, prova criptográfica enviada ao servidor. O serviço sabe que a afirmação é válida. Não sabe quem você é. O Android tem capacidades equivalentes com o StrongBox e o Trusted Execution Environment.

Os fornecedores de navegador precisam estender o WebAuthn ou criar um padrão paralelo pra verificação de afirmações. Um site deveria poder pedir uma afirmação verificada tão facilmente quanto pede uma passkey. Mesmo padrão de API. Mesma experiência de uso. Mesmo modelo de segurança. A tubulação existe. Só falta alguém ligar. Considerando que Apple, Google e a FIDO Alliance já provaram que conseguem se coordenar nas passkeys, o que já foi um pequeno milagre de cooperação corporativa, isso não é tão forçado quanto parece.

O que ninguém consegue ver

Vou ser específico sobre as garantias de privacidade, porque é aqui que a maioria das propostas de identidade digital desmorona e as pessoas, com razão, começam a resmungar sobre estados de vigilância.

Seu governo nunca fica sabendo quais serviços você usa. O provedor da plataforma encaminha os pedidos ao IdP do governo usando as próprias chaves. O governo vê “a Apple pediu uma credencial”. Não vê “o Will visitou um site especializado em fãs”. Isso importa.

Os serviços nunca veem seus dados. Eles recebem respostas criptográficas a perguntas específicas. Não seu nome. Não sua data de nascimento. Não sua foto. Um sim ou não assinado por uma cadeia de emissores confiável. É só isso.

Sem identificadores únicos por padrão. A credencial contém afirmações, não identificadores. Não existe um ID de usuário que os serviços possam cruzar entre plataformas. Você é um conjunto de fatos verificados, não uma entidade rastreável. Dá pra provar que tem mais de 18 em cinquenta sites diferentes e nenhum deles consegue saber que é a mesma pessoa. Tente fazer isso com o upload de um passaporte.

Para serviços que realmente precisam identificar você, como bancos, polícia e 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 provedor da plataforma e o governo cooperam, usando um mecanismo de divisão de chave que exige as duas partes. Uma chave sozinha é inútil. Isso torna a vigilância em massa estruturalmente impossível e preserva a identificação legítima nos casos regulados. É o equivalente criptográfico de precisar de duas chaves pra lançar um míssil nuclear, só que em vez de acabar com o mundo você está verificando a identidade de alguém num pedido de financiamento imobiliário. Bem menos dramático. Mesma matemática.

Tudo acontece no dispositivo. As chaves do verificador nunca saem do enclave seguro. Nenhum servidor central processa sua biometria. Nenhum serviço na nuvem vê suas credenciais do governo. A prova é gerada localmente e transmitida ao serviço. Mais nada se move.

O que precisa acontecer

A tecnologia está pronta. Os padrões existem. O hardware está implantado em bilhões de dispositivos. O que falta é vontade de coordenar o que, tratando-se de governos, provedores de plataforma e órgãos de padronização, deve levar só… sejamos otimistas e digamos cinco anos… ou cem no Reino Unido.

Os governos precisam publicar chaves dos seus provedores de identidade e emitir credenciais verificáveis com suporte a divulgação seletiva. A Estônia já fez a parte difícil. A UE está exigindo carteiras até 2026. O Reino Unido está estudando uma identidade digital. A Austrália está… bom, a Austrália está tentando descobrir como impedir adolescentes de 14 anos de criar contas no TikTok, o que talvez se beneficiasse de ter um bom sistema de verificação de idade em vez de só ameaçar as plataformas com multas. Os compromissos de infraestrutura estão em andamento. Alguém só precisa fazer um falar com o outro.

Os provedores de plataforma precisam construir a camada de estrutura: gerenciamento de credenciais no dispositivo, emissão intermediária, integração com o enclave seguro pra verificação de afirmações. Apple e Google estão 90% lá com as passkeys. Os 10% restantes são estender a mesma arquitetura às afirmações verificáveis. Como as duas empresas adorariam ser as guardiãs da sua identidade digital (e cobrar uma taxinha pelo privilégio), suspeito que o incentivo de negócio exista.

Os fornecedores de navegador precisam estender o WebAuthn ou criar um padrão paralelo pra verificação de afirmações. Um site deveria poder pedir uma afirmação verificada tão facilmente quanto pede uma autenticação por passkey. Mesmo padrão de API. Mesma experiência de uso. Mesmo modelo de segurança.

E os serviços precisam parar de pedir documentos e começar a fazer perguntas. “Esse usuário tem mais de 16?” é uma pergunta de sim ou não. Não deveria exigir um passaporte. Não deveria exigir uma selfie. Não deveria exigir o envio da foto da sua carteira de motorista pra uma empresa sediada numa jurisdição cujo nome você não sabe soletrar. Exige um único booleano assinado, verificado contra uma chave pública publicada.

Passamos vinte anos construindo sistemas de identidade que tratam a vigilância como funcionalidade. Está na hora de construir um que trate a privacidade como arquitetura.

Da próxima vez que alguém pedir pra você enviar seu passaporte pra provar que tem idade pra olhar memes, lembre-se: a tecnologia pra fazer isso direito já existe. Foi testada em batalha por uma década. Está rodando no seu celular agora mesmo. A única coisa que nos impede é a mesma que impede a maioria das boas ideias em tecnologia: fazer três grupos de pessoas que não se gostam muito concordarem num padrão.

Então, basicamente, qualquer dia desses…

UK Online Safety Act 2023 ↩
The Register: Imgur exits the UK as parent company faces fine. Bloqueou geograficamente todos os usuários do Reino Unido a partir de 30 de setembro de 2025 em vez de cumprir as exigências 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 a 23 ↩
Euronews: Spain to ban social media platforms for children under 16. Anunciada em 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. Exige EUDI Wallets em todos os Estados-membros até o fim de 2026 ↩
Will Hackett: Reclaiming the commons: the case for an accountable internet ↩
e-Estonia: X-Road interoperability platform. Conecta mais de 450 organizações por meio de troca de dados de código aberto e descentralizada ↩
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, com carteiras previstas para o 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 fazer a verificação biométrica ↩
FIDO Alliance: Passkeys. Padrão FIDO2/WebAuthn para autenticação sem senha ↩