GBR: Auth Documentação e Idealização

Visão Geral da Arquitetura de Identidade Híbrida (gbr_auth)

A fundação do acesso não pode ser um gargalo central, nem uma anarquia P2P incontrolável. Estabelecemos três pilares:

*Raiz Soberana (Passkey):* O atestado criptográfico biométrico do humano.
*Autoridade M2M (ZCAP-LD):* O mecanismo de delegação puramente matemático e verificável offline.
*Shadow Tradutor (Legacy Bridge):* O adaptador que converte a matemática P2P em sessões que o Active Directory/LDAP entende.

ADR

EARS

Estudos

O Estudo Rápido: Gestão de API Keys sob o `gbr_auth`

Com o gbr_auth 100% operacional, a chave da Gemini (BYOC), ou qualquer outra jamais tocaria o código Gleam em texto plano. O fluxo seria uma dança criptográfica em 4 atos:

*Ato 1: O Ingresso (WebAuthn & TPM)*

Quando você configurasse a CLI pela primeira vez, você digitaria a chave da Gemini. A CLI usaria sua biometria (Passkey) para gerar uma chave de encriptação local. A chave da Gemini seria salva no disco criptografada com AES-256-GCM. O disco pode ser roubado, a chave da Gemini estará inacessível sem o seu dedo no leitor biométrico.

*Ato 2: O Enclave (Rust NIF & mlock)*

Ao iniciar o gleambr_ai, você passa pela Passkey. A chave da Gemini é descriptografada e enviada direto para o nosso Módulo Rust (gbr_crypto). O Rust aloca a chave na memória física, aciona a syscall mlock() (impedindo que o Windows/Linux jogue a chave no arquivo de paginação/Swap) e devolve para o Gleam apenas um ponteiro opaco: Reference: #Ref<0.1.2.3>. Se um malware fizer um dump da memória (RAM) da Erlang VM, ele só encontra o ponteiro inútil.

*Ato 3: A Delegação (ZCAP-LD)*

Vamos supor que o seu Agente Principal precise criar um "Sub-Agente" para ler um arquivo grande. Ele não passa a chave da Gemini para o Sub-Agente. Ele cria um ZCAP-LD delegando o direito: {"scope": "invoke_llm", "ttl": "10m"}. O Sub-Agente prova quem é e ganha o direito de pedir inferências ao cérebro central, mas continua sem saber qual é a senha do Google.

*Ato 4: O HTTP Blindado (A Mágica Final)*

Quando o llm_cloud.gleam precisar fazer o POST para a API do Gemini, ele tem um problema: como montar o cabeçalho x-goog-api-key se ele só tem um ponteiro?

Ele não monta! O Gleam delega a chamada de rede para a camada segura.
Ele faria algo como: gbr_auth.secure_http_post(url, body_json, api_key_ref).
O Rust (lá em baixo) recebe o corpo do JSON, - pega a chave verdadeira do Enclave, - monta o cabeçalho HTTP, - criptografa no túnel TLS, - envia para o Google, - recebe a resposta e - devolve para o Gleam apenas a String limpa do resultado.

*Conclusão do Estudo:* O gbr_auth transforma nossa CLI em uma "Caixa Preta". A IA (Gleam) pensa, raciocina e pede ações, mas a mão que executa a criptografia e carrega o dinheiro (API Key) é o Rust, blindada contra o próprio agente.

Estudo github

*Ideia:*

Conseguimos fazer auth usando o github, algum meito de auth deles, de forma decentralizada?

Exemplo: Eu subo um gleambr_ai (Web Chat AI) em uma cloud qualquer e determino que a auth deve ser feita da seguinte forma: - Usar o github OAuth/OCID, ou outro meio melhor se existir - Validar e é membro da organização github.com/gleam-br - Aqui não sei a melhor forma, se os membros geram chaves e validamos elas - OU se centralizamos ACL pelo github org members?

A Ilusão do "GitHub Descentralizado"

*A Análise Crítica:*

"Autenticação descentralizada usando GitHub" é um oximoro (uma contradição de termos). O GitHub pertence à Microsoft. Se a Microsoft cair, se eles mudarem a API, ou se banirem a organização gleam-br, o seu sistema "descentralizado" morre na hora. A raiz de confiança (Root of Trust) é 100% centralizada.

*O Veredito:*

Você *não deve* centralizar a ACL (Access Control List) checando a API do GitHub a cada mensagem no seu chat. Isso seria criar um gargalo (Rate Limits da API) e destruir a natureza P2P da malha.

*A Solução Padrão-Ouro (O nosso ADR-051 em Ação):*

Nós já resolvemos esse exato problema arquitetural no passado! Faremos exatamente a opção 1 que você sugeriu (gerar chaves), usando o padrão *Identity Oracle*:

O seu Web Chat sobe na nuvem. Ele atua como um "Gatekeeper".
O desenvolvedor entra no chat e clica em "Login with GitHub".
O Gatekeeper vai até a API do GitHub uma única vez e pergunta: "Esse cara é da org gleam-br?".
O GitHub diz: "Sim".
O Gatekeeper (Oráculo) diz: "Perfeito. O GitHub não manda mais nada a partir daqui". O Gatekeeper assina um *ZCAP-LD* delegando acesso ao did:key do navegador do desenvolvedor.
Daí em diante, o desenvolvedor fala com os agentes autônomos na malha P2P usando apenas a matemática do ZCAP-LD. Zero dependência do GitHub durante a operação.

GBR: Auth Documentação e Idealização | Wiki