GBR: ADR-0005 Oráculo de Identidade Institucional (Ponte OIDC para ZCAP-LD)

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

*Contexto:*

Para viabilizar a "Recuperação Social" (Social Recovery) em ambientes corporativos, o sistema exige que o diretório legado da empresa (LDAP/Active Directory) atue como um "Guardião". No entanto, expor telas de login no Nó P2P (Monitor v2.0) cria um vetor de ataque de força bruta. Além disso, se a chave criptográfica que o Nó utiliza para emitir os votos de recuperação for comprometida, toda a rede do cliente estará em risco. Precisamos de uma ponte segura entre a autenticação Web2 e a autorização Web3.

Empresas precisam usar sua "Fonte Única de Verdade" (LDAP/AD). Telas de login caseiras são alvos de força bruta.

*Decisão:*

Integrar o Nó Monitor como um *Oráculo de Identidade. Ele utiliza *OIDC/OAuth2** para validar o humano contra o provedor da empresa (Okta/Entra ID). O sucesso gera um ZCAP-LD "Manchado" (Temporário/Tainted) com escopo restrito e validade curta (24h).

1. *Delegação Web2 via OIDC (OpenID Connect):* O Nó Monitor v2.0 atuará como um Confidential Client do padrão OAuth2/OIDC. O processo de autenticação corporativa ocorrerá inteiramente nos servidores do Provedor de Identidade (IdP) do cliente (ex: Okta, Microsoft Entra, Google Workspace). O Nó P2P apenas validará o JWT (JSON Web Token) resultante.
2. *Custódia de Chave Baseada em Hardware (Key Custody):* A chave privada Ed25519 do "Guardião Institucional" (o Nó Monitor) *nunca residirá na memória (RAM) da Erlang VM*. A assinatura de atestados será delegada ao TPM 2.0 do servidor físico ou a um cofre de rede (ex: HashiCorp Vault / AWS KMS) através de abstrações no NIF Rust (gbr_crypto).
3. *Delegação Just-In-Time e Manchada (Tainted ZCAP-LD):* Uma recuperação bem-sucedida via OIDC não emite uma identidade permanente. O Oráculo emitirá um ZCAP-LD "manchado", caracterizado por: - *Escopo Estrito:* Permissão restrita exclusivamente aos namespaces corporativos (ex: read:horus.db). - *TTL Curto:* Validade máxima de 24 a 48 horas. - *Obrigatoriedade de Rotação:* O usuário deverá usar este acesso temporário para registrar uma nova Passkey soberana em seu dispositivo local.

*Consequências:*

• *Positivas:* Terceiriza a mitigação de Brute-Force e gestão de MFA (Múltiplos Fatores) para gigantes da tecnologia; garante que a chave do Guardião sobreviva a invasões do Sistema Operacional (graças ao TPM/Vault); isola matematicamente o escopo de uma recuperação.
• *Positivas:* Delegar segurança de login para especialistas (Google/MS). Facilita o onboarding corporativo.
• *Negativas:* Exige configuração prévia de App Registrations (Client ID/Secret) no IdP do cliente corporativo; dependência de hardware específico (TPM) ou infraestrutura de cofre na implantação do Monitor v2. (Parte mitigado, aceito o risco p/ covergência do produto no mercado)

Análise da negativa

Sugestão de reutilizarmos a defesa do ADR-0003 (Enclave Rust + mlock) para guardar a chave do *Guardião Institucional, abolindo a *obrigatoriedade do TPM/Vault. Objetivo único de tornar viável o produto comercialmente para todos do mercado e não apenas para grandes empresas.

1. A Mitigação Mid-Market: Enclaves Rust em vez de TPM (Revisão da Negativa)

*Análise Crítica:*

Tecnicamente, estamos propondo a criação de um *Modelo de Custódia em Camadas (Tiered Custody Model)*.

• *Tier 1 (Nível Pentágono - Opcional):* Uso de TPM 2.0 ou HSM (Hardware Security Module). A chave vive no silício. Protege contra atacantes que têm acesso root ao kernel do Linux.
• *Tier 2 (Nível Enterprise - Padrão GBR):* A chave did:key do Monitor é guardada em disco encriptada (AES-256-GCM) e, ao ser carregada, vai direto para o *Enclave Rust*. Aplicamos o mlock() para impedir que o Sistema Operacional jogue a chave para o arquivo de paginação (Swap) e bloqueamos Core Dumps.

*Veredito:* O *Tier 2* é absolutamente viável e seguro contra 99% das ameaças. Um atacante só conseguiria roubar a chave se conseguisse injetar um Rootkit no Kernel da máquina hospedeira para ler a memória protegida em tempo real (um ataque altamente sofisticado). Ao aceitarmos o Tier 2 como padrão, o Monitor v2.0 pode ser instalado em qualquer VPS simples (AWS EC2, DigitalOcean), reduzindo drasticamente o custo de implantação (TCO) para o cliente.

Atualização no ADR (Custódia de Chaves)

• *Decisão Refinada:* O sistema adotará um *Modelo de Custódia Tierizado. O padrão (Tier 2) utilizará *Enclaves de Memória Rust (mlock) com Zeroization** para guardar a chave do Oráculo Institucional, permitindo implantação em infraestrutura comoditizada (VPS/VMs comuns). O uso de TPM/Vault (Tier 1) será suportado como um plug-in para clientes de missão crítica.
• *Negativa Mitigada:* "A dependência de Hardware Específico foi removida, reduzindo a barreira de entrada comercial do produto".