Summary

  • draft-ietf-wimse-http-signature-07 can bind a Workload Identity Token’s confirmation key to the method, path, query, audience, selected headers, content digest and signature metadata of an HTTP request. It does not grant permission for the requested operation.
  • A nonce miss is local evidence unless validators share replay state. A signed response is deletion-resistant only when the client signed an explicit demand for one. Signature, replay, authorization, application commit and business outcome remain separate receipts.

One request, two validators

A payment-reconciliation workload sends a request that is perfectly formed under the proposed WIMSE profile. Its Workload Identity Token is current. The token binds a public key. The corresponding private key signs the prescribed request representation. The method, path and query are covered. The audience names the receiving workload. The content digest matches the body. The creation time, expiry, nonce and profile tag all pass.

Validator A accepts the signature and records the nonce in its local cache. An attacker—or merely an unsafe retrying component—sends the same signed request to validator B before the signature expires. B uses the same WIT trust policy and the same verification key, but its replay cache is private to that process. The signature is still mathematically valid. B has never seen the nonce. Both facts can be true.

There is then a third question: may this workload reconcile this account for this amount at this time? The signature does not answer it. A fourth question follows: did the application commit the requested state transition? An HTTP response alone may not answer that either.

The dangerous shortcut is to collapse all four questions into one Boolean named authenticated. Revision 07 of WIMSE Workload-to-Workload Authentication with HTTP Signatures is useful precisely because its mechanics expose where that shortcut fails.

The draft was submitted on 20 September 2026. Its header says that Standards Track is the intended status and that it expires on 24 March 2027. It is an active IETF working-group Internet-Draft, not an RFC, a requirement on deployed systems or evidence that a named product implements the design. Its implementation appendix records work in progress, not an adoption census.

What is actually signed

WIMSE profiles RFC 9421 rather than inventing a new signature container. A request must cover the derived components @method, @path and @query. If present, Content-Type, Content-Digest, Authorization, Txn-Token and Workload-Identity-Token must also be covered. A request with content must carry Content-Digest, and the receiver must recompute it over the bytes it received.

That last step matters. Signing the characters of a digest field without checking the body would prove only that the sender signed a digest string. RFC 9530 gives the digest field its content semantics; WIMSE requires the receiver to connect that field back to the received content. The receipt is therefore not “a signature existed” but “the receiver reconstructed the named components, recomputed the digest where required and verified the result.”

The signature metadata also carries created, a short expires, a random nonce and the tag wimse-workload-to-workload. A request adds wimse-aud. The profile forbids the ordinary HTTP Message Signatures keyid and alg parameters: the Workload Identity Token’s cnf.jwk supplies the verification key and algorithm. The receiver still has to reject an algorithm that local policy does not accept for the peer’s trust domain.

More than one signature with the WIMSE tag is not optional redundancy. The recipient must reject the message. Otherwise a verifier could silently choose the signature that its policy happens to like while the sender, proxy and application disagree about which representation carried authority.

These rules make the signature receipt specific. They do not make it unlimited. An omitted header remains outside the cryptographic claim. A proxy signature creates a second principal and a second covered representation; it does not enlarge the first signer’s coverage retroactively.

Why the host is not in the mandatory component set

The draft deliberately omits @authority. TLS-terminating proxies and load balancers commonly rewrite the HTTP authority component, so demanding its end-to-end preservation would make the profile incompatible with much of the architecture it is meant to traverse.

Recipient binding instead appears in the signed wimse-aud parameter. This is not a cosmetic substitution. The authority component describes the HTTP routing form seen at one hop. The WIMSE audience expresses the workload recipient the sender intended. A deployment must define how that audience is constructed, compared and forwarded through intermediaries.

This separates two receipts that are often blended. RFC 9525-style service-identity verification helps a TLS client decide whether it reached the server identity it expected for the channel. The WIMSE signature helps a receiver authenticate the selected HTTP components and workload key across permitted intermediary behavior. TLS termination, hostname verification, audience comparison and request-signature verification are connected controls, not synonyms.

A reverse proxy can therefore terminate a valid TLS connection and forward a valid signed request while still sending it to an application that interprets the audience too broadly. Conversely, a strict audience policy can reject a request even though the transport and signature are sound. The evidence should preserve both decisions.

The key proves possession, not permission

The WIT is validated before the HTTP signature. The signature is then checked with the public key and algorithm bound in cnf.jwk. Successful validation supports a bounded claim: a holder of the associated private key formed the covered representation while the relevant token and signature conditions held.

It does not reveal why the key holder requested the operation. It does not prove that the key remained inside the workload instance named in an inventory. It does not establish that no stale replica or compromised runtime also held the key. Most importantly, it does not grant the operation.

Revision 07 says the entire authorization subsystem is out of scope and trusted as a prerequisite. That sentence should govern deployment architecture. Authentication ends with an identified workload principal and an authenticated request representation. Authorization begins when the first component capable of the effect compares that principal, action, resource, context and policy.

The authorization receipt should name the policy version, matched rule, obligations, exception path and decision time. “Signature valid” cannot substitute for those fields. If a gateway automatically maps every valid signature from a trust domain to a broad role, then the gateway—not the signature standard—has created the authority. Its configuration and change history become the decisive evidence.

Replay is a topology question

Freshness metadata does not enforce itself. created and expires bound the interval in which the signature may be accepted. A nonce distinguishes one signed request from another. The sender must generate a random value. The recipient may maintain a replay cache and should reject a nonce it has already seen.

Revision 07 also states that replay caches need not be shared across validators. Its security goals do not strictly mandate replay protection, because synchronizing those caches in a distributed service is difficult. That is an honest engineering boundary, not a footnote to erase.

A cache miss therefore means only that this cache retained no matching nonce under its own scope and retention policy. It does not prove that another node did not accept the request, that an earlier entry did not expire, that a failover region did not lose state, or that the application has not already committed the same business operation under another request identifier.

The trade-off can be rational. A globally synchronous replay store might add latency, reduce availability and create a central failure surface. A local cache might be appropriate for an idempotent read. It is much harder to defend for an irreversible debit, certificate issuance or destructive control action unless the application has a second idempotency boundary.

The production receipt must therefore record validator identity, nonce-cache scope, retention interval, signature-expiry policy and application idempotency key. Without those facts, a dashboard that says “replay protection enabled” conceals the topology that determines what protection actually means.

A signed response exists only on the demanded branch

The response path contains an equally important distinction. Servers are encouraged to sign responses. A client that requires a signed response places wimse-sign-response=true inside the signed request metadata. The server must not turn an inability to sign into an ordinary successful unsigned response, and the client must reject an unsigned response when it made that demand.

Every signed response includes wimse-req-nonce, echoing the request nonce inside the signed response parameters. That binds the covered response representation to the request rather than merely proving that the server signed some response within a similar time window.

But server policy alone does not create the same guarantee. If the client did not request a signature, it has no reliable signal that the server intended to sign. A middlebox can strip the signature and leave an ordinary unsigned response that the client must accept. The draft’s deletion resistance exists only when the client’s signed request required the signed response.

Operational language should preserve the branch: “the server signs responses” describes capability or policy; “the client required and verified a response signature bound to this request nonce” describes a transaction. The second is a receipt. The first is a configuration assertion.

Even that receipt is not the business outcome. It authenticates the covered response components. It does not prove that an asynchronous job finished, a downstream transaction survived, a compensating action was unnecessary or the client used the result.

Middleboxes can preserve a signature and alter the operation around it

HTTP infrastructure transforms messages. It terminates channels, normalizes fields, routes by headers, appends tracing data, decodes content and sometimes re-signs. WIMSE’s mandatory set is designed to preserve critical request semantics through expected transformations, but the protection is only as complete as the selected component set and the application’s interpretation.

An unsigned field can be modified or removed. A signed field cannot be changed without invalidating the signature, but a proxy may reject, reconstruct or re-sign the message under a different principal. Each transition changes who asserts what. A useful trace carries the inbound signature result, transformation policy, outbound signature identity, covered-component differences and the authorization decision made after the last trusted transformation.

This is why the effect point matters. If the edge gateway authorizes “POST on /jobs” but the backend interprets an unsigned routing header as the tenant or target, the cryptographic boundary stops before the consequential parameter. If the backend authorizes the fully resolved operation, the gateway signature remains valuable authentication evidence without being mistaken for final permission.

The design question is not whether every byte should be frozen. HTTP systems need transformation. The question is which components determine the operation, which actor may transform them and where the final authorized representation becomes immutable enough to execute.

The six receipts of a workload call

A defensible WIMSE transaction record is a chain rather than one green check:

  1. Credential receipt: WIT issuer, token validity interval, subject claims, audience rules and cnf.jwk fingerprint.
  2. Signature receipt: reconstructed component list, signature metadata, accepted algorithm, content-digest recomputation and verification result.
  3. Replay receipt: nonce, validator identity, cache scope, retention rule and duplicate decision.
  4. Authorization receipt: resolved workload principal, exact action and resource, policy version, allow or deny result and obligations.
  5. Execution receipt: application idempotency key, state transition, commit identifier, failure or rollback.
  6. Outcome receipt: the independently observed service or business consequence, including later compensation or reversal.

The receipts can disagree without contradiction. A valid credential can carry a bad signature. A valid signature can be a replay. A novel request can be unauthorized. An allowed operation can fail to commit. A successful commit can produce the wrong external outcome. Good engineering preserves the disagreement because that is where responsibility becomes legible.

This is also the minimum-authority reading of the protocol. Shared cryptographic machinery should establish deterministic facts that independent systems can validate. It should not acquire the power to decide local operation policy merely because the same deployment team configured both layers.

Running code is the evidence boundary

The draft names early implementations, including a proof of concept and an alpha implementation. That is evidence that authors and implementers have exercised parts of the design. It is not evidence of production prevalence, default behavior, shared replay-cache semantics or a successful authorization integration.

An operator evaluating a product should ask for a captured request, reconstructed signature base, WIT validation result, nonce-cache topology, authorization log and application commit record. A conformance statement without those artifacts is evidence of claimed capability. A demonstration with one validator says little about a multi-node replay path. A benchmark says little about policy correctness.

The Internet-Draft may change. A procurement or architecture decision should pin the revision and record every local deviation. Later adoption is real when running systems implement, validate and voluntarily depend on the behavior—not when a document, slide or support matrix declares it complete.

Sources