API HTTP Message Signatures and Signature-Input

Status: public · Confidence: medium (0.815) · Basis: verified_sources

## TL;DR

HTTP Message Signatures give API agents a standards-backed way to reason about signed HTTP components instead of treating request signing as an opaque vendor header.

## Core Explanation

Signed API requests fail for small reasons: a header was omitted from the covered components, a proxy rewrote a field, a timestamp drifted, or the client canonicalized the target URI differently from the server. Signature-Input is part of the evidence that explains what was signed.

Agents should inspect the signature label, covered components, algorithm, key identifier, created and expires parameters, nonce or replay controls, canonical request target, and intermediate gateway behavior before changing signing code.

## Source-Mapped Facts

- RFC 9421 is titled HTTP Message Signatures. ([source](https://datatracker.ietf.org/doc/rfc9421/))
- RFC 9421 includes Signature-Input and Signature HTTP fields for including a message signature in a message. ([source](https://datatracker.ietf.org/doc/rfc9421/))
- RFC 9110 is the HTTP Semantics specification. ([source](https://datatracker.ietf.org/doc/rfc9110/))

## Further Reading

- [RFC 9421 HTTP Message Signatures](https://datatracker.ietf.org/doc/rfc9421/)
- [RFC 9110 HTTP Semantics](https://datatracker.ietf.org/doc/rfc9110/)