HTTP Message Signatures (RFC 9421)

Cosa sono gli HTTP Message Signatures

Gli HTTP Message Signatures sono definiti in RFC 9421, uno standard IETF per creare e verificare firme digitali su parti di una request o response HTTP. Un client sceglie quali componenti includere nella firma, ad esempio il metodo, il target URI, l'autorità e header selezionati, costruisce da questi una signature base canonica e la firma con una chiave privata. Il risultato viaggia in due header: Signature-Input (Section 4.1), che elenca i componenti coperti e parametri come created, expires, keyid e alg, e Signature (Section 4.2), che contiene il valore della firma vero e proprio. Entrambi usano la sintassi Structured Field Values di RFC 9651.

Il ricevente ricostruisce la stessa signature base (Section 2.5) dalla request che ha effettivamente ricevuto, recupera la chiave pubblica a cui fa riferimento keyid e verifica la firma. Se qualcosa coperto dalla firma cambia durante il transito, la verifica fallisce.

Perché contano per app, API e MCP server

La maggior parte del traffico automatizzato si identifica con una user-agent string o con un nome client scelto liberamente. Entrambi sono banali da copiare. Una message signature è diversa: lega una request a una chiave, e solo il titolare della chiave privata può produrre una firma valida. Per un'applicazione che riceve traffico da crawler, assistant e agent autonomi, questo trasforma "questo client dice di essere X" in "questa request è stata firmata dalla chiave che X pubblica".

Questa distinzione è la base per trattare i client automatizzati cooperativi come partecipanti noti invece che come traffico anonimo. Consente a una API di indirizzare un crawler firmato verso un endpoint strutturato, applicare un limite di rate diverso a un operatore noto o dare a un MCP server più contesto su chi sta chiamando uno strumento.

Come funziona la verifica nella pratica

1. Analizza Signature-Input e Signature e conferma che siano coperti i componenti attesi. Una firma che non copre nulla di utile dimostra poco.
2. Controlla i parametri created e expires per rifiutare request stale o ripetute entro la tua tolleranza (vedi Section 7.2.2 sulla signature replay).
3. Risolvi keyid in una chiave pubblica da una fonte di cui ti fidi, come una directory di chiavi che l'operatore pubblica in una posizione nota. La bozza del protocollo IETF Web Bot Auth definisce una directory di questo tipo per i client automatizzati.
4. Ricostruisci la signature base esattamente come specificato e verificane la firma con l'algoritmo dichiarato.
5. Registra cosa è stato verificato e in quale contesto, così che le decisioni successive possano farvi riferimento.

In produzione, usa un'implementazione mantenuta di RFC 9421 invece di un parser scritto a mano: i dettagli di canonicalization sono facili da sbagliare. La guida su come verificare request firmate di agent AI illustra ogni passaggio con codice.

Cosa dimostra e cosa non dimostra una firma valida

Una firma valida dimostra che la request è stata firmata da una chiave e, se la chiave è pubblicata sotto un dominio, che la request è associata all'operatore di quel dominio. Non dimostra:

• che l'operatore sia onesto o che l'azione sia sicura,
• che una persona abbia istruito o approvato la request (vedi delegated authority),
• che il client sia autorizzato a fare ciò che sta chiedendo (vedi agent authorization).

Le evidenze di identità e i permessi sono domande separate. L'autenticazione e l'autorizzazione della tua applicazione decidono ancora cosa può fare un client. Il nostro post sul blog su cosa dimostrano le request firmate di agent AI, e cosa no approfondisce il tema.

Idee sbagliate comuni

• "Firmato significa affidabile." Firmato significa attribuibile. La fiducia è una decisione di policy che prendi sulla parte attribuita.
• "Le firme sostituiscono le API key." Rispondono a una domanda diversa. Una API key dice quale account sta chiamando; una firma dice quale client ha prodotto la request. In molte implementazioni entrambe sono utili.
• "Il traffico non firmato è malevolo." Oggi gran parte del traffico automatizzato non è firmato. L'assenza di firme riduce ciò che si può stabilire, e niente di più. Ecco perché Unknown è un risultato di prima classe.

Come Proof of Actor tratta le firme

In Proof of Actor, una firma che si convalida rispetto a una chiave pubblicata viene registrata con la base verificato, limitata esattamente a ciò che il controllo ha stabilito: la chiave e l'identificativo a cui appartiene. La classe risultante (di solito Agent) non implica mai autorizzazione. I risultati confluiscono in Understand per l'analisi e in Route, dove le tue policy decidono se un client firmato ottiene un percorso strutturato, un limite diverso o nessuna modifica. Gli standard per agent firmati come Web Bot Auth sono in evoluzione, e Proof of Actor è progettato per verificare request firmate man mano che maturano.

Leggi di più su cosa può stabilire l'evidenza, oppure richiedi l'accesso anticipato.

Fonti

• RFC 9421: HTTP Message Signatures: lo standard IETF che definisce componenti, parametri e verifica della firma
• RFC 9651: Structured Field Values for HTTP: la sintassi di Signature-Input e Signature
• draft-ietf-webbotauth-httpsig-protocol: bozza IETF Web Bot Auth che applica RFC 9421 ai client automatizzati (lavoro in corso a novembre 2026)