Summary

  • draft-li-oauth-delegated-authorization-03 propõe uma raiz assinada pelo servidor de autorização, tokens filhos assinados localmente pelas chaves vinculadas e uma prova DPoP feita pela chave da folha.
  • A validação pode demonstrar continuidade de chaves e redução de permissões, audiência, validade e profundidade; não demonstra por que um delegado foi escolhido, qual tarefa uma pessoa pretendia ou se um servidor offline recebeu a revogação.
  • Daniel Kade propõe um recibo de intenção de delegação fora do protocolo, unindo mandato raiz, custódia por salto, tarefa e limite de efeito, atualidade da revogação, decisão do recurso e encerramento, sem guardar credenciais.

Delegar sem entregar a autoridade inteira

Um orquestrador pode ter acesso a várias APIs e precisar de um agente especializado para apenas uma leitura. Entregar o token original oferece demais. Compartilhar a chave privada dissolve a atribuição. Obrigar o authorization server a participar de cada subtarefa preserva o controle central, mas elimina parte da autonomia local que torna esses sistemas úteis.

A revisão 03 define um Delegated Authorization Token vinculado a chave. O authorization server assina o token raiz e coloca em cnf.jkt a impressão digital da chave pública do primeiro cliente. Quando a profundidade permite, esse cliente assina um token filho com a chave vinculada pelo pai e vincula o novo token à chave do delegate client.

O resource server recebe a cadeia completa em ordem. Confia na chave da raiz por configuração ou metadados autenticados. Para cada filho, calcula a impressão digital RFC 7638 da JWK pública apresentada no cabeçalho protegido e compara com o cnf.jkt do pai. A folha produz uma prova DPoP ligada ao método HTTP, URI, serialização exata da cadeia e janela de frescor.

A cadeia capturada, sozinha, não funciona. O apresentador precisa controlar a chave privada final. Por isso o rascunho propõe o esquema HTTP DA e veta tratar o objeto como bearer token.

Essa construção responde com precisão: a chave indicada pelo pai autorizou a próxima chave sob limites verificáveis, e o solicitante final controla a chave esperada. Ela não identifica, por si só, o propósito organizacional da operação.

A redução mora na semântica

Cada token filho só pode estreitar permissões, audiências, intervalo de validade e delegação restante. Em scope, a comparação usa conjuntos. Um valor ausente no conjunto efetivo do pai não pode aparecer no filho. Omitir o claim descarta aquela componente de permissão.

Em authorization_details, a aparência do JSON não revela toda a autoridade. Valores padrão, arrays, curingas, recursos, ações e limites podem mudar o significado. Um documento menor pode conceder mais se a ausência de uma propriedade ativar um default amplo.

O texto exige que a especificação de cada tipo forneça uma regra determinística de contenção. Comparar texto bruto ou só o nome de type é insuficiente. Se o verificador não consegue provar que o detalhe filho cabe no detalhe efetivo do pai, precisa rejeitar a cadeia.

Claims de extensão que influenciam autorização seguem o mesmo princípio. Todos os verificadores pretendidos precisam conhecer sua semântica de delegação. Uma restrição que apenas um componente entende não pode ser usada como decoração para dizer que o poder foi reduzido.

Assim, a propriedade monotônica depende de mais que criptografia. O vocabulário, a versão da regra e a interpretação dos defaults tornam-se parte da superfície de controle. Uma auditoria precisa registrar qual comparador produziu o resultado, não apenas que a assinatura passou.

Profundidade não é uma nota de risco

Toda raiz inclui max_delegation_depth finito. Zero impede um filho válido. Se o valor efetivo do pai é m, um filho pode declarar de zero a m-1; a omissão resulta em m-1. O authorization server também aplica um máximo configurado, enquanto parsers e verificadores limitam quantidade, tamanho e custo de assinatura.

O campo mede arestas futuras no grafo. Não mede impacto. Um único salto terminal pode permitir uma alteração irreversível; três saltos podem terminar numa consulta somente leitura. Profundidade zero não afirma baixo risco, aprovação daquele cliente nem consentimento para uma transação específica.

Quando há resource owner, a decisão inicial deve cobrir a capacidade de emitir tokens filhos sem nova interação e a profundidade máxima. Consentimento para acesso comum não pode virar consentimento para delegação. Se uma profundidade explícita for recusada, o servidor não pode emitir silenciosamente um valor menor e chamar isso de aprovação.

O rascunho, porém, não define como a interface explica essa capacidade. Um aviso correto sobre “dois níveis” pode deixar ocultos os possíveis delegados, o mecanismo de descoberta de suas chaves, a tarefa e os efeitos que exigiriam nova autorização. O protocolo fixa a forma da ramificação, não seus ocupantes futuros.

O limite entre chain e task

Ficam fora do escopo a descoberta de chave entre clientes, a negociação fora de banda, a entrega de múltiplas cadeias, o vínculo da cadeia recebida a um pedido ou tarefa particular, as regras de comparação de cada aplicação e a distribuição de status de revogação.

São exatamente as peças que ligam autoridade genérica a uma decisão concreta.

Considere um agente de pesquisa com leitura em uma única API, dez minutos de validade e profundidade zero. A cadeia pode estar perfeita e ainda não distinguir “resumir o relatório aprovado” de “varrer todos os documentos acessíveis”. A política do recurso e o contexto do request podem negar o segundo caso, mas a razão humana para a tarefa não aparece na continuidade de chaves.

O próprio texto diz que validar a cadeia não autoriza sozinho uma solicitação protegida. O resource server ainda verifica DPoP, request binding, audiência e permissão de aplicação. Depois disso, um allow não comprova execução bem-sucedida. Uma operação pode falhar ou provocar efeitos fora do campo de visão do servidor.

Mandato raiz, custódia de cada salto, intenção da tarefa, validade corrente e efeito observado são cinco perguntas diferentes.

Revogar e tornar a revogação efetiva

Revogar a raiz invalida todas as cadeias que partem dela. Revogar um filho invalida toda cadeia que o contém e seus descendentes, mas não o pai, irmãos ou outros tokens que usem a mesma chave. O alvo precisa ser identificado de forma inequívoca, como pelo digest da serialização exata.

Um pedido de revogação bem-sucedido grava estado no authorization server. Não entrega esse estado a resource servers offline. A revisão 03 não define a distribuição. Tokens curtos limitam o período de desconhecimento, mas não dizem quando cada verificador recebeu a notícia.

Por isso o controle tem dois relógios: quando o servidor registrou a revogação e qual versão, idade e política de falha o recurso tinha quando decidiu. Um registro central às 10h não prova conhecimento periférico às 10h01.

O cache também deve respeitar essa diferença. Assinaturas e restrições efetivas podem ser cacheadas pelo digest da cadeia, mas expiração, estado das chaves, política local e revogação recebida precisam invalidar a entrada. Frescor e replay de DPoP continuam por request.

A visibilidade muda de endereço

A emissão local evita que o authorization server observe automaticamente cada delegate, resource, instante e padrão multi-hop. Isso pode reduzir concentração de dados.

Já o resource server vê a cadeia ordenada. Seus claims podem revelar emissor, subject, relações entre clientes, audiências, permissões e estrutura do workflow. Um cnf.jkt estável ou identificador persistente pode ligar requests em serviços diferentes.

A visibilidade de auditoria, portanto, migra. Eventos úteis incluem emissão raiz, delegação local, resultado de validação, autoridade efetiva e decisão do recurso. O rascunho recomenda referenciar a cadeia com digest unidirecional e remover Authorization e DPoP de logs rotineiros. Detalhes e identificadores precisam de proteção.

O objetivo não deve ser copiar credenciais completas para um repositório central, e sim permitir que observações distribuídas sejam reconciliadas por referências mínimas.

A mesma chave usa e reproduz autoridade

A chave privada vinculada permite demonstrar posse da folha e, quando sobra profundidade, assinar um filho. Se comprometida, o invasor pode exercer a autoridade ainda válida e criar descendentes dentro dos limites.

A proposta recomenda chaves não exportáveis, APIs de assinatura estreitas e, quando possível, uma chave distinta por token. A interface deve distinguir inputs de emissão de token e de prova DPoP. Reuso aumenta correlação e raio de incidente.

Além disso, um token filho não carrega identificador do pai. Ele pode ser válido sob outra cadeia cujo token anterior vincule a mesma chave e cujas restrições comportem o filho. É uma propriedade intencional do formato inicial. Quem exige uso com um único pai deve separar as chaves ou criar uma restrição de aplicação.

Uma impressão digital atesta a chave. Não atesta o processo que a controlava, a política de sua API de assinatura ou a tarefa que a organização imaginava.

Um recibo de intenção de delegação

Proponho um recibo de intenção de delegação. É desenho de governança de Daniel Kade, não requisito do Internet-Draft nem novo claim para o token.

Na raiz, o recibo guarda digest seguro do evento de autorização e da versão da apresentação de consentimento, emissor e metadados confiáveis, capacidade de delegar, permissões efetivas, audiências, validade e profundidade. Não guarda token, chave privada, prova DPoP, headers brutos ou dados de subject desnecessários.

Em cada salto local, junta digest da cadeia, impressões digitais públicas do pai e filho, restrições antes e depois, regra e versão de contenção, identidade do serviço de assinatura e evidência mínima da escolha do cliente. Reuso de chave e exigência de pai único ficam explícitos.

Depois acrescenta o que o credential genérico não traz: digest da tarefa concreta, saída aceitável e limite de efeito; responsável pela decisão; limites de ambiente, ação ou valor; e gatilhos para nova interação humana. O conteúdo sensível não precisa ser copiado.

No resource server, registra versão de política, comparador semântico, versão e frescor do estado de revogação recebido, resultado DPoP, autoridade efetiva e decisão final. O encerramento informa classe de operação, sucesso ou falha, efeitos materiais e referência de rollback ou incidente.

A primeira versão pode conter apenas mandato raiz, digest do salto, digest de tarefa e efeito, frescor de revogação e decisão observada. Ela não tenta provar uma intenção abstrata; preserva a evidência operacional que a cadeia não foi feita para carregar.

Manter pequena a afirmação de sucesso

A revisão 03 é um Internet-Draft individual, atualizado em 24 de julho de 2026. Não é documento adotado pelo OAuth WG, consenso IETF, Last Call, aprovação do IESG, RFC ou registro IANA ativo. O detalhamento não prova implementação ou adoção.

Dentro dessa fronteira, a proposta é valiosa. Ela dá linhagem verificável à delegação local, exige que autoridade apenas diminua, obriga semânticas desconhecidas a falhar fechadas e reconhece que revogação offline não se propaga sozinha.

Uma cadeia válida permite dizer que determinadas chaves puderam reduzir e exercer uma autorização sob condições calculadas. Não permite dizer que a pessoa desejou aquele delegado, aquela tarefa e aquele efeito.

Depois que dados foram expostos ou um sistema mudou, nenhuma assinatura posterior recria uma intenção ausente. Autoridade viaja na cadeia. Intenção precisa permanecer ao lado dela antes do efeito.

Fontes

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, revisão 03
  5. Registro do rascunho no Datatracker
  6. Histórico do rascunho Delegated Authorization
  7. Carta do grupo OAuth
  8. RFC 6749: framework de autorização OAuth 2.0
  9. RFC 7009: revogação de token OAuth 2.0
  10. RFC 7638: impressão digital JSON Web Key
  11. RFC 8414: metadados do servidor de autorização
  12. RFC 8707: indicadores de recurso para OAuth 2.0
  13. RFC 8725: melhores práticas para JWT
  14. RFC 9396: solicitações ricas de autorização
  15. RFC 9449: demonstração de posse DPoP
  16. RFC 9700: melhores práticas de segurança para OAuth 2.0
  17. RFC 9728: metadados de recurso protegido OAuth 2.0