Aggregate Signatures for WIMSE Delegation-Chain Integrity

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 12 March 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

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. This forms a chain, and each workload in the chain signs the message. The destination needs assurance about the whole chain, not only the last workload it received the message from.¶

In the base mechanism each workload signs independently. This creates two problems in a chain.¶

First, the signatures can be stripped. A workload on the path can delete another workload's signature, and the shorter chain still verifies. The destination cannot tell that a workload was removed.¶

Second, the signatures accumulate. Every hop adds a full signature, so the total size grows with the length of the chain. This becomes particularly problematic with post-quantum signatures, which are large, often several kilobytes. A chain of even a few workloads then carries tens of kilobytes of signatures, which can exceed HTTP header size limits.¶

This document addresses both problems in two layers. First, each hop records a digest of the request it received and the request it forwards (Section 6), giving a verifiable record of how the request was transformed. This alone detects removal of any hop that changed the request, because the recorded digests no longer line up. Second, the hops' signatures are combined into a single aggregate signature (Section 5). The aggregate detects removal of a hop even when it did not change the request, and keeps the signature material close to the size of one signature regardless of the length of the chain. The mechanism works with any aggregate signature scheme, including post-quantum schemes as they mature.¶

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 highlight the problems described in Section 1.¶

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.¶

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:¶

Hop:

A workload that signs the request as it passes along the chain.¶

Delegation Chain:

The ordered sequence of hops that sign the request, from the initiator (H_1) to the last hop (H_N).¶

Initiator:

The first hop (H_1), which originates the request.¶

Destination:

The party (H_{N+1}) that receives the request 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 message signed by hop i. It consists of the request components and parameters listed in that hop's Signature-Input ([RFC9421]), including the WIMSE parameters ([I-D.ietf-wimse-http-signature]). The signature algorithm hashes m_i when producing the signature.¶

• s_i: the signature of hop i over m_i.¶

• S: the aggregate of s_1 to s_N.¶

  H1: sign(m1) --> s1 --.
                        |
  H2: sign(m2) --> s2 --+--> aggregate --> S
                        |
  H3: sign(m3) --> s3 --'

  Verify once:  S  against  { (k1,m1), (k2,m2), (k3,m3) }

  * 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

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 ([RFC8941]). 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.¶

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.¶

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 several responses into one is a transforming hop like any other.¶

The response takes the same path as the request, in reverse: from the destination back through each hop to the initiator. This is inherent to how the chain is connected: each hop has a link only to its neighbors, and each link is protected by TLS, so an intermediary cannot respond to the initiator directly, and the response returns hop by hop.¶

The differences are the parameter name and the direction: each hop carries the digest of the response it received in wimse-resp-digest, and continuity is verified from the destination back to the initiator.¶

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 two-hop chain: an initiator H1 sends a request to a hop H2, which transforms it and forwards it. Only the request is shown. 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.¶

H1 originates the request. It has no predecessor, so its wimse-req-digest carries the origin value. The aggregate contains only H1's signature so far.¶

POST /task HTTP/1.1
Host: h2.example
Content-Type: application/json
Content-Digest: sha-256=:d1a...=:
Workload-Identity-Token: eyJ0eXAiOi...
Signature-Input: h1=("@method" "@target-uri" "content-digest" \
    "workload-identity-token");created=1710000000;expires=1710000060;\
    nonce="a1b2...";tag="wimse";wimse-aud="h2.example";\
    wimse-req-digest=:AAAA...=:
Signature-Aggregate: :QoM1...=:

{"task": "..."}

H2 verifies H1's signature, transforms the request (so its Content-Digest changes), and forwards it. H2's wimse-req-digest is the digest of the request it received from H1, which equals H1's Content-Digest. H2 folds its signature into the aggregate, which now covers both hops.¶

POST /run HTTP/1.1
Host: h3.example
Content-Type: application/json
Content-Digest: sha-256=:9f3...=:
Workload-Identity-Token: eyJ0eXAiOi...
Signature-Input: h1=("@method" "@target-uri" "content-digest" \
    "workload-identity-token");created=1710000000;expires=1710000060;\
    nonce="a1b2...";tag="wimse";wimse-aud="h2.example";\
    wimse-req-digest=:AAAA...=:, \
  h2=("@method" "@target-uri" "content-digest" \
    "workload-identity-token");created=1710000005;expires=1710000065;\
    nonce="c3d4...";tag="wimse";wimse-aud="h3.example";\
    wimse-req-digest=:d1a...=:
Signature-Aggregate: :7Zx9...=:

{"task": "...transformed..."}

Note that H2's wimse-req-digest (:d1a...=:) equals H1's Content-Digest in the first message: this is the continuity link that ties the two hops together.¶

The destination verifies the single Signature-Aggregate value against both Signature-Input entries and their WIT keys, and checks that H2's wimse-req-digest equals H1's Content-Digest.¶

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. Any algorithm that aggregates signatures over distinct messages under distinct keys can be used, 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 BLS, specified in the BLS Signatures document ([I-D.irtf-cfrg-bls-signature]); its algorithm identifier for use in a WIT will be defined in a separate specification.¶

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 chain carries a single aggregate value instead of every hop's signature, so its size does not grow with the length of the chain. Individual signatures carry every hop's signature; only aggregation avoids this. The saving is largest for long chains and for post-quantum signatures, whose signatures are large.¶

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 request digests of Section 6 provide attributability, not correctness. They record which hop changed the request 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.¶

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 request 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. Requiring a particular hop to be present is a matter of authorization and is out of scope.¶

12. Privacy Considerations

Every hop presents its WIT, which identifies the workload, so the complete set of workloads in a chain, and the order in which they signed, is visible to the destination and to every party on the path. The request digests further reveal that the request was transformed at each hop and link each hop's input to its output. Together these expose the structure of a delegation: which workloads participated, in what order, and where the request changed.¶

This exposure is inherent to the mechanism. Chain integrity requires each hop to be identified by its WIT, so the participating identities cannot be hidden while still verifying the chain. A deployment can limit only what each WIT reveals about its workload; however, the delegation chain itself, including the participating workloads, their order, and the authenticated request transformations must remain visible to any party that verifies the chain.¶

13. IANA Considerations

14. References

Appendix A. What the Aggregate Adds Over Per-Hop Digests

The request digests (Section 6) already detect removal of a hop that changed the request: 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 request, 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.¶

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