GBR: EARS-0002 Especificação de Requisitos do Oráculo de Identidade (Ponte OIDC)

*Requisitos Ubíquos (Ubiquitous Requirements)*

• *UBQ-01:* O pacote gbr_crypto deve delegar toda a operação de assinatura do Nó Guardião para o módulo de segurança em hardware (TPM) ou cofre externo (Vault), sendo estritamente proibido o carregamento da chave privada em texto plano para a memória alocada do processo Gleam.
• *UBQ-02:* O sistema não deve prover interfaces gráficas locais para coleta de credenciais legadas (senhas de AD), devendo utilizar o fluxo Authorization Code Grant (OIDC) com redirecionamento para o Provedor de Identidade do cliente.

*Requisitos Orientados a Eventos (Event-Driven Requirements)*

• *EVD-01:* Quando o Nó Monitor receber o callback com o JWT emitido pelo Provedor de Identidade (OIDC), o sistema deve validar a assinatura criptográfica e as propriedades iss (Issuer) e aud (Audience) antes de gerar o pacote de atestação P2P.
• *EVD-02:* Quando um usuário invocar um ZCAP-LD classificado como "Manchado/Temporário" (Tainted) gerado por um processo de recuperação, o frontend corporativo deve exibir um alerta fixo exigindo o registro de uma nova Passkey local.

*Requisitos Orientados a Estado (State-Driven Requirements)*

• *STD-01:* Enquanto o sistema não puder se comunicar com o HSM/TPM ou Vault externo para assinatura, o Ator OTP encarregado pelo Oráculo de Identidade deve transicionar para o estado Degraded, recusando todas as tentativas de recuperação de conta.

*Requisitos de Comportamento Indesejado (Unwanted Behavior Requirements)*

• *UNW-01:* Se o JWT do provedor OIDC não contiver as claims de Autenticação de Múltiplos Fatores (amr indicando MFA), o Nó Monitor deve rejeitar o pedido de recuperação para garantir o nível de garantia (AAL) exigido pela malha.
• *UNW-02:* Se um ZCAP-LD emitido via recuperação OIDC tentar ser utilizado para interagir com namespaces fora do escopo corporate.*, o Agente receptor deve bloquear a execução com erro de Privilege Violation.

UNW-01: O Ataque de Downgrade (Por que exigimos MFA no OIDC?)

Esclarecimentos sobre a exigência da claim amr (Authentication Methods References) indicando MFA no token JWT.

*A Ciência do Risco (Por que isso estava no EARS?):*

Imagine a seguinte balança de segurança (baseada na norma NIST SP 800-63B):

• *Sua Passkey (WebAuthn):* É um nível de garantia altíssimo (AAL3). Ela exige algo que você tem (hardware) e algo que você é (biometria).
• *Sua Senha do AD/LDAP:* É um nível de garantia baixo (AAL1). É apenas algo que você sabe (que pode ser roubado, vazado ou adivinhado).

*O "Downgrade Attack":*

Se o nosso Guardião Institucional permitir que um usuário recupere uma Passkey (AAL3) usando apenas uma Senha (AAL1), nós criamos uma brecha gigantesca. Um hacker que comprou a senha do funcionário na Dark Web vai acessar o OIDC, emitir o ZCAP-LD e assumir a identidade daquele usuário na malha P2P. A segurança do sistema passa a ser igual à do elo mais fraco (a senha).

**Como o amr resolve isso:**

Quando o usuário loga no Okta/Microsoft, o IdP gera um JWT. Dentro desse JWT, existe um array chamado amr.

• Se ele logou só com senha, o amr vem assim: ["pwd"].
• Se ele usou senha + SMS/Token, o amr vem assim: ["pwd", "mfa"] ou ["pwd", "otp"].

O *UNW-01* dizia que o GleamBR/Monitor v2 deve olhar para esse array. Se não tiver mfa, o Falcon cruza os braços e diz: "A sua senha está certa, mas para gerar uma chave de segurança de nível militar, você precisa aprovar no seu autenticador de celular".

Atualização no EARS (O Dilema do MFA no UNW-01)

Transformaremos o requisito rígido em uma *Política Configurável pelo Cliente*, documentando o risco.

• *UNW-01 (Revisado):* Se o JWT do provedor OIDC não contiver as claims de Autenticação de Múltiplos Fatores (amr com MFA) e o Agente estiver configurado no modo Strict_AAL, o Nó Monitor deve rejeitar o pedido para prevenir Ataques de Downgrade. Em modo Legacy_Compat, o sistema aceitará o JWT, mas emitirá o ZCAP-LD com um TTL severamente reduzido (ex: 2 horas) e restrição de escopo máxima.