Resumo

  • A revisão 07 usa a chave cnf.jwk do Workload Identity Token para assinar método, caminho, consulta, audiência, cabeçalhos selecionados, digest do conteúdo e parâmetros de tempo. Isso autentica a representação coberta; não concede o direito de executar a operação.
  • Um cache local sem o nonce não prova novidade no cluster. Uma resposta só fica protegida contra remoção da assinatura quando o cliente exigiu essa assinatura em sua própria requisição assinada. Identidade, replay, autorização, execução e resultado precisam de provas próprias.

A repetição que o cluster não lembra como um só

Uma requisição chega ao validador A. O WIT é aceito, a chave de confirmação verifica a assinatura, o Content-Digest corresponde ao corpo, a audiência está correta e o nonce não consta da memória local. A registra o nonce e encaminha o pedido.

Pouco depois, os mesmos bytes chegam ao validador B. A assinatura ainda está dentro de expires, mas B não compartilha o cache de A. A verificação é válida e, para B, o nonce é inédito. Não há contradição: cada resultado descreve uma memória diferente.

Ainda faltam duas perguntas. Essa carga de trabalho pode realizar a ação sobre o recurso específico? A aplicação confirmou a mudança de estado? Quando a plataforma resume tudo em authenticated=true, transforma uma prova limitada em autoridade que o protocolo nunca concedeu.

draft-ietf-wimse-http-signature-07 foi apresentado em 20 de setembro de 2026. O cabeçalho indica intenção de Standards Track e vencimento em 24 de março de 2027. Não é RFC. É um Internet-Draft ativo do grupo de trabalho, não obrigação implantada, medição de adoção ou comprovação sobre qualquer produto. A lista de implementações mostra experimentos, não um censo de produção.

O perímetro exato da assinatura

O perfil reutiliza a RFC 9421. A requisição cobre obrigatoriamente @method, @path e @query. Quando presentes, Content-Type, Content-Digest, Authorization, Txn-Token e Workload-Identity-Token também entram. Se houver corpo, o receptor recalcula o Content-Digest sobre os bytes recebidos.

Assinar apenas a representação textual de um digest não ligaria a prova ao conteúdo. A RFC 9530 define a semântica do campo; o novo cálculo fecha a ligação. Um recibo operacional deve guardar a base reconstruída, a lista de componentes, o digest calculado e o resultado, não só a frase “assinatura válida”.

Os parâmetros contêm created, um expires curto, nonce aleatório e a tag wimse-workload-to-workload; a requisição acrescenta wimse-aud. O perfil proíbe os parâmetros keyid e alg da assinatura HTTP porque chave e algoritmo vêm de cnf.jwk no WIT. Mesmo assim, a política local decide se aceita o algoritmo para aquele domínio de confiança.

Mais de uma assinatura com a tag WIMSE obriga a rejeição. Escolher silenciosamente uma delas permitiria que remetente, proxy e aplicação apontassem para representações diferentes e chamassem todas de “a requisição assinada”.

Um campo omitido continua fora da garantia. Se um intermediário transforma e assina de novo, produz uma nova afirmação por um novo principal; não amplia retroativamente a cobertura anterior.

A audiência lógica atravessa a mudança de authority

@authority não faz parte do conjunto obrigatório porque proxies e balanceadores que terminam TLS costumam reescrevê-lo. A vinculação do destinatário passa para o parâmetro assinado wimse-aud.

Essa escolha separa fatos que a operação costuma misturar. A identidade de serviço verificada no canal segundo a RFC 9525, a authority HTTP vista em um salto e a audiência WIMSE são diferentes. O TLS pode estar correto e a audiência ser ampla demais. A assinatura pode estar correta e o serviço rejeitar a audiência.

Por isso, a trilha precisa registrar o nome esperado pelo cliente, a identidade apresentada, o ponto de terminação TLS, a audiência enviada, a interpretação do receptor e o destino final. Um único estado “autenticado” apaga onde o significado mudou.

Posse da chave não cria mandato

O receptor valida o WIT e depois a assinatura com a chave vinculada. O resultado sustenta uma afirmação limitada: alguém com a chave privada correspondente formou os componentes cobertos durante a janela aceita.

Ele não prova custódia exclusiva em uma única instância, não explica a intenção e não converte identidade técnica em função de negócio. A revisão 07 declara todo o subsistema de autorização fora do escopo e o trata como pré-requisito confiável.

Isso exige uma fronteira, não um atalho. A autenticação entrega principal e requisição. O primeiro componente que conhece a ação resolvida e ainda pode impedir o efeito compara principal, ação, recurso, contexto e versão de política.

O recibo de autorização registra regra, decisão, obrigações, exceção e instante. Se o gateway converte todo WIT de um domínio em papel amplo, é a configuração do gateway que criou o poder. Sua aprovação e histórico precisam ser auditados.

Replay é propriedade da arquitetura de estado

created e expires reduzem o intervalo de aceitação, mas não impedem uma segunda apresentação dentro dele. O nonce só ajuda se alguma memória conservar a primeira. O draft permite cache de replay e recomenda rejeitar o valor já visto, porém não exige compartilhamento entre validadores. Também não promete proteção estrita como objetivo, devido ao custo de sincronização distribuída.

Logo, ausência no cache significa ausência nesta memória, neste escopo e nesta retenção. Não demonstra que outra região não aceitou, que um registro anterior não expirou ou que a aplicação não processou uma operação equivalente com outro identificador.

Para leitura idempotente, o compromisso pode ser aceitável. Para débito, emissão, exclusão ou comando irreversível, a aplicação precisa de uma barreira adicional: chave de idempotência, restrição transacional ou livro de commits. “Proteção contra replay ativada” sem topologia, tempo de retenção e comportamento de failover é uma descrição incompleta.

A assinatura da resposta nasce na solicitação do cliente

O servidor pode assinar respostas. A garantia forte surge quando o cliente inclui wimse-sign-response=true nos parâmetros assinados de sua requisição. Se não puder assinar, o servidor não deve devolver um sucesso comum; o cliente deve rejeitar uma resposta sem assinatura.

Toda resposta assinada contém wimse-req-nonce igual ao nonce da requisição. Assim, a prova liga os componentes da resposta à chamada concreta, e não apenas a uma chave de servidor.

Se o cliente não exigiu, a política do servidor não produz a mesma resistência à remoção. Um intermediário pode retirar a assinatura e o cliente deve aceitar a resposta ordinária. “O servidor assina” é uma afirmação de capacidade. “O cliente exigiu e verificou a resposta ligada ao nonce” é um recibo de transação.

Mesmo o recibo de resposta não prova o desfecho. Um serviço pode aceitar trabalho assíncrono e falhar depois. O resultado precisa ser observado em outra camada.

A última transformação define o ponto de autorização

Intermediários terminam TLS, normalizam campos, roteiam, decodificam e podem assinar novamente. Campos cobertos não mudam sem invalidar a assinatura; campos fora dela podem mudar. Se a aplicação escolhe a conta ou o tenant por um cabeçalho não assinado depois da autorização do gateway, a decisão ocorreu cedo demais.

A trilha deve unir validação de entrada, regra de transformação, identidade da nova assinatura, diferenças de cobertura e autorização final. Não é necessário congelar todos os bytes de HTTP. É necessário fixar quem pode modificar os valores que determinam o efeito.

O registro completo forma seis recibos: WIT e impressão da chave; base de assinatura e digest recalculado; nonce, validador e alcance do cache; principal, ação, recurso e política; idempotência e commit; observação independente do resultado. Eles podem discordar. Uma assinatura válida pode ser replay, uma solicitação nova pode ser proibida, uma operação autorizada pode falhar e um commit pode ser revertido.

Essa divergência é a base da responsabilização. Um apêndice de implementação ou uma alegação de conformidade indica capacidade. Avaliar código em execução requer captura, base reconstruída, validação do token, topologia dos caches, log de autorização e transição de estado. Como o draft pode mudar, a decisão também deve registrar revisão e desvios locais.

Fontes