De Senhas a Provas Portáteis: Um Guia do Construtor 2025 para Identidade Web3
A maioria dos aplicativos ainda ancora a identidade a nomes de usuário, senhas e bancos de dados centralizados. Esse modelo é frágil (vazamentos), vazante (revenda de dados) e engessado (repetição infinita de KYC). A nova pilha que surge em torno de identificadores descentralizados (DIDs), credenciais verificáveis (VCs) e atestações aponta para um futuro diferente: os usuários carregam provas criptográficas de fatos sobre si mesmos e revelam apenas o que for necessário — nem mais, nem menos.
Este post destila o cenário e oferece um plano prático que você pode colocar em produção hoje.
A Mudança: De Contas para Credenciais
O núcleo dessa nova pilha de identidade é construído sobre duas normas fundamentais da W3C que mudam radicalmente como lidamos com os dados dos usuários.
- Identificadores Descentralizados (DIDs): São identificadores controlados pelo usuário que não exigem um registro central como um sistema de nomes de domínio. Pense em um DID como um endereço permanente e auto‑propriedade para identidade. Um DID resolve para um “documento DID” assinado contendo chaves públicas e pontos de serviço, permitindo autenticação segura e descentralizada. A norma
v1.0
tornou‑se uma Recomendação oficial da W3C em 19 de julho de 2022, marcando um marco importante para o ecossistema. - Credenciais Verificáveis (VCs): Formato digital à prova de violação para expressar declarações, como “idade acima de 18”, “possui diploma da Universidade X” ou “passou por verificação KYC”. O Modelo de Dados VC 2.0 tornou‑se Recomendação da W3C em 15 de maio de 2025, consolidando uma base moderna para emissão e verificação dessas credenciais.
O que muda para os desenvolvedores? A mudança é profunda. Em vez de armazenar informações pessoais sensíveis (PII) no seu banco de dados, você verifica provas criptográficas fornecidas pela carteira do usuário. Você pode solicitar apenas a informação específica que precisa (por exemplo, residência em determinado país) sem ver o documento subjacente, graças a primitivas poderosas como divulgação seletiva.
Onde Isso Encontra os Logins que Você Já Usa
Esse novo mundo não exige abandonar experiências de login familiares. Pelo contrário, ele as complementa.
- Passkeys / WebAuthn: Sua solução para autenticação resistente a phishing. Passkeys são credenciais FIDO vinculadas a um dispositivo ou biometria (Face ID, impressão digital) e agora são amplamente suportadas nos principais navegadores e sistemas operacionais. Elas oferecem uma experiência de login sem senha, fluida, para seu app ou carteira.
- Sign‑In with Ethereum (SIWE / EIP‑4361): Padrão que permite ao usuário provar o controle de um endereço de blockchain e vinculá‑lo a uma sessão de aplicação. Funciona via mensagem simples assinada, baseada em nonce, criando uma ponte limpa entre sessões Web2 tradicionais e controle Web3.
A melhor prática é usá‑las juntas: implemente passkeys para login cotidiano e ofereça SIWE para fluxos vinculados à carteira onde o usuário precisa autorizar uma ação nativa de cripto.
Os Trilhos para Emitir e Verificar Credenciais
Para que as credenciais sejam úteis, precisamos de maneiras padronizadas de emiti‑las aos usuários e de os usuários as apresentarem às apps. A OpenID Foundation fornece os dois protocolos chave para isso.
- Emissão: OpenID for Verifiable Credential Issuance (OID4VCI) define uma API protegida por OAuth para obter credenciais de emissores (governo, provedor KYC) para a carteira digital do usuário. É flexível, suportando múltiplos formatos de credencial.
- Apresentação: OpenID for Verifiable Presentations (OID4VP) padroniza como sua aplicação faz um “pedido de prova” e como a carteira do usuário responde. Isso pode acontecer via redirecionamentos OAuth clássicos ou por APIs modernas de navegador.
Ao construir, você encontrará alguns formatos de credencial projetados para diferentes ecossistemas e casos de uso:
- W3C VC com Suites de Integridade de Dados (JSON‑LD): Frequentemente combinados com criptografia BBS+ para habilitar divulgação seletiva poderosa.
- VC‑JOSE‑COSE e SD‑JWT VC (IETF): Formatos construídos para ecossistemas JWT e CBOR, também com fortes capacidades de divulgação seletiva.
Felizmente, a interoperabilidade está melhorando rapidamente. Perfis como OpenID4VC High Assurance ajudam a reduzir as opções técnicas, tornando as integrações entre fornecedores muito mais sensatas para desenvolvedores.
Métodos DID: Escolhendo o Esquema de Endereço Correto
Um DID é apenas um identificador; um “método DID” especifica como ele é ancorado a uma raiz de confiança. Você desejará suportar alguns dos mais comuns.
- did:web: Este método amarra um DID a um domínio que você controla. É incrivelmente fácil de implantar e uma escolha fantástica para empresas, emissores e organizações que querem usar sua infraestrutura web existente como âncora de confiança.
- did:pkh: Deriva um DID diretamente de um endereço de blockchain (por exemplo, um endereço Ethereum). Muito útil quando sua base de usuários já possui carteiras cripto e você quer ligar a identidade aos ativos on‑chain.
Regra prática: Suporte ao menos dois métodos — did:web
para organizações e did:pkh
para usuários individuais. Use uma biblioteca padrão de resolvedor DID para lidar com a busca e consulte os registros oficiais para avaliar segurança, persistência e governança de qualquer novo método que considere adicionar.
Blocos de Construção Úteis que Você Pode Plug‑ar
Além dos padrões centrais, várias ferramentas podem melhorar sua pilha de identidade.
- ENS (Ethereum Name Service): Fornece nomes legíveis por humanos (
seunome.eth
) que podem mapear para endereços de blockchain e DIDs. Ferramenta valiosa para melhorar a experiência do usuário, reduzir erros e oferecer uma camada de perfil simples. - Atestações: “Facts” verificáveis e flexíveis que podem ser registrados on‑chain ou off‑chain. O Ethereum Attestation Service (EAS), por exemplo, oferece um substrato robusto para construir grafos de reputação e confiança sem jamais armazenar PII em um ledger público.
Ventos de Conformidade que Você Deve Acompanhar
Regulação costuma ser vista como obstáculo, mas neste espaço é um acelerador massivo. O Quadro de Identidade Digital da UE (eIDAS 2.0), adotado oficialmente como Regulamento UE 2024/1183 em 20 de maio de 2024, é o desenvolvimento mais significativo. Ele obriga todos os Estados‑Membros da UE a oferecer aos cidadãos uma Carteira Digital de Identidade da UE (EUDI) gratuita. Com regulamentos de implementação publicados em 7 de maio de 2025, isso sinaliza fortemente a adoção de credenciais baseadas em carteira tanto em serviços públicos quanto privados na Europa.
Mesmo que você não opere na UE, espere que a Carteira EUDI e seus protocolos subjacentes moldem as expectativas dos usuários e impulsionem a adoção de carteiras globalmente.
Padrões de Design que Funcionam na Produção (2025)
- Primeiro Sem Senha, Carteiras Opcionais: Use passkeys como padrão de login. É seguro, simples e familiar. Só introduza SIWE quando o usuário precisar executar uma ação vinculada a cripto, como mintar um NFT ou receber um pagamento.
- Peça Provas, Não Documentos: Substitua uploads engessados por um pedido de prova VC usando OID4VP. Em vez de solicitar a carteira de motorista, peça prova de “idade acima de 18” ou “residência no país X”. Aceite credenciais que suportem divulgação seletiva, como as que usam BBS+ ou SD‑JWT.
- Mantenha PII Fora dos Seus Servidores: Quando um usuário prova algo, registre uma atestado ou um resultado de verificação de curta duração, não a credencial bruta. Atestados on‑chain são poderosos para criar registros auditáveis — “Usuário Y passou KYC com Emissor Z em data D” — sem armazenar dados pessoais.
- Deixe Organizações Serem Emissores com did:web: Empresas, universidades e outras organizações já controlam seus domínios. Permita que assinem credenciais como emissores usando
did:web
, gerenciando chaves criptográficas sob seus modelos de governança web existentes. - Use ENS para Nomes, Não para Identidade: Trate ENS como um apelido amigável e ponte de perfil. É ótimo para UX, mas mantenha as reivindicações de identidade autoritativas dentro de credenciais e atestações.
Uma Arquitetura Inicial
Aqui está um plano para um sistema de identidade moderno baseado em credenciais:
- Autenticação
- Login Padrão: Passkeys (FIDO/WebAuthn).
- Sessões Ligadas a Cripto: Sign‑In with Ethereum (SIWE) para ações baseadas em carteira.
- Credenciais
- Emissão: Integre com endpoints OID4VCI dos emissores escolhidos (provedor KYC, universidade, etc.).
- Apresentação: Dispare pedidos de prova OID4VP a partir do seu app web ou nativo. Esteja preparado para aceitar tanto W3C VCs (com BBS+) quanto VCs SD‑JWT.
- Resolução & Confiança
- Resolvedor DID: Use uma biblioteca que suporte ao menos
did:web
edid:pkh
. Mantenha uma lista de permissões de DIDs emissores confiáveis para evitar spoofing.
- Resolvedor DID: Use uma biblioteca que suporte ao menos
- Atestações & Reputação
- Registros Duráveis: Quando precisar de um sinal auditável de verificação, crie uma atestado contendo hash, DID do emissor e timestamp, ao invés de armazenar a reivindicação em si.
- Armazenamento & Privacidade
- Minimalismo: Reduza drasticamente o PII armazenado no servidor. Criptografe tudo em repouso e defina políticas estritas de tempo de vida (TTL). Prefira provas efêmeras e aproveite zero‑knowledge ou divulgação seletiva.
Lições de UX Aprendidas
- Comece Invisível: Para a maioria dos usuários, a melhor carteira é a que eles não precisam pensar. Use passkeys para login fluido e só exponha interações de carteira quando absolutamente necessário.
- Divulgação Progressiva: Não peça tudo de uma vez. Solicite a menor prova possível que desbloqueie o objetivo imediato do usuário. Com divulgação seletiva, você não precisa do documento completo para validar um fato.
- Recuperação de Chave Importa: Uma credencial vinculada a uma única chave de dispositivo é um risco. Planeje re‑emissão e portabilidade entre dispositivos desde o início. Esse é um motivo chave para adoção de formatos como SD‑JWT VC e vinculação baseada em reivindicações.
- Apelidos Legíveis Ajudam: Um nome ENS é muito menos intimidador que um endereço hexadecimal longo. Reduz erros e adiciona contexto reconhecível, mesmo que a autoridade real esteja nas credenciais subjacentes.
O Que Entregar no Próximo Trimestre: Roteiro Pragmatico
- Semanas 1–2:
- Adicionar passkeys ao fluxo principal de login.
- Proteger todas as ações nativas de cripto atrás de verificação SIWE.
- Semanas 3–6:
- Pilotar um simples gate de idade ou região usando um pedido OID4VP.
- Aceitar credenciais VC 2.0 com divulgação seletiva (BBS+ ou SD‑JWT VC).
- Começar a criar atestações para eventos “verificação concluída” ao invés de registrar PII.
- Semanas 7–10:
- Integrar um emissor parceiro (ex.: seu provedor KYC) usando
did:web
e implementar lista de permissões de DIDs. - Oferecer vínculo de nome ENS nos perfis de usuário para melhorar a UX de endereços.
- Integrar um emissor parceiro (ex.: seu provedor KYC) usando
- Semanas 11–12:
- Modelar ameaças nos fluxos de apresentação e revogação. Adicionar telemetria para modos de falha comuns (credencial expirada, emissor não confiável).
- Publicar uma postura de privacidade clara explicando exatamente o que você solicita, por quê, por quanto tempo retém e como os usuários podem auditar.
O Que Está Mudando Rápido (Fique de Olho)
- Rollouts da Carteira EUDI da UE: Implementação e testes de conformidade dessas carteiras moldarão massivamente capacidades e UX de verificação globalmente.
- Perfis OpenID4VC: Interoperabilidade entre emissores, carteiras e verificadores está em constante aprimoramento graças a novos perfis e suítes de teste.
- Criptossuites de Divulgação Seletiva: Bibliotecas e guias para BBS+ e SD‑JWT VC amadurecem rapidamente, facilitando a implementação.
Princípios para Construir
- Prove, Não Armazene: Priorize verificação de reivindicações ao invés de armazenar PII bruto.
- Interoperabilidade por Padrão: Suporte múltiplos formatos de credencial e métodos DID desde o início para tornar sua pilha à prova de futuro.
- Minimize & Divulgue: Peça a menor reivindicação possível. Seja transparente com os usuários sobre o que está sendo verificado e por quê.
- Recuperação Sem Drama: Planeje perda de dispositivo e rotação de emissores. Evite vinculação frágil de chaves que possa deixar usuários presos.
Se você está construindo fintech, redes sociais ou plataformas para criadores, identidade primeiro‑credencial não é mais uma aposta futura — é o caminho mais curto para risco reduzido, onboarding mais suave e interoperabilidade global.