Did you know? An HTTP request can carry a valid cryptographic signature and still be unsafe for an automated agent to obey. The signature may cover only the date while leaving the payment amount, target path or content unprotected. Or the same once-valid signed instruction may be replayed. HTTP Message Signatures, standardised in RFC 9421, give applications a way to sign precisely named components of requests and responses; the application must separately decide what those components prove and what authority the signer actually has.
The safe pattern is to choose an application-specific coverage policy, construct or reconstruct the exact signature base, verify the cryptographic proof using an approved key, check time and replay rules, validate any content digest, and only then apply ordinary authorisation and business constraints. A coding agent or integration service should never treat the presence of a Signature header as a command to act. A rejected or uncertain verification result means no consequential write.
This guide concerns real present-day HTTP clients, servers and AI tool integrations, not the existence of artificial superintelligence. It explains the actual mechanics of RFC 9421, gives an independently checkable numerical acceptance example, diagnoses subtle proxy and replay failures, and transfers the method to a different API. All numerical request batches below are illustrative, not a claim that an external service was tested.
Contents
- A signature proves selected bytes and policy context, not a whole request
- The two signature headers serve different jobs
- Choose covered components from the operation’s threat model
- A signature over Content-Digest is not automatically a signature over every body byte
- Canonicalisation: the verifier must reconstruct the same signature base
- Key trust, algorithm selection and the difference between identity and entitlement
- A once-valid signature can be reused without a replay policy
- Worked verification ledger: 240 requests, mutually exclusive failures
- Eight concrete integration errors and their repair
- Reverse proxies, message transformations and signature scope
- Multiple signatures, optional components and downgrade mistakes
- Failure semantics should be safe and diagnosable
- Transfer case: a signed report read becomes a signed destructive delete
- What cryptographic signatures cannot settle for an AI agent
- Frequently asked questions
- Practical pathways and exact primary references
A signature proves selected bytes and policy context, not a whole request
HTTP carries a method, request target, headers and potentially a content body. Intermediaries can legitimately transform some representations, so signing every raw wire byte would be brittle. RFC 9421 instead specifies a canonical signature base built from a declared set of covered components and signature parameters. The resulting cryptographic proof can establish that the approved signer vouched for those exact reconstructed values under the chosen algorithm and key.
A dangerous shortcut is to read the word Signature in the request and announce that the complete transaction is trustworthy. An attacker might preserve the signed date and modify an unsigned target resource, or reuse a signed instruction while the server treats it as new. A signature cannot cover something the signer deliberately or accidentally omitted from the list. The verifier has to decide what must be covered for this specific operation.
Cryptographic verification is only one gate. A legitimate account might sign a request asking to delete an object it is not authorised to delete. A valid signature does not expand that account’s permissions. A trusted integration key might be intended for a testing tenant, not a production tenant. Before execution, check signer identity and scope, target object ownership, current policy and any approval requirement.
The normative primary reference is IETF RFC 9421, HTTP Message Signatures, published February 2024. It defines component identifiers, signature-base construction, Signature-Input and Signature fields, key and algorithm considerations, and security guidance. It explicitly describes the mechanism as part of a larger security system rather than a complete authorisation framework.
This specialist question is distinct from verifying a simple webhook secret. The published webhook authenticity guide owns callback trust. Here the reader needs the general RFC 9421 component model, signature-policy evaluation and correct HTTP-message reconstruction across clients and intermediaries.
The two signature headers serve different jobs
RFC 9421 introduces Signature-Input and Signature. Signature-Input is a structured description of what components were covered and which parameters accompanied the computation. Signature carries the resulting cryptographic value for one or more named signatures. The names let a message carry several signatures with different purposes. The presence of several labels does not mean the receiver may choose whichever weak one happens to verify.
A simplified illustrative descriptor might name @method, @target-uri, content-digest and content-type, followed by creation time, expiration, key identifier and a nonce. The actual HTTP syntax follows Structured Fields rules and cannot be replaced casually with a comma-separated informal string. Signers and verifiers must agree on exactly which fields and derived components are represented, how they are transformed, and in which order they appear.
An implementation builds a signature base consisting of component identifier/value lines and a final @signature-params line. Signature parameters themselves are included as part of the signed base. That matters: a verifier must not let an attacker change the declared list of covered components or expiration without invalidating the proof. The exact byte serialisation must match RFC 9421, not an approximation assembled from pretty-printed dictionaries.
The key identifier helps locate the candidate verification key, but a keyid string is not itself an authenticated permission. Resolve candidate keys only from a trusted configured set, validate their status and algorithm, and then verify. A surprising keyid supplied in an untrusted request must not trigger arbitrary remote key downloads or a new identity assignment.
Readers working with JSON representations should distinguish this signature base from JSON canonicalization. RFC 8785 can make selected JSON representations stable for signing in suitable designs; RFC 9421 describes how to sign HTTP components and relies on digest mechanisms when the content itself needs binding.
Choose covered components from the operation’s threat model
Imagine a service accepting a signed instruction to allocate inventory. The operation has POST as the HTTP method, a tenant-specific request target, application/json as its content type, a body containing item identifiers and quantities, and a request ID used for business idempotency. What may an attacker alter to change the result? If method or target changes, the action can change. If the body changes, quantities change. If tenant context changes, the command could affect somebody else’s resources.
A sensible coverage policy may require the method, a target identifier such as @target-uri or carefully selected equivalent derived components, the content-digest field and any application fields the server materially relies on. It should also require suitable signature parameters and an acceptable signing identity. The precise list is a design decision, not a generic magic checklist from this article. Verify against the deployed proxy architecture and expected transformations.
A signer can cover a field that has no security effect, such as a display preference, while leaving the real amount unsigned. Cryptography cannot rescue such a policy. Conversely, signing a header that a reverse proxy predictably rewrites may cause healthy traffic to fail. That should prompt deliberate alignment of the signing boundary, not unreviewed removal of the important target components.
RFC 9421 provides derived components such as @method, @authority, @path, @query and @target-uri under defined rules. They are not arbitrary variables in an application framework. The chosen component is interpreted according to the target message and its semantics. A frontend proxy that replaces host or scheme can complicate verification if signer and verifier disagree about the original target.
The most useful review is adversarial and concrete: write down each mutable part of the HTTP transaction that could change the business effect, then ask whether the signature covers it or another independent authorisation control binds it. Make that question a versioned test contract. A generic ‘signature valid’ Boolean loses the information needed to audit a narrowly covered signature.
A signature over Content-Digest is not automatically a signature over every body byte
RFC 9421 does not directly cover raw HTTP content bytes as a component. A common pattern is to compute a content digest according to RFC 9530, Digest Fields and include the relevant digest field in the HTTP signature coverage. The verifier then checks two things: that the signed digest-field value is authentic and that the received message content actually matches that digest under the specified semantics.
If the receiver verifies the HTTP signature but never recomputes the body digest, an attacker who can alter unsigned body bytes may change the action while leaving a valid signature on an unchanged digest header. The digest must be recomputed using the agreed algorithm over the correct representation; otherwise the apparent content integrity is an illusion.
Content-Digest and Repr-Digest serve different representation purposes in RFC 9530. A compressed, transformed or partially transferred representation can make the distinction important. The endpoint must define which content is being acted on and which digest it expects before using the signature result to approve a consequential write.
Suppose a request says content-digest: sha-256 with a value that originally matched 512 bytes of JSON. The proxy delivers 513 different bytes, perhaps after adding one newline. The digest check should detect the mismatch even when the signed digest field itself remains unchanged. Canonicalising application JSON as an afterthought can conceal whether the signer and receiver agreed on bytes. That is why content processing rules matter as much as cryptographic primitives.
The HTTP Digest Fields guide owns the exact digest distinctions. This article explains the extra binding step: signature verification must include a checked digest when the body changes business meaning. Report separate statuses for signature validity, coverage-policy completeness and content-integrity verification.
Canonicalisation: the verifier must reconstruct the same signature base
A signature is computed over a definite sequence of bytes. HTTP field names are case-insensitive, fields can be combined under defined rules, and structured field values have specific serialisation. RFC 9421 supplies canonicalisation rules so signer and verifier can independently construct a consistent ASCII signature base even when some HTTP presentation details differ on the wire.
Do not simply sort all headers alphabetically and concatenate them. The order of covered component identifiers in Signature-Input matters. The field name used as the component identifier must follow the specification’s lowercasing and field rules. A duplicate header may have field-specific combination semantics. Some transformed values cannot be reconstructed after a proxy modifies them, which is a deployment-design issue rather than proof the cryptography is defective.
Structured Fields, standardised in RFC 8941, supply the syntax foundation. Some RFC 9421 components and parameters depend on structured serialisation; a naïve implementation that manually strips quote characters or normalises whitespace can generate a different base from a conformant peer. Small parse deviations may look like mysterious intermittent signature failures.
One powerful negative test changes an unsigned field and confirms the signature can still verify while the server’s application policy declines to trust that field. Another test changes a required covered component and checks that verification fails. Both are useful: the first demonstrates the boundary of coverage and the second proves the verifier enforces it.
A production system should retain enough nonsecret diagnostic detail to explain a rejection, such as component missing, malformed structured field, unacceptable algorithm or digest mismatch. It should not log secret keys or reveal sufficient credentials for replay. Treat detailed cryptographic evidence as sensitive operational information rather than unbounded chat context.
Key trust, algorithm selection and the difference between identity and entitlement
RFC 9421 allows implementations to employ appropriate supported signature or message-authentication algorithms and keying arrangements. A symmetric MAC requires shared secret distribution and can authenticate to parties that share the secret, but it does not establish the same kind of independently attributable signatory as an asymmetric signature. The application should document which relationship it needs.
Never let a request choose a weak or unsupported algorithm merely by naming it. The verifier needs a trusted policy mapping from identity and purpose to acceptable algorithms, keys and covered components. A key rotated out of service might still verify a mathematically correct signature; that alone does not make it currently authorised. Reject disabled, expired, wrong-tenant or wrong-purpose keys according to the authoritative key registry.
If an agent represents several customers, credentials should not be reused casually across those principals. The signed request may correctly prove that the agent service sent it; the service must still establish on whose behalf it acted and whether that delegation is current. This boundary matters especially when an automated workflow moves from informational reads to destructive writes.
A suitable audit record stores key identifier, configured principal identity, accepted algorithm, signature-policy identifier, checked request target, outcome and time, subject to privacy rules. Logging entire HTTP request bodies can leak secrets; recording only a generic ‘auth OK’ can hide how a mismatched target was accepted. Balance traceability with data minimisation and retention limits.
Related but distinct is DPoP sender-constrained OAuth access tokens, which binds a proof to an HTTP request and the OAuth token context under RFC 9449. DPoP cannot be treated as a drop-in synonym for general HTTP Message Signatures or vice versa. Pick the protocol appropriate to the authority being established.
A once-valid signature can be reused without a replay policy
Signatures establish integrity and the signer’s participation in the signed values, not automatic one-time use. If a malicious intermediary captures a valid POST ordering ten items and can replay it, a receiver that checks only the signature can perform the same action twice. Timestamps, expiration parameters and nonces are tools for constraining this problem, but the application must enforce their meaning.
Define a maximum accepted age and any permitted clock skew. Reject signatures outside the accepted interval. Nonce handling is useful where duplicate execution is dangerous: store a replay key scoped to the relevant principal and action, and reject reuse during the appropriate retention window. The policy must be enforced atomically across the infrastructure if requests can race to multiple workers.
A nonce string in Signature-Input does not itself prevent replay. A receiver can record it incorrectly, discard it before an accepted signature expires, or key it only by a field that an attacker controls. Use an atomic reserve-or-reject mechanism and specify what to do when the replay store is unavailable. For high-risk writes, fail closed rather than silently stop deduplicating.
Replay rejection and business idempotency are related but different. Idempotency may ensure that two legitimately repeated client attempts yield one recorded effect while returning a consistent result. Cryptographic replay defence checks whether an authenticated message is being used outside the intended fresh context. A legitimate user may need to retry a failed operation with the same business idempotency key but a newly signed request.
Time limits are not perfect either. A signature accepted inside a one-minute window can still be replayed within that minute unless a nonce or separate business invariant prevents duplicate effects. Keep the two questions separate: ‘Was this signed by an approved key recently?’ and ‘Would executing this request now create a duplicate or unauthorised action?’
Worked verification ledger: 240 requests, mutually exclusive failures
Here is an invented, fully partitioned example. A service processes 240 incoming signed API write requests under one documented signature policy. It evaluates required components before expensive work, then time windows, trusted keys, cryptographic proof and body integrity before approving effects. For this exercise every request falls into exactly one first-failure or accepted category, so the denominators stay stable.
Seven requests lack one or more policy-required covered components. Five more have unacceptable creation or expiration times. Eight use keys that the service cannot accept for this operation. Four have invalid signatures under their configured keys. Of the remaining requests, six have mismatched verified Content-Digest values. The rest are accepted after ordinary authorisation checks. The sum of first-failure cases is 7 + 5 + 8 + 4 + 6 = 30.
The accepted count is therefore 240 − 30 = 210. Acceptance fraction is 210/240 = 0.875, or 87.5%. Rejection fraction is 30/240 = 12.5%. These are illustrative test figures, not measurements of an external API. If someone counted only the four cryptographic mismatches as failures, they would report 236/240 = 98.33%, an inflated ‘security success’ rate that ignores unsigned material, stale requests, unauthorised keys and tampered bodies.
Now consider two concurrent copies of one correctly signed command. Both may pass the component, time, key, signature and digest checks. Without atomic replay reservation or suitable idempotent business semantics, both might execute. That edge case was deliberately not included in the ledger above; its consequences require testing the execution boundary rather than retroactively hiding duplicate writes among the 210 accepted requests.
The general diagnostic technique is to report each decision as a first-failure stage with an explicit denominator and then separately count downstream policy rejections. This makes operational statistics meaningful. It avoids claiming cryptographic correctness is equivalent to business safety and identifies where implementation repairs would change actual behaviour.
Eight concrete integration errors and their repair
One error is signing only a Date field. It may establish an authenticated timestamp while leaving target and content mutable. The repair is a policy that requires effect-defining components to be covered and verified. A second error is trusting whatever components the sender happened to list. The receiver must require a minimum coverage set for the requested action, not let attackers negotiate a weaker policy through Signature-Input.
A third error is changing JSON after its digest was computed, or verifying a digest against the wrong representation. Repair it by defining exact content bytes and transformation boundaries. A fourth is reconstructing a signature base from an altered proxy URL. Repair it by selecting a trusted verification boundary and agreeing on canonical derived components and forwarded values.
A fifth error is dynamically fetching an attacker-controlled keyid URL as though it were an approved key. Repair it with a trusted key registry and explicit rotation rules. A sixth is treating the existence of a nonce as proof of uniqueness. Repair it with a durable atomic replay store scoped to identity and action, plus a documented failure mode when the store is unavailable.
A seventh error is saying ‘signed equals authorised’. Repair it with separate authentication, permission, resource-ownership and approval checks. An eighth is repeating a timed-out write because the signature was good. Repair it with original-operation reconciliation and idempotency checks rather than blindly creating another business effect.
Each repair has a different test oracle. Component coverage tests change method or target; content tests mutate bytes; replay tests race identical requests; key tests rotate or revoke known credentials; authorisation tests use a legitimate but insufficiently privileged signer. A single green end-to-end demo is not enough to establish all of these boundaries.
Reverse proxies, message transformations and signature scope
Many production requests pass through gateways that terminate TLS, rewrite hostnames, strip some headers or transform content encodings. A signature verified before a transformation may cover a different message state than one verified afterward. An integration should decide which trusted hop verifies the signature and which components survive intact through that hop.
Treat Forwarded and X-Forwarded-style headers as untrusted unless the infrastructure has a clear trusted proxy chain. A client can often supply spoofed forwarding values to an edge service. Reconstructing @target-uri from an unvalidated forwarded host can make a signature bind the wrong authority or fail inconsistently across environments.
One approach is for the receiver to sign and verify components known to be stable across an authorised gateway path. Another is to terminate signature verification at the edge before transformations, then pass the authenticated identity and exact verified effect context through an independently protected internal channel. Neither approach licenses silently dropping method or target binding when it matters.
Use a test that signs an HTTPS request to the public host, traverses the actual proxy chain and independently verifies at the intended boundary. Then change one proxy configuration at a time. A mismatch caused by an infrastructure deployment is a reason to reconcile the message model, not a reason to bypass verification or downgrade to trust in IP address alone.
The published reverse proxy trust guide explores original-client identity and forwarded-header hazards. Those are complementary concerns: proxy trust influences which message representation and authority the verifier can safely reconstruct.
Multiple signatures, optional components and downgrade mistakes
A message may contain more than one named signature. One signature could satisfy transport-specific requirements while another satisfies a business instruction policy. A service that accepts the first mathematically valid signature without checking its designated purpose risks a downgrade: an attacker can present a low-assurance signature in place of the one required for a payment or deletion.
Decide which signature labels, keys and component sets can satisfy each operation. Verification outcomes can be collected individually, but the final decision must evaluate the complete operation policy. The existence of a valid general metadata signature cannot substitute for required coverage of the request amount and target.
Optional headers also require care. If a security-critical covered component is missing, the signature base algorithm may be unable to reconstruct it and must fail according to the standard. An implementation should not quietly invent an empty value or remove the component from the list to make verification succeed. That would change the sender’s claimed signed statement.
Some protocol libraries represent headers differently from application code. A verifier accepting duplicate, malformed or ambiguous structured fields can disagree with downstream processing about what the request means. Test that the same semantic value used by business logic is the value whose covered representation was verified. A correct signature over a different interpretation is not a secure authorisation boundary.
Failure semantics should be safe and diagnosable
The system needs explicit decision states: missing signature, malformed signature fields, unacceptable coverage, unknown key, unacceptable algorithm, invalid cryptographic proof, expired or not-yet-valid signature, replay, content mismatch, insufficient authorisation and uncertain external effects. These should not all be converted into a single misleading ‘500 server error’ that encourages blind retries.
Some failures are client-correctable, such as clock synchronisation or creating a new permitted signature; others are security refusals that should not be automatically retried with looser validation. Tell the caller enough to follow the legitimate remediation path without disclosing secret keys, internal verification material or information that would help a malicious party enumerate privileged identities.
A successful signature verification may be followed by a business validation failure. Keep the authentic request receipt separate from the action result. The signer may need to correct a missing resource or insufficient permission; it must not claim that the tool executed just because the cryptographic layer succeeded.
If the response is lost after a consequential write, inspect the original operation’s durable ID and effect before retrying. Signed requests can be duplicated by network infrastructure or clients; the integration’s recovery contract should keep authentication, deduplication and outcome readback as distinct steps. This is the same reliability principle explained in idempotency and reconciliation.
Transfer case: a signed report read becomes a signed destructive delete
Change the context from an inventory-write service to an API that allows both GET /reports/42 and DELETE /reports/42. Suppose a client signs @method, @path, content-type and a creation timestamp. The GET needs no body, while DELETE might require a separate approval and resource-owner permission. The same cryptographic mechanism can represent both, but the policy cannot simply be copied from a read-only operation to a destructive one.
Imagine that the approved key is allowed to read reports but not delete them. A mathematically valid DELETE signature proves this key signed a request with that method and path; it does not grant deletion permission. The server must decline deletion under its authority rules. An agent may explain that the signature is valid while the command is refused—those two observations are fully consistent.
Suppose the real owner subsequently approves deletion, the client signs a fresh request and the server accepts it once. A second copy arriving five seconds later can be fresh in clock terms but still be a replay. An atomic nonce or operation-ID rule should reject duplicate execution. Record one completed deletion, not two, and ensure the client can retrieve the original result after a timeout.
Now add a proxy that rewrites a public path /v2/reports/42 to an internal path /reports/42. If signature verification happens downstream and the signer covered the public @path, naïvely verifying against the internal path will fail. The correct response is an explicit deployment design that binds signed public and internal semantics, not simply omitting path from coverage.
The transfer shows how the same standard needs operation-specific authorisation, safe treatment of intermediaries, and independent effect verification. A general signature algorithm cannot know whether a report is confidential or a deletion is reversible; those are business and human-governance questions.
What cryptographic signatures cannot settle for an AI agent
RFC 9421 cannot guarantee that the signed request is wise, lawful, correctly interpreted or consistent with a user’s current instructions. It does not decide whether a principal may access a tenant or whether a workflow has satisfied a necessary human review. It also does not magically establish that a remote tool executed its requested work when a response is ambiguous.
Signed message coverage has to reflect the intended security property. An application may deliberately leave innocuous headers unsigned, but it must not allow an unsigned value to control the action in a way that defeats the signature policy. Security claims should name what is covered, by whom, for how long and under which authority, rather than declaring the HTTP message generally ‘trusted’.
Security also depends on private-key handling, correct clock assumptions, algorithms, middleware, replay-storage availability and sound endpoint implementation. A signing library is not a replacement for a protocol review. The HTTP standards themselves document security considerations and application responsibilities beyond cryptographic primitives.
Finally, signature verification is not the same as end-to-end confidentiality. HTTPS protects transport under its own trust model, while message signatures can bind selected values across appropriate hops. Neither alone removes data-governance and least-privilege requirements for AI agents carrying user information.
Frequently asked questions
Does an HTTP Message Signature authenticate the entire body? Not by itself. A suitable content digest can be a covered field, but the verifier must independently check the actual received content against that digest.
Why are there two signature headers? Signature-Input declares the covered components and signature parameters; Signature carries the corresponding cryptographic signature bytes. A valid security policy must interpret both.
What is @method? It is a standard derived HTTP component representing the request method in the signature base. It is not a free-text label invented by an application.
Does a valid cryptographic result authorise a tool call? No. Signer authentication, operation scope, resource permissions and human approval requirements remain separate checks.
Does adding a nonce stop replay? Only if the receiver enforces freshness and deduplicates nonce use atomically for the appropriate scope. The presence of a nonce string is insufficient.
Can intermediaries modify messages without breaking signatures? Some transformations are compatible with the RFC’s component model, but modifying covered values can break verification. Choose the verification boundary and coverage rules deliberately.
Are HTTP Message Signatures and DPoP interchangeable? No. They differ in their standardised purpose, binding and protocol details. Choose the one matching the actual token and request authentication design.
Should an agent retry after an unknown signed-write response? It should first reconcile the original operation’s recorded effect and idempotency state. A newly signed duplicate can still perform an unintended second action.
Practical pathways and exact primary references
For an API implementer, write a per-operation coverage profile before choosing a library: allowed principals and keys, required component identifiers, content-digest policy, timestamp window, nonce scope and accepted algorithms. Test canonical serialisation against the RFC examples. Reject messages whose signed coverage is insufficient even if the cryptographic bytes verify.
For an agent engineer, isolate signature verification and permission decisions from generative reasoning. The model may help the user understand a rejection, but it should not be allowed to weaken coverage or grant itself credentials. Keep original operation IDs, signed-request receipts and final effect readbacks separate, and never advertise an unverified tool result as complete.
For a reviewer or student, compare two apparently signed requests where one covers only date and the other covers method, target and a checked content digest. Identify which changes an attacker can make without breaking each signature. Then apply the hypothetical replay case: a signature that verifies twice does not mean the business action may execute twice.
Primary standards: RFC 9421 HTTP Message Signatures, RFC 9530 Digest Fields, RFC 8941 Structured Field Values for HTTP, and RFC 9110 HTTP Semantics. These sources give actual normative definitions; deployment policies must be reviewed alongside them.
For the wider system roadmap continue with How Super Intelligence Works, while the broader educational objective of checking evidence before action appears in the Gold Standard of Education. The numerical cases in this article were constructed for explanation; no live signature was generated, verified or executed in this manuscript.