Aggregate Signatures for WIMSE Delegation-Chain Integrity
draft-reddy-wimse-aggregate-signatures-00

Workload Identity in Multi System Environments                  T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                           H. Tschofenig
Expires: 12 March 2027                                          UniBw M.
                                                        8 September 2026

       Aggregate Signatures for WIMSE Delegation-Chain Integrity
               draft-reddy-wimse-aggregate-signatures-00

Abstract

   This document profiles the WIMSE HTTP Message Signatures mechanism
   ([I-D.ietf-wimse-http-signature]) to protect a request that passes
   through a chain of workloads.  In the base mechanism each workload
   signs independently: an intermediary can remove a signature
   undetected, and the signatures accumulate on every hop.  This
   document combines the workloads' signatures into one aggregate
   signature.  Removal of a signature becomes detectable, and the
   signature material no longer grows with the length of the chain, a
   significant saving for post-quantum signature algorithms, whose
   signatures are large.  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 & Tschofenig        Expires 12 March 2027                 [Page 1]
Internet-Draft       Aggregate Signatures for WIMSE       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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Delegation in Agentic Systems . . . . . . . . . . . . . . . .   4
     2.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology and Conventions . . . . . . . . . . . . . . . . .   5
   4.  How Aggregate Signatures Work . . . . . . . . . . . . . . . .   5
   5.  Chain Integrity via Aggregate Signatures  . . . . . . . . . .   6
     5.1.  Non-Removability of Interior Signatures . . . . . . . . .   6
     5.2.  Anchoring the End Signatures  . . . . . . . . . . . . . .   7
   6.  Request Lineage . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Initiator . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Responses . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Message Flow  . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Algorithm Agility . . . . . . . . . . . . . . . . . . . . . .  11
   10. Trade-offs  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     13.1.  HTTP Signature Metadata Parameters . . . . . . . . . . .  13

Reddy & Tschofenig        Expires 12 March 2027                 [Page 2]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

       13.1.1.  wimse-req-digest . . . . . . . . . . . . . . . . . .  13
       13.1.2.  wimse-resp-digest  . . . . . . . . . . . . . . . . .  13
     13.2.  HTTP Fields  . . . . . . . . . . . . . . . . . . . . . .  14
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     14.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  What the Aggregate Adds Over Per-Hop Digests . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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

Reddy & Tschofenig        Expires 12 March 2027                 [Page 3]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

   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.

2.1.  Scope

   This document addresses workload identity and message integrity for
   delegation chains.  Authorization is out of scope.  Scoped delegation
   and transferable authorization credentials are a separate problem,
   addressed by other mechanisms discussed in OAUTH WG.

2.2.  Goals

   For a delegation chain, this document aims to:

   *  preserve the identity of the originating workload across all hops;

   *  let a receiving party verify that the chain traces back to the
      originator; and

   *  produce a signed, attributable record of each hop's transformation
      of the request.

Reddy & Tschofenig        Expires 12 March 2027                 [Page 4]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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.

Reddy & Tschofenig        Expires 12 March 2027                 [Page 5]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

     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

        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 ([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.

5.1.  Non-Removability of Interior Signatures

   As the request 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.

Reddy & Tschofenig        Expires 12 March 2027                 [Page 6]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

   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.2.  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.1); 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.

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.

Reddy & Tschofenig        Expires 12 March 2027                 [Page 7]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

   *  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 request it received (its input).

   *  The digest of the request it forwards (its output).  This is the
      Content-Digest ([RFC9530]) already required by
      [I-D.ietf-wimse-http-signature] when a body is present.

   The input digest is carried in a new signature parameter, wimse-req-
   digest, so it is covered by the signature like any other parameter.
   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 alone is not enough:
   it records only what a hop sends, not what it received, so on its own
   it cannot show that one hop's output is the next hop's input.

   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 request 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 request/response transformations.

6.2.  Initiator

   The initiator has no predecessor, so it has no input digest.  Its
   wimse-req-digest carries the reserved 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.1).

Reddy & Tschofenig        Expires 12 March 2027                 [Page 8]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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.

Reddy & Tschofenig        Expires 12 March 2027                 [Page 9]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

   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": "..."}

                 Figure 2: Request sent by the initiator H1

   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..."}

    Figure 3: Request forwarded by H2, aggregate now covering H1 and H2

   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.

Reddy & Tschofenig        Expires 12 March 2027                [Page 10]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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.

Reddy & Tschofenig        Expires 12 March 2027                [Page 11]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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.

Reddy & Tschofenig        Expires 12 March 2027                [Page 12]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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

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

13.1.1.  wimse-req-digest

   *  Name: wimse-req-digest

   *  Description: on request signatures, the digest of the request as
      received by the signing hop (its input digest), used to establish
      request transformation lineage across a delegation chain.  A
      distinguished origin value indicates the initiator.

   *  Reference: RFC XXXX, Section 6.

13.1.2.  wimse-resp-digest

   *  Name: wimse-resp-digest

   *  Description: on response signatures, the digest of the response as
      received by the signing hop from downstream (its response input
      digest), used to establish response transformation lineage across
      a delegation chain.  A distinguished origin value indicates the
      initiator of the response.

   *  Reference: RFC XXXX, Section 7.

Reddy & Tschofenig        Expires 12 March 2027                [Page 13]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

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

   *  Reference: RFC XXXX, Section 5

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-06, 4
              August 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-wimse-http-signature-06>.

   [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 & Tschofenig        Expires 12 March 2027                [Page 14]
Internet-Draft       Aggregate Signatures for WIMSE       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>.

   [RFC8941]  Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8941>.

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

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

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:

Reddy & Tschofenig        Expires 12 March 2027                [Page 15]
Internet-Draft       Aggregate Signatures for WIMSE       September 2026

     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@unibw.de

Reddy & Tschofenig        Expires 12 March 2027                [Page 16]