HTTP Message Signatures (RFC 9421)

O que são HTTP Message Signatures

HTTP Message Signatures são definidas em RFC 9421, um padrão do IETF para criar e verificar assinaturas digitais sobre partes de uma requisição ou resposta HTTP. Um cliente escolhe quais componentes cobrir, por exemplo o método, a URI de destino, a autoridade e headers selecionados, constrói uma base canônica de assinatura a partir deles e a assina com uma chave privada. O resultado trafega em dois headers: Signature-Input (Section 4.1), que lista os componentes cobertos e parâmetros como created, expires, keyid e alg, e Signature (Section 4.2), que carrega o próprio valor da assinatura. Ambos usam a sintaxe de Structured Field Values da RFC 9651.

O destinatário reconstrói a mesma base de assinatura (Section 2.5) a partir da requisição que realmente recebeu, localiza a chave pública referenciada por keyid e verifica a assinatura. Se algo coberto pela assinatura mudar no trânsito, a verificação falha.

Por que elas importam para apps, APIs e MCP servers

A maior parte do tráfego automatizado se identifica com um user-agent string ou com um nome de cliente escolhido por conta própria. Ambos são triviais de copiar. Uma message signature é diferente: ela vincula uma requisição a uma chave, e somente o detentor da chave privada consegue produzir uma assinatura válida. Para uma aplicação que recebe tráfego de crawlers, assistentes e agentes autônomos, isso transforma "este cliente diz que é X" em "esta requisição foi assinada pela chave que X publica".

Essa distinção é a base para tratar clientes automatizados cooperativos como participantes conhecidos, e não como tráfego anônimo. Isso permite que uma API direcione um crawler assinado para um endpoint estruturado, aplique um rate limit diferente a um operador conhecido ou dê a um MCP server mais contexto sobre quem está chamando uma tool.

Como a verificação funciona na prática

1. Faça o parse de Signature-Input e Signature e confirme que os componentes esperados estão cobertos. Uma assinatura que não cobre nada útil prova pouco.
2. Verifique os parâmetros created e expires para rejeitar requisições antigas ou repetidas dentro da sua tolerância (veja Section 7.2.2 sobre signature replay).
3. Resolva keyid para uma chave pública a partir de uma fonte em que você confia, como um diretório de chaves publicado pelo operador em um local conhecido. O rascunho de protocolo da IETF Web Bot Auth protocol draft define esse tipo de diretório para clientes automatizados.
4. Reconstrua a base de assinatura exatamente como especificado e verifique-a com o algoritmo declarado.
5. Registre o que foi verificado e em que contexto, para que decisões posteriores possam se basear nisso.

Em produção, use uma implementação mantida de RFC 9421 em vez de fazer o parse manualmente: detalhes de canonicalization são fáceis de errar. O guia sobre how to verify signed AI agent requests percorre cada etapa com código.

O que uma assinatura válida comprova e o que não comprova

Uma assinatura válida comprova que a requisição foi assinada por uma chave e, se a chave for publicada sob um domínio, que a requisição está associada ao operador desse domínio. Ela não comprova:

• que o operador é honesto ou que a ação é segura,
• que uma pessoa instruiu ou aprovou a requisição (veja delegated authority),
• que o cliente está autorizado a fazer o que está pedindo (veja agent authorization).

Evidência de identidade e permissão são questões separadas. A autenticação e a autorização da própria aplicação continuam decidindo o que um cliente pode fazer. Nosso post no blog sobre what signed AI agent requests prove, and what they don't cobre isso com mais profundidade.

Equívocos comuns

• "Assinado significa confiável." Assinado significa atribuível. Confiança é uma decisão de política que você toma sobre a parte atribuída.
• "Assinaturas substituem API keys." Elas respondem a uma pergunta diferente. Uma API key diz qual account está chamando; uma assinatura diz qual cliente produziu a requisição. Muitas implantações se beneficiam de ambas.
• "Tráfego sem assinatura é malicioso." A maior parte do tráfego automatizado hoje não tem assinatura. A ausência de assinaturas reduz o que pode ser estabelecido, nada além disso. É por isso que Unknown é um resultado de primeira classe.

Como Proof of Actor trata assinaturas

No Proof of Actor, uma assinatura que valida contra uma chave publicada é registrada com a base Verified, limitada exatamente ao que a verificação estabeleceu: a chave e o identificador ao qual ela pertence. A classe resultante, normalmente Agent, nunca implica autorização. Os resultados fluem para Understand para análise e para Route, onde suas próprias políticas decidem se um cliente assinado recebe um caminho estruturado, um limite diferente ou nenhuma mudança. Padrões de signed-agent como Web Bot Auth estão evoluindo, e o Proof of Actor foi projetado para verificar requisições assinadas à medida que amadurecem.

Leia mais sobre o que a evidência pode estabelecer, ou solicite acesso antecipado.

Fontes

• RFC 9421: HTTP Message Signatures: o padrão da IETF que define componentes de assinatura, parâmetros e verificação
• RFC 9651: Structured Field Values for HTTP: a sintaxe de Signature-Input e Signature
• draft-ietf-webbotauth-httpsig-protocol: rascunho da IETF Web Bot Auth aplicando RFC 9421 a clientes automatizados (trabalho em andamento em novembro de 2026)