Authenticated Provenance for WIMSE Delegation Chains
draft-reddy-wimse-aggregate-signatures-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Hannes Tschofenig , Yaron Sheffer | ||
| Last updated | 2026-09-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reddy-wimse-aggregate-signatures-01
Workload Identity in Multi System Environments T. Reddy
Internet-Draft Nokia
Intended status: Standards Track H. Tschofenig
Expires: 1 April 2027 UniBw M.
Y. Sheffer
Intuit
28 September 2026
Authenticated Provenance for WIMSE Delegation Chains
draft-reddy-wimse-aggregate-signatures-01
Abstract
A request and its response, passing through a chain of workloads, may
need authenticated provenance: proof of which workloads participated
and whether each changed the message. The base WIMSE HTTP Message
Signatures mechanism ([I-D.ietf-wimse-http-signature]) authenticates
one workload's message to its immediate recipient and does not
provide this across a chain. This document establishes authenticated
provenance using per-hop digests of what each hop received and
forwarded; this alone detects an omitted hop that changed the
message. An aggregate signature closes the remaining gap, a hop that
forwards the message unchanged, and keeps the signature close to the
size of one signature regardless of chain length. The mechanism
works with any aggregate signature scheme.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-reddy-wimse-aggregate-
signatures/.
Discussion of this document takes place on the Workload Identity in
Multi System Environments Working Group mailing list
(mailto:wimse@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at
https://www.ietf.org/mailman/listinfo/wimse/.
Source for this draft and an issue tracker can be found at
https://github.com/tireddy2/WIMSE-aggregate-signature.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Reddy, et al. Expires 1 April 2027 [Page 1]
Internet-Draft WIMSE Chain Provenance September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Delegation in Agentic Systems . . . . . . . . . . . . . . . . 5
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Relationship to Distributed Tracing . . . . . . . . . . . 6
3. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
4. How Aggregate Signatures Work . . . . . . . . . . . . . . . . 7
5. Chain Integrity via Aggregate Signatures . . . . . . . . . . 8
5.1. Carrying Per-Hop Credentials . . . . . . . . . . . . . . 9
5.2. Preserving Per-Hop Covered-Component Values . . . . . . . 9
5.3. Non-Removability of Interior Signatures . . . . . . . . . 10
5.4. Anchoring the End Signatures . . . . . . . . . . . . . . 10
6. Request Lineage . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Response . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 17
10. Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . 18
Reddy, et al. Expires 1 April 2027 [Page 2]
Internet-Draft WIMSE Chain Provenance September 2026
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13.1. HTTP Signature Metadata Parameters . . . . . . . . . . . 19
13.1.1. wimse-req-digest . . . . . . . . . . . . . . . . . . 20
13.1.2. wimse-req-path . . . . . . . . . . . . . . . . . . . 20
13.1.3. wimse-req-query . . . . . . . . . . . . . . . . . . 20
13.1.4. wimse-resp-digest . . . . . . . . . . . . . . . . . 20
13.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. What the Aggregate Adds Over Per-Hop Digests . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The WIMSE architecture ([I-D.ietf-wimse-arch]) authenticates a
workload with a Workload Identity Token (WIT)
([I-D.ietf-wimse-workload-creds]), a credential that identifies the
workload. On its own a WIT is a bearer credential: any party that
obtains it could present it as its own.
The WIMSE HTTP Message Signatures mechanism
([I-D.ietf-wimse-http-signature]) binds the WIT to a specific HTTP
message. The sending workload signs the message with the key bound
to its WIT. This proves the sender holds the WIT's key, and it
protects the message from modification in transit, including by
intermediaries that terminate TLS.
A request may pass through several workloads before reaching its
destination, forming a delegation chain.
[I-D.ietf-wimse-http-signature] authenticates one workload's message
to its immediate recipient and requires a single signature per
message; it does not define a mechanism for preserving provenance
across a sequence of distinct workload-to-workload exchanges. This
is by design, not a shortcoming: the base protocol was not scoped to
provide it.
This document defines that additional property: authenticated
provenance across a delegation chain, meaning the ability for a
downstream party to verify which workloads participated in the chain
and whether each one changed the message. Because every hop's
signature remains verifiable at the destination, an alteration by a
later hop is also detected: if the initiator signed a POST and a hop
forwards it as a DELETE, the initiator's signature no longer
verifies.
Reddy, et al. Expires 1 April 2027 [Page 3]
Internet-Draft WIMSE Chain Provenance September 2026
The base WIMSE HTTP Message Signatures mechanism
([I-D.ietf-wimse-http-signature]) authenticates a workload to its
immediate peer. It gives no mechanism for the destination to learn
the full set of workloads that participated in a delegation chain,
for either the request or the response. When an agent delegates a
sub-task through several other agents or tools, nothing lets a later
party reconstruct who was actually involved, a gap that matters most
in agentic systems (Section 2), where the path is dynamic and chosen
at runtime.
A party receiving a delegated request or response may need to know,
for each participating workload, whether it forwarded the message
unchanged or modified it. This document proves that per workload,
using the aggregate signature (Section 5) and the lineage digests
(Section 6) together. A party that separately knows a workload's
expected role can use this proof to detect misbehavior: for example,
a gateway that is expected only to forward can be shown to have
modified the message instead. What a workload is allowed to do is a
separate question, addressed by authorization policy and out of scope
(Section 2.2); this document only proves what a workload actually
did.
A misbehaving workload can act in one of two ways: it can omit itself
from the chain undetected, or it can tamper with the message, for
example an agent that hallucinates and forwards a sub-task built on
fabricated information. This mechanism supports audit and forensics:
it narrows the search by identifying which workload made a change and
fingerprinting what changed, so an auditor knows which workload's own
logs to consult for the actual transformation. Without this record,
finding that workload requires tracing the chain manually, and for
one omitted silently, may not be possible at all.
This document defines two mechanisms. First, each hop's WIMSE
signature covers, in addition to what [I-D.ietf-wimse-http-signature]
requires, lineage digests of the message body the hop received and
forwarded, and the path and query it sent (Section 6). This detects
removal of a hop that changed the message body, and identifies which
hop changed the body, path or query, with individual signatures.
Second, an aggregate signature, used in place of individual
signatures, additionally prevents removal of a hop that forwarded the
message unchanged (Section 5, Appendix A), and keeps the signature
size constant regardless of chain length, which matters for large PQC
signatures once PQC aggregate schemes mature (Section 9).
Reddy, et al. Expires 1 April 2027 [Page 4]
Internet-Draft WIMSE Chain Provenance September 2026
2. Delegation in Agentic Systems
An AI agent is a workload and is authenticated by a WIT like any
other workload. Agentic systems are a primary motivation for this
document because they produce delegation chains with two properties
that make the need for authenticated provenance described in
Section 1 especially important.
The path is dynamic. An agent decides at processing time which
downstream agent to delegate a sub-task to, so the chain is not fixed
by configuration and is not known to the destination in advance. The
destination therefore cannot check the chain against an expected
path; it can only rely on what the chain itself proves. This is why
silent removal of a hop must be detectable from the signatures alone.
The request is transformed at each hop. Unlike a forwarding proxy,
an agent changes the content it passes on: the sub-task given to a
downstream agent differs from the task the agent received. Each
transformation must be cryptographically attributable to the agent
that performed it.
2.1. Goals
For a delegation chain, this document provides evidence, carried on
the message and verified by the party acting on it, for three uses:
In-band attack detection: Detecting attacks on the chain from the
message itself, at the next workload or the destination, without
relying on out-of-band records.
Observability: A signed record of which workloads participated and
whether each changed the message.
Policy enforcement: Input to decisions that depend on the multi-hop
behavior of the task, not only on the last hop. For example, a
destination can reject a request that passed through a workload
not permitted to handle the task, or whose content was modified by
a workload expected only to forward it.
The mechanism provides the following security properties:
* Originator authentication: the initiator is identified by its WIT,
and the chain traces back to it.
* Removal detection: a workload that signed cannot be removed from
the chain, including one that forwarded the message unchanged
(Section 5).
Reddy, et al. Expires 1 April 2027 [Page 5]
Internet-Draft WIMSE Chain Provenance September 2026
* Modification detection: a change made by a party that did not sign
is detected (Section 6). A change made by a signing workload to
@method or content-type, for example a POST forwarded as a DELETE,
is also detected, because the earlier workloads' signatures no
longer verify (Section 5.2).
* Change attribution: a change made by a signing workload is
recorded as that workload's change (Section 6).
* Non-repudiation: a workload cannot deny what it received or sent,
because it signed both.
* Response binding: each response is bound to the request it answers
(Section 7).
2.2. Scope
Authorization is out of scope and is being addressed in the OAuth WG.
2.3. Relationship to Distributed Tracing
Distributed tracing ([W3C-TRACE-CONTEXT]) also records which
workloads handled a request or response. The record is unsigned: a
workload can alter what it reports or leave itself out. It is also
collected out-of-band: per-workload logs must be gathered and
correlated across workloads, which is slow and expensive, and a
receiving party must wait on, or trust, that trace. This document
instead carries verifiable evidence on the message itself, so the
receiving party can act on it directly. A workload cannot later deny
what it received or sent, because it signed both.
3. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terms from [I-D.ietf-wimse-arch],
[I-D.ietf-wimse-workload-creds], and [I-D.ietf-wimse-http-signature].
Aggregation is used as defined in [I-D.irtf-cfrg-bls-signature]:
given a list of signatures for a list of messages and public keys, an
aggregation algorithm produces one signature that authenticates the
same list of messages and public keys. This document additionally
uses:
Authenticated Provenance: Signed evidence of which workloads
Reddy, et al. Expires 1 April 2027 [Page 6]
Internet-Draft WIMSE Chain Provenance September 2026
participated in a delegation chain and whether each changed the
message.
Hop: A workload that signs the message as it passes along the chain.
Delegation Chain: The sequence of hops that sign the message, from
the initiator (H_1) to the last hop (H_N). This document
authenticates which hops participated and the message lineage
between them (Section 6). The lineage also authenticates the
order of hops that change the message, but not of consecutive hops
that forward it unchanged. A workload may issue several requests
to fulfill a delegated task. A request that delegates the task,
or part of it, to another workload continues the chain. A request
the workload issues on its own behalf, for example to retrieve
data from a tool, is not part of the chain; the workload acts as
the initiator of a new chain and can use this mechanism for it.
Initiator: The first hop (H_1), which originates the message.
Destination: The party (H_{N+1}) that receives the message from the
last hop and verifies the chain.
4. How Aggregate Signatures Work
An aggregate signature scheme combines several signatures, each
produced by a different signer over a different message, into a
single value. A verifier checks that one value against the whole set
of signer public keys and messages (Figure 1). The values are:
* k_i: the public key of hop i, obtained from its WIT.
* m_i: the signature base ([RFC9421] Section 2.5) for hop i, built
per the WIMSE profile ([I-D.ietf-wimse-http-signature]) from hop
i's Signature-Input entry. This is the input to HTTP_SIGN and
HTTP_VERIFY ([RFC9421] Section 3.3).
* s_i: the signature of hop i over m_i.
* S: the aggregate of s_1 to s_N.
Reddy, et al. Expires 1 April 2027 [Page 7]
Internet-Draft WIMSE Chain Provenance September 2026
H1: sign(m1) --> s1 --.
|
H2: sign(m2) --> s2 --+--> aggregate --> S
|
H3: sign(m3) --> s3 --'
Verify: S against { (k1,m1), (k2,m2), (k3,m3) } in a single operation
* one value S proves all of H1, H2, H3 signed
* to drop Hk from S, the attacker must subtract sk but sk is never
placed on the wire, so it cannot be removed
Figure 1: Aggregating per-hop signatures into a single value
Combining requires no secret: any party can fold a further signature
into the running value S. Removing a contribution is different. To
remove hop k from S, a party needs s_k, the individual signature of
hop k. In a chain where only the running aggregate is forwarded, an
interior hop's individual signature is never placed on the wire, so
an upstream hop cannot be removed. The algorithm that produces and
combines the signatures is not fixed by this document; it is carried
in each hop's WIT. Because signatures can be aggregated only within
a single scheme, all hops in the chain will have to use the same
algorithm (see Section 9).
5. Chain Integrity via Aggregate Signatures
Each hop signs its message as profiled in
[I-D.ietf-wimse-http-signature], additionally covering the lineage
parameters of Section 6. The hops' signatures are combined into a
single aggregate signature carried in a new HTTP field, Signature-
Aggregate. Like the Signature field of [RFC9421], its value is a
Byte Sequence and is therefore base64-encoded ([RFC9651]). The
presence of Signature-Aggregate signals aggregate mode: a hop that
receives it folds its signature into the running aggregate rather
than adding an independent Signature, and the destination verifies
the single value against all Signature-Input entries. Each hop's
Signature-Input entry is retained, so the verifier has, for each hop,
the covered components and, via the hop's WIT, the public key needed
to verify the aggregate.
When Signature-Aggregate is present, the Signature field MUST NOT be
present, overriding the requirement in [RFC9421] Section 4 that
Signature-Input and Signature contain the same labels. A verifier
that supports this specification verifies Signature-Aggregate once,
against the full set of (public key, message) pairs derived from
Signature-Input.
Reddy, et al. Expires 1 April 2027 [Page 8]
Internet-Draft WIMSE Chain Provenance September 2026
Each hop tags its Signature-Input entry "wimse-delegation-chain"
rather than "wimse-workload-to-workload". The rule in
[I-D.ietf-wimse-http-signature] Section 3 that a recipient reject a
message carrying more than one signature tagged "wimse-workload-to-
workload" is scoped to that tag and does not apply.
5.1. Carrying Per-Hop Credentials
In a delegation chain, each hop's WIT is carried as a member of
Workload-Identity-Tokens, a Dictionary Structured Field ([RFC9651]),
keyed by the hop's Signature-Input label. A hop's Signature-Input
entry covers "workload-identity-tokens";key="<label>", its own WIT.
The label MUST be the same in both fields: it selects the hop's WIT,
the WIT's sub claim identifies the hop, and the WIT's cnf.jwk gives
the hop's public key.
A hop MUST choose a label that is not already present in Workload-
Identity-Tokens, so that adding its own WIT does not overwrite an
earlier hop's member.
On receiving a message, a hop keeps every existing entry in Workload-
Identity-Tokens unchanged. It checks each earlier hop's signature
using the key from that hop's WIT, then adds its own WIT under its
own label.
A hop MUST NOT replace or remove an existing member of Workload-
Identity-Tokens. Doing so changes the covered value for that label's
Signature-Input entry, so the affected hop's signature fails to
verify.
5.2. Preserving Per-Hop Covered-Component Values
@path and @query take their values from the message a hop sends,
which later hops overwrite. Each hop additionally covers wimse-req-
path and wimse-req-query, String parameters holding its own @path and
@query values. Each hop carries these in its own Signature-Input
entry, where they persist for later hops, so the verifier
reconstructs an earlier hop's signature base from them rather than
from the final message.
[I-D.ietf-wimse-http-signature] requires @query to be covered even
when the request has no query component, in which case its value is
"?" ([RFC9421] Section 2.2.7). wimse-req-query carries that value
unchanged.
@method and content-type need no parameter: a workload MUST NOT
change either, so the received values verify every workload, and any
change is caught as a failed signature.
Reddy, et al. Expires 1 April 2027 [Page 9]
Internet-Draft WIMSE Chain Provenance September 2026
A hop's content-digest value is what the next hop records in its
wimse-req-digest (Section 6), so the verifier reads it from the next
hop's Signature-Input entry when rebuilding that hop's signature
base. The last hop has no successor, so its value is the Content-
Digest of the final message.
5.3. Non-Removability of Interior Signatures
As the message travels, each hop adds its signature to a running
aggregate. A hop forwards only this combined value. The individual
signatures that went into it are not sent.
Security against removal of an individual contribution relies on the
unforgeability of the selected aggregate signature scheme. To make a
verifier accept a chain with one hop removed, an attacker needs the
aggregate for the remaining hops. Producing that value means
subtracting the removed hop's individual signature from the
aggregate. That signature was never sent, so the attacker cannot do
this.
The verifier checks the aggregate against the set of hops presented
with it. A chain with a hop removed does not verify. Removal is
therefore detected, and verification is all-or-nothing: the whole
chain verifies, or it fails.
5.4. Anchoring the End Signatures
The previous subsection shows that an interior hop cannot be removed.
This leaves the two ends of the chain.
Removing the last hop's signature removes that hop's own
authentication. The last hop is the party presenting the request, so
this defeats its own purpose.
Discarding the aggregate and signing a new one makes the attacker the
initiator of a new chain. The initiator is identified by its WIT.
Whether a workload is allowed to originate a request is an
authorization decision, which is out of scope (Section 2.2); this
mechanism only binds the initiator's identity to the chain through
its WIT. A destination that accepts requests only from permitted
initiators will reject a chain re-originated by an intermediary.
If an intermediary forwards the request unchanged without adding its
signature, the chain passes through intact and still verifies;
nothing is lost. If it modifies the request without signing, the
last hop's signature no longer matches the modified request and the
change is detected.
Reddy, et al. Expires 1 April 2027 [Page 10]
Internet-Draft WIMSE Chain Provenance September 2026
6. Request Lineage
In an agentic system the request is modified as it travels. Some
changes are legitimate: an orchestrator or gateway rewrites the
request before passing it on. Some are not: a forwarding proxy is
meant to pass the request through unchanged, so if it alters the
request, that is an attack.
This section lets a verifier tell these apart, and serves two
purposes:
* Detect an unauthorized modifier. A change made by a party that
did not sign is rejected.
* Provide an audit trail. A change made by a signing hop is
allowed, but recorded and attributable to that hop.
The difference between the two is simply whether a signing hop made
the change.
6.1. Mechanism
Each hop records two digests, both covered by its signature:
* The digest of the message body it received (its input).
* The digest of the message body it forwards (its output). This is
the Content-Digest ([RFC9530]) already required by
[I-D.ietf-wimse-http-signature] when a body is present.
Content-Digest covers only the message body, not the method, target
URI, or headers; those are separately covered by each hop's own
signature, via its covered components. The lineage mechanism
establishes continuity of the body across hops, not of the request or
response as a whole.
The input digest is carried in a new signature parameter, wimse-req-
digest, so it is covered by the signature like any other parameter.
Its value is a String ([RFC9651]) holding the serialized Content-
Digest field value as the hop received it, for example wimse-req-
digest="sha-256=:d1a...=:", or the reserved value "origin" for the
initiator.
Each hop signs as required by [I-D.ietf-wimse-http-signature], and
additionally covers wimse-req-digest on requests and wimse-resp-
digest on responses (Section 7). Content-Digest records only what a
hop sends, so each hop must state separately what it received.
Reddy, et al. Expires 1 April 2027 [Page 11]
Internet-Draft WIMSE Chain Provenance September 2026
The verifier walks the chain and verifies that each hop's output
digest matches the next hop's input digest. A mismatch indicates
that the body was modified between the two hops. If the modification
is reflected in the signed input and output digests recorded by a
hop, it is a legitimate transformation attributable to that hop.
Otherwise, the modification is unauthorized, and the request is
rejected.
The signed lineage record is tamper-evident and provides a verifiable
audit trail for body transformations.
6.2. Initiator
The initiator has no predecessor, so it has no input digest. Its
wimse-req-digest carries the reserved String value "origin", which
identifies the start of the request lineage. The initiator is
identified by its WIT; whether it is allowed to originate the request
is an authorization decision and is out of scope (Section 2.2).
7. Responses
The response path is handled the same as the request path (Section 5,
Section 6), in reverse. The responses are aggregated, and each hop
records the response it received and the response it forwards. An
orchestrator that combines responses from several workloads into one
verifies each, then conveys back the combined response: it sets
wimse-resp-digest to "origin". The responses it received remain
signed by the workloads that sent them, so an audit of the
orchestrator can establish which workloads contributed.
The response takes the same path as the request, in reverse: from the
destination back through each hop to the initiator. Each hop,
including the initiator, holds the context for the request it made
and needs the corresponding response to continue its own task; a
workload that did not make a request has no context to act on a
response to it.
The differences are the parameter name and the direction: each hop
carries the digest of the message content it received in wimse-resp-
digest, and continuity is verified from the destination back to the
initiator. wimse-resp-digest takes the same form as wimse-req-digest
(Section 6): a String holding the serialized value of the Content-
Digest field as the hop received it.
A response signature covers @path;req and @query;req, taking their
values from the request it answers. A hop verifying the whole chain
has only its own request, not the requests other hops sent, so it
cannot resolve those components for those hops' signatures. Each hop
Reddy, et al. Expires 1 April 2027 [Page 12]
Internet-Draft WIMSE Chain Provenance September 2026
therefore covers wimse-req-path and wimse-req-query instead, holding
the path and query of the request it answers. @method;req needs no
parameter: the method does not change across hops (Section 5.2).
The response originator has no predecessor on the response path and
therefore no received response. It MUST set wimse-resp-digest to the
reserved value "origin", which identifies the start of the response
lineage. Verifiers MUST treat this value as indicating that the
response originated at the destination hop.
8. Message Flow
This section shows the request path for a three-hop chain: an
initiator H1, a transforming hop H2, and a pass-through hop H3 that
forwards the request unchanged to the destination. The request path
is shown first, then one response (Section 8.1). Signature,
aggregate, and digest values are truncated. Within the field values,
line breaks preceded by a backslash are inserted for readability only
and are not part of the field. This example follows
[I-D.ietf-wimse-http-signature].
H1 originates the request. It has no predecessor, so its wimse-req-
digest is "origin". Workload-Identity-Tokens has one member, h1,
covered by H1's own Signature-Input entry via key="h1".
POST /task?job=42 HTTP/1.1
Host: h2.example
Content-Type: application/json
Content-Digest: sha-256=:d1a...=:
Workload-Identity-Tokens: h1="eyJhbGciOiJFUzI1NiIs...h1wit...jw"
Signature-Input: h1=("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h1");created=1710000000;\
expires=1710000060;nonce="a1b2...";tag="wimse-delegation-chain";\
wimse-aud="h2.example";wimse-req-digest="origin";\
wimse-req-path="/task";wimse-req-query="?job=42"
Signature-Aggregate: :QoM1...=:
{"task": "..."}
Figure 2: Request sent by the initiator H1
H2 verifies H1's signature using the key from h1's WIT, transforms
the request, and forwards it. H2 keeps H1's entry in Workload-
Identity-Tokens unchanged and adds its own under h2. H2's wimse-req-
digest equals H1's Content-Digest, continuing the lineage. H2 folds
its signature into the aggregate, which now covers both hops.
Reddy, et al. Expires 1 April 2027 [Page 13]
Internet-Draft WIMSE Chain Provenance September 2026
POST /run HTTP/1.1
Host: h3.example
Content-Type: application/json
Content-Digest: sha-256=:9f3...=:
Workload-Identity-Tokens: h1="eyJhbGciOiJFUzI1NiIs...h1wit...jw", \
h2="eyJhbGciOiJFUzI1NiIs...h2wit...jw"
Signature-Input: h1=("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h1");created=1710000000;\
expires=1710000060;nonce="a1b2...";tag="wimse-delegation-chain";\
wimse-aud="h2.example";wimse-req-digest="origin";\
wimse-req-path="/task";wimse-req-query="?job=42", \
h2=("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h2");created=1710000005;\
expires=1710000065;nonce="c3d4...";tag="wimse-delegation-chain";\
wimse-aud="h3.example";wimse-req-digest="sha-256=:d1a...=:";\
wimse-req-path="/run";wimse-req-query="?"
Signature-Aggregate: :7Zx9...=:
{"task": "...transformed..."}
Figure 3: Request forwarded by H2, aggregate now covering H1 and H2
H3 forwards the request to the destination unchanged. H3's wimse-
req-digest equals H2's Content-Digest, and H3's own Content-Digest is
identical to H2's, since nothing was transformed. H3 keeps H1's and
H2's entries in Workload-Identity-Tokens unchanged and adds its own
under h3.
Reddy, et al. Expires 1 April 2027 [Page 14]
Internet-Draft WIMSE Chain Provenance September 2026
POST /finish HTTP/1.1
Host: dest.example
Content-Type: application/json
Content-Digest: sha-256=:9f3...=:
Workload-Identity-Tokens: h1="eyJhbGciOiJFUzI1NiIs...h1wit...jw", \
h2="eyJhbGciOiJFUzI1NiIs...h2wit...jw", \
h3="eyJhbGciOiJFUzI1NiIs...h3wit...jw"
Signature-Input: h1=("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h1");created=1710000000;\
expires=1710000060;nonce="a1b2...";tag="wimse-delegation-chain";\
wimse-aud="h2.example";wimse-req-digest="origin";\
wimse-req-path="/task";wimse-req-query="?job=42", \
h2=(...);wimse-req-digest="sha-256=:d1a...=:";\
wimse-req-path="/run";wimse-req-query="?", \
h3=("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h3");created=1710000010;\
expires=1710000070;nonce="e5f6...";tag="wimse-delegation-chain";\
wimse-aud="dest.example";wimse-req-digest="sha-256=:9f3...=:";\
wimse-req-path="/finish";wimse-req-query="?"
Signature-Aggregate: :Rw2p...=:
{"task": "...transformed..."}
Figure 4: Request forwarded by H3 unchanged, aggregate now
covering H1, H2, and H3
The destination validates each WIT in Workload-Identity-Tokens, takes
each hop's public key from its WIT's cnf.jwk, and reconstructs each
hop's signature base (using wimse-req-path and wimse-req-query for
@path and @query, and the next hop's wimse-req-digest for content-
digest), then verifies Signature-Aggregate against all three (public
key, message) pairs in a single operation. It also checks the digest
chain: H2's wimse-req-digest records what H1 sent, H3's wimse-req-
digest records what H2 sent, and the final Content-Digest is what H3
sent. Because H3 forwarded unchanged, its recorded input equals the
final Content-Digest, so the digest chain alone cannot show whether
H3 participated; only the aggregate does.
Figure 5 shows the signature base the destination builds for H1, the
hop whose values are furthest from the final message.
Reddy, et al. Expires 1 April 2027 [Page 15]
Internet-Draft WIMSE Chain Provenance September 2026
"@method": POST
"@path": /task
"@query": ?job=42
"content-type": application/json
"content-digest": sha-256=:d1a...=:
"workload-identity-tokens";key="h1": \
"eyJhbGciOiJFUzI1NiIs...h1wit...jw"
"@signature-params": ("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h1");created=1710000000;\
expires=1710000060;nonce="a1b2...";tag="wimse-delegation-chain";\
wimse-aud="h2.example";wimse-req-digest="origin";\
wimse-req-path="/task";wimse-req-query="?job=42"
Figure 5: Signature base reconstructed for H1
Each line has one of three sources. @path, @query and @signature-
params come from h1's own Signature-Input entry. content-digest comes
from h2's wimse-req-digest, since it records what H1 sent. @method
and content-type come from the final message, because neither changes
across hops.
8.1. Response
The destination responds to H3. It originates the response, so its
wimse-resp-digest is "origin". wimse-req-nonce carries the nonce of
H3's request, binding this response to it, and wimse-req-path and
wimse-req-query carry the path and query of that request in place of
@path;req and @query;req (Section 7).
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:5c7...=:
Workload-Identity-Tokens: d="eyJhbGciOiJFUzI1NiIs...dwit...jw"
Signature-Input: d=("@status" "@method";req "content-type" \
"content-digest" "workload-identity-tokens";key="d");created=1710000015;\
expires=1710000075;nonce="g7h8...";tag="wimse-delegation-chain";\
wimse-req-nonce="e5f6...";wimse-resp-digest="origin";\
wimse-req-path="/finish";wimse-req-query="?"
Signature-Aggregate: :Lk4t...=:
{"result": "..."}
Figure 6: Response sent by the destination to H3
Figure 7 shows the signature base H1 builds for the destination's
response, after the response has travelled back through H3 and H2.
Reddy, et al. Expires 1 April 2027 [Page 16]
Internet-Draft WIMSE Chain Provenance September 2026
"@status": 200
"@method";req: POST
"content-type": application/json
"content-digest": sha-256=:5c7...=:
"workload-identity-tokens";key="d": \
"eyJhbGciOiJFUzI1NiIs...dwit...jw"
"@signature-params": ("@status" "@method";req "content-type" \
"content-digest" "workload-identity-tokens";key="d");created=1710000015;\
expires=1710000075;nonce="g7h8...";tag="wimse-delegation-chain";\
wimse-req-nonce="e5f6...";wimse-resp-digest="origin";\
wimse-req-path="/finish";wimse-req-query="?"
Figure 7: Signature base reconstructed for the destination's response
content-digest comes from H3's wimse-resp-digest, which records the
response H3 received. @method;req and content-type come from the
final response. Everything else comes from the destination's own
entry, including wimse-req-nonce, which identifies H3's request as
the one answered. @path;req and @query;req do not appear: the wimse-
req-path and wimse-req-query parameters in the signature-params line
carry those values instead (Section 7).
Each hop on the way back adds its own entry the same way, setting
wimse-resp-digest to the digest of the response it received and
folding its signature into the aggregate.
9. Algorithm Agility
This document does not depend on any particular aggregate signature
algorithm. The signature algorithm is carried in each hop's WIT
(cnf.jwk.alg), as in [I-D.ietf-wimse-http-signature], and all hops in
a chain use the same algorithm. The mechanism can be instantiated
with any aggregate signature scheme that remains secure when signers'
keys are generated independently and resists rogue-key attacks,
consistent with [RFC7696].
Algorithm agility does not mean a verifier accepts whatever algorithm
a hop presents. Each verifier applies a policy of acceptable
algorithms and rejects a hop whose algorithm falls outside it, even
if the signature verifies. The algorithm in the WIT records what a
hop used; the policy decides what is acceptable. Without such a
policy, agility becomes a downgrade path.
At the time of writing, the mechanism can be instantiated with the
BLS message-augmentation scheme ([I-D.irtf-cfrg-bls-signature]
Section 3.2). Its algorithm identifier for use in a WIT will be
defined in a separate specification.
Reddy, et al. Expires 1 April 2027 [Page 17]
Internet-Draft WIMSE Chain Provenance September 2026
BLS is not post-quantum secure. Post-quantum aggregation is an
active area of research, including work on aggregating Falcon
signatures ([FALCON-LABRADOR]), and any such scheme can be used when
it matures, without changing this protocol.
Without an aggregate-capable algorithm, for example in a post-quantum
deployment (ML-DSA does not aggregate), a chain falls back to
individual per-hop post-quantum signatures. Integrity then rests on
the per-hop request and response digests, each hop recording what it
received and what it forwarded: they catch removal of a hop that
changed the request or response, but not one that did not, which is
what the aggregate protects.
10. Trade-offs
Aggregation verifies the chain as a whole. This is what makes it
non-strippable (Section 5), but it also means a single bad signature
makes the whole chain fail to verify, and the verifier cannot tell
which hop was at fault. A faulty hop can therefore deny service to
the chain.
The benefit is that the aggregate stays close to one signature's size
regardless of chain length. Signature-Input, Workload-Identity-
Tokens, and the digests still grow with the chain.
11. Security Considerations
Chain integrity relies on the non-removability of the aggregate
(Section 5) and on the initiator being identified by its WIT: an
attacker can neither remove an interior hop nor re-originate the
chain as a permitted initiator. Because each hop verifies the chain
it received before forwarding it, tampering is detected at the next
honest hop, not only at the destination.
The message digests of Section 6 provide attributability, not
correctness. They record which hop changed the message from a given
input to a given output, and reject a change no hop signed for, but
they do not judge whether a change was legitimate. A hop can change
content maliciously and still produce a valid record; the change is
attributable to that hop.
Reddy, et al. Expires 1 April 2027 [Page 18]
Internet-Draft WIMSE Chain Provenance September 2026
The algorithm each hop uses is carried in its WIT, so a verifier
learns what was used but not what should have been used. Because the
path is dynamic, the expected algorithm for a given hop is not known
in advance and cannot be checked after the fact. An attacker able to
forge signature using a traditional algorithm could present a hop
signed with that algorithm in place of a post-quantum one, and the
chain would verify. Once a traditional algorithm is broken this
cannot be detected; it is prevented only by policy. A post-quantum
deployment excludes traditional algorithms from the acceptable set.
A chain is only as strong as the weakest algorithm in it, whether the
hops sign individually or their signatures are aggregated. A single
hop signing with a broken or traditional algorithm lets an attacker
substitute that hop's contribution. With individual signatures, the
hops must use algorithms of comparable strength, though not
necessarily the same algorithm: two post-quantum algorithms of equal
strength are acceptable. Aggregation adds a further constraint,
because signatures combine only within one algorithm: every hop uses
the same algorithm.
These protections apply to the response only if the response is
signed along the chain (Section 7). If it is not, a response can be
dropped or altered without detection.
The mechanism proves which hops signed, not that every expected hop
was included. A hop can deliver or forward the message without
involving a further hop; because the path is dynamic, the destination
does not know which hops to expect, so such a bypass cannot be
detected. A destination can require a particular workload to be
present as policy (Section 2.1); without such a policy, the omission
is not detectable.
12. Privacy Considerations
Each hop presents its WIT, so any party that verifies the chain
learns which workloads participated, and the digest lineage reveals
where the message was changed. Each workload's wimse-aud names the
workload it sent to, which can reveal the sequence of hops.
13. IANA Considerations
13.1. HTTP Signature Metadata Parameters
IANA is requested to register the following entries in the "HTTP
Signature Metadata Parameters" registry, per the registration
template in Section 6.3.1 of [RFC9421].
Reddy, et al. Expires 1 April 2027 [Page 19]
Internet-Draft WIMSE Chain Provenance September 2026
13.1.1. wimse-req-digest
* Name: wimse-req-digest
* Description: String; in request signatures, the serialized
Content-Digest field value of the message content as received by
the signing hop, or "origin" for the initiator.
* Reference: RFC XXXX, Section 6.
13.1.2. wimse-req-path
* Name: wimse-req-path
* Description: String; in request and response signatures, the @path
value of the request the signing hop sent.
* Reference: RFC XXXX, Section 5.2, Section 7.
13.1.3. wimse-req-query
* Name: wimse-req-query
* Description: String; in request and response signatures, the
@query value of the request the signing hop sent.
* Reference: RFC XXXX, Section 5.2, Section 7.
13.1.4. wimse-resp-digest
* Name: wimse-resp-digest
* Description: String; in response signatures, the serialized
Content-Digest field value of the message content as received by
the signing hop, or "origin" for the response originator.
* Reference: RFC XXXX, Section 7.
13.2. HTTP Fields
IANA is requested to register the following in the "Hypertext
Transfer Protocol (HTTP) Field Name" registry:
* Field Name: Signature-Aggregate
* Status: permanent
* Structured Type: Item
Reddy, et al. Expires 1 April 2027 [Page 20]
Internet-Draft WIMSE Chain Provenance September 2026
* Reference: RFC XXXX, Section 5
* Field Name: Workload-Identity-Tokens
* Status: permanent
* Structured Type: Dictionary
* Reference: RFC XXXX, Section 5.1
14. References
14.1. Normative References
[I-D.ietf-wimse-http-signature]
Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload
Authentication with HTTP Signatures", Work in Progress,
Internet-Draft, draft-ietf-wimse-http-signature-07, 20
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-wimse-http-signature-07>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J. A., Schwenkschuster, A.,
Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
Credentials", Work in Progress, Internet-Draft, draft-
ietf-wimse-workload-creds-02, 2 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[I-D.irtf-cfrg-bls-signature]
Boneh, D., Bradley, J., Gorbunov, S., Wahby, R. S., Wee,
H., Wood, C. A., and Z. Zhang, "BLS Signatures", Work in
Progress, Internet-Draft, draft-irtf-cfrg-bls-signature-
07, 6 July 2026, <https://datatracker.ietf.org/doc/html/
draft-irtf-cfrg-bls-signature-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/rfc/rfc7696>.
Reddy, et al. Expires 1 April 2027 [Page 21]
Internet-Draft WIMSE Chain Provenance September 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/rfc/rfc9651>.
14.2. Informative References
[FALCON-LABRADOR]
Aardal, M. A., Aranha, D. F., Boudgoust, K., Kolby, S.,
and A. Takahashi, "Aggregating Falcon Signatures with
LaBRADOR", CRYPTO 2024, IACR ePrint 2024/311, 2024,
<https://eprint.iacr.org/2024/311>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[W3C-TRACE-CONTEXT]
W3C, "Trace Context", W3C Recommendation, 2021,
<https://www.w3.org/TR/trace-context/>.
Appendix A. What the Aggregate Adds Over Per-Hop Digests
The message digests (Section 6) already detect removal of a hop that
changed the message: with that hop gone, the recorded input and
output digests of the remaining hops no longer line up. The
aggregate adds one thing on top. It also detects removal of a hop
that signed but did not change the message, for example a gateway
that forwards the body unchanged. The examples below use a three-hop
chain H1, H2, H3 in which H2 forwards the request unchanged.
As in Figure 1, m_i is the message hop i signs, s_i is its signature,
and k_i is its public key, taken from its WIT.
Reddy, et al. Expires 1 April 2027 [Page 22]
Internet-Draft WIMSE Chain Provenance September 2026
With individual signatures and the digests, the pass-through hop can
be stripped, because removing it keeps the digests aligned:
H1 Content-Digest=A req-digest=origin
H2 Content-Digest=A req-digest=A (forwards unchanged)
H3 Content-Digest=B req-digest=A
Attacker strips H2 and presents H1 -> H3:
H3.req-digest=A equals H1.Content-Digest=A, continuity holds
s1 and s3 still verify on their own
=> accepted; H2 is erased
With the aggregate, the same removal fails, because H2's signature
cannot be taken out of the combined value:
Aggregate S = s1 + s2 + s3
Attacker strips H2 and claims the chain is H1 -> H3:
it needs s1 + s3 = S - s2
but s2 was never on the wire, so it cannot form it
=> rejected
Aggregation is also smaller: individual signatures grow with the
length of the chain, while an aggregate is a single signature
regardless of length.
Acknowledgments
This document builds on the WIMSE Workload Credentials and HTTP
Signature drafts.
Authors' Addresses
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Hannes Tschofenig
University of the Bundeswehr Munich
Neubiberg
Germany
Email: hannes.tschofenig@gmx.net
Yaron Sheffer
Intuit
Reddy, et al. Expires 1 April 2027 [Page 23]
Internet-Draft WIMSE Chain Provenance September 2026
Email: yaronf.ietf@gmail.com
Reddy, et al. Expires 1 April 2027 [Page 24]