HTTP Message Signatures (RFC 9421)

Wat HTTP Message Signatures zijn

HTTP Message Signatures zijn gedefinieerd in RFC 9421, een IETF-standaard voor het aanmaken en verifiëren van digitale handtekeningen over delen van een HTTP-verzoek of -antwoord. Een client kiest welke componenten worden afgedekt (bijvoorbeeld de methode, de doel-URI, de autoriteit en geselecteerde headers), maakt daaruit een canonieke signature base en ondertekent die met een private key. Het resultaat reist mee in twee headers: Signature-Input (Section 4.1), die de afgedekte componenten en parameters zoals created, expires, keyid en alg opsomt, en Signature (Section 4.2), dat de handtekeningwaarde zelf bevat. Beide gebruiken de Structured Field Values-syntaxis van RFC 9651.

De ontvanger bouwt dezelfde signature base opnieuw op (Section 2.5) uit het verzoek dat daadwerkelijk is ontvangen, zoekt de publieke sleutel op waarnaar keyid verwijst, en controleert de handtekening. Als iets dat door de handtekening werd afgedekt onderweg is gewijzigd, mislukt de verificatie.

Waarom dit relevant is voor apps, API's en MCP servers

De meeste geautomatiseerde traffic identificeert zich met een user-agent string of een zelfgekozen clientnaam. Beide zijn triviaal te kopiëren. Een message signature werkt anders: die koppelt een verzoek aan een sleutel, en alleen de houder van de private key kan een geldige handtekening produceren. Voor een applicatie die traffic ontvangt van crawlers, assistenten en autonome agents, verandert dat "deze client zegt dat hij X is" in "dit verzoek is ondertekend met de sleutel die X publiceert".

Dat onderscheid vormt de basis om samenwerkende geautomatiseerde clients te behandelen als bekende deelnemers in plaats van als anonieme traffic. Zo kan een API een ondertekende crawler naar een gestructureerd endpoint routeren, een ander rate limit toepassen op een bekende operator, of een MCP server meer context geven over wie een tool aanroept.

Hoe verificatie in de praktijk werkt

1. Parseer Signature-Input en Signature en controleer dat de verwachte componenten zijn afgedekt. Een handtekening die niets bruikbaars afdekt, bewijst weinig.
2. Controleer de parameters created en expires om verouderde of opnieuw afgespeelde verzoeken te weigeren binnen je tolerantie (zie Section 7.2.2 over signature replay).
3. Los keyid op naar een publieke sleutel uit een bron die je vertrouwt, zoals een key directory die de operator op een bekende locatie publiceert. De IETF Web Bot Auth protocol draft definieert zo'n directory voor geautomatiseerde clients.
4. Bouw de signature base exact opnieuw op zoals gespecificeerd en verifieer deze met het gedeclareerde algoritme.
5. Leg vast wat is geverifieerd en in welke context, zodat latere beslissingen daarnaar kunnen verwijzen.

Gebruik in productie een onderhouden RFC 9421-implementatie in plaats van zelf parsing te schrijven: details van canonicalization zijn makkelijk verkeerd te doen. De gids over hoe je ondertekende verzoeken van AI-agents verifieert doorloopt elke stap met code.

Wat een geldige handtekening wel en niet bewijst

Een geldige handtekening bewijst dat het verzoek is ondertekend met een sleutel en, als de sleutel onder een domein is gepubliceerd, dat het verzoek is gekoppeld aan de operator van dat domein. Het bewijst niet:

• dat de operator eerlijk is of dat de actie veilig is,
• dat een persoon het verzoek heeft geïnstrueerd of goedgekeurd (zie gedelegeerde bevoegdheid),
• dat de client bevoegd is om te doen wat hij vraagt (zie agent authorization).

Identiteitsbewijs en toestemming zijn afzonderlijke vragen. De eigen authenticatie en autorisatie van je applicatie bepalen nog steeds wat een client mag doen. Ons blogbericht over wat ondertekende verzoeken van AI-agents bewijzen, en wat niet gaat hier dieper op in.

Veelvoorkomende misvattingen

• "Ondertekend betekent vertrouwd." Ondertekend betekent toerekenbaar. Vertrouwen is een beleidsbeslissing die je neemt over de toegeschreven partij.
• "Handtekeningen vervangen API-keys." Ze beantwoorden een andere vraag. Een API-key zegt welk account aanroept; een handtekening zegt welke client het verzoek heeft geproduceerd. In veel implementaties zijn beide nuttig.
• "Onondertekende traffic is kwaadaardig." De meeste geautomatiseerde traffic is tegenwoordig niet ondertekend. Ontbrekende handtekeningen verminderen alleen wat kan worden vastgesteld, niets meer. Daarom is Unknown een volwaardige uitkomst.

Hoe Proof of Actor met handtekeningen omgaat

In Proof of Actor wordt een handtekening die valideert tegen een gepubliceerde sleutel vastgelegd met de basis Verified, precies beperkt tot wat de controle heeft vastgesteld: de sleutel en de identifier waartoe die behoort. De resulterende klasse (meestal Agent) impliceert nooit autorisatie. Resultaten stromen door naar Understand voor analyse en naar Route, waar je eigen policies bepalen of een ondertekende client een gestructureerd pad krijgt, een andere limiet, of helemaal geen wijziging. Standaarden voor ondertekende agents zoals Web Bot Auth zijn in ontwikkeling, en Proof of Actor is ontworpen om ondertekende verzoeken te verifiëren naarmate ze volwassen worden.

Lees meer over wat het bewijs kan vaststellen, of vraag vroege toegang aan.

Bronnen

• RFC 9421: HTTP Message Signatures: de IETF-standaard die signature components, parameters en verificatie definieert
• RFC 9651: Structured Field Values for HTTP: de syntaxis van Signature-Input en Signature
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth-draft die RFC 9421 toepast op geautomatiseerde clients (werk in uitvoering per november 2026)