Resumo

  • A revisão 01 de Authenticated Provenance for WIMSE Delegation Chains combina continuidade de resumos com uma assinatura agregada: uma localiza mudanças; a outra torna um signatário que nada alterou difícil de remover sem invalidar o conjunto.
  • O agregado fica próximo do tamanho de uma assinatura, mas WITs, entradas Signature-Input, valores de caminho e consulta e resumos de entrada e saída continuam aumentando a cada salto.
  • Uma verificação válida atribui os participantes apresentados e suas transformações. Não prova que todos os serviços esperados participaram, que uma mudança era autorizada ou correta, nem que a aplicação concluiu a ação.

A economia que termina no campo de assinatura

Considere uma solicitação que sai de um agente, ganha detalhes num orquestrador, atravessa uma ferramenta e chega a um gateway antes do destino. O corpo pode mudar duas vezes. O caminho pode mudar sem que o corpo mude. O destinatário recebe apenas a última mensagem HTTP, não as representações anteriores.

draft-reddy-wimse-aggregate-signatures-01, publicado em 28 de setembro de 2026, tenta preservar essa procedência. É um Internet-Draft individual ativo, com intenção de Standards Track, e não um RFC, documento de grupo de trabalho, consenso do IETF, relatório de implementação ou prova de adoção. A distinção importa porque o desenho ainda pode mudar, ser substituído ou expirar.

A proposta usa dois mecanismos. Primeiro, cada carga assina uma relação entre o que recebeu e o que enviou. O resumo do corpo recebido aparece em wimse-req-digest; o corpo transmitido é representado por Content-Digest. O iniciador começa com o valor reservado origin. O destino percorre a cadeia e confronta a saída assinada de um salto com a entrada assinada do seguinte.

Essa continuidade denuncia a remoção de um intermediário que alterou o corpo. Sem ele, os resumos vizinhos deixam de se encaixar. Também atribui a transformação ao serviço que assinou os valores anterior e posterior. Ainda assim, os resumos não cobrem sozinhos o método, o caminho, a consulta ou os cabeçalhos relevantes. Esses elementos pertencem à base de assinatura de cada salto.

O segundo mecanismo combina os valores individuais numa única Signature-Aggregate. O verificador não valida esse valor no vazio. Ele monta a lista ordenada de pares — chave pública e mensagem reconstruída — e verifica o agregado contra todo o conjunto.

É aí que surge uma propriedade diferente. Imagine H2 recebendo e encaminhando exatamente o mesmo corpo. Numa cadeia que guarda somente assinaturas individuais e resumos alinhados, alguém poderia retirar H2 e ainda apresentar uma continuidade perfeita de H1 para H3. No modo agregado, a contribuição de H2 foi incorporada ao valor coletivo. Não existe uma assinatura destacada que o atacante simplesmente descarte; omitir H2 da lista faz a verificação falhar.

Mas a propriedade não recupera um serviço que nunca assinou. Um proxy que encaminha silenciosamente, ou um controle obrigatório que foi contornado antes de entrar na cadeia, não aparece por magia no agregado. Se a política exige que um verificador de dados, um classificador de segurança ou um aprovador participe, o destino precisa comparar o conjunto comprovado com uma regra externa sobre participantes obrigatórios.

O envelope que não pode desaparecer

A seção de tamanho da revisão 01 separa assinatura e evidência. A assinatura agregada permanece aproximadamente do tamanho de uma assinatura, independentemente do número de saltos. O restante não permanece constante.

Para cada participante, o destino precisa de um rótulo único e da entrada Signature-Input; da lista de componentes cobertos; de parâmetros como criação, expiração, nonce, tag e audiência; de um Workload Identity Token; do resumo de entrada; dos valores preservados em wimse-req-path e wimse-req-query; do resumo de saída; e da ordem que permite relacionar um registro com os vizinhos.

O WIT fornece a identidade sub e a chave pública em cnf.jwk. A revisão introduz Workload-Identity-Tokens como um dicionário de Structured Fields indexado pelo rótulo do salto. Cada participante preserva os membros anteriores, valida o prefixo, escolhe um novo rótulo e assina o seu próprio membro. Retirar ou substituir um token anterior altera um valor coberto.

Transportar o token, porém, não é validá-lo. O verificador ainda precisa conferir emissor, audiência, validade, chave, domínio de confiança e política de algoritmo antes de processar a mensagem. Um WIT presente registra o que foi apresentado; não concede confiança por presença.

A reconstrução também depende de valores que já não existem na última URI. Um orquestrador pode ter enviado /plan, enquanto o gateway enviou /execute; a consulta pode ter mudado. Cada salto preserva seus valores de saída assinados. O destino os usa para reconstituir a base de assinatura antiga, em vez de aplicar o caminho final a todas as mensagens históricas.

Para o Content-Digest de saída de um salto, o destino lê o resumo de entrada assinado pelo sucessor. O último salto não tem sucessor; sua saída é o Content-Digest final. Método e tipo de conteúdo vêm da mensagem final porque a proposta não permite que mudem ao longo da cadeia. Se mudarem, as assinaturas anteriores deixam de reconstruir.

Portanto, a forma econômica correta não é “uma assinatura”. É uma assinatura agregada S mais a soma, para cada salto, do token W, da entrada de assinatura I, dos resumos D e dos valores de reconstrução R: S + Σ(W + I + D + R). Essa expressão é um modelo explicativo de Daniel Kade, não uma medição. O custo real depende do tamanho dos tokens, URIs, algoritmos, serialização e compressão de cabeçalhos.

Uma falha coletiva não aponta o culpado

Agregação também muda a forma de investigar. A pergunta de admissão é coletiva: o valor apresentado verifica contra todos os pares de chave e mensagem ou não? Uma única contribuição inválida derruba o resultado completo. O agregado, sozinho, não identifica qual salto falhou.

Isso melhora a não remoção, mas pode piorar a experiência operacional. Uma credencial expirada, um valor de caminho perdido, um resumo corrompido ou uma chave rejeitada pode bloquear a cadeia inteira. A equipe que recebe “inválido” ainda precisa de recibos locais, validações do prefixo, logs protegidos ou reprodução controlada para localizar a contribuição defeituosa. A revisão 01 não define um protocolo universal de culpa.

O mesmo cuidado vale para algoritmos. Todos os participantes de uma cadeia agregada precisam usar um algoritmo agregável compatível. O texto aponta o esquema BLS com aumento de mensagem como uma forma atual de instanciar o desenho, mas deixa o identificador de algoritmo do WIT para outra especificação. BLS não é pós-quântico. Um identificador assinado informa qual algoritmo o participante declarou; a política local continua decidindo se ele é permitido.

Sem um algoritmo agregável, o desenho pode recorrer a assinaturas individuais. Os resumos ainda detectam a retirada de um salto que alterou o corpo. A proteção específica contra a remoção de um signatário que encaminhou o corpo sem alteração deixa de existir. Essa diferença precisa aparecer no recibo de decisão, não apenas na documentação da biblioteca.

A resposta e o resultado permanecem separados

A resposta segue o caminho inverso e pode carregar a mesma lógica: resumos de entrada e saída, credenciais, componentes reconstruíveis e assinatura agregada. O originador da resposta usa wimse-resp-digest="origin". Se a resposta não for assinada ao longo da cadeia, este mecanismo não detecta necessariamente sua alteração ou descarte.

Mesmo uma resposta assinada não prova que o estado externo mudou. Ela pode atribuir quem declarou sucesso e qual representação foi encaminhada. Não substitui o identificador de commit da aplicação, a observação do recurso ou o recibo financeiro. Procedência, autorização, execução e efeito são camadas diferentes.

Essa separação também protege contra uma leitura excessiva de “participação”. A cadeia pode provar que determinada carga assinou uma transformação internamente consistente. Não diz que a transformação respeitou a função daquele serviço, preservou a intenção do usuário ou produziu um resultado benéfico. Um participante mal configurado pode assinar com perfeição uma mudança indevida.

Fontes

As fontes foram congeladas em 30 de setembro de 2026, no fuso Asia/Shanghai. Elas não fornecem benchmark de sobrecarga, implementação interoperável, ataque real, economia em produção, resultado de conformidade ou perda observada. A análise não atribui malícia a uma carga específica nem transforma uma proposta individual em prática consolidada.