Pular para o conteúdo principal

Uma postagem marcadas com "Credenciais Verificáveis"

Ver todas os Marcadores

De Senhas a Provas Portáteis: Um Guia do Construtor 2025 para Identidade Web3

· Leitura de 10 minutos
Dora Noda
Dora Noda
Software Engineer

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 e did:pkh. Mantenha uma lista de permissões de DIDs emissores confiáveis para evitar spoofing.
  • 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.
  • 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.