HTTP Message Signatures (RFC 9421)

Was HTTP Message Signatures sind

HTTP Message Signatures sind in RFC 9421 definiert, einem IETF-Standard zum Erstellen und Prüfen digitaler Signaturen über Teile einer HTTP request oder response. Ein Client wählt aus, welche Komponenten abgedeckt werden sollen, zum Beispiel die Methode, die target URI, die authority und ausgewählte headers, erstellt daraus eine kanonische signature base und signiert sie mit einem privaten Key. Das Ergebnis wird in zwei headers übertragen: Signature-Input (Section 4.1), der die abgedeckten Komponenten und Parameter wie created, expires, keyid und alg auflistet, sowie Signature (Section 4.2), der den eigentlichen Signaturwert trägt. Beide nutzen die Structured Field Values syntax aus RFC 9651.

Der Empfänger baut die gleiche signature base (Section 2.5) aus der tatsächlich empfangenen request neu auf, sucht den öffentlichen Key, auf den keyid verweist, und prüft die Signatur. Wenn sich unterwegs etwas geändert hat, das von der Signatur abgedeckt ist, schlägt die Verifikation fehl.

Warum das für Apps, APIs und MCP servers wichtig ist

Die meisten automatisierten Zugriffe identifizieren sich mit einem user-agent string oder einem selbst gewählten Client-Namen. Beides lässt sich leicht kopieren. Eine Message Signature ist anders: Sie verknüpft eine request mit einem Key, und nur der Inhaber des privaten Keys kann eine gültige Signatur erzeugen. Für eine Anwendung, die Traffic von Crawlern, Assistenten und autonomen Agenten empfängt, wird aus "Dieser Client sagt, dass er X ist" damit "Diese request wurde mit dem Key signiert, den X veröffentlicht".

Dieser Unterschied ist die Grundlage dafür, kooperierende automatisierte Clients als bekannte Teilnehmer statt als anonymen Traffic zu behandeln. So kann eine API einen signierten Crawler an einen strukturierten endpoint leiten, für einen bekannten Betreiber ein anderes rate limit anwenden oder einem MCP server mehr Kontext dazu geben, wer ein tool aufruft.

Wie Verifikation in der Praxis funktioniert

1. Signature-Input und Signature parsen und bestätigen, dass die erwarteten Komponenten abgedeckt sind. Eine Signatur, die nichts Nützliches abdeckt, beweist wenig.
2. Die Parameter created und expires prüfen, um veraltete oder wiederholte requests innerhalb Ihrer Toleranz abzulehnen (siehe Section 7.2.2 zu signature replay).
3. keyid zu einem öffentlichen Key aus einer Quelle auflösen, der Sie vertrauen, zum Beispiel einem key directory, das der Betreiber an einer bekannten Stelle veröffentlicht. Der IETF-Entwurf Web Bot Auth protocol draft definiert ein solches Verzeichnis für automatisierte Clients.
4. Die signature base exakt wie spezifiziert neu aufbauen und mit dem deklarierten Algorithmus verifizieren.
5. Festhalten, was verifiziert wurde und in welchem Kontext, damit spätere Entscheidungen sich darauf beziehen können.

Verwenden Sie in der Produktion eine gepflegte RFC 9421-Implementierung statt selbst geschriebener Parsing-Logik: Details der Canonicalization sind leicht falsch umzusetzen. Der Leitfaden how to verify signed AI agent requests geht jeden Schritt mit Code durch.

Was eine gültige Signatur beweist und was nicht

Eine gültige Signatur beweist, dass die request von einem Key signiert wurde, und, wenn der Key unter einer Domain veröffentlicht ist, dass die request dem Betreiber dieser Domain zugeordnet ist. Sie beweist nicht:

• dass der Betreiber ehrlich ist oder die Aktion sicher ist,
• dass eine Person die request angewiesen oder freigegeben hat (siehe delegated authority),
• dass der Client berechtigt ist, das Gewünschte auszuführen (siehe agent authorization).

Identitätsnachweis und Berechtigung sind getrennte Fragen. Die eigene Authentication und Authorization Ihrer Anwendung entscheiden weiterhin, was ein Client tun darf. Unser Blogbeitrag what signed AI agent requests prove, and what they don't geht darauf ausführlicher ein.

Häufige Missverständnisse

• "Signiert bedeutet vertrauenswürdig." Signiert bedeutet zurechenbar. Vertrauen ist eine Policy-Entscheidung, die Sie über die zugeordnete Partei treffen.
• "Signaturen ersetzen API keys." Sie beantworten eine andere Frage. Ein API key sagt, welches Konto aufruft; eine Signatur sagt, welcher Client die request erzeugt hat. In vielen Setups sind beide nützlich.
• "Unsignierter Traffic ist bösartig." Der meiste automatisierte Traffic ist heute unsigniert. Fehlende Signaturen schränken nur ein, was festgestellt werden kann, mehr nicht. Deshalb ist Unknown ein erstklassiges Ergebnis.

Wie Proof of Actor Signaturen behandelt

In Proof of Actor wird eine Signatur, die gegen einen veröffentlichten Key validiert, mit der Basis Verified erfasst, und zwar genau im Umfang dessen, was die Prüfung festgestellt hat: den Key und die zugehörige Kennung. Die daraus resultierende Klasse, meist Agent, impliziert niemals Autorisierung. Die Ergebnisse fließen in Understand zur Analyse und in Route, wo Ihre eigenen Policies entscheiden, ob ein signierter Client einen strukturierten Pfad erhält, ein anderes Limit oder überhaupt keine Änderung. Standards für signierte Agents wie Web Bot Auth entwickeln sich weiter, und Proof of Actor ist darauf ausgelegt, signierte requests zu verifizieren, sobald sie ausreifen.

Lesen Sie mehr darüber, was die evidence belegen kann, oder tragen Sie sich für frühen Zugang ein.

Quellen

• RFC 9421: HTTP Message Signatures: der IETF-Standard, der Signaturkomponenten, Parameter und Verifikation definiert
• RFC 9651: Structured Field Values for HTTP: die syntax von Signature-Input und Signature
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth-Entwurf, der RFC 9421 auf automatisierte Clients anwendet (Stand November 2026 in Arbeit)