Resumo

  • draft-li-oauth-delegated-authorization-03 propõe uma raiz emitida pelo servidor de autorização e filhos mais estreitos assinados por clientes para outros clientes. É um Internet-Draft individual com intenção Standards Track, não um RFC, consenso ou evidência de uso.
  • A assinatura do filho prova uma transição de chave autorizada pelo pai imediato. Não prova sozinha a raiz, a contenção cumulativa, o consentimento específico para delegar ou a política atual do recurso.
  • A folha apresenta a cadeia exata e ordenada com uma prova DPoP. O servidor de recursos ainda valida todos os ancestrais, o estado de revogação e a autorização local antes do efeito.

O sistema de agentes recebe um token perfeitamente assinado. A operação pede somente leitura, o prazo é curto e a chave privada está no agente correto. Mesmo assim, ainda não há resposta para a pergunta essencial: quem permitiu que o assinante nomeasse esse agente?

O rascunho draft-li-oauth-delegated-authorization-03 transforma essa pergunta numa cadeia. O servidor de autorização assina a raiz e vincula a autoridade à chave de A por cnf.jkt. Se houver profundidade, A assina um filho ligado à chave de B. Nenhum descendente pode ser mais amplo que o resultado acumulado desde a raiz.

Isso reduz chamadas centrais em fluxos distribuídos. Mas a ausência do servidor na emissão local não cria liberdade ilimitada. A raiz autorizou uma capacidade finita de delegar. Cada cliente pode exercê-la apenas reduzindo permissões, público, tempo e profundidade; o servidor de recursos refaz a conta no uso.

A revisão 03 é de 24 de julho de 2026 e expira em 25 de janeiro de 2027. O cabeçalho pretende Standards Track, enquanto a API Datatracker não traz stream nem nível pretendido. Pedidos de registro no texto não são alocações presentes. Este artigo não afirma adoção, implementação ou interoperabilidade.

A confiança da raiz precisa vir de fora

A chave que verifica a raiz vem de configuração confiável ou metadados autenticados do servidor de autorização. Não basta o token declarar iss e oferecer a chave que o validará. O objeto não escolhe sua própria âncora.

Nos filhos, a JWK pública do delegante aparece no cabeçalho protegido. O verificador calcula sua impressão RFC 7638, compara com cnf.jkt do pai imediato e verifica a assinatura. O recibo diz que o controlador da chave vinculada pelo pai assinou o próximo passo.

Ele não diz que a chave pertencia ao workload, empresa ou tenant pretendido. A obtenção da chave de B e a associação ao B correto estão fora do escopo. Um runtime pode fornecer a chave errada e toda a criptografia posterior permanecer válida.

É preciso registrar separadamente continuidade de chave e associação operacional. A primeira contém impressões, assinatura e posição. A segunda identifica instância, tenant, operador e canal. Uma tela única de “delegado verificado” apaga a dependência externa.

O primeiro elemento tem de ser a raiz. O verificador não pode procurar mais adiante um token que torne aceitável um prefixo inválido. Autoridade tem direção.

Reduzir autorização exige semântica determinística

Para scope, o filho precisa ser subconjunto do conjunto efetivo do pai. Para authorization_details, cada tipo precisa definir o que significa subset: recursos, ações, curingas, ausências, arrays e defaults.

JSON menor não significa autoridade menor. Omissão pode significar qualquer conta. Mesmo type pode ocultar recurso diferente. Comparar texto ou contar campos não demonstra contenção.

Quando a regra não existe ou não é implementada, a cadeia deve ser rejeitada. Essa disciplina mantém a camada comum mínima: fatos que os participantes podem verificar localmente por cálculo, sem um intérprete permanente inventando equivalência.

Omissão também tem efeitos diferentes. Sem scope ou authorization_details, o componente desaparece e não pode reaparecer em descendentes. Sem aud, o público efetivo do pai continua. Sem nbf, não nasce nova restrição inicial. Toda claim futura precisa declarar introdução, herança, redução, remoção e reintrodução.

Por isso a validação começa na raiz e percorre em ordem. Validar JWTs isolados e ler a folha perde a história das omissões e composições. O recibo é o cálculo da trajetória.

Profundidade não controla quantidade nem valor

A raiz contém max_delegation_depth. Com valor m, o filho explícito fica entre zero e m-1; omitido, torna-se m-1. Zero ainda permite acesso, mas encerra novas delegações.

Esse número limita níveis, não fan-out. Um cliente pode criar muitos irmãos. Um token curto pode executar muitas operações. Uma permissão nominalmente estreita pode aprovar um pagamento irreversível.

O projeto também exige limites de quantidade, bytes e custo. Operadores precisam limitar filhos, reutilização de chaves, duração e manter inventário. Ao tirar o servidor de autorização da emissão, também se tira dele a observação automática do grafo.

Logs locais recuperam visibilidade, mas não viram autoridade. Eles ajudam a encontrar descendentes depois de comprometimento; não tornam válida uma ampliação proibida.

Consentimento para usar não é consentimento para nomear

Quando há proprietário do recurso, o servidor diferencia acesso de delegação emitida por cliente. Autorizar A a consultar dados não autoriza automaticamente A a escolher B. O consentimento deveria mostrar permissões, públicos, validade e profundidade, deixando claro que o servidor não aprovará cada filho.

A raiz pode conter poder de uso e poder de nomeação. A mesma chave faz DPoP e assina filhos quando resta profundidade. Um vazamento permite os dois. A interface de assinatura deve separar entradas para impedir que um oracle de proof se transforme em emissor.

O token não prova que o proprietário viu o delegado específico. Ele aprovou uma faixa; A escolheu a contraparte. Essa seleção local precisa de recibo e responsabilidade próprios.

O servidor de autorização fixa o teto, o delegante escolhe e estreita, o servidor de recursos decide no ponto de efeito. Nenhum substitui os demais.

A ordem exata é ligada à prova final

A credencial DA proposta concatena JWTs compactos com ~, da raiz à folha. O ath de DPoP cobre os bytes exatos. Não se decodifica, normaliza ou serializa de novo antes do hash.

Isso impede alteração da cadeia capturada sem nova prova da folha. Não valida seus ancestrais. Raiz, todas as assinaturas, cada continuidade, profundidade, contenção, público e tempo continuam sendo checados.

DPoP prova que a folha usou essa cadeia na requisição de método e URI. Não prova que a cadeia merecia autoridade. O artigo existente de RFC 9449 mantém a fronteira geral de sender constraint; esta peça trata da autorização ancestral.

O filho não contém identificador do pai. Pode ser válido em outra cadeia compatível se o token anterior vincular a mesma chave e suas restrições o cobrirem. Uma chave por token reduz a portabilidade. Pai único requer binding adicional.

Registrar revogação não é distribuí-la

A proposta estende RFC 7009 para receber a cadeia exata e revogar o último token. O titular da chave alvo ou o delegante direto pode provar poder de revogar. Autenticação OAuth comum não basta.

Revogar a raiz invalida todas as ramificações. Revogar um filho invalida cadeias que o contêm e seus descendentes, não pai, irmãos ou outro token na mesma chave.

O HTTP 200 não é recibo global. A revogação bem-sucedida grava estado no servidor de autorização; não o entrega a validadores offline. O projeto não define distribuição. Vida curta, introspecção ou feed de status precisam ser escolhidos à parte.

Registre o momento da decisão e o momento em que cada servidor a observou. Destruir chave não termina automaticamente sessões derivadas. Distribuir status não desfaz efeitos já confirmados.

A política local continua soberana no efeito

Após validar criptografia e monotonicidade, o servidor aplica política do proprietário, tenant, estado do recurso, revogação e regras da aplicação. Cadeia válida pode ser negada.

A raiz é limite máximo, não comando remoto. Filhos baixam esse máximo; o servidor local pode negar mais por fatos atuais. Conta bloqueada, retenção legal ou risco novo continuam válidos.

O efeito é outro recibo. Autorização positiva pode terminar em conflito, timeout ou ação parcial. Replay DPoP não oferece exactly-once. Aplicação precisa de idempotência, commit e reconciliação.

Recibo Evidência mínima Não prova
Consentimento raiz Acesso, delegação separada, profundidade Filho futuro específico
Emissão raiz Emissor, hash, direitos, público, tempo, chave Acesso atual
Associação Instância, tenant, impressão, canal Contenção do filho
Emissão filho Pai, hash, limites, profundidade Raiz confiável ou status
Cadeia Assinaturas, continuidades, subset, tempo Posse da folha
DPoP folha Método, URI, ath, nonce, replay Ancestrais válidos
Estado Revogação observada e idade Entrega universal
Decisão local Política, operação, decisão Commit
Efeito Transação e estado persistido Resultado externo
Reconciliação Observação e exceções Próxima autoridade

O filho pode ser autêntico. A autoridade só existe na cadeia inteira, ainda atual e aceita localmente.