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="