Summary

  • A 28 September individual Internet-Draft proposes authenticated provenance for requests and responses moving through WIMSE workload chains. It is not a Working Group standard or an RFC.
  • Per-hop input and output digests can reveal removal of an intermediary that changed a message. An intermediary that forwards it unchanged leaves neighboring digests aligned.
  • The proposed aggregate signature is intended to make that unchanged signer non-removable, while authorization, exact order among consecutive unchanged hops, and final application outcomes remain separate questions.

Imagine three workloads in a request path. The middle one signs and passes the request on without changing its body. If an observer later removes that middle entry from a list of individual signatures, the first workload's output digest and the last workload's input digest can still match. A tidy lineage is therefore not necessarily a complete account of who handled the request.

That is the concrete problem in the 28 September revision of Authenticated Provenance for WIMSE Delegation Chains. The Datatracker labels draft-reddy-wimse-aggregate-signatures-01 an active individual Internet-Draft, with no RFC stream and an IESG state of I-D Exists. Its “Standards Track” intention is printed in draft boilerplate; it is not an IETF decision. The aggregate-signature idea appeared in revision -00 on 8 September. Revision -01 develops the distinction between a change record and a participation record, rather than inventing aggregation overnight.

The baseline WIMSE HTTP Message Signatures work binds a workload identity to a message for the immediate recipient. That protects one exchange; it is not an end-to-end roster of every workload in a longer delegation. The new individual proposal asks every signing hop to record what it received and forwarded, including body digests and the path and query treatment. If a hop changes the body, removing its record breaks the join between its neighbors. A downstream verifier can also look for where a transformation occurred, without pretending the digest reveals why it occurred or whether the transformed content is true.

The silent forwarder is different. Appendix A gives a three-hop example in which the middle hop's input and output are the same. Remove that hop's independently carried signature and the remaining digest chain still fits. The proposed Signature-Aggregate combines per-hop signatures in a running value while keeping the separate signatures off the wire. Under the draft's stated cryptographic assumptions, presenting the aggregate with a signer omitted should fail verification. That is a claim about a proposed mechanism, not a measurement from a deployed system.

The proposal has costs and limits that matter as much as its cleverness. The aggregate signature value can remain roughly the size of one signature, but workload tokens, signature inputs and lineage digests still grow with chain length. Hops need a compatible aggregate-capable algorithm; the draft says ML-DSA has no aggregate form and that a per-hop fallback does not protect an unchanged forwarder against removal. An invalid contribution makes the whole aggregate fail without identifying which hop spoiled it. The text's lineage authenticates the order of message-changing hops, not, by itself, the order of consecutive unchanged forwarders.

The proposed HTTP field and signature parameters are IANA requests in a draft, not established registrations.

Most important, the draft expressly leaves authorization outside scope. A cryptographic showing that a workload signed says nothing by itself about whether it was permitted to see a task, alter it or invoke a tool. Nor does a verified participant set prove that a downstream application accepted an action. Those judgments require separate policy and result evidence at the party that acts.

Sources