What is the Signature-Input header in RFC 9421?
The Signature-Input header in RFC 9421 is a metadata header that declares which parts of an HTTP message are covered by a digital signature. It specifies the components (such as headers or the request body), the signature algorithm, the key identifier, and optional parameters like creation time and expiration. This header works alongside the Signature header, which contains the actual cryptographic signature, to enable verifiable integrity and authenticity of HTTP messages.
Last updated 21 August 2026
The Signature-Input header is critical for HTTP message signing because it tells verifiers exactly what was signed, how it was signed, and which key to use for verification. Without it, the Signature header would be meaningless, as there would be no way to confirm the scope or validity of the signature.
What the Signature-Input header contains
The Signature-Input header is a structured field that lists one or more signature labels, each defining a set of parameters for a corresponding signature in the Signature header. Here's what it includes:
1. The ordered list of covered components
The header specifies which parts of the HTTP message are covered by the signature. Components are listed in the order they were signed, and each component is identified by a lowercase name (for example, @method, @target-uri, content-type, digest). The order matters because the signature is computed over the canonicalized byte sequence of these components in the exact order listed.
Example:
Signature-Input: sig1=("@method" "@target-uri" "content-type" "digest")
2. The keyid parameter
The keyid parameter identifies the public key used to verify the signature. It is a string that the verifier uses to look up the corresponding public key in a registry or key store. The format of keyid is not defined by RFC 9421, but it must be unique within the context of the application.
Example:
Signature-Input: sig1=("@method" "@target-uri");keyid="test-key-ed25519"
3. The alg parameter
The alg parameter specifies the cryptographic algorithm used to generate the signature. RFC 9421 supports several algorithms, including ed25519, ecdsa-p256-sha256, and rsa-pss-sha512. The algorithm must match the one used to generate the signature in the Signature header.
Example:
Signature-Input: sig1=("@method");alg="ed25519"
4. The created and expires parameters
These optional parameters define the lifetime of the signature:
- created: A Unix timestamp (seconds since epoch) indicating when the signature was generated.
- expires: A Unix timestamp indicating when the signature is no longer valid.
If expires is present, verifiers must reject the signature if the current time is past the expiration time. These parameters help prevent replay attacks and ensure signatures are used within a valid time window.
Example:
Signature-Input: sig1=("@method");created=1618884473;expires=1618884533
How Signature-Input pairs with the Signature header
The Signature-Input header and the Signature header work together to enable verifiable HTTP message signing:
1. The Signature-Input header declares what is signed (the components), how it is signed (the algorithm), and which key to use (keyid).
2. The Signature header contains the actual cryptographic signature, computed over the canonicalized byte sequence of the components listed in Signature-Input.
For example, a signed HTTP request might look like this:
POST /api/data HTTP/1.1
Host: example.com
Content-Type: application/json
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Signature-Input: sig1=("@method" "@target-uri" "content-type" "digest");keyid="test-key-ed25519";alg="ed25519";created=1618884473
Signature: sig1=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==:
To verify this signature:
1. The verifier extracts the components listed in Signature-Input (@method, @target-uri, content-type, digest).
2. The verifier canonicalizes these components according to RFC 9421 rules (for example, normalizing header names to lowercase, serializing the request target).
3. The verifier computes the byte sequence of the canonicalized components in the order listed.
4. The verifier uses the keyid to look up the public key and the alg to determine the verification algorithm.
5. The verifier checks the signature in the Signature header against the computed byte sequence.
Do it with AlgoVoi
AlgoVoi provides a free, open-source (Apache-2.0) verifier for RFC 9421 HTTP message signatures. The algovoi-rfc9421-verifier package (v0.4.4) lets you verify signatures in Python or TypeScript with byte-for-byte parity between the two implementations. It supports ed25519 today, with ecdsa-p256-sha256 and rsa-pss-sha512 on the roadmap.
Install it with:
pip install algovoi-rfc9421-verifier
or
npm install @algovoi/rfc9421-verifier
You can also use the hosted verifier at https://verify.algovoi.co.uk/rfc9421 to test signatures without installing anything.
Start verifying HTTP signatures today
The Signature-Input header is the backbone of RFC 9421, enabling verifiable, tamper-evident HTTP messages. Whether you're securing API requests, agentic workflows, or compliance records, understanding and using this header is essential.
Start with the docs to integrate RFC 9421 signing and verification into your workflow.
Related: RFC 9421 HTTP message signatures
A connected set of answers on signing and verifying HTTP messages and agent-to-agent calls under RFC 9421.
- Verify RFC 9421 HTTP message signatures
- Sign an HTTP request with RFC 9421
- HTTP message signatures for agent-to-agent (A2A) requests
- Free clinic: verify your agent's signed calls offline
- RFC 9421 canonicalization rules
- RFC 9421 vs the older draft-cavage signatures
- Bind an RFC 9421 signature to an agent credential