Resumo

  • A revisão 01 do draft-zehavi-oauth-authz-req-del-chain foi anunciada em 10 de setembro de 2026 como Internet-Draft individual, sem adoção pelo grupo OAuth e sem status de RFC.
  • JWS destacadas, hashes do nó anterior, posições e continuidade de audiência protegem a integridade dos intermediários que aparecem na cadeia.
  • A retirada do fim ou do meio quebra verificações. Um broker, porém, pode iniciar outra cadeia válida consigo mesmo em chain[0].
  • Cabe à política local decidir se o primeiro emissor visível pode ocupar essa posição para determinado cliente, recurso e contexto de implantação.

O registro pode começar depois da operação

Uma solicitação OAuth redirecionada nem sempre vai diretamente do cliente ao servidor que pede consentimento. Ela pode passar por vários brokers. Cada intermediário é servidor de autorização para quem está abaixo e cliente OAuth para quem está acima. No final, o servidor que emitirá o token talvez conheça diretamente só o último broker.

O rascunho de cadeia de delegação propõe transportar o percurso num objeto RAR authorization_details. Cada nó JSON identifica quem atesta, para quem atesta, sua posição e o cliente reconhecido naquela etapa. A assinatura JWS é destacada, e p_hash liga o nó ao evento assinado anterior.

O servidor receptor começa pelo último nó. Confirma que a audiência aponta para ele e que o emissor corresponde ao cliente OAuth autenticado que apresentou a solicitação. Depois percorre chaves, assinaturas, números, namespaces, hashes e o encaixe entre audiência e emissor de nós adjacentes.

O conjunto pode passar por tudo. A aprovação demonstra coerência do material recebido, não que o material cubra toda a história.

Duas remoções deixam vestígio; a origem nova não

A revisão 01 separa três formas de truncamento. Cortar a cauda faz a cadeia terminar no destinatário errado. Retirar um item do meio invalida o hash guardado pelo sucessor e a continuidade entre os dois lados.

Na cabeça, o mecanismo é outro. Um broker pode abandonar o contexto anterior e criar uma cadeia nova, colocando-se na posição zero e usando p_hash nulo. Dali em diante, todas as assinaturas podem ser genuínas. O documento chama isso de re-origination e afirma que a validação criptográfica não prova a inexistência de algo antes de chain[0].

Não há aqui relato de ataque. É uma delimitação expressa da proposta. Uma corrente de hashes autentica a continuidade depois de um começo declarado; não fornece uma testemunha externa sobre a completude desse começo.

O servidor precisa então consultar sua política: esse emissor pode aparecer primeiro para o cliente terminal, o recurso e o ambiente envolvidos? Uma assinatura válida tampouco concede autoridade ao signatário. O novo client_roles pode indicar oauth_broker, mas a revisão rejeita o uso de uma função autoafirmada como prova de confiança. O cliente imediato ainda precisa de autenticação OAuth normal.

O controle de omissão protege uma cadeia já conhecida

A nova versão acrescenta descoberta de suporte pelos metadados do RFC 8414. Se o próximo servidor não compreender a cadeia, o broker não pode simplesmente apagá-la.

As opções são recusar a transação, manter o contexto por outro mecanismo confiável ou encaminhar sem a cadeia apenas quando a política local e os nós assinados permitirem. omit_chain aceita allowed ou forbidden; sua ausência equivale a proibição. Todos os nós validados precisam permitir a omissão.

Esse desenho impede que uma perda posterior de evidência seja silenciosa. Ele não revela contexto descartado antes da criação do primeiro nó. A permissão de degradar no próximo salto e a confiança na origem declarada precisam de registros separados.

A revisão também solicita à IANA o registro de client_roles. Por enquanto, isso é parte de um rascunho individual: não comprova alocação, consenso, adoção, implementação, implantação ou incidente.

Fontes