GBR: ADR-0001 WebAuthn (Passkey) como Âncora de Identidade Humana e Prova de Vida

• *Status:* Proposto -> (Aceito)
• *Data:* 2026-05-12

*Contexto:*

Em ambientes distribuídos (M2M), a identidade é matemática (did:key). Porém, o ingresso humano requer autenticação resistente a phishing e escalável. Senhas são um vetor de ataque inaceitável.

Sistemas distribuídos exigem identidades soberanas. Senhas são vulneráveis e centralizadas. Precisamos de uma ponte entre a biometria humana e a matemática P2P.

*Decisão:*

1. *Adoção Exclusiva de Passkeys:* O ingresso humano na rede Gleam-BR/Monitor v2.0 ocorrerá exclusivamente via WebAuthn. A chave pública resultante (P-256 ou Ed25519) torna-se o Identificador Soberano do usuário na malha.
2. *Prova de Vida Local:* A biometria (FaceID, TouchID, Windows Hello) é confiada ao dispositivo do usuário; a malha apenas exige a assinatura resultante do desafio criptográfico.
3. *Bootstrapping via Autenticação Legada:* Na integração inicial em ambientes corporativos, o usuário realizará o primeiro login usando suas credenciais legadas (ex: LDAP/AD). Esse sucesso autoriza o registro da sua primeira Passkey no domínio da organização, vinculando a identidade distribuída à identidade corporativa.

*Consequências:*

• *Positivas:* Elimina a necessidade de gerir senhas; previne ataques de phishing e credential stuffing, UX biométrica moderna.
• *Negativas:* Exige hardware compatível (mitigado por Cross-Device Auth via Smartphone).

Análise da negativa a fundo

Dissecando a Negativa 1: "Exige suporte de hardware moderno no cliente"

*hardwares com módulos de segurança criptográfica embutidos*

O padrão WebAuthn / Passkey baseia-se na premissa de que a chave privada *nunca pode ser exportada ou ser lida pela memória principal (RAM) do sistema operacional*. Para que isso seja possível, o dispositivo do cliente precisa ter:

1. *Um Cofre Físico no Silício:* - No ecossistema *Apple, isso é o *Secure Enclave (presente em iPhones, iPads e Macs com TouchID/FaceID). - No ecossistema *Windows/PC, isso é o chip *TPM 2.0** (Trusted Platform Module), acoplado ao Windows Hello. - No ecossistema *Android, é o *Titan M ou o TrustZone (TEE - Trusted Execution Environment).
2. *Sensores Biométricos (Opcional, mas recomendado):* - Leitores de impressão digital ou reconhecimento facial em 3D.
3. *Sistema Operacional Compatível:* - Windows 10/11, macOS recentes, Android 9+ ou iOS 14+. Computadores rodando sistemas legados (ex: Windows 7 ou distribuições Linux antigas sem configuração específica de fido2) falharão nativamente.

*O Risco Real:* Se o cliente Horus vender o Monitor v2.0 para uma fábrica onde os operadores usam PCs de chão de fábrica de 2012 (sem TPM e sem leitor de digital), a autenticação via Passkey falhará nativamente no hardware.

*A Mitigação (Aceitar ou Rejeitar?):*

• *Veredito: RISCO ACEITÁVEL.*
• *Como mitigamos:* Para computadores legados que não possuem TPM, o padrão WebAuthn aceita Roaming Authenticators. O usuário pode usar o seu próprio smartphone (lendo um QR Code na tela do PC antigo) para autorizar o acesso, ou a empresa pode fornecer *YubiKeys* (pendrives USB de segurança por ~$40). O hardware moderno passa a ser o celular do funcionário ou a chave USB, e não a máquina da fábrica.

Dissecando a Negativa 2: "Overhead de UX inicial durante o processo de bootstrapping corporativo"

Em uma empresa tradicional, o processo de onboarding (o primeiro login) é simples: o TI entrega um usuário e uma senha provisória, o funcionário digita, muda a senha e está trabalhando.

No nosso sistema híbrido (onde o LDAP é a fonte da verdade para o bootstrapping), o fluxo do primeiro dia (UX - User Experience) tem mais atrito:

1. O funcionário acessa o painel do GleamBR/Monitor v2.0.
2. O sistema pede login e senha do Active Directory/LDAP (Ponte Legada).
3. Após validar o LDAP, o sistema bloqueia a tela e diz: "Precisamos registrar o seu dispositivo. Toque no sensor biométrico".
4. O sistema operacional do usuário abre um pop-up pedindo permissão para criar uma Passkey.
5. Só então o ZCAP-LD é gerado e o usuário pode trabalhar.

*O Risco Real:* Rejeição inicial por parte dos usuários ("Por que preciso usar a minha digital no computador da empresa?") e aumento inicial de chamados no Help Desk da TI perguntando como configurar o celular ou o Windows Hello.

*A Mitigação (Aceitar ou Rejeitar?):*

• *Veredito: RISCO ALTAMENTE ACEITÁVEL.*
• *Como mitigamos:* O atrito ocorre *apenas no primeiro login* de um dispositivo novo. Do segundo dia em diante, o usuário nunca mais digitará uma senha. Ele apenas clicará em "Entrar" e tocará no sensor. A economia a longo prazo com chamados de "esqueci minha senha" e o bloqueio definitivo contra ataques de Phishing (que custam milhões às corporações) justificam plenamente o atrito dos 30 segundos adicionais no primeiro dia de trabalho.