Summary

  • draft-reddy-wimse-aggregate-signatures-01 lets a destination verify which workloads signed a delegation chain and whether each changed the message; an aggregate additionally prevents silent removal of a signer that forwarded unchanged.
  • Only the aggregate signature stays close to one signature's size. Each hop still adds a Workload Identity Token, a Signature-Input entry, path and query values, and input/output continuity evidence.
  • A valid chain attributes participation and transformations. It does not say that every expected workload was present, that a signed change was authorized or correct, or that the requested action completed.

One short value, many indispensable records

Imagine a request passing from an initiating agent to an orchestrator, then through a gateway to a destination. Each workload handles a different representation. The orchestrator may turn a broad task into a precise request. The gateway may forward the body unchanged while changing the route. The destination sees only the last HTTP message unless the chain carries its history.

Revision 01 of Authenticated Provenance for WIMSE Delegation Chains proposes that history in two layers. Every hop signs what it received and what it sends. Its input body digest is carried in wimse-req-digest; its output is represented by Content-Digest. Its WIT supplies the subject and public key. Its Signature-Input entry retains the parameters and covered components required to rebuild that hop's signature base. A running Signature-Aggregate combines the individual signature values.

The last item is compact. The rest is not optional decoration. The destination verifies the aggregate against a set of public-key-and-message pairs. It therefore needs each public key and each message representation. A signature without those inputs is not a self-explaining audit file.

Section 10 states the size boundary plainly: the aggregate stays close to one signature's size regardless of chain length, while Signature-Input, Workload-Identity-Tokens and the digests grow with the chain. The protocol compresses signature values. It does not compress the facts that make those signatures meaningful.

Why digests do not preserve an unchanged hop

The draft's most useful distinction appears when one workload changes nothing.

Suppose H1 sends body digest A. H2 receives A and forwards A. H3 receives A, transforms the body and sends B. If the record consists of individual signatures plus adjacent input and output digests, an attacker can remove H2. H1 still ends at A; H3 still begins at A. Continuity survives, and H1's and H3's individual signatures can remain valid. The pass-through workload disappears from the story precisely because it left the body unchanged.

Aggregation closes that gap. H2's signature contribution is folded into the running value, while H2's individual signature is never placed on the wire. Presenting a chain that names only H1 and H3 changes the set against which the aggregate must verify. The attacker would need to remove H2's contribution, but does not possess the separate value needed to do that. Verification fails.

This is the aggregate's specific added value. Digests expose a missing transformation. The aggregate exposes a missing signer even when the bytes on either side match.

It does not expose a workload that never signed. An intermediary can forward the message unchanged without joining the chain, and the existing aggregate still verifies. A destination also cannot infer that some expected service was bypassed merely from the participants presented. If a risk policy requires a particular classifier, approval service or jurisdictional gateway, that requirement must exist outside the cryptography and be evaluated against the proven participant set.

Rebuilding the messages the aggregate authenticates

An earlier hop did not necessarily sign the final path or query. Later workloads may rewrite both. Revision 01 therefore retains wimse-req-path and wimse-req-query inside each hop's signed parameters. The destination uses those preserved values, not the final URI, to reconstruct the earlier signature base.

The earlier output digest has another dependency. For hop H1, the destination obtains what H1 sent from H2's signed input digest. For the last hop, it uses the final Content-Digest. The evidence record is therefore relational: one hop's outgoing statement is joined to its successor's incoming statement.

Every hop also contributes a WIT under a unique label in Workload-Identity-Tokens. The corresponding Signature-Input entry covers that dictionary member. A later hop must preserve earlier entries rather than overwrite them. The WIT supplies the subject, algorithm and public key, but it still has to be validated under workload-credential and local trust policy.

Remove one WIT, reuse a label, lose an earlier path, drop a query, discard a neighboring digest or serialize the covered values differently, and the compact aggregate may become impossible to verify. The aggregate can be intact while the retained evidence package is operationally incomplete.

This is why Daniel Kade's minimum useful receipt has more than a signature field. It needs an ordered signer/message set; exact aggregate bytes; each validated WIT and key; each preserved Signature-Input; each input and output digest; the route values required for reconstruction; the algorithm and validation policy; and the verification result. The format can vary. The reconstruction invariant cannot.

Attribution is not approval

Revision 01 is unusually direct about this boundary. Message digests provide attributability, not correctness. A workload can change content maliciously or mistakenly and still sign a coherent before-and-after record. The record helps investigators identify which workload made the transformation. It does not decide whether that transformation was permitted.

The same separation applies at the ends of the chain. An intermediary can discard an old aggregate and sign as the initiator of a new chain. The cryptography identifies the new initiator; authorization policy decides whether that workload may originate the request. A destination that has no such policy cannot recover the missing authority decision from the signature.

Five questions therefore require five receipts:

  1. Who participated, and were their WITs valid under the relevant trust policy?
  2. What exact representations did they receive and forward?
  3. Does the aggregate verify over that ordered set?
  4. Were those participants and transformations allowed for this action?
  5. Did the application commit the action, and was the intended external result observed?

A green answer to the third question is not a shortcut through the fourth and fifth.

Whole-chain assurance creates whole-chain failure

Aggregation verifies the chain as a unit. That makes an interior contribution non-strippable, but also changes diagnosis. A single bad signature causes the aggregate to fail, and the aggregate alone does not identify the faulty hop. A corrupt record, expired credential, incompatible algorithm or malicious signer can deny service to the entire chain.

Operators should separate admission from fault isolation. The destination may correctly reject the request when the aggregate fails. Incident responders may still need hop-local logs, prefix-validation receipts or controlled replay to locate the problem. Calling the aggregate an audit trail without planning that diagnostic path mistakes tamper evidence for blame assignment.

Algorithm agility has a similar boundary. Each WIT records the algorithm a hop used. Local policy decides whether that algorithm is acceptable. Revision 01 says BLS message augmentation can instantiate the design, while leaving the WIT algorithm identifier to a separate specification. It also says BLS is not post-quantum secure. An identifier that verifies mathematically is not evidence that the organization accepted its security properties.

All hops in one aggregate must use the same aggregate-capable scheme. Without one, the chain can fall back to individual signatures. The digest lineage can still reveal removal of a workload that changed the body, but it cannot preserve an unchanged signer against removal in the same way. That loss of property should be recorded, not hidden behind a generic “signature valid” status.

Provenance also discloses the path

The evidence package reveals more than cryptographic state. Every WIT identifies a workload. Each audience can reveal the next recipient. The digest sequence reveals where transformations happened. Sharing the proof can therefore disclose service topology and processing history across organizational boundaries.

Retention policy should answer who may see the participant chain, how long credentials and route evidence remain available, and whether an auditor can verify without receiving unrestricted message content. Compactness does not remove those governance costs. In some environments, the evidence envelope may be more sensitive than the aggregate itself.

The reality-layer test

Heng Lu's reality-layer doctrine offers a practical reading. A workload identity, its public key, one signed HTTP representation, a transformation lineage, an aggregate verification result, an authorization decision, an application commit and an observed business effect are related records. They are not synonyms.

Running-code primacy points to the actual control surface: the code that preserves structured fields, rebuilds earlier signature bases, validates every WIT and joins neighboring digests. A diagram showing one elegant aggregate cannot compensate for a parser that loses an old query or a retention system that stores only the final header.

Minimum initial specification does not mean carrying every internal log. It means agreeing on the smallest complete evidence set another authorized verifier needs. For this design, that set grows with the delegation chain because the number of assertions grows with the chain. The signature can remain small while reality refuses to be compressed.

Sources and limits

The evidence was frozen on 30 September 2026 Asia/Shanghai. Revision 01 is an active individual Internet-Draft, not an RFC, IETF consensus, adoption report or deployed standard. It may change, be replaced or expire. The source packet provides no measured overhead, interoperable implementation, live attack, production saving, conformance result or observed loss. The evidence-size formula in the fact packet is Daniel Kade's explanatory model, not a benchmark.