From 2d3af57923001b84ed38bbd57bc00a24563dfb31 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Fri, 6 Mar 2026 19:20:38 +0100 Subject: [PATCH] Restructure repo: single source file with git tags for versioning Drop versioned directories and archive/ in favor of git tags (draft-00, draft-01) for frozen submissions. Rename source to draft-nennemann-wimse-ect.md (version comes from docname in front matter). Update build.sh to extract docname automatically. Ignore generated outputs. Co-Authored-By: Claude Opus 4.6 --- .gitignore | 4 + build.sh | 25 +- draft-nennemann-wimse-ect-00.html | 2910 ----------------- draft-nennemann-wimse-ect-00.md | 926 ------ draft-nennemann-wimse-ect-00.txt | 1288 -------- draft-nennemann-wimse-ect-00.xml | 1690 ---------- ...-ect-01.md => draft-nennemann-wimse-ect.md | 0 master-prompt.md | 1186 ------- 8 files changed, 25 insertions(+), 8004 deletions(-) delete mode 100644 draft-nennemann-wimse-ect-00.html delete mode 100644 draft-nennemann-wimse-ect-00.md delete mode 100644 draft-nennemann-wimse-ect-00.txt delete mode 100644 draft-nennemann-wimse-ect-00.xml rename draft-nennemann-wimse-ect-01.md => draft-nennemann-wimse-ect.md (100%) delete mode 100644 master-prompt.md diff --git a/.gitignore b/.gitignore index 6d13810..e6e6de4 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,5 @@ .refcache/ +# Generated build outputs (XML, TXT, HTML) +draft-nennemann-wimse-ect-*.xml +draft-nennemann-wimse-ect-*.txt +draft-nennemann-wimse-ect-*.html diff --git a/build.sh b/build.sh index acc93af..adeb389 100755 --- a/build.sh +++ b/build.sh @@ -1,22 +1,39 @@ #!/bin/bash set -e -DRAFT="draft-nennemann-wimse-ect-01" DIR="$(cd "$(dirname "$0")" && pwd)" +SRC="$DIR/draft-nennemann-wimse-ect.md" + +# Extract docname from YAML front matter +DRAFT=$(grep '^docname:' "$SRC" | head -1 | awk '{print $2}') +if [ -z "$DRAFT" ]; then + echo "Error: could not extract docname from $SRC" + exit 1 +fi # Tool paths -KRAMDOWN="/usr/local/lib/ruby/gems/3.4.0/bin/kramdown-rfc2629" -XML2RFC="/Users/christian/Library/Python/3.9/bin/xml2rfc" +KRAMDOWN="$(which kramdown-rfc2629 2>/dev/null)" +XML2RFC="$(which xml2rfc 2>/dev/null)" + +if [ -z "$KRAMDOWN" ]; then + echo "Error: kramdown-rfc2629 not found. Install with: gem install kramdown-rfc2629" + exit 1 +fi +if [ -z "$XML2RFC" ]; then + echo "Error: xml2rfc not found. Install with: pip install xml2rfc" + exit 1 +fi export PYTHONWARNINGS="ignore::UserWarning" +echo "Building: $DRAFT" echo "Using kramdown-rfc2629: $KRAMDOWN" echo "Using xml2rfc: $XML2RFC" echo "" # Step 1: Markdown -> XML echo "Converting markdown to XML..." -"$KRAMDOWN" "$DIR/$DRAFT.md" > "$DIR/$DRAFT.xml" +"$KRAMDOWN" "$SRC" > "$DIR/$DRAFT.xml" # Step 2: XML -> TXT echo "Generating text output..." diff --git a/draft-nennemann-wimse-ect-00.html b/draft-nennemann-wimse-ect-00.html deleted file mode 100644 index c1d91ac..0000000 --- a/draft-nennemann-wimse-ect-00.html +++ /dev/null @@ -1,2910 +0,0 @@ - - - - - - -Execution Context Tokens for Distributed Agentic Workflows - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftWIMSE Execution ContextFebruary 2026
NennemannExpires 29 August 2026[Page]
-
-
-
-
Workgroup:
-
WIMSE
-
Internet-Draft:
-
draft-nennemann-wimse-ect-00
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Author:
-
-
-
C. Nennemann
-
Independent Researcher
-
-
-
-
-

Execution Context Tokens for Distributed Agentic Workflows

-
-

Abstract

-

This document defines Execution Context Tokens (ECTs), a JWT-based -extension to the WIMSE architecture that records task execution -across distributed agentic workflows. Each ECT is a signed record -of a single task, linked to predecessor tasks through a directed -acyclic graph (DAG). ECTs reuse the WIMSE signing model and are -transported in a new Execution-Context HTTP header field alongside -existing WIMSE identity headers.

-
-
-
-

-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 29 August 2026.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

The WIMSE framework [I-D.ietf-wimse-arch] and its service-to- -service protocol [I-D.ietf-wimse-s2s-protocol] authenticate -workloads across call chains but do not record what those -workloads actually did. This document defines Execution Context -Tokens (ECTs), a JWT-based extension that fills the gap between -workload identity and execution accountability. Each ECT is a -signed record of a single task, linked to predecessor tasks -through a directed acyclic graph (DAG).

-
-
-

-1.1. Scope and Applicability -

-

This document defines:

-
    -
  • -

    The Execution Context Token (ECT) format (Section 3)

    -
    • -
  • -

    DAG structure for task dependency ordering (Section 5)

    -
    • -
  • -

    An HTTP header for ECT transport (Section 4)

    -
    • -
  • -

    Audit ledger interface requirements (Section 7)

    -
    • -
-

The following are out of scope and are handled by WIMSE:

-
    -
  • -

    Workload authentication and identity provisioning

    -
    • -
  • -

    Key distribution and management

    -
    • -
  • -

    Trust domain establishment and management

    -
    • -
  • -

    Credential lifecycle management

    -
    • -
-
-
-
-
-
-
-

-2. Conventions and Definitions -

-

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.

-

The following terms are used in this document:

-
-
Agent:
-
-

An autonomous workload, as defined by WIMSE -[I-D.ietf-wimse-arch], that executes tasks within a workflow.

-
-
-
Task:
-
-

A discrete unit of agent work that consumes inputs and produces -outputs.

-
-
-
Directed Acyclic Graph (DAG):
-
-

A graph structure representing task dependency ordering where -edges are directed and no cycles exist.

-
-
-
Execution Context Token (ECT):
-
-

A JSON Web Token [RFC7519] defined by this specification that -records task execution details.

-
-
-
Audit Ledger:
-
-

An append-only, immutable log of all ECTs within a workflow or -set of workflows, used for audit and verification.

-
-
-
Workload Identity Token (WIT):
-
-

A WIMSE credential proving a workload's identity within a trust -domain.

-
-
-
Workload Proof Token (WPT):
-
-

A WIMSE proof-of-possession token used for request-level -authentication.

-
-
-
Trust Domain:
-
-

A WIMSE concept representing an organizational boundary with a -shared identity issuer, corresponding to a SPIFFE [SPIFFE] -trust domain.

-
-
-
-
-
-
-
-

-3. Execution Context Token Format -

-

An Execution Context Token is a JSON Web Token (JWT) [RFC7519] -signed as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use -JWS Compact Serialization (the base64url-encoded -header.payload.signature format) so that they can be carried in -a single HTTP header value.

-

ECTs reuse the WIMSE signing model. The ECT MUST be signed with -the same private key associated with the agent's WIT. The JOSE -header "kid" parameter MUST reference the public key identifier -from the agent's WIT, and the "alg" parameter MUST match the -algorithm used in the corresponding WIT. In WIMSE deployments, -the ECT "iss" claim SHOULD use the WIMSE workload identifier -format (a SPIFFE ID [SPIFFE]).

-
-
-

-3.1. JOSE Header -

-

The ECT JOSE header MUST contain the following parameters:

-
-
-
-
-{
-  "alg": "ES256",
-  "typ": "wimse-exec+jwt",
-  "kid": "agent-a-key-id-123"
-}
-
-
-
Figure 1: -ECT JOSE Header Example -
-
-
-
alg:
-
-

REQUIRED. The digital signature algorithm used to sign the ECT. -MUST match the algorithm in the corresponding WIT. -Implementations MUST support ES256 [RFC7518]. The "alg" -value MUST NOT be "none". Symmetric algorithms (e.g., HS256, -HS384, HS512) MUST NOT be used, as ECTs require asymmetric -signatures for non-repudiation.

-
-
-
typ:
-
-

REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs -from other JWT types, consistent with the WIMSE convention for -type parameter values.

-
-
-
kid:
-
-

REQUIRED. The key identifier referencing the public key from -the agent's WIT [RFC7517]. Used by verifiers to look up the -correct public key for signature verification.

-
-
-
-
-
-
-
-

-3.2. JWT Claims -

-
-
-

-3.2.1. Standard JWT Claims -

-

An ECT MUST contain the following standard JWT claims [RFC7519]:

-
-
iss:
-
-

REQUIRED. StringOrURI. A URI identifying the issuer of the -ECT. In WIMSE deployments, this SHOULD be the workload's -SPIFFE ID in the format spiffe://<trust-domain>/<path>, -matching the "sub" claim of the agent's WIT. Non-WIMSE -deployments MAY use other URI schemes (e.g., HTTPS URLs or -URN:UUID identifiers).

-
-
-
aud:
-
-

REQUIRED. StringOrURI or array of StringOrURI. The intended -recipient(s) of the ECT. The "aud" claim SHOULD contain the -identifiers of all entities that will verify the ECT. When -an ECT must be verified by both the next agent and the audit -ledger independently, "aud" MUST be an array containing both -identifiers. Each verifier checks that its own identity -appears in "aud".

-
-
-
iat:
-
-

REQUIRED. NumericDate. The time at which the ECT was issued.

-
-
-
exp:
-
-

REQUIRED. NumericDate. The expiration time of the ECT. -Implementations SHOULD set this to 5 to 15 minutes after "iat".

-
-
-
jti:
-
-

REQUIRED. String. A unique identifier for both the ECT and -the task it records, in UUID format [RFC9562]. The "jti" -serves as both the token identifier (for replay detection) and -the task identifier (for DAG parent references in "par"). -Receivers MUST reject ECTs whose "jti" has already been seen -within the expiration window. When "wid" is present, -uniqueness is scoped to the workflow; when "wid" is absent, -uniqueness MUST be enforced globally across the ECT store.

-
-
-
-
-
-
-
-

-3.2.2. Execution Context -

-

The following claims are defined by this specification:

-
-
wid:
-
-

OPTIONAL. String. A workflow identifier that groups related -ECTs into a single workflow. When present, MUST be a UUID -[RFC9562].

-
-
-
exec_act:
-
-

REQUIRED. String. The action or task type identifier describing -what the agent performed (e.g., "process_payment", -"validate_safety"). This claim name avoids collision with the -"act" (Actor) claim registered by [RFC8693].

-
-
-
par:
-
-

REQUIRED. Array of strings. Parent task identifiers -representing DAG dependencies. Each element MUST be the "jti" -value of a previously verified ECT. An empty array indicates -a root task with no dependencies. A workflow MAY contain -multiple root tasks.

-
-
-
-
-
-
-
-

-3.2.3. Data Integrity -

-

The following claims provide integrity verification for task -inputs and outputs without revealing the data itself:

-
-
inp_hash:
-
-

OPTIONAL. String. The base64url encoding (without padding) of -the SHA-256 hash of the input data, computed over the raw octets -of the input. SHA-256 is the mandatory algorithm with no -algorithm prefix in the value, consistent with [RFC9449] and -[I-D.ietf-wimse-s2s-protocol].

-
-
-
out_hash:
-
-

OPTIONAL. String. The base64url encoding (without padding) of -the SHA-256 hash of the output data, using the same format as -"inp_hash".

-
-
-
-
-
-
-
-

-3.2.4. Extensions -

-
-
ext:
-
-

OPTIONAL. Object. A general-purpose extension object for -domain-specific claims not defined by this specification. -Implementations that do not understand extension claims MUST -ignore them. Extension key names SHOULD use reverse domain -notation (e.g., "com.example.custom_field") to avoid -collisions. The serialized "ext" object SHOULD NOT exceed -4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels.

-
-
-
-
-
-
-
-
-
-

-3.3. Complete ECT Example -

-

The following is a complete ECT payload example:

-
-
-
-
-{
-  "iss": "spiffe://example.com/agent/clinical",
-  "aud": "spiffe://example.com/agent/safety",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "550e8400-e29b-41d4-a716-446655440001",
-
-  "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
-  "exec_act": "recommend_treatment",
-  "par": [],
-
-  "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-  "ext": {
-    "com.example.trace_id": "abc123"
-  }
-}
-
-
-
Figure 2: -Complete ECT Payload Example -
-
-
-
-
-
-
-
-

-4. HTTP Header Transport -

-
-
-

-4.1. Execution-Context Header Field -

-

This specification defines the Execution-Context HTTP header field -[RFC9110] for transporting ECTs between agents.

-

The header field value is the ECT in JWS Compact Serialization -format [RFC7515]. The value consists of three Base64url-encoded -parts separated by period (".") characters.

-

An agent sending a request to another agent includes the -Execution-Context header alongside the WIMSE Workload-Identity -header. When a Workload Proof Token (WPT) is available per -[I-D.ietf-wimse-s2s-protocol], agents SHOULD include it -alongside the WIT and ECT.

-
-
-
-
-GET /api/safety-check HTTP/1.1
-Host: safety-agent.example.com
-Workload-Identity: eyJhbGci...WIT...
-Execution-Context: eyJhbGci...ECT...
-
-
-
Figure 3: -HTTP Request with ECT Header -
-
-

When multiple parent tasks contribute context to a single request, -multiple Execution-Context header field lines MAY be included, each -carrying a separate ECT in JWS Compact Serialization format.

-

When a receiver processes multiple Execution-Context headers, it -MUST individually verify each ECT per the procedure in -Section 6. If any single ECT fails verification, the -receiver MUST reject the entire request. The set of verified -parent task IDs across all received ECTs represents the complete -set of parent dependencies available for the receiving agent's -subsequent ECT.

-
-
-
-
-
-
-

-5. DAG Validation -

-

ECTs form a Directed Acyclic Graph (DAG) where each task -references its parent tasks via the "par" claim. DAG validation -is performed against the ECT store — either an audit ledger or -the set of parent ECTs received inline.

-

When receiving and verifying an ECT, implementations MUST perform -the following DAG validation steps:

-
    -
  1. -

    Task ID Uniqueness: The "jti" claim MUST be unique within the -applicable scope (the workflow identified by "wid", or the -entire ECT store if "wid" is absent). If an ECT with the same -"jti" already exists, the ECT MUST be rejected.

    -
    2. -
  2. -

    Parent Existence: Every task identifier listed in the "par" -array MUST correspond to a task that is available in the ECT -store (either previously recorded in the ledger or received -inline as a verified parent ECT). If any parent task is not -found, the ECT MUST be rejected.

    -
    3. -
  3. -

    Temporal Ordering: The "iat" value of every parent task MUST NOT be greater than the "iat" value of the current task plus a -configurable clock skew tolerance (RECOMMENDED: 30 seconds). -That is, for each parent: parent.iat < child.iat + -clock_skew_tolerance. The tolerance accounts for clock skew -between agents; it does not guarantee strict causal ordering -from timestamps alone. Causal ordering is primarily enforced -by the DAG structure (parent existence in the ECT store), not by -timestamps. If any parent task violates this constraint, the -ECT MUST be rejected.

    -
    4. -
  4. -

    Acyclicity: Following the chain of parent references MUST NOT -lead back to the current ECT's "jti". If a cycle is detected, -the ECT MUST be rejected.

    -
    5. -
  5. -

    Trust Domain Consistency: Parent tasks SHOULD belong to the -same trust domain or to a trust domain with which a federation -relationship has been established.

    -
    6. -
-

To prevent denial-of-service via extremely deep or wide DAGs, -implementations SHOULD enforce a maximum ancestor traversal limit -(RECOMMENDED: 10000 nodes). If the limit is reached before cycle -detection completes, the ECT SHOULD be rejected.

-

In distributed deployments, a parent ECT may not yet be available -locally due to replication lag. Implementations MAY defer -validation to allow parent ECTs to arrive, but MUST NOT treat -the ECT as verified until all parent references are resolved.

-
-
-
-
-

-6. Signature and Token Verification -

-
-
-

-6.1. Verification Procedure -

-

When an agent receives an ECT, it MUST perform the following -verification steps in order:

-
    -
  1. -

    Parse the JWS Compact Serialization to extract the JOSE header, -payload, and signature components per [RFC7515].

    -
    2. -
  2. -

    Verify that the "typ" header parameter is "wimse-exec+jwt".

    -
    3. -
  3. -

    Verify that the "alg" header parameter appears in the -verifier's configured allowlist of accepted signing algorithms. -The allowlist MUST NOT include "none" or any symmetric -algorithm (e.g., HS256, HS384, HS512). Implementations MUST -include ES256 in the allowlist; additional asymmetric algorithms -MAY be included per deployment policy.

    -
    4. -
  4. -

    Verify the "kid" header parameter references a known, valid -public key from a WIT within the trust domain.

    -
    5. -
  5. -

    Retrieve the public key identified by "kid" and verify the JWS -signature per [RFC7515] Section 5.2.

    -
    6. -
  6. -

    Verify that the signing key identified by "kid" has not been -revoked within the trust domain. Implementations MUST check -the key's revocation status using the trust domain's key -lifecycle mechanism (e.g., certificate revocation list, OCSP, -or SPIFFE trust bundle updates).

    -
    7. -
  7. -

    Verify the "alg" header parameter matches the algorithm in the -corresponding WIT.

    -
    8. -
  8. -

    Verify the "iss" claim matches the "sub" claim of the WIT -associated with the "kid" public key.

    -
    9. -
  9. -

    Verify the "aud" claim contains the verifier's own workload -identity. When "aud" is an array, it is sufficient that the -verifier's identity appears as one element; the presence of -other audience values does not cause verification failure. -When the verifier is the audit ledger, the ledger's own -identity MUST appear in "aud".

    -
    10. -
  10. -

    Verify the "exp" claim indicates the ECT has not expired.

    -
    11. -
  11. -

    Verify the "iat" claim is not unreasonably far in the past -(implementation-specific threshold, RECOMMENDED maximum of -15 minutes) and is not unreasonably far in the future -(RECOMMENDED: no more than 30 seconds ahead of the -verifier's current time, to account for clock skew).

    -
    12. -
  12. -

    Verify all required claims ("jti", "exec_act", "par") are -present and well-formed.

    -
    13. -
  13. -

    Perform DAG validation per Section 5.

    -
    14. -
  14. -

    If all checks pass and an audit ledger is deployed, the ECT -SHOULD be appended to the ledger.

    -
    15. -
-

If any verification step fails, the ECT MUST be rejected and the -failure MUST be logged for audit purposes. Error messages -SHOULD NOT reveal whether specific parent task IDs exist in the -ECT store, to prevent information disclosure.

-

When ECT verification fails during HTTP request processing, the -receiving agent SHOULD respond with HTTP 403 (Forbidden) if the -WIT is valid but the ECT is invalid, and HTTP 401 -(Unauthorized) if the ECT signature verification fails. The -response body SHOULD include a generic error indicator without -revealing which specific verification step failed. The receiving -agent MUST NOT process the requested action when ECT verification -fails.

-
-
-
-
-
-
-

-7. Audit Ledger Interface -

-

ECTs MAY be recorded in an immutable audit ledger for compliance -verification and post-hoc analysis. A ledger is RECOMMENDED for -regulated environments but is not required for point-to-point -operation. This specification does not mandate a specific storage -technology. Implementations MAY use append-only logs, databases -with cryptographic commitment schemes, distributed ledgers, or -any storage mechanism that provides the required properties.

-

When an audit ledger is deployed, the implementation MUST provide:

-
    -
  1. -

    Append-only semantics: Once an ECT is recorded, it MUST NOT be -modified or deleted.

    -
    2. -
  2. -

    Ordering: The ledger MUST maintain a total ordering of ECT -entries via a monotonically increasing sequence number.

    -
    3. -
  3. -

    Lookup by ECT ID: The ledger MUST support efficient retrieval -of ECT entries by "jti" value.

    -
    4. -
  4. -

    Integrity verification: The ledger SHOULD provide a mechanism -to verify that no entries have been tampered with (e.g., -hash chains or Merkle trees).

    -
    5. -
-

The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion.

-
-
-
-
-

-8. Security Considerations -

-
-
-

-8.1. Threat Model -

-

The threat model considers: (1) a malicious agent that creates -false ECT claims, (2) an agent whose private key has been -compromised, (3) a ledger tamperer attempting to modify recorded -entries, and (4) a time manipulator altering timestamps to affect -perceived ordering.

-
-
-
-
-

-8.2. Self-Assertion Limitation -

-

ECTs are self-asserted by the executing agent. The agent claims -what it did, and this claim is signed with its private key. A -compromised or malicious agent could create ECTs with false claims -(e.g., claiming an action was performed when it was not).

-

ECTs do not independently verify that:

-
    -
  • -

    The claimed execution actually occurred as described

    -
    • -
  • -

    The input/output hashes correspond to the actual data processed

    -
    • -
  • -

    The agent faithfully performed the stated action

    -
    • -
-

The trustworthiness of ECT claims depends on the trustworthiness -of the signing agent and the integrity of the broader deployment -environment. ECTs provide a technical mechanism for execution -recording; they do not by themselves satisfy any specific -regulatory compliance requirement.

-
-
-
-
-

-8.3. Signature Verification -

-

ECTs MUST be signed with the agent's private key using JWS -[RFC7515]. The signature algorithm MUST match the algorithm -specified in the agent's WIT. Receivers MUST verify the ECT -signature against the WIT public key before processing any -claims. Receivers MUST verify that the signing key has not been -revoked within the trust domain (see step 6 in -Section 6).

-

If signature verification fails or if the signing key has been -revoked, the ECT MUST be rejected entirely and the failure MUST -be logged.

-

Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification.

-
-
-
-
-

-8.4. Replay Attack Prevention -

-

ECTs include short expiration times (RECOMMENDED: 5-15 minutes) -and audience restriction via "aud" to limit replay attacks. -Implementations MUST maintain a cache of recently-seen "jti" -values and MUST reject ECTs with duplicate "jti" values. Each -ECT is cryptographically bound to the issuing agent via "kid"; -verifiers MUST confirm that "kid" resolves to the "iss" agent's -key (step 8 in Section 6).

-
-
-
-
-

-8.5. Man-in-the-Middle Protection -

-

ECTs MUST be transmitted over TLS or mTLS connections. When used -with [I-D.ietf-wimse-s2s-protocol], transport security is -already established.

-
-
-
-
-

-8.6. Key Compromise -

-

If an agent's private key is compromised, an attacker can forge -ECTs that appear to originate from that agent. Mitigations:

-
    -
  • -

    Implementations SHOULD use short-lived keys and rotate them -frequently.

    -
    • -
  • -

    Private keys SHOULD be stored in hardware security modules or -equivalent secure key storage.

    -
    • -
  • -

    Trust domains MUST support rapid key revocation.

    -
    • -
-

ECTs recorded before key revocation remain valid historical -records but SHOULD be flagged for audit purposes. New ECTs -MUST NOT reference a parent ECT whose signing key is known to -be revoked at creation time.

-
-
-
-
-

-8.7. Collusion and DAG Integrity -

-

A single malicious agent cannot forge parent task references -because DAG validation requires parent tasks to exist in the ECT -store. However, multiple colluding agents could create a false -execution history. Additionally, a malicious agent may omit -actual parent dependencies from "par" to hide influences on its -output; because ECTs are self-asserted -(Section 8.2), no mechanism can force complete -dependency declaration.

-

Mitigations include:

-
    -
  • -

    The ledger SHOULD be maintained by an entity independent of the -workflow agents.

    -
    • -
  • -

    Multiple independent ledger replicas can be compared for -consistency.

    -
    • -
  • -

    External auditors can compare the declared DAG against expected -workflow patterns.

    -
    • -
-

Verifiers SHOULD validate that the declared "wid" of parent ECTs -matches the "wid" of the child ECT, rejecting cross-workflow -parent references unless explicitly permitted by deployment -policy.

-
-
-
-
-

-8.8. Privilege Escalation via ECTs -

-

ECTs record execution history; they do not convey authorization. -Verifiers MUST NOT interpret the presence of an ECT, or a -particular set of parent references in "par", as an authorization -grant. Authorization decisions MUST remain with the identity and -authorization layer (WIT, WPT, and deployment policy).

-
-
-
-
-

-8.9. Denial of Service -

-

Implementations SHOULD apply rate limiting to prevent excessive -ECT submissions. DAG validation SHOULD be performed after -signature verification to avoid wasting resources on unsigned -tokens.

-
-
-
-
-

-8.10. Timestamp Accuracy -

-

Implementations SHOULD use synchronized time sources (e.g., NTP) -and SHOULD allow a configurable clock skew tolerance (RECOMMENDED: -30 seconds). Cross-organizational deployments MAY require a -higher tolerance and SHOULD document the configured value.

-
-
-
-
-

-8.11. ECT Size Constraints -

-

Implementations SHOULD limit the "par" array to a maximum of -256 entries. See Section 3.2.4 for "ext" size limits.

-
-
-
-
-
-
-

-9. Privacy Considerations -

-
-
-

-9.1. Data Exposure in ECTs -

-

ECTs necessarily reveal:

-
    -
  • -

    Agent identities ("iss", "aud") for accountability purposes

    -
    • -
  • -

    Action descriptions ("exec_act") for audit trail completeness

    -
    • -
  • -

    Timestamps ("iat", "exp") for temporal ordering

    -
    • -
-

ECTs are designed to NOT reveal:

-
    -
  • -

    Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash")

    -
    • -
  • -

    Internal computation details or intermediate steps

    -
    • -
  • -

    Proprietary algorithms or intellectual property

    -
    • -
  • -

    Personally identifiable information (PII)

    -
    • -
-
-
-
-
-

-9.2. Data Minimization -

-

Implementations SHOULD minimize the information included in ECTs. -The "exec_act" claim SHOULD use structured identifiers (e.g., -"process_payment") rather than natural language descriptions. -Extension keys in "ext" (Section 3.2.4) deserve particular -attention: human-readable values risk exposing sensitive operational -details. See Section 3.2.4 for guidance on using -structured identifiers.

-
-
-
-
-

-9.3. Storage and Access Control -

-

ECTs stored in audit ledgers SHOULD be access-controlled so that -only authorized auditors can read them. Implementations SHOULD -consider encryption at rest for ledger storage. ECTs provide -structural records of execution ordering; they are not intended -for public disclosure.

-

Full input and output data (corresponding to the hashes in ECTs) -SHOULD be stored separately from the ledger with additional access -controls, since auditors may need to verify hash correctness but -general access to the data values is not needed.

-
-
-
-
-
-
-

-10. IANA Considerations -

-
-
-

-10.1. Media Type Registration -

-

This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:

-
-
Type name:
-
-

application

-
-
-
Subtype name:
-
-

wimse-exec+jwt

-
-
-
Required parameters:
-
-

none

-
-
-
Optional parameters:
-
-

none

-
-
-
Encoding considerations:
-
-

8bit; an ECT is a JWT that is a JWS using the Compact -Serialization, which is a sequence of Base64url-encoded values -separated by period characters.

-
-
-
Security considerations:
-
-

See the Security Considerations section of this document.

-
-
-
Interoperability considerations:
-
-

none

-
-
-
Published specification:
-
-

This document

-
-
-
Applications that use this media type:
-
-

Applications that implement agentic workflows requiring execution -context tracing and audit trails.

-
-
-
Additional information:
-
-

Magic number(s): none -File extension(s): none -Macintosh file type code(s): none

-
-
-
Person and email address to contact for further information:
-
-

Christian Nennemann, ietf@nennemann.de

-
-
-
Intended usage:
-
-

COMMON

-
-
-
Restrictions on usage:
-
-

none

-
-
-
Author:
-
-

Christian Nennemann

-
-
-
Change controller:
-
-

IETF

-
-
-
-
-
-
-
-

-10.2. HTTP Header Field Registration -

-

This document requests registration of the following header field -in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA:

-
-
Field name:
-
-

Execution-Context

-
-
-
Status:
-
-

permanent

-
-
-
Specification document:
-
-

This document, Section 4

-
-
-
-
-
-
-
-

-10.3. JWT Claims Registration -

-

This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 1: -JWT Claims Registrations -
Claim NameClaim DescriptionChange ControllerReference
widWorkflow IdentifierIETF - Section 3.2.2 -
exec_actAction/Task TypeIETF - Section 3.2.2 -
parParent Task IdentifiersIETF - Section 3.2.2 -
inp_hashInput Data HashIETF - Section 3.2.3 -
out_hashOutput Data HashIETF - Section 3.2.3 -
extExtension ObjectIETF - Section 3.2.4 -
-
-
-
-
-
-
-
-

-11. References -

-
-
-

-11.1. Normative References -

-
-
[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-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-06>.
-
-
[I-D.ietf-wimse-s2s-protocol]
-
-Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s-protocol-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-s2s-protocol-07>.
-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC7515]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
-
-
[RFC7517]
-
-Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
-
-
[RFC7518]
-
-Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/rfc/rfc7518>.
-
-
[RFC7519]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC9110]
-
-Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
-
-
[RFC9562]
-
-Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, , <https://www.rfc-editor.org/rfc/rfc9562>.
-
-
-
-
-
-
-

-11.2. Informative References -

-
-
[I-D.ietf-oauth-transaction-tokens]
-
-Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07>.
-
-
[I-D.ietf-scitt-architecture]
-
-Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
-
-
[I-D.oauth-transaction-tokens-for-agents]
-
-Raut, A., "Transaction Tokens For Agents", Work in Progress, Internet-Draft, draft-oauth-transaction-tokens-for-agents-04, , <https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04>.
-
-
[OPENTELEMETRY]
-
-Cloud Native Computing Foundation, "OpenTelemetry Specification", <https://opentelemetry.io/docs/specs/otel/>.
-
-
[RFC8693]
-
-Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , <https://www.rfc-editor.org/rfc/rfc8693>.
-
-
[RFC9449]
-
-Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.
-
-
[SPIFFE]
-
-"Secure Production Identity Framework for Everyone (SPIFFE)", <https://spiffe.io/docs/latest/spiffe-about/overview/>.
-
-
-
-
-
-
-
-
-

-Use Cases -

-

This section describes a representative use case demonstrating how -ECTs provide structured execution records.

-

Note: task identifiers in this section are abbreviated for -readability. In production, all "jti" values are required to be -UUIDs per Section 3.2.2.

-
-
-

-Cross-Organization Financial Trading -

-

In a cross-organization trading workflow, an investment bank's -agents coordinate with an external credit rating agency. The -agents operate in separate trust domains with a federation -relationship. The DAG records that independent assessments from -both organizations were completed before trade execution.

-
-
-
-
-Trust Domain: bank.example
-  Agent A1 (Portfolio Risk):
-    jti: task-001    par: []
-    iss: spiffe://bank.example/agent/risk
-    exec_act: analyze_portfolio_risk
-
-Trust Domain: ratings.example (external)
-  Agent B1 (Credit Rating):
-    jti: task-002    par: []
-    iss: spiffe://ratings.example/agent/credit
-    exec_act: assess_credit_rating
-
-Trust Domain: bank.example
-  Agent A2 (Compliance):
-    jti: task-003    par: [task-001, task-002]
-    iss: spiffe://bank.example/agent/compliance
-    exec_act: verify_trade_compliance
-
-  Agent A3 (Execution):
-    jti: task-004    par: [task-003]
-    iss: spiffe://bank.example/agent/execution
-    exec_act: execute_trade
-
-
-
Figure 4: -Cross-Organization Trading Workflow -
-
-

The resulting DAG:

-
-
-
-
-task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
-  [bank.example]                      [ratings.example]
-          \                              /
-           v                            v
-         task-003 (verify_trade_compliance)
-           [bank.example]
-                    |
-                    v
-         task-004 (execute_trade)
-           [bank.example]
-
-
-
Figure 5: -Cross-Organization DAG -
-
-

Task 003 has two parents from different trust domains, -demonstrating cross-organizational fan-in. The compliance agent -verifies both parent ECTs — one signed by a local key and one by -a federated key from the rating agency's trust domain.

-
-
-
-
- -
-
-

-Acknowledgments -

-

The author thanks the WIMSE working group for their foundational -work on workload identity in multi-system environments. The -concepts of Workload Identity Tokens and Workload Proof Tokens -provide the identity foundation upon which execution context -tracing is built.

-
-
-
-
-

-Author's Address -

-
-
Christian Nennemann
-
Independent Researcher
- -
-
-
- - - diff --git a/draft-nennemann-wimse-ect-00.md b/draft-nennemann-wimse-ect-00.md deleted file mode 100644 index b243f39..0000000 --- a/draft-nennemann-wimse-ect-00.md +++ /dev/null @@ -1,926 +0,0 @@ ---- -title: "Execution Context Tokens for Distributed Agentic Workflows" -abbrev: "WIMSE Execution Context" -category: std -docname: draft-nennemann-wimse-ect-00 -submissiontype: IETF -number: -date: -v: 3 -area: "ART" -workgroup: "WIMSE" -keyword: - - execution context - - workload identity - - agentic workflows - - audit trail - -author: - - - fullname: Christian Nennemann - organization: Independent Researcher - email: ietf@nennemann.de - -normative: - RFC7515: - RFC7517: - RFC7519: - RFC7518: - RFC9562: - RFC9110: - I-D.ietf-wimse-arch: - I-D.ietf-wimse-s2s-protocol: - -informative: - RFC8693: - SPIFFE: - title: "Secure Production Identity Framework for Everyone (SPIFFE)" - target: https://spiffe.io/docs/latest/spiffe-about/overview/ - date: false - OPENTELEMETRY: - title: "OpenTelemetry Specification" - target: https://opentelemetry.io/docs/specs/otel/ - date: false - author: - - org: Cloud Native Computing Foundation - I-D.ietf-scitt-architecture: - RFC9449: - I-D.ietf-oauth-transaction-tokens: - I-D.oauth-transaction-tokens-for-agents: - ---- abstract - -This document defines Execution Context Tokens (ECTs), a JWT-based -extension to the WIMSE architecture that records task execution -across distributed agentic workflows. Each ECT is a signed record -of a single task, linked to predecessor tasks through a directed -acyclic graph (DAG). ECTs reuse the WIMSE signing model and are -transported in a new Execution-Context HTTP header field alongside -existing WIMSE identity headers. - ---- middle - -# Introduction - -The WIMSE framework {{I-D.ietf-wimse-arch}} and its service-to- -service protocol {{I-D.ietf-wimse-s2s-protocol}} authenticate -workloads across call chains but do not record what those -workloads actually did. This document defines Execution Context -Tokens (ECTs), a JWT-based extension that fills the gap between -workload identity and execution accountability. Each ECT is a -signed record of a single task, linked to predecessor tasks -through a directed acyclic graph (DAG). - -## Scope and Applicability - -This document defines: - -- The Execution Context Token (ECT) format ({{ect-format}}) -- DAG structure for task dependency ordering ({{dag-validation}}) -- An HTTP header for ECT transport ({{http-header}}) -- Audit ledger interface requirements ({{ledger-interface}}) - -The following are out of scope and are handled by WIMSE: - -- Workload authentication and identity provisioning -- Key distribution and management -- Trust domain establishment and management -- Credential lifecycle management - -# Conventions and Definitions - -{::boilerplate bcp14-tagged} - -The following terms are used in this document: - -Agent: -: An autonomous workload, as defined by WIMSE - {{I-D.ietf-wimse-arch}}, that executes tasks within a workflow. - -Task: -: A discrete unit of agent work that consumes inputs and produces - outputs. - -Directed Acyclic Graph (DAG): -: A graph structure representing task dependency ordering where - edges are directed and no cycles exist. - -Execution Context Token (ECT): -: A JSON Web Token {{RFC7519}} defined by this specification that - records task execution details. - -Audit Ledger: -: An append-only, immutable log of all ECTs within a workflow or - set of workflows, used for audit and verification. - -Workload Identity Token (WIT): -: A WIMSE credential proving a workload's identity within a trust - domain. - -Workload Proof Token (WPT): -: A WIMSE proof-of-possession token used for request-level - authentication. - -Trust Domain: -: A WIMSE concept representing an organizational boundary with a - shared identity issuer, corresponding to a SPIFFE {{SPIFFE}} - trust domain. - -# Execution Context Token Format {#ect-format} - -An Execution Context Token is a JSON Web Token (JWT) {{RFC7519}} -signed as a JSON Web Signature (JWS) {{RFC7515}}. ECTs MUST use -JWS Compact Serialization (the base64url-encoded -`header.payload.signature` format) so that they can be carried in -a single HTTP header value. - -ECTs reuse the WIMSE signing model. The ECT MUST be signed with -the same private key associated with the agent's WIT. The JOSE -header "kid" parameter MUST reference the public key identifier -from the agent's WIT, and the "alg" parameter MUST match the -algorithm used in the corresponding WIT. In WIMSE deployments, -the ECT "iss" claim SHOULD use the WIMSE workload identifier -format (a SPIFFE ID {{SPIFFE}}). - -## JOSE Header {#jose-header} - -The ECT JOSE header MUST contain the following parameters: - -~~~json -{ - "alg": "ES256", - "typ": "wimse-exec+jwt", - "kid": "agent-a-key-id-123" -} -~~~ -{: #fig-header title="ECT JOSE Header Example"} - -alg: -: REQUIRED. The digital signature algorithm used to sign the ECT. - MUST match the algorithm in the corresponding WIT. - Implementations MUST support ES256 {{RFC7518}}. The "alg" - value MUST NOT be "none". Symmetric algorithms (e.g., HS256, - HS384, HS512) MUST NOT be used, as ECTs require asymmetric - signatures for non-repudiation. - -typ: -: REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs - from other JWT types, consistent with the WIMSE convention for - type parameter values. - -kid: -: REQUIRED. The key identifier referencing the public key from - the agent's WIT {{RFC7517}}. Used by verifiers to look up the - correct public key for signature verification. - -## JWT Claims {#jwt-claims} - -### Standard JWT Claims - -An ECT MUST contain the following standard JWT claims {{RFC7519}}: - -iss: -: REQUIRED. StringOrURI. A URI identifying the issuer of the - ECT. In WIMSE deployments, this SHOULD be the workload's - SPIFFE ID in the format `spiffe:///`, - matching the "sub" claim of the agent's WIT. Non-WIMSE - deployments MAY use other URI schemes (e.g., HTTPS URLs or - URN:UUID identifiers). - -aud: -: REQUIRED. StringOrURI or array of StringOrURI. The intended - recipient(s) of the ECT. The "aud" claim SHOULD contain the - identifiers of all entities that will verify the ECT. When - an ECT must be verified by both the next agent and the audit - ledger independently, "aud" MUST be an array containing both - identifiers. Each verifier checks that its own identity - appears in "aud". - -iat: -: REQUIRED. NumericDate. The time at which the ECT was issued. - -exp: -: REQUIRED. NumericDate. The expiration time of the ECT. - Implementations SHOULD set this to 5 to 15 minutes after "iat". - -jti: -: REQUIRED. String. A unique identifier for both the ECT and - the task it records, in UUID format {{RFC9562}}. The "jti" - serves as both the token identifier (for replay detection) and - the task identifier (for DAG parent references in "par"). - Receivers MUST reject ECTs whose "jti" has already been seen - within the expiration window. When "wid" is present, - uniqueness is scoped to the workflow; when "wid" is absent, - uniqueness MUST be enforced globally across the ECT store. - -### Execution Context {#exec-claims} - -The following claims are defined by this specification: - -wid: -: OPTIONAL. String. A workflow identifier that groups related - ECTs into a single workflow. When present, MUST be a UUID - {{RFC9562}}. - -exec_act: -: REQUIRED. String. The action or task type identifier describing - what the agent performed (e.g., "process_payment", - "validate_safety"). This claim name avoids collision with the - "act" (Actor) claim registered by {{RFC8693}}. - -par: -: REQUIRED. Array of strings. Parent task identifiers - representing DAG dependencies. Each element MUST be the "jti" - value of a previously verified ECT. An empty array indicates - a root task with no dependencies. A workflow MAY contain - multiple root tasks. - -### Data Integrity {#data-integrity-claims} - -The following claims provide integrity verification for task -inputs and outputs without revealing the data itself: - -inp_hash: -: OPTIONAL. String. The base64url encoding (without padding) of - the SHA-256 hash of the input data, computed over the raw octets - of the input. SHA-256 is the mandatory algorithm with no - algorithm prefix in the value, consistent with {{RFC9449}} and - {{I-D.ietf-wimse-s2s-protocol}}. - -out_hash: -: OPTIONAL. String. The base64url encoding (without padding) of - the SHA-256 hash of the output data, using the same format as - "inp_hash". - -### Extensions {#extension-claims} - -ext: -: OPTIONAL. Object. A general-purpose extension object for - domain-specific claims not defined by this specification. - Implementations that do not understand extension claims MUST - ignore them. Extension key names SHOULD use reverse domain - notation (e.g., "com.example.custom_field") to avoid - collisions. The serialized "ext" object SHOULD NOT exceed - 4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels. - -## Complete ECT Example - -The following is a complete ECT payload example: - -~~~json -{ - "iss": "spiffe://example.com/agent/clinical", - "aud": "spiffe://example.com/agent/safety", - "iat": 1772064150, - "exp": 1772064750, - "jti": "550e8400-e29b-41d4-a716-446655440001", - - "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789", - "exec_act": "recommend_treatment", - "par": [], - - "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", - - "ext": { - "com.example.trace_id": "abc123" - } -} -~~~ -{: #fig-full-ect title="Complete ECT Payload Example"} - -# HTTP Header Transport {#http-header} - -## Execution-Context Header Field - -This specification defines the Execution-Context HTTP header field -{{RFC9110}} for transporting ECTs between agents. - -The header field value is the ECT in JWS Compact Serialization -format {{RFC7515}}. The value consists of three Base64url-encoded -parts separated by period (".") characters. - -An agent sending a request to another agent includes the -Execution-Context header alongside the WIMSE Workload-Identity -header. When a Workload Proof Token (WPT) is available per -{{I-D.ietf-wimse-s2s-protocol}}, agents SHOULD include it -alongside the WIT and ECT. - -~~~ -GET /api/safety-check HTTP/1.1 -Host: safety-agent.example.com -Workload-Identity: eyJhbGci...WIT... -Execution-Context: eyJhbGci...ECT... -~~~ -{: #fig-http-example title="HTTP Request with ECT Header"} - -When multiple parent tasks contribute context to a single request, -multiple Execution-Context header field lines MAY be included, each -carrying a separate ECT in JWS Compact Serialization format. - -When a receiver processes multiple Execution-Context headers, it -MUST individually verify each ECT per the procedure in -{{verification}}. If any single ECT fails verification, the -receiver MUST reject the entire request. The set of verified -parent task IDs across all received ECTs represents the complete -set of parent dependencies available for the receiving agent's -subsequent ECT. - -# DAG Validation {#dag-validation} - -ECTs form a Directed Acyclic Graph (DAG) where each task -references its parent tasks via the "par" claim. DAG validation -is performed against the ECT store — either an audit ledger or -the set of parent ECTs received inline. - -When receiving and verifying an ECT, implementations MUST perform -the following DAG validation steps: - -1. Task ID Uniqueness: The "jti" claim MUST be unique within the - applicable scope (the workflow identified by "wid", or the - entire ECT store if "wid" is absent). If an ECT with the same - "jti" already exists, the ECT MUST be rejected. - -2. Parent Existence: Every task identifier listed in the "par" - array MUST correspond to a task that is available in the ECT - store (either previously recorded in the ledger or received - inline as a verified parent ECT). If any parent task is not - found, the ECT MUST be rejected. - -3. Temporal Ordering: The "iat" value of every parent task MUST - NOT be greater than the "iat" value of the current task plus a - configurable clock skew tolerance (RECOMMENDED: 30 seconds). - That is, for each parent: `parent.iat < child.iat + - clock_skew_tolerance`. The tolerance accounts for clock skew - between agents; it does not guarantee strict causal ordering - from timestamps alone. Causal ordering is primarily enforced - by the DAG structure (parent existence in the ECT store), not by - timestamps. If any parent task violates this constraint, the - ECT MUST be rejected. - -4. Acyclicity: Following the chain of parent references MUST NOT - lead back to the current ECT's "jti". If a cycle is detected, - the ECT MUST be rejected. - -5. Trust Domain Consistency: Parent tasks SHOULD belong to the - same trust domain or to a trust domain with which a federation - relationship has been established. - -To prevent denial-of-service via extremely deep or wide DAGs, -implementations SHOULD enforce a maximum ancestor traversal limit -(RECOMMENDED: 10000 nodes). If the limit is reached before cycle -detection completes, the ECT SHOULD be rejected. - -In distributed deployments, a parent ECT may not yet be available -locally due to replication lag. Implementations MAY defer -validation to allow parent ECTs to arrive, but MUST NOT treat -the ECT as verified until all parent references are resolved. - -# Signature and Token Verification {#verification} - -## Verification Procedure - -When an agent receives an ECT, it MUST perform the following -verification steps in order: - -1. Parse the JWS Compact Serialization to extract the JOSE header, - payload, and signature components per {{RFC7515}}. - -2. Verify that the "typ" header parameter is "wimse-exec+jwt". - -3. Verify that the "alg" header parameter appears in the - verifier's configured allowlist of accepted signing algorithms. - The allowlist MUST NOT include "none" or any symmetric - algorithm (e.g., HS256, HS384, HS512). Implementations MUST - include ES256 in the allowlist; additional asymmetric algorithms - MAY be included per deployment policy. - -4. Verify the "kid" header parameter references a known, valid - public key from a WIT within the trust domain. - -5. Retrieve the public key identified by "kid" and verify the JWS - signature per {{RFC7515}} Section 5.2. - -6. Verify that the signing key identified by "kid" has not been - revoked within the trust domain. Implementations MUST check - the key's revocation status using the trust domain's key - lifecycle mechanism (e.g., certificate revocation list, OCSP, - or SPIFFE trust bundle updates). - -7. Verify the "alg" header parameter matches the algorithm in the - corresponding WIT. - -8. Verify the "iss" claim matches the "sub" claim of the WIT - associated with the "kid" public key. - -9. Verify the "aud" claim contains the verifier's own workload - identity. When "aud" is an array, it is sufficient that the - verifier's identity appears as one element; the presence of - other audience values does not cause verification failure. - When the verifier is the audit ledger, the ledger's own - identity MUST appear in "aud". - -10. Verify the "exp" claim indicates the ECT has not expired. - -11. Verify the "iat" claim is not unreasonably far in the past - (implementation-specific threshold, RECOMMENDED maximum of - 15 minutes) and is not unreasonably far in the future - (RECOMMENDED: no more than 30 seconds ahead of the - verifier's current time, to account for clock skew). - -12. Verify all required claims ("jti", "exec_act", "par") are - present and well-formed. - -13. Perform DAG validation per {{dag-validation}}. - -14. If all checks pass and an audit ledger is deployed, the ECT - SHOULD be appended to the ledger. - -If any verification step fails, the ECT MUST be rejected and the -failure MUST be logged for audit purposes. Error messages -SHOULD NOT reveal whether specific parent task IDs exist in the -ECT store, to prevent information disclosure. - -When ECT verification fails during HTTP request processing, the -receiving agent SHOULD respond with HTTP 403 (Forbidden) if the -WIT is valid but the ECT is invalid, and HTTP 401 -(Unauthorized) if the ECT signature verification fails. The -response body SHOULD include a generic error indicator without -revealing which specific verification step failed. The receiving -agent MUST NOT process the requested action when ECT verification -fails. - -# Audit Ledger Interface {#ledger-interface} - -ECTs MAY be recorded in an immutable audit ledger for compliance -verification and post-hoc analysis. A ledger is RECOMMENDED for -regulated environments but is not required for point-to-point -operation. This specification does not mandate a specific storage -technology. Implementations MAY use append-only logs, databases -with cryptographic commitment schemes, distributed ledgers, or -any storage mechanism that provides the required properties. - -When an audit ledger is deployed, the implementation MUST provide: - -1. Append-only semantics: Once an ECT is recorded, it MUST NOT be - modified or deleted. - -2. Ordering: The ledger MUST maintain a total ordering of ECT - entries via a monotonically increasing sequence number. - -3. Lookup by ECT ID: The ledger MUST support efficient retrieval - of ECT entries by "jti" value. - -4. Integrity verification: The ledger SHOULD provide a mechanism - to verify that no entries have been tampered with (e.g., - hash chains or Merkle trees). - -The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion. - -# Security Considerations - -## Threat Model - -The threat model considers: (1) a malicious agent that creates -false ECT claims, (2) an agent whose private key has been -compromised, (3) a ledger tamperer attempting to modify recorded -entries, and (4) a time manipulator altering timestamps to affect -perceived ordering. - -## Self-Assertion Limitation {#self-assertion-limitation} - -ECTs are self-asserted by the executing agent. The agent claims -what it did, and this claim is signed with its private key. A -compromised or malicious agent could create ECTs with false claims -(e.g., claiming an action was performed when it was not). - -ECTs do not independently verify that: - -- The claimed execution actually occurred as described -- The input/output hashes correspond to the actual data processed -- The agent faithfully performed the stated action - -The trustworthiness of ECT claims depends on the trustworthiness -of the signing agent and the integrity of the broader deployment -environment. ECTs provide a technical mechanism for execution -recording; they do not by themselves satisfy any specific -regulatory compliance requirement. - -## Signature Verification - -ECTs MUST be signed with the agent's private key using JWS -{{RFC7515}}. The signature algorithm MUST match the algorithm -specified in the agent's WIT. Receivers MUST verify the ECT -signature against the WIT public key before processing any -claims. Receivers MUST verify that the signing key has not been -revoked within the trust domain (see step 6 in -{{verification}}). - -If signature verification fails or if the signing key has been -revoked, the ECT MUST be rejected entirely and the failure MUST -be logged. - -Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification. - -## Replay Attack Prevention - -ECTs include short expiration times (RECOMMENDED: 5-15 minutes) -and audience restriction via "aud" to limit replay attacks. -Implementations MUST maintain a cache of recently-seen "jti" -values and MUST reject ECTs with duplicate "jti" values. Each -ECT is cryptographically bound to the issuing agent via "kid"; -verifiers MUST confirm that "kid" resolves to the "iss" agent's -key (step 8 in {{verification}}). - -## Man-in-the-Middle Protection - -ECTs MUST be transmitted over TLS or mTLS connections. When used -with {{I-D.ietf-wimse-s2s-protocol}}, transport security is -already established. - -## Key Compromise - -If an agent's private key is compromised, an attacker can forge -ECTs that appear to originate from that agent. Mitigations: - -- Implementations SHOULD use short-lived keys and rotate them - frequently. -- Private keys SHOULD be stored in hardware security modules or - equivalent secure key storage. -- Trust domains MUST support rapid key revocation. - -ECTs recorded before key revocation remain valid historical -records but SHOULD be flagged for audit purposes. New ECTs -MUST NOT reference a parent ECT whose signing key is known to -be revoked at creation time. - -## Collusion and DAG Integrity {#collusion-and-false-claims} - -A single malicious agent cannot forge parent task references -because DAG validation requires parent tasks to exist in the ECT -store. However, multiple colluding agents could create a false -execution history. Additionally, a malicious agent may omit -actual parent dependencies from "par" to hide influences on its -output; because ECTs are self-asserted -({{self-assertion-limitation}}), no mechanism can force complete -dependency declaration. - -Mitigations include: - -- The ledger SHOULD be maintained by an entity independent of the - workflow agents. -- Multiple independent ledger replicas can be compared for - consistency. -- External auditors can compare the declared DAG against expected - workflow patterns. - -Verifiers SHOULD validate that the declared "wid" of parent ECTs -matches the "wid" of the child ECT, rejecting cross-workflow -parent references unless explicitly permitted by deployment -policy. - -## Privilege Escalation via ECTs - -ECTs record execution history; they do not convey authorization. -Verifiers MUST NOT interpret the presence of an ECT, or a -particular set of parent references in "par", as an authorization -grant. Authorization decisions MUST remain with the identity and -authorization layer (WIT, WPT, and deployment policy). - -## Denial of Service - -Implementations SHOULD apply rate limiting to prevent excessive -ECT submissions. DAG validation SHOULD be performed after -signature verification to avoid wasting resources on unsigned -tokens. - -## Timestamp Accuracy - -Implementations SHOULD use synchronized time sources (e.g., NTP) -and SHOULD allow a configurable clock skew tolerance (RECOMMENDED: -30 seconds). Cross-organizational deployments MAY require a -higher tolerance and SHOULD document the configured value. - -## ECT Size Constraints - -Implementations SHOULD limit the "par" array to a maximum of -256 entries. See {{extension-claims}} for "ext" size limits. - -# Privacy Considerations - -## Data Exposure in ECTs - -ECTs necessarily reveal: - -- Agent identities ("iss", "aud") for accountability purposes -- Action descriptions ("exec_act") for audit trail completeness -- Timestamps ("iat", "exp") for temporal ordering - -ECTs are designed to NOT reveal: - -- Actual input or output data values (replaced with cryptographic - hashes via "inp_hash" and "out_hash") -- Internal computation details or intermediate steps -- Proprietary algorithms or intellectual property -- Personally identifiable information (PII) - -## Data Minimization {#data-minimization} - -Implementations SHOULD minimize the information included in ECTs. -The "exec_act" claim SHOULD use structured identifiers (e.g., -"process_payment") rather than natural language descriptions. -Extension keys in "ext" ({{extension-claims}}) deserve particular -attention: human-readable values risk exposing sensitive operational -details. See {{extension-claims}} for guidance on using -structured identifiers. - -## Storage and Access Control - -ECTs stored in audit ledgers SHOULD be access-controlled so that -only authorized auditors can read them. Implementations SHOULD -consider encryption at rest for ledger storage. ECTs provide -structural records of execution ordering; they are not intended -for public disclosure. - -Full input and output data (corresponding to the hashes in ECTs) -SHOULD be stored separately from the ledger with additional access -controls, since auditors may need to verify hash correctness but -general access to the data values is not needed. - -# IANA Considerations - -## Media Type Registration - -This document requests registration of the following media type -in the "Media Types" registry maintained by IANA: - -Type name: -: application - -Subtype name: -: wimse-exec+jwt - -Required parameters: -: none - -Optional parameters: -: none - -Encoding considerations: -: 8bit; an ECT is a JWT that is a JWS using the Compact - Serialization, which is a sequence of Base64url-encoded values - separated by period characters. - -Security considerations: -: See the Security Considerations section of this document. - -Interoperability considerations: -: none - -Published specification: -: This document - -Applications that use this media type: -: Applications that implement agentic workflows requiring execution - context tracing and audit trails. - -Additional information: -: Magic number(s): none - File extension(s): none - Macintosh file type code(s): none - -Person and email address to contact for further information: -: Christian Nennemann, ietf@nennemann.de - -Intended usage: -: COMMON - -Restrictions on usage: -: none - -Author: -: Christian Nennemann - -Change controller: -: IETF - -## HTTP Header Field Registration {#header-registration} - -This document requests registration of the following header field -in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA: - -Field name: -: Execution-Context - -Status: -: permanent - -Specification document: -: This document, {{http-header}} - -## JWT Claims Registration {#claims-registration} - -This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA: - -| Claim Name | Claim Description | Change Controller | Reference | -|:---:|:---|:---:|:---:| -| wid | Workflow Identifier | IETF | {{exec-claims}} | -| exec_act | Action/Task Type | IETF | {{exec-claims}} | -| par | Parent Task Identifiers | IETF | {{exec-claims}} | -| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} | -| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} | -| ext | Extension Object | IETF | {{extension-claims}} | -{: #table-claims title="JWT Claims Registrations"} - ---- back - -# Use Cases {#use-cases} -{:numbered="false"} - -This section describes a representative use case demonstrating how -ECTs provide structured execution records. - -Note: task identifiers in this section are abbreviated for -readability. In production, all "jti" values are required to be -UUIDs per {{exec-claims}}. - -## Cross-Organization Financial Trading -{:numbered="false"} - -In a cross-organization trading workflow, an investment bank's -agents coordinate with an external credit rating agency. The -agents operate in separate trust domains with a federation -relationship. The DAG records that independent assessments from -both organizations were completed before trade execution. - -~~~ -Trust Domain: bank.example - Agent A1 (Portfolio Risk): - jti: task-001 par: [] - iss: spiffe://bank.example/agent/risk - exec_act: analyze_portfolio_risk - -Trust Domain: ratings.example (external) - Agent B1 (Credit Rating): - jti: task-002 par: [] - iss: spiffe://ratings.example/agent/credit - exec_act: assess_credit_rating - -Trust Domain: bank.example - Agent A2 (Compliance): - jti: task-003 par: [task-001, task-002] - iss: spiffe://bank.example/agent/compliance - exec_act: verify_trade_compliance - - Agent A3 (Execution): - jti: task-004 par: [task-003] - iss: spiffe://bank.example/agent/execution - exec_act: execute_trade -~~~ -{: #fig-finance title="Cross-Organization Trading Workflow"} - -The resulting DAG: - -~~~ -task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating) - [bank.example] [ratings.example] - \ / - v v - task-003 (verify_trade_compliance) - [bank.example] - | - v - task-004 (execute_trade) - [bank.example] -~~~ -{: #fig-finance-dag title="Cross-Organization DAG"} - -Task 003 has two parents from different trust domains, -demonstrating cross-organizational fan-in. The compliance agent -verifies both parent ECTs — one signed by a local key and one by -a federated key from the rating agency's trust domain. - -# Related Work -{:numbered="false"} - -## WIMSE Workload Identity -{:numbered="false"} - -The WIMSE architecture {{I-D.ietf-wimse-arch}} and service-to- -service protocol {{I-D.ietf-wimse-s2s-protocol}} provide the -identity foundation upon which ECTs are built. WIT/WPT answer -"who is this agent?" and "does it control the claimed key?" while -ECTs record "what did this agent do?" Together they form an -identity-plus-accountability framework for regulated agentic -systems. - -## OAuth 2.0 Token Exchange and the "act" Claim -{:numbered="false"} - -{{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and -registers the "act" (Actor) claim in the JWT Claims registry. -The "act" claim creates nested JSON objects representing a -delegation chain: "who is acting on behalf of whom." While -the nesting superficially resembles a chain, it is strictly -linear (each "act" object contains at most one nested "act"), -represents authorization delegation rather than task execution, -and carries no task identifiers or input/output integrity -data. The "act" chain cannot represent -branching (fan-out) or convergence (fan-in) and therefore -cannot form a DAG. - -ECTs intentionally use the distinct claim name "exec_act" for the -action/task type to avoid collision with the "act" claim. The -two concepts are orthogonal: "act" records "who authorized whom," -ECTs record "what was done, in what order." - -## Transaction Tokens -{:numbered="false"} - -OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}} -propagate authorization context across workload call chains. -The Txn-Token "req_wl" claim accumulates a comma-separated list -of workloads that requested replacement tokens, which is the -closest existing mechanism to call-chain recording. - -However, "req_wl" cannot form a DAG because: - -- It is linear: a comma-separated string with no branching or - merging representation. When a workload fans out to multiple - downstream services, each receives the same "req_wl" value and - the branching is invisible. -- It is incomplete: only workloads that request a replacement - token from the Transaction Token Service appear in "req_wl"; - workloads that forward the token unchanged are not recorded. -- It carries no task-level granularity, no parent references, - and no execution content. -- It cannot represent convergence (fan-in): when two independent - paths must both complete before a dependent task proceeds, a - linear "req_wl" string cannot express that relationship. - -Extensions for agentic use cases -({{I-D.oauth-transaction-tokens-for-agents}}) add agent -identity and constraints ("agentic_ctx") but no execution -ordering or DAG structure. - -ECTs and Transaction Tokens are complementary: a Txn-Token -propagates authorization context ("this request is authorized -for scope X on behalf of user Y"), while an ECT records -execution accountability ("task T was performed, depending on -tasks P1 and P2"). An -agent request could carry both a Txn-Token for authorization -and an ECT for execution recording. The WPT "tth" claim -defined in {{I-D.ietf-wimse-s2s-protocol}} can hash-bind a -WPT to a co-present Txn-Token; a similar binding mechanism -for ECTs is a potential future extension. - -## Distributed Tracing (OpenTelemetry) -{:numbered="false"} - -OpenTelemetry {{OPENTELEMETRY}} and similar distributed tracing -systems provide observability for debugging and monitoring. ECTs -differ in several important ways: ECTs are cryptographically -signed per-task with the agent's private key; ECTs are -tamper-evident through JWS signatures; ECTs enforce DAG validation -rules; and ECTs are designed for regulatory audit rather than -operational monitoring. OpenTelemetry data is typically controlled -by the platform operator and can be modified or deleted without -detection. ECTs and distributed traces are complementary: traces -provide observability while ECTs provide signed execution records. -ECTs may reference OpenTelemetry trace identifiers in the "ext" -claim for correlation. - -## W3C Provenance Data Model (PROV) -{:numbered="false"} - -The W3C PROV Data Model defines an Entity-Activity-Agent ontology -for representing provenance information. PROV's concepts map -closely to ECT structures: PROV Activities correspond to ECT -tasks, PROV Agents correspond to WIMSE workloads, and PROV's -"wasInformedBy" relation corresponds to ECT "par" references. -However, PROV uses RDF/OWL ontologies designed for post-hoc -documentation, while ECTs are runtime-embeddable JWT tokens with -cryptographic signatures. ECT audit data could be exported to -PROV format for interoperability with provenance-aware systems. - -## SCITT (Supply Chain Integrity, Transparency, and Trust) -{:numbered="false"} - -The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a -framework for transparent and auditable supply chain records. -ECTs and SCITT are complementary: the ECT "wid" claim can serve -as a correlation identifier in SCITT Signed Statements, linking -an ECT audit trail to a supply chain transparency record. - -# Acknowledgments -{:numbered="false"} - -The author thanks the WIMSE working group for their foundational -work on workload identity in multi-system environments. The -concepts of Workload Identity Tokens and Workload Proof Tokens -provide the identity foundation upon which execution context -tracing is built. diff --git a/draft-nennemann-wimse-ect-00.txt b/draft-nennemann-wimse-ect-00.txt deleted file mode 100644 index 33f2fe3..0000000 --- a/draft-nennemann-wimse-ect-00.txt +++ /dev/null @@ -1,1288 +0,0 @@ - - - - -WIMSE C. Nennemann -Internet-Draft Independent Researcher -Intended status: Standards Track 25 February 2026 -Expires: 29 August 2026 - - - Execution Context Tokens for Distributed Agentic Workflows - draft-nennemann-wimse-ect-00 - -Abstract - - This document defines Execution Context Tokens (ECTs), a JWT-based - extension to the WIMSE architecture that records task execution - across distributed agentic workflows. Each ECT is a signed record of - a single task, linked to predecessor tasks through a directed acyclic - graph (DAG). ECTs reuse the WIMSE signing model and are transported - in a new Execution-Context HTTP header field alongside existing WIMSE - identity headers. - -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 29 August 2026. - -Copyright Notice - - Copyright (c) 2026 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 1] - -Internet-Draft WIMSE Execution Context February 2026 - - - 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 - 1.1. Scope and Applicability . . . . . . . . . . . . . . . . . 3 - 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 - 3. Execution Context Token Format . . . . . . . . . . . . . . . 4 - 3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 5 - 3.2.2. Execution Context . . . . . . . . . . . . . . . . . . 6 - 3.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . 6 - 3.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 7 - 3.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 7 - 4. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Execution-Context Header Field . . . . . . . . . . . . . 8 - 5. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Signature and Token Verification . . . . . . . . . . . . . . 9 - 6.1. Verification Procedure . . . . . . . . . . . . . . . . . 9 - 7. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 12 - 8.2. Self-Assertion Limitation . . . . . . . . . . . . . . . . 12 - 8.3. Signature Verification . . . . . . . . . . . . . . . . . 12 - 8.4. Replay Attack Prevention . . . . . . . . . . . . . . . . 13 - 8.5. Man-in-the-Middle Protection . . . . . . . . . . . . . . 13 - 8.6. Key Compromise . . . . . . . . . . . . . . . . . . . . . 13 - 8.7. Collusion and DAG Integrity . . . . . . . . . . . . . . . 13 - 8.8. Privilege Escalation via ECTs . . . . . . . . . . . . . . 14 - 8.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 - 8.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 14 - 8.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 14 - 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 - 9.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . . 14 - 9.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 15 - 9.3. Storage and Access Control . . . . . . . . . . . . . . . 15 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10.1. Media Type Registration . . . . . . . . . . . . . . . . 15 - 10.2. HTTP Header Field Registration . . . . . . . . . . . . . 16 - 10.3. JWT Claims Registration . . . . . . . . . . . . . . . . 16 - - - -Nennemann Expires 29 August 2026 [Page 2] - -Internet-Draft WIMSE Execution Context February 2026 - - - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 11.2. Informative References . . . . . . . . . . . . . . . . . 18 - Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Cross-Organization Financial Trading . . . . . . . . . . . . . 19 - Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 21 - OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 21 - Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 21 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 22 - W3C Provenance Data Model (PROV) . . . . . . . . . . . . . . . 22 - SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 23 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 - -1. Introduction - - The WIMSE framework [I-D.ietf-wimse-arch] and its service-to- service - protocol [I-D.ietf-wimse-s2s-protocol] authenticate workloads across - call chains but do not record what those workloads actually did. - This document defines Execution Context Tokens (ECTs), a JWT-based - extension that fills the gap between workload identity and execution - accountability. Each ECT is a signed record of a single task, linked - to predecessor tasks through a directed acyclic graph (DAG). - -1.1. Scope and Applicability - - This document defines: - - * The Execution Context Token (ECT) format (Section 3) - - * DAG structure for task dependency ordering (Section 5) - - * An HTTP header for ECT transport (Section 4) - - * Audit ledger interface requirements (Section 7) - - The following are out of scope and are handled by WIMSE: - - * Workload authentication and identity provisioning - - * Key distribution and management - - * Trust domain establishment and management - - * Credential lifecycle management - - - - - -Nennemann Expires 29 August 2026 [Page 3] - -Internet-Draft WIMSE Execution Context February 2026 - - -2. Conventions and Definitions - - 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. - - The following terms are used in this document: - - Agent: An autonomous workload, as defined by WIMSE - [I-D.ietf-wimse-arch], that executes tasks within a workflow. - - Task: A discrete unit of agent work that consumes inputs and - produces outputs. - - Directed Acyclic Graph (DAG): A graph structure representing task - dependency ordering where edges are directed and no cycles exist. - - Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by - this specification that records task execution details. - - Audit Ledger: An append-only, immutable log of all ECTs within a - workflow or set of workflows, used for audit and verification. - - Workload Identity Token (WIT): A WIMSE credential proving a - workload's identity within a trust domain. - - Workload Proof Token (WPT): A WIMSE proof-of-possession token used - for request-level authentication. - - Trust Domain: A WIMSE concept representing an organizational - boundary with a shared identity issuer, corresponding to a SPIFFE - [SPIFFE] trust domain. - -3. Execution Context Token Format - - An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed - as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use JWS Compact - Serialization (the base64url-encoded header.payload.signature format) - so that they can be carried in a single HTTP header value. - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 4] - -Internet-Draft WIMSE Execution Context February 2026 - - - ECTs reuse the WIMSE signing model. The ECT MUST be signed with the - same private key associated with the agent's WIT. The JOSE header - "kid" parameter MUST reference the public key identifier from the - agent's WIT, and the "alg" parameter MUST match the algorithm used in - the corresponding WIT. In WIMSE deployments, the ECT "iss" claim - SHOULD use the WIMSE workload identifier format (a SPIFFE ID - [SPIFFE]). - -3.1. JOSE Header - - The ECT JOSE header MUST contain the following parameters: - - { - "alg": "ES256", - "typ": "wimse-exec+jwt", - "kid": "agent-a-key-id-123" - } - - Figure 1: ECT JOSE Header Example - - alg: REQUIRED. The digital signature algorithm used to sign the - ECT. MUST match the algorithm in the corresponding WIT. - Implementations MUST support ES256 [RFC7518]. The "alg" value - MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384, - HS512) MUST NOT be used, as ECTs require asymmetric signatures for - non-repudiation. - - typ: REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs - from other JWT types, consistent with the WIMSE convention for - type parameter values. - - kid: REQUIRED. The key identifier referencing the public key from - the agent's WIT [RFC7517]. Used by verifiers to look up the - correct public key for signature verification. - -3.2. JWT Claims - -3.2.1. Standard JWT Claims - - An ECT MUST contain the following standard JWT claims [RFC7519]: - - iss: REQUIRED. StringOrURI. A URI identifying the issuer of the - ECT. In WIMSE deployments, this SHOULD be the workload's SPIFFE - ID in the format spiffe:///, matching the - "sub" claim of the agent's WIT. Non-WIMSE deployments MAY use - other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers). - - aud: REQUIRED. StringOrURI or array of StringOrURI. The intended - - - -Nennemann Expires 29 August 2026 [Page 5] - -Internet-Draft WIMSE Execution Context February 2026 - - - recipient(s) of the ECT. The "aud" claim SHOULD contain the - identifiers of all entities that will verify the ECT. When an ECT - must be verified by both the next agent and the audit ledger - independently, "aud" MUST be an array containing both identifiers. - Each verifier checks that its own identity appears in "aud". - - iat: REQUIRED. NumericDate. The time at which the ECT was issued. - - exp: REQUIRED. NumericDate. The expiration time of the ECT. - Implementations SHOULD set this to 5 to 15 minutes after "iat". - - jti: REQUIRED. String. A unique identifier for both the ECT and - the task it records, in UUID format [RFC9562]. The "jti" serves - as both the token identifier (for replay detection) and the task - identifier (for DAG parent references in "par"). Receivers MUST - reject ECTs whose "jti" has already been seen within the - expiration window. When "wid" is present, uniqueness is scoped to - the workflow; when "wid" is absent, uniqueness MUST be enforced - globally across the ECT store. - -3.2.2. Execution Context - - The following claims are defined by this specification: - - wid: OPTIONAL. String. A workflow identifier that groups related - ECTs into a single workflow. When present, MUST be a UUID - [RFC9562]. - - exec_act: REQUIRED. String. The action or task type identifier - describing what the agent performed (e.g., "process_payment", - "validate_safety"). This claim name avoids collision with the - "act" (Actor) claim registered by [RFC8693]. - - par: REQUIRED. Array of strings. Parent task identifiers - representing DAG dependencies. Each element MUST be the "jti" - value of a previously verified ECT. An empty array indicates a - root task with no dependencies. A workflow MAY contain multiple - root tasks. - -3.2.3. Data Integrity - - The following claims provide integrity verification for task inputs - and outputs without revealing the data itself: - - inp_hash: OPTIONAL. String. The base64url encoding (without - - - - - - -Nennemann Expires 29 August 2026 [Page 6] - -Internet-Draft WIMSE Execution Context February 2026 - - - padding) of the SHA-256 hash of the input data, computed over the - raw octets of the input. SHA-256 is the mandatory algorithm with - no algorithm prefix in the value, consistent with [RFC9449] and - [I-D.ietf-wimse-s2s-protocol]. - - out_hash: OPTIONAL. String. The base64url encoding (without - padding) of the SHA-256 hash of the output data, using the same - format as "inp_hash". - -3.2.4. Extensions - - ext: OPTIONAL. Object. A general-purpose extension object for - domain-specific claims not defined by this specification. - Implementations that do not understand extension claims MUST - ignore them. Extension key names SHOULD use reverse domain - notation (e.g., "com.example.custom_field") to avoid collisions. - The serialized "ext" object SHOULD NOT exceed 4096 bytes and - SHOULD NOT exceed a nesting depth of 5 levels. - -3.3. Complete ECT Example - - The following is a complete ECT payload example: - - { - "iss": "spiffe://example.com/agent/clinical", - "aud": "spiffe://example.com/agent/safety", - "iat": 1772064150, - "exp": 1772064750, - "jti": "550e8400-e29b-41d4-a716-446655440001", - - "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789", - "exec_act": "recommend_treatment", - "par": [], - - "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", - - "ext": { - "com.example.trace_id": "abc123" - } - } - - Figure 2: Complete ECT Payload Example - -4. HTTP Header Transport - - - - - - -Nennemann Expires 29 August 2026 [Page 7] - -Internet-Draft WIMSE Execution Context February 2026 - - -4.1. Execution-Context Header Field - - This specification defines the Execution-Context HTTP header field - [RFC9110] for transporting ECTs between agents. - - The header field value is the ECT in JWS Compact Serialization format - [RFC7515]. The value consists of three Base64url-encoded parts - separated by period (".") characters. - - An agent sending a request to another agent includes the Execution- - Context header alongside the WIMSE Workload-Identity header. When a - Workload Proof Token (WPT) is available per - [I-D.ietf-wimse-s2s-protocol], agents SHOULD include it alongside the - WIT and ECT. - - GET /api/safety-check HTTP/1.1 - Host: safety-agent.example.com - Workload-Identity: eyJhbGci...WIT... - Execution-Context: eyJhbGci...ECT... - - Figure 3: HTTP Request with ECT Header - - When multiple parent tasks contribute context to a single request, - multiple Execution-Context header field lines MAY be included, each - carrying a separate ECT in JWS Compact Serialization format. - - When a receiver processes multiple Execution-Context headers, it MUST - individually verify each ECT per the procedure in Section 6. If any - single ECT fails verification, the receiver MUST reject the entire - request. The set of verified parent task IDs across all received - ECTs represents the complete set of parent dependencies available for - the receiving agent's subsequent ECT. - -5. DAG Validation - - ECTs form a Directed Acyclic Graph (DAG) where each task references - its parent tasks via the "par" claim. DAG validation is performed - against the ECT store — either an audit ledger or the set of parent - ECTs received inline. - - When receiving and verifying an ECT, implementations MUST perform the - following DAG validation steps: - - 1. Task ID Uniqueness: The "jti" claim MUST be unique within the - applicable scope (the workflow identified by "wid", or the entire - ECT store if "wid" is absent). If an ECT with the same "jti" - already exists, the ECT MUST be rejected. - - - - -Nennemann Expires 29 August 2026 [Page 8] - -Internet-Draft WIMSE Execution Context February 2026 - - - 2. Parent Existence: Every task identifier listed in the "par" array - MUST correspond to a task that is available in the ECT store - (either previously recorded in the ledger or received inline as a - verified parent ECT). If any parent task is not found, the ECT - MUST be rejected. - - 3. Temporal Ordering: The "iat" value of every parent task MUST NOT - be greater than the "iat" value of the current task plus a - configurable clock skew tolerance (RECOMMENDED: 30 seconds). - That is, for each parent: parent.iat < child.iat + - clock_skew_tolerance. The tolerance accounts for clock skew - between agents; it does not guarantee strict causal ordering from - timestamps alone. Causal ordering is primarily enforced by the - DAG structure (parent existence in the ECT store), not by - timestamps. If any parent task violates this constraint, the ECT - MUST be rejected. - - 4. Acyclicity: Following the chain of parent references MUST NOT - lead back to the current ECT's "jti". If a cycle is detected, - the ECT MUST be rejected. - - 5. Trust Domain Consistency: Parent tasks SHOULD belong to the same - trust domain or to a trust domain with which a federation - relationship has been established. - - To prevent denial-of-service via extremely deep or wide DAGs, - implementations SHOULD enforce a maximum ancestor traversal limit - (RECOMMENDED: 10000 nodes). If the limit is reached before cycle - detection completes, the ECT SHOULD be rejected. - - In distributed deployments, a parent ECT may not yet be available - locally due to replication lag. Implementations MAY defer validation - to allow parent ECTs to arrive, but MUST NOT treat the ECT as - verified until all parent references are resolved. - -6. Signature and Token Verification - -6.1. Verification Procedure - - When an agent receives an ECT, it MUST perform the following - verification steps in order: - - 1. Parse the JWS Compact Serialization to extract the JOSE header, - payload, and signature components per [RFC7515]. - - 2. Verify that the "typ" header parameter is "wimse-exec+jwt". - - - - - -Nennemann Expires 29 August 2026 [Page 9] - -Internet-Draft WIMSE Execution Context February 2026 - - - 3. Verify that the "alg" header parameter appears in the verifier's - configured allowlist of accepted signing algorithms. The - allowlist MUST NOT include "none" or any symmetric algorithm - (e.g., HS256, HS384, HS512). Implementations MUST include ES256 - in the allowlist; additional asymmetric algorithms MAY be - included per deployment policy. - - 4. Verify the "kid" header parameter references a known, valid - public key from a WIT within the trust domain. - - 5. Retrieve the public key identified by "kid" and verify the JWS - signature per [RFC7515] Section 5.2. - - 6. Verify that the signing key identified by "kid" has not been - revoked within the trust domain. Implementations MUST check the - key's revocation status using the trust domain's key lifecycle - mechanism (e.g., certificate revocation list, OCSP, or SPIFFE - trust bundle updates). - - 7. Verify the "alg" header parameter matches the algorithm in the - corresponding WIT. - - 8. Verify the "iss" claim matches the "sub" claim of the WIT - associated with the "kid" public key. - - 9. Verify the "aud" claim contains the verifier's own workload - identity. When "aud" is an array, it is sufficient that the - verifier's identity appears as one element; the presence of - other audience values does not cause verification failure. When - the verifier is the audit ledger, the ledger's own identity MUST - appear in "aud". - - 10. Verify the "exp" claim indicates the ECT has not expired. - - 11. Verify the "iat" claim is not unreasonably far in the past - (implementation-specific threshold, RECOMMENDED maximum of 15 - minutes) and is not unreasonably far in the future (RECOMMENDED: - no more than 30 seconds ahead of the verifier's current time, to - account for clock skew). - - 12. Verify all required claims ("jti", "exec_act", "par") are - present and well-formed. - - 13. Perform DAG validation per Section 5. - - 14. If all checks pass and an audit ledger is deployed, the ECT - SHOULD be appended to the ledger. - - - - -Nennemann Expires 29 August 2026 [Page 10] - -Internet-Draft WIMSE Execution Context February 2026 - - - If any verification step fails, the ECT MUST be rejected and the - failure MUST be logged for audit purposes. Error messages SHOULD NOT - reveal whether specific parent task IDs exist in the ECT store, to - prevent information disclosure. - - When ECT verification fails during HTTP request processing, the - receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT - is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the - ECT signature verification fails. The response body SHOULD include a - generic error indicator without revealing which specific verification - step failed. The receiving agent MUST NOT process the requested - action when ECT verification fails. - -7. Audit Ledger Interface - - ECTs MAY be recorded in an immutable audit ledger for compliance - verification and post-hoc analysis. A ledger is RECOMMENDED for - regulated environments but is not required for point-to-point - operation. This specification does not mandate a specific storage - technology. Implementations MAY use append-only logs, databases with - cryptographic commitment schemes, distributed ledgers, or any storage - mechanism that provides the required properties. - - When an audit ledger is deployed, the implementation MUST provide: - - 1. Append-only semantics: Once an ECT is recorded, it MUST NOT be - modified or deleted. - - 2. Ordering: The ledger MUST maintain a total ordering of ECT - entries via a monotonically increasing sequence number. - - 3. Lookup by ECT ID: The ledger MUST support efficient retrieval of - ECT entries by "jti" value. - - 4. Integrity verification: The ledger SHOULD provide a mechanism to - verify that no entries have been tampered with (e.g., hash chains - or Merkle trees). - - The ledger SHOULD be maintained by an entity independent of the - workflow agents to reduce the risk of collusion. - -8. Security Considerations - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 11] - -Internet-Draft WIMSE Execution Context February 2026 - - -8.1. Threat Model - - The threat model considers: (1) a malicious agent that creates false - ECT claims, (2) an agent whose private key has been compromised, (3) - a ledger tamperer attempting to modify recorded entries, and (4) a - time manipulator altering timestamps to affect perceived ordering. - -8.2. Self-Assertion Limitation - - ECTs are self-asserted by the executing agent. The agent claims what - it did, and this claim is signed with its private key. A compromised - or malicious agent could create ECTs with false claims (e.g., - claiming an action was performed when it was not). - - ECTs do not independently verify that: - - * The claimed execution actually occurred as described - - * The input/output hashes correspond to the actual data processed - - * The agent faithfully performed the stated action - - The trustworthiness of ECT claims depends on the trustworthiness of - the signing agent and the integrity of the broader deployment - environment. ECTs provide a technical mechanism for execution - recording; they do not by themselves satisfy any specific regulatory - compliance requirement. - -8.3. Signature Verification - - ECTs MUST be signed with the agent's private key using JWS [RFC7515]. - The signature algorithm MUST match the algorithm specified in the - agent's WIT. Receivers MUST verify the ECT signature against the WIT - public key before processing any claims. Receivers MUST verify that - the signing key has not been revoked within the trust domain (see - step 6 in Section 6). - - If signature verification fails or if the signing key has been - revoked, the ECT MUST be rejected entirely and the failure MUST be - logged. - - Implementations MUST use established JWS libraries and MUST NOT - implement custom signature verification. - - - - - - - - -Nennemann Expires 29 August 2026 [Page 12] - -Internet-Draft WIMSE Execution Context February 2026 - - -8.4. Replay Attack Prevention - - ECTs include short expiration times (RECOMMENDED: 5-15 minutes) and - audience restriction via "aud" to limit replay attacks. - Implementations MUST maintain a cache of recently-seen "jti" values - and MUST reject ECTs with duplicate "jti" values. Each ECT is - cryptographically bound to the issuing agent via "kid"; verifiers - MUST confirm that "kid" resolves to the "iss" agent's key (step 8 in - Section 6). - -8.5. Man-in-the-Middle Protection - - ECTs MUST be transmitted over TLS or mTLS connections. When used - with [I-D.ietf-wimse-s2s-protocol], transport security is already - established. - -8.6. Key Compromise - - If an agent's private key is compromised, an attacker can forge ECTs - that appear to originate from that agent. Mitigations: - - * Implementations SHOULD use short-lived keys and rotate them - frequently. - - * Private keys SHOULD be stored in hardware security modules or - equivalent secure key storage. - - * Trust domains MUST support rapid key revocation. - - ECTs recorded before key revocation remain valid historical records - but SHOULD be flagged for audit purposes. New ECTs MUST NOT - reference a parent ECT whose signing key is known to be revoked at - creation time. - -8.7. Collusion and DAG Integrity - - A single malicious agent cannot forge parent task references because - DAG validation requires parent tasks to exist in the ECT store. - However, multiple colluding agents could create a false execution - history. Additionally, a malicious agent may omit actual parent - dependencies from "par" to hide influences on its output; because - ECTs are self-asserted (Section 8.2), no mechanism can force complete - dependency declaration. - - Mitigations include: - - * The ledger SHOULD be maintained by an entity independent of the - workflow agents. - - - -Nennemann Expires 29 August 2026 [Page 13] - -Internet-Draft WIMSE Execution Context February 2026 - - - * Multiple independent ledger replicas can be compared for - consistency. - - * External auditors can compare the declared DAG against expected - workflow patterns. - - Verifiers SHOULD validate that the declared "wid" of parent ECTs - matches the "wid" of the child ECT, rejecting cross-workflow parent - references unless explicitly permitted by deployment policy. - -8.8. Privilege Escalation via ECTs - - ECTs record execution history; they do not convey authorization. - Verifiers MUST NOT interpret the presence of an ECT, or a particular - set of parent references in "par", as an authorization grant. - Authorization decisions MUST remain with the identity and - authorization layer (WIT, WPT, and deployment policy). - -8.9. Denial of Service - - Implementations SHOULD apply rate limiting to prevent excessive ECT - submissions. DAG validation SHOULD be performed after signature - verification to avoid wasting resources on unsigned tokens. - -8.10. Timestamp Accuracy - - Implementations SHOULD use synchronized time sources (e.g., NTP) and - SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30 - seconds). Cross-organizational deployments MAY require a higher - tolerance and SHOULD document the configured value. - -8.11. ECT Size Constraints - - Implementations SHOULD limit the "par" array to a maximum of 256 - entries. See Section 3.2.4 for "ext" size limits. - -9. Privacy Considerations - -9.1. Data Exposure in ECTs - - ECTs necessarily reveal: - - * Agent identities ("iss", "aud") for accountability purposes - - * Action descriptions ("exec_act") for audit trail completeness - - * Timestamps ("iat", "exp") for temporal ordering - - - - -Nennemann Expires 29 August 2026 [Page 14] - -Internet-Draft WIMSE Execution Context February 2026 - - - ECTs are designed to NOT reveal: - - * Actual input or output data values (replaced with cryptographic - hashes via "inp_hash" and "out_hash") - - * Internal computation details or intermediate steps - - * Proprietary algorithms or intellectual property - - * Personally identifiable information (PII) - -9.2. Data Minimization - - Implementations SHOULD minimize the information included in ECTs. - The "exec_act" claim SHOULD use structured identifiers (e.g., - "process_payment") rather than natural language descriptions. - Extension keys in "ext" (Section 3.2.4) deserve particular attention: - human-readable values risk exposing sensitive operational details. - See Section 3.2.4 for guidance on using structured identifiers. - -9.3. Storage and Access Control - - ECTs stored in audit ledgers SHOULD be access-controlled so that only - authorized auditors can read them. Implementations SHOULD consider - encryption at rest for ledger storage. ECTs provide structural - records of execution ordering; they are not intended for public - disclosure. - - Full input and output data (corresponding to the hashes in ECTs) - SHOULD be stored separately from the ledger with additional access - controls, since auditors may need to verify hash correctness but - general access to the data values is not needed. - -10. IANA Considerations - -10.1. Media Type Registration - - This document requests registration of the following media type in - the "Media Types" registry maintained by IANA: - - Type name: application - - Subtype name: wimse-exec+jwt - - Required parameters: none - - Optional parameters: none - - - - -Nennemann Expires 29 August 2026 [Page 15] - -Internet-Draft WIMSE Execution Context February 2026 - - - Encoding considerations: 8bit; an ECT is a JWT that is a JWS using - the Compact Serialization, which is a sequence of Base64url- - encoded values separated by period characters. - - Security considerations: See the Security Considerations section of - this document. - - Interoperability considerations: none - - Published specification: This document - - Applications that use this media type: Applications that implement - agentic workflows requiring execution context tracing and audit - trails. - - Additional information: Magic number(s): none File extension(s): - none Macintosh file type code(s): none - - Person and email address to contact for further information: Christi - an Nennemann, ietf@nennemann.de - - Intended usage: COMMON - - Restrictions on usage: none - - Author: Christian Nennemann - - Change controller: IETF - -10.2. HTTP Header Field Registration - - This document requests registration of the following header field in - the "Hypertext Transfer Protocol (HTTP) Field Name Registry" - maintained by IANA: - - Field name: Execution-Context - - Status: permanent - - Specification document: This document, Section 4 - -10.3. JWT Claims Registration - - This document requests registration of the following claims in the - "JSON Web Token Claims" registry maintained by IANA: - - - - - - -Nennemann Expires 29 August 2026 [Page 16] - -Internet-Draft WIMSE Execution Context February 2026 - - - +============+=====================+===================+===========+ - | Claim Name | Claim Description | Change Controller | Reference | - +============+=====================+===================+===========+ - | wid | Workflow Identifier | IETF | Section | - | | | | 3.2.2 | - +------------+---------------------+-------------------+-----------+ - | exec_act | Action/Task Type | IETF | Section | - | | | | 3.2.2 | - +------------+---------------------+-------------------+-----------+ - | par | Parent Task | IETF | Section | - | | Identifiers | | 3.2.2 | - +------------+---------------------+-------------------+-----------+ - | inp_hash | Input Data Hash | IETF | Section | - | | | | 3.2.3 | - +------------+---------------------+-------------------+-----------+ - | out_hash | Output Data Hash | IETF | Section | - | | | | 3.2.3 | - +------------+---------------------+-------------------+-----------+ - | ext | Extension Object | IETF | Section | - | | | | 3.2.4 | - +------------+---------------------+-------------------+-----------+ - - Table 1: JWT Claims Registrations - -11. References - -11.1. Normative References - - [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-06, 30 September 2025, - . - - [I-D.ietf-wimse-s2s-protocol] - Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. - Sheffer, "WIMSE Workload-to-Workload Authentication", Work - in Progress, Internet-Draft, draft-ietf-wimse-s2s- - protocol-07, 16 October 2025, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - - -Nennemann Expires 29 August 2026 [Page 17] - -Internet-Draft WIMSE Execution Context February 2026 - - - [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web - Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, - DOI 10.17487/RFC7517, May 2015, - . - - [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, - DOI 10.17487/RFC7518, May 2015, - . - - [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, - Ed., "HTTP Semantics", STD 97, RFC 9110, - DOI 10.17487/RFC9110, June 2022, - . - - [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique - IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May - 2024, . - -11.2. Informative References - - [I-D.ietf-oauth-transaction-tokens] - Tulshibagwale, A., Fletcher, G., and P. Kasselman, - "Transaction Tokens", Work in Progress, Internet-Draft, - draft-ietf-oauth-transaction-tokens-07, 24 January 2026, - . - - [I-D.ietf-scitt-architecture] - Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, - Y., and S. Lasker, "An Architecture for Trustworthy and - Transparent Digital Supply Chains", Work in Progress, - Internet-Draft, draft-ietf-scitt-architecture-22, 10 - October 2025, . - - - - - - -Nennemann Expires 29 August 2026 [Page 18] - -Internet-Draft WIMSE Execution Context February 2026 - - - [I-D.oauth-transaction-tokens-for-agents] - Raut, A., "Transaction Tokens For Agents", Work in - Progress, Internet-Draft, draft-oauth-transaction-tokens- - for-agents-04, 10 February 2026, - . - - [OPENTELEMETRY] - Cloud Native Computing Foundation, "OpenTelemetry - Specification", - . - - [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., - and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, - DOI 10.17487/RFC8693, January 2020, - . - - [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., - Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of - Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, - September 2023, . - - [SPIFFE] "Secure Production Identity Framework for Everyone - (SPIFFE)", - . - -Use Cases - - This section describes a representative use case demonstrating how - ECTs provide structured execution records. - - Note: task identifiers in this section are abbreviated for - readability. In production, all "jti" values are required to be - UUIDs per Section 3.2.2. - -Cross-Organization Financial Trading - - In a cross-organization trading workflow, an investment bank's agents - coordinate with an external credit rating agency. The agents operate - in separate trust domains with a federation relationship. The DAG - records that independent assessments from both organizations were - completed before trade execution. - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 19] - -Internet-Draft WIMSE Execution Context February 2026 - - - Trust Domain: bank.example - Agent A1 (Portfolio Risk): - jti: task-001 par: [] - iss: spiffe://bank.example/agent/risk - exec_act: analyze_portfolio_risk - - Trust Domain: ratings.example (external) - Agent B1 (Credit Rating): - jti: task-002 par: [] - iss: spiffe://ratings.example/agent/credit - exec_act: assess_credit_rating - - Trust Domain: bank.example - Agent A2 (Compliance): - jti: task-003 par: [task-001, task-002] - iss: spiffe://bank.example/agent/compliance - exec_act: verify_trade_compliance - - Agent A3 (Execution): - jti: task-004 par: [task-003] - iss: spiffe://bank.example/agent/execution - exec_act: execute_trade - - Figure 4: Cross-Organization Trading Workflow - - The resulting DAG: - - task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating) - [bank.example] [ratings.example] - \ / - v v - task-003 (verify_trade_compliance) - [bank.example] - | - v - task-004 (execute_trade) - [bank.example] - - Figure 5: Cross-Organization DAG - - Task 003 has two parents from different trust domains, demonstrating - cross-organizational fan-in. The compliance agent verifies both - parent ECTs — one signed by a local key and one by a federated key - from the rating agency's trust domain. - - - - - - - -Nennemann Expires 29 August 2026 [Page 20] - -Internet-Draft WIMSE Execution Context February 2026 - - -Related Work - -WIMSE Workload Identity - - The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service - protocol [I-D.ietf-wimse-s2s-protocol] provide the identity - foundation upon which ECTs are built. WIT/WPT answer "who is this - agent?" and "does it control the claimed key?" while ECTs record - "what did this agent do?" Together they form an identity-plus- - accountability framework for regulated agentic systems. - -OAuth 2.0 Token Exchange and the "act" Claim - - [RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers - the "act" (Actor) claim in the JWT Claims registry. The "act" claim - creates nested JSON objects representing a delegation chain: "who is - acting on behalf of whom." While the nesting superficially resembles - a chain, it is strictly linear (each "act" object contains at most - one nested "act"), represents authorization delegation rather than - task execution, and carries no task identifiers or input/output - integrity data. The "act" chain cannot represent branching (fan-out) - or convergence (fan-in) and therefore cannot form a DAG. - - ECTs intentionally use the distinct claim name "exec_act" for the - action/task type to avoid collision with the "act" claim. The two - concepts are orthogonal: "act" records "who authorized whom," ECTs - record "what was done, in what order." - -Transaction Tokens - - OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] - propagate authorization context across workload call chains. The - Txn-Token "req_wl" claim accumulates a comma-separated list of - workloads that requested replacement tokens, which is the closest - existing mechanism to call-chain recording. - - However, "req_wl" cannot form a DAG because: - - * It is linear: a comma-separated string with no branching or - merging representation. When a workload fans out to multiple - downstream services, each receives the same "req_wl" value and the - branching is invisible. - - * It is incomplete: only workloads that request a replacement token - from the Transaction Token Service appear in "req_wl"; workloads - that forward the token unchanged are not recorded. - - - - - -Nennemann Expires 29 August 2026 [Page 21] - -Internet-Draft WIMSE Execution Context February 2026 - - - * It carries no task-level granularity, no parent references, and no - execution content. - - * It cannot represent convergence (fan-in): when two independent - paths must both complete before a dependent task proceeds, a - linear "req_wl" string cannot express that relationship. - - Extensions for agentic use cases - ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and - constraints ("agentic_ctx") but no execution ordering or DAG - structure. - - ECTs and Transaction Tokens are complementary: a Txn-Token propagates - authorization context ("this request is authorized for scope X on - behalf of user Y"), while an ECT records execution accountability - ("task T was performed, depending on tasks P1 and P2"). An agent - request could carry both a Txn-Token for authorization and an ECT for - execution recording. The WPT "tth" claim defined in - [I-D.ietf-wimse-s2s-protocol] can hash-bind a WPT to a co-present - Txn-Token; a similar binding mechanism for ECTs is a potential future - extension. - -Distributed Tracing (OpenTelemetry) - - OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems - provide observability for debugging and monitoring. ECTs differ in - several important ways: ECTs are cryptographically signed per-task - with the agent's private key; ECTs are tamper-evident through JWS - signatures; ECTs enforce DAG validation rules; and ECTs are designed - for regulatory audit rather than operational monitoring. - OpenTelemetry data is typically controlled by the platform operator - and can be modified or deleted without detection. ECTs and - distributed traces are complementary: traces provide observability - while ECTs provide signed execution records. ECTs may reference - OpenTelemetry trace identifiers in the "ext" claim for correlation. - -W3C Provenance Data Model (PROV) - - The W3C PROV Data Model defines an Entity-Activity-Agent ontology for - representing provenance information. PROV's concepts map closely to - ECT structures: PROV Activities correspond to ECT tasks, PROV Agents - correspond to WIMSE workloads, and PROV's "wasInformedBy" relation - corresponds to ECT "par" references. However, PROV uses RDF/OWL - ontologies designed for post-hoc documentation, while ECTs are - runtime-embeddable JWT tokens with cryptographic signatures. ECT - audit data could be exported to PROV format for interoperability with - provenance-aware systems. - - - - -Nennemann Expires 29 August 2026 [Page 22] - -Internet-Draft WIMSE Execution Context February 2026 - - -SCITT (Supply Chain Integrity, Transparency, and Trust) - - The SCITT architecture [I-D.ietf-scitt-architecture] defines a - framework for transparent and auditable supply chain records. ECTs - and SCITT are complementary: the ECT "wid" claim can serve as a - correlation identifier in SCITT Signed Statements, linking an ECT - audit trail to a supply chain transparency record. - -Acknowledgments - - The author thanks the WIMSE working group for their foundational work - on workload identity in multi-system environments. The concepts of - Workload Identity Tokens and Workload Proof Tokens provide the - identity foundation upon which execution context tracing is built. - -Author's Address - - Christian Nennemann - Independent Researcher - Email: ietf@nennemann.de - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 23] diff --git a/draft-nennemann-wimse-ect-00.xml b/draft-nennemann-wimse-ect-00.xml deleted file mode 100644 index 531f067..0000000 --- a/draft-nennemann-wimse-ect-00.xml +++ /dev/null @@ -1,1690 +0,0 @@ - - - - - - - - - - -]> - - - - - Execution Context Tokens for Distributed Agentic Workflows - - - Independent Researcher -
- ietf@nennemann.de -
- - - - - ART - WIMSE - execution context workload identity agentic workflows audit trail - - - - - - -This document defines Execution Context Tokens (ECTs), a JWT-based -extension to the WIMSE architecture that records task execution -across distributed agentic workflows. Each ECT is a signed record -of a single task, linked to predecessor tasks through a directed -acyclic graph (DAG). ECTs reuse the WIMSE signing model and are -transported in a new Execution-Context HTTP header field alongside -existing WIMSE identity headers. - - - - - - - - - - - - - - -
Introduction - -The WIMSE framework and its service-to- -service protocol authenticate -workloads across call chains but do not record what those -workloads actually did. This document defines Execution Context -Tokens (ECTs), a JWT-based extension that fills the gap between -workload identity and execution accountability. Each ECT is a -signed record of a single task, linked to predecessor tasks -through a directed acyclic graph (DAG). - -
Scope and Applicability - -This document defines: - - - The Execution Context Token (ECT) format () - DAG structure for task dependency ordering () - An HTTP header for ECT transport () - Audit ledger interface requirements () - - -The following are out of scope and are handled by WIMSE: - - - Workload authentication and identity provisioning - Key distribution and management - Trust domain establishment and management - Credential lifecycle management - - -
-
-
Conventions and Definitions - -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 when, and only when, they -appear in all capitals, as shown here. - - - -The following terms are used in this document: - -
-
Agent:
-
- An autonomous workload, as defined by WIMSE -, that executes tasks within a workflow. -
-
Task:
-
- A discrete unit of agent work that consumes inputs and produces -outputs. -
-
Directed Acyclic Graph (DAG):
-
- A graph structure representing task dependency ordering where -edges are directed and no cycles exist. -
-
Execution Context Token (ECT):
-
- A JSON Web Token defined by this specification that -records task execution details. -
-
Audit Ledger:
-
- An append-only, immutable log of all ECTs within a workflow or -set of workflows, used for audit and verification. -
-
Workload Identity Token (WIT):
-
- A WIMSE credential proving a workload's identity within a trust -domain. -
-
Workload Proof Token (WPT):
-
- A WIMSE proof-of-possession token used for request-level -authentication. -
-
Trust Domain:
-
- A WIMSE concept representing an organizational boundary with a -shared identity issuer, corresponding to a SPIFFE -trust domain. -
-
- -
-
Execution Context Token Format - -An Execution Context Token is a JSON Web Token (JWT) -signed as a JSON Web Signature (JWS) . ECTs MUST use -JWS Compact Serialization (the base64url-encoded -header.payload.signature format) so that they can be carried in -a single HTTP header value. - -ECTs reuse the WIMSE signing model. The ECT MUST be signed with -the same private key associated with the agent's WIT. The JOSE -header "kid" parameter MUST reference the public key identifier -from the agent's WIT, and the "alg" parameter MUST match the -algorithm used in the corresponding WIT. In WIMSE deployments, -the ECT "iss" claim SHOULD use the WIMSE workload identifier -format (a SPIFFE ID ). - -
JOSE Header - -The ECT JOSE header MUST contain the following parameters: - -
- -
-
alg:
-
- REQUIRED. The digital signature algorithm used to sign the ECT. -MUST match the algorithm in the corresponding WIT. -Implementations MUST support ES256 . The "alg" -value MUST NOT be "none". Symmetric algorithms (e.g., HS256, -HS384, HS512) MUST NOT be used, as ECTs require asymmetric -signatures for non-repudiation. -
-
typ:
-
- REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs -from other JWT types, consistent with the WIMSE convention for -type parameter values. -
-
kid:
-
- REQUIRED. The key identifier referencing the public key from -the agent's WIT . Used by verifiers to look up the -correct public key for signature verification. -
-
- -
-
JWT Claims - -
Standard JWT Claims - -An ECT MUST contain the following standard JWT claims : - -
-
iss:
-
- REQUIRED. StringOrURI. A URI identifying the issuer of the -ECT. In WIMSE deployments, this SHOULD be the workload's -SPIFFE ID in the format spiffe://<trust-domain>/<path>, -matching the "sub" claim of the agent's WIT. Non-WIMSE -deployments MAY use other URI schemes (e.g., HTTPS URLs or -URN:UUID identifiers). -
-
aud:
-
- REQUIRED. StringOrURI or array of StringOrURI. The intended -recipient(s) of the ECT. The "aud" claim SHOULD contain the -identifiers of all entities that will verify the ECT. When -an ECT must be verified by both the next agent and the audit -ledger independently, "aud" MUST be an array containing both -identifiers. Each verifier checks that its own identity -appears in "aud". -
-
iat:
-
- REQUIRED. NumericDate. The time at which the ECT was issued. -
-
exp:
-
- REQUIRED. NumericDate. The expiration time of the ECT. -Implementations SHOULD set this to 5 to 15 minutes after "iat". -
-
jti:
-
- REQUIRED. String. A unique identifier for both the ECT and -the task it records, in UUID format . The "jti" -serves as both the token identifier (for replay detection) and -the task identifier (for DAG parent references in "par"). -Receivers MUST reject ECTs whose "jti" has already been seen -within the expiration window. When "wid" is present, -uniqueness is scoped to the workflow; when "wid" is absent, -uniqueness MUST be enforced globally across the ECT store. -
-
- -
-
Execution Context - -The following claims are defined by this specification: - -
-
wid:
-
- OPTIONAL. String. A workflow identifier that groups related -ECTs into a single workflow. When present, MUST be a UUID -. -
-
exec_act:
-
- REQUIRED. String. The action or task type identifier describing -what the agent performed (e.g., "process_payment", -"validate_safety"). This claim name avoids collision with the -"act" (Actor) claim registered by . -
-
par:
-
- REQUIRED. Array of strings. Parent task identifiers -representing DAG dependencies. Each element MUST be the "jti" -value of a previously verified ECT. An empty array indicates -a root task with no dependencies. A workflow MAY contain -multiple root tasks. -
-
- -
-
Data Integrity - -The following claims provide integrity verification for task -inputs and outputs without revealing the data itself: - -
-
inp_hash:
-
- OPTIONAL. String. The base64url encoding (without padding) of -the SHA-256 hash of the input data, computed over the raw octets -of the input. SHA-256 is the mandatory algorithm with no -algorithm prefix in the value, consistent with and -. -
-
out_hash:
-
- OPTIONAL. String. The base64url encoding (without padding) of -the SHA-256 hash of the output data, using the same format as -"inp_hash". -
-
- -
-
Extensions - -
-
ext:
-
- OPTIONAL. Object. A general-purpose extension object for -domain-specific claims not defined by this specification. -Implementations that do not understand extension claims MUST -ignore them. Extension key names SHOULD use reverse domain -notation (e.g., "com.example.custom_field") to avoid -collisions. The serialized "ext" object SHOULD NOT exceed -4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels. -
-
- -
-
-
Complete ECT Example - -The following is a complete ECT payload example: - -
- -
-
-
HTTP Header Transport - -
Execution-Context Header Field - -This specification defines the Execution-Context HTTP header field - for transporting ECTs between agents. - -The header field value is the ECT in JWS Compact Serialization -format . The value consists of three Base64url-encoded -parts separated by period (".") characters. - -An agent sending a request to another agent includes the -Execution-Context header alongside the WIMSE Workload-Identity -header. When a Workload Proof Token (WPT) is available per -, agents SHOULD include it -alongside the WIT and ECT. - -
- -When multiple parent tasks contribute context to a single request, -multiple Execution-Context header field lines MAY be included, each -carrying a separate ECT in JWS Compact Serialization format. - -When a receiver processes multiple Execution-Context headers, it -MUST individually verify each ECT per the procedure in -. If any single ECT fails verification, the -receiver MUST reject the entire request. The set of verified -parent task IDs across all received ECTs represents the complete -set of parent dependencies available for the receiving agent's -subsequent ECT. - -
-
-
DAG Validation - -ECTs form a Directed Acyclic Graph (DAG) where each task -references its parent tasks via the "par" claim. DAG validation -is performed against the ECT store — either an audit ledger or -the set of parent ECTs received inline. - -When receiving and verifying an ECT, implementations MUST perform -the following DAG validation steps: - - - Task ID Uniqueness: The "jti" claim MUST be unique within the -applicable scope (the workflow identified by "wid", or the -entire ECT store if "wid" is absent). If an ECT with the same -"jti" already exists, the ECT MUST be rejected. - Parent Existence: Every task identifier listed in the "par" -array MUST correspond to a task that is available in the ECT -store (either previously recorded in the ledger or received -inline as a verified parent ECT). If any parent task is not -found, the ECT MUST be rejected. - Temporal Ordering: The "iat" value of every parent task MUST -NOT be greater than the "iat" value of the current task plus a -configurable clock skew tolerance (RECOMMENDED: 30 seconds). -That is, for each parent: parent.iat < child.iat + -clock_skew_tolerance. The tolerance accounts for clock skew -between agents; it does not guarantee strict causal ordering -from timestamps alone. Causal ordering is primarily enforced -by the DAG structure (parent existence in the ECT store), not by -timestamps. If any parent task violates this constraint, the -ECT MUST be rejected. - Acyclicity: Following the chain of parent references MUST NOT -lead back to the current ECT's "jti". If a cycle is detected, -the ECT MUST be rejected. - Trust Domain Consistency: Parent tasks SHOULD belong to the -same trust domain or to a trust domain with which a federation -relationship has been established. - - -To prevent denial-of-service via extremely deep or wide DAGs, -implementations SHOULD enforce a maximum ancestor traversal limit -(RECOMMENDED: 10000 nodes). If the limit is reached before cycle -detection completes, the ECT SHOULD be rejected. - -In distributed deployments, a parent ECT may not yet be available -locally due to replication lag. Implementations MAY defer -validation to allow parent ECTs to arrive, but MUST NOT treat -the ECT as verified until all parent references are resolved. - -
-
Signature and Token Verification - -
Verification Procedure - -When an agent receives an ECT, it MUST perform the following -verification steps in order: - - - Parse the JWS Compact Serialization to extract the JOSE header, -payload, and signature components per . - Verify that the "typ" header parameter is "wimse-exec+jwt". - Verify that the "alg" header parameter appears in the -verifier's configured allowlist of accepted signing algorithms. -The allowlist MUST NOT include "none" or any symmetric -algorithm (e.g., HS256, HS384, HS512). Implementations MUST -include ES256 in the allowlist; additional asymmetric algorithms -MAY be included per deployment policy. - Verify the "kid" header parameter references a known, valid -public key from a WIT within the trust domain. - Retrieve the public key identified by "kid" and verify the JWS -signature per Section 5.2. - Verify that the signing key identified by "kid" has not been -revoked within the trust domain. Implementations MUST check -the key's revocation status using the trust domain's key -lifecycle mechanism (e.g., certificate revocation list, OCSP, -or SPIFFE trust bundle updates). - Verify the "alg" header parameter matches the algorithm in the -corresponding WIT. - Verify the "iss" claim matches the "sub" claim of the WIT -associated with the "kid" public key. - Verify the "aud" claim contains the verifier's own workload -identity. When "aud" is an array, it is sufficient that the -verifier's identity appears as one element; the presence of -other audience values does not cause verification failure. -When the verifier is the audit ledger, the ledger's own -identity MUST appear in "aud". - Verify the "exp" claim indicates the ECT has not expired. - Verify the "iat" claim is not unreasonably far in the past -(implementation-specific threshold, RECOMMENDED maximum of -15 minutes) and is not unreasonably far in the future -(RECOMMENDED: no more than 30 seconds ahead of the -verifier's current time, to account for clock skew). - Verify all required claims ("jti", "exec_act", "par") are -present and well-formed. - Perform DAG validation per . - If all checks pass and an audit ledger is deployed, the ECT -SHOULD be appended to the ledger. - - -If any verification step fails, the ECT MUST be rejected and the -failure MUST be logged for audit purposes. Error messages -SHOULD NOT reveal whether specific parent task IDs exist in the -ECT store, to prevent information disclosure. - -When ECT verification fails during HTTP request processing, the -receiving agent SHOULD respond with HTTP 403 (Forbidden) if the -WIT is valid but the ECT is invalid, and HTTP 401 -(Unauthorized) if the ECT signature verification fails. The -response body SHOULD include a generic error indicator without -revealing which specific verification step failed. The receiving -agent MUST NOT process the requested action when ECT verification -fails. - -
-
-
Audit Ledger Interface - -ECTs MAY be recorded in an immutable audit ledger for compliance -verification and post-hoc analysis. A ledger is RECOMMENDED for -regulated environments but is not required for point-to-point -operation. This specification does not mandate a specific storage -technology. Implementations MAY use append-only logs, databases -with cryptographic commitment schemes, distributed ledgers, or -any storage mechanism that provides the required properties. - -When an audit ledger is deployed, the implementation MUST provide: - - - Append-only semantics: Once an ECT is recorded, it MUST NOT be -modified or deleted. - Ordering: The ledger MUST maintain a total ordering of ECT -entries via a monotonically increasing sequence number. - Lookup by ECT ID: The ledger MUST support efficient retrieval -of ECT entries by "jti" value. - Integrity verification: The ledger SHOULD provide a mechanism -to verify that no entries have been tampered with (e.g., -hash chains or Merkle trees). - - -The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion. - -
-
Security Considerations - -
Threat Model - -The threat model considers: (1) a malicious agent that creates -false ECT claims, (2) an agent whose private key has been -compromised, (3) a ledger tamperer attempting to modify recorded -entries, and (4) a time manipulator altering timestamps to affect -perceived ordering. - -
-
Self-Assertion Limitation - -ECTs are self-asserted by the executing agent. The agent claims -what it did, and this claim is signed with its private key. A -compromised or malicious agent could create ECTs with false claims -(e.g., claiming an action was performed when it was not). - -ECTs do not independently verify that: - - - The claimed execution actually occurred as described - The input/output hashes correspond to the actual data processed - The agent faithfully performed the stated action - - -The trustworthiness of ECT claims depends on the trustworthiness -of the signing agent and the integrity of the broader deployment -environment. ECTs provide a technical mechanism for execution -recording; they do not by themselves satisfy any specific -regulatory compliance requirement. - -
-
Signature Verification - -ECTs MUST be signed with the agent's private key using JWS -. The signature algorithm MUST match the algorithm -specified in the agent's WIT. Receivers MUST verify the ECT -signature against the WIT public key before processing any -claims. Receivers MUST verify that the signing key has not been -revoked within the trust domain (see step 6 in -). - -If signature verification fails or if the signing key has been -revoked, the ECT MUST be rejected entirely and the failure MUST -be logged. - -Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification. - -
-
Replay Attack Prevention - -ECTs include short expiration times (RECOMMENDED: 5-15 minutes) -and audience restriction via "aud" to limit replay attacks. -Implementations MUST maintain a cache of recently-seen "jti" -values and MUST reject ECTs with duplicate "jti" values. Each -ECT is cryptographically bound to the issuing agent via "kid"; -verifiers MUST confirm that "kid" resolves to the "iss" agent's -key (step 8 in ). - -
-
Man-in-the-Middle Protection - -ECTs MUST be transmitted over TLS or mTLS connections. When used -with , transport security is -already established. - -
-
Key Compromise - -If an agent's private key is compromised, an attacker can forge -ECTs that appear to originate from that agent. Mitigations: - - - Implementations SHOULD use short-lived keys and rotate them -frequently. - Private keys SHOULD be stored in hardware security modules or -equivalent secure key storage. - Trust domains MUST support rapid key revocation. - - -ECTs recorded before key revocation remain valid historical -records but SHOULD be flagged for audit purposes. New ECTs -MUST NOT reference a parent ECT whose signing key is known to -be revoked at creation time. - -
-
Collusion and DAG Integrity - -A single malicious agent cannot forge parent task references -because DAG validation requires parent tasks to exist in the ECT -store. However, multiple colluding agents could create a false -execution history. Additionally, a malicious agent may omit -actual parent dependencies from "par" to hide influences on its -output; because ECTs are self-asserted -(), no mechanism can force complete -dependency declaration. - -Mitigations include: - - - The ledger SHOULD be maintained by an entity independent of the -workflow agents. - Multiple independent ledger replicas can be compared for -consistency. - External auditors can compare the declared DAG against expected -workflow patterns. - - -Verifiers SHOULD validate that the declared "wid" of parent ECTs -matches the "wid" of the child ECT, rejecting cross-workflow -parent references unless explicitly permitted by deployment -policy. - -
-
Privilege Escalation via ECTs - -ECTs record execution history; they do not convey authorization. -Verifiers MUST NOT interpret the presence of an ECT, or a -particular set of parent references in "par", as an authorization -grant. Authorization decisions MUST remain with the identity and -authorization layer (WIT, WPT, and deployment policy). - -
-
Denial of Service - -Implementations SHOULD apply rate limiting to prevent excessive -ECT submissions. DAG validation SHOULD be performed after -signature verification to avoid wasting resources on unsigned -tokens. - -
-
Timestamp Accuracy - -Implementations SHOULD use synchronized time sources (e.g., NTP) -and SHOULD allow a configurable clock skew tolerance (RECOMMENDED: -30 seconds). Cross-organizational deployments MAY require a -higher tolerance and SHOULD document the configured value. - -
-
ECT Size Constraints - -Implementations SHOULD limit the "par" array to a maximum of -256 entries. See for "ext" size limits. - -
-
-
Privacy Considerations - -
Data Exposure in ECTs - -ECTs necessarily reveal: - - - Agent identities ("iss", "aud") for accountability purposes - Action descriptions ("exec_act") for audit trail completeness - Timestamps ("iat", "exp") for temporal ordering - - -ECTs are designed to NOT reveal: - - - Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash") - Internal computation details or intermediate steps - Proprietary algorithms or intellectual property - Personally identifiable information (PII) - - -
-
Data Minimization - -Implementations SHOULD minimize the information included in ECTs. -The "exec_act" claim SHOULD use structured identifiers (e.g., -"process_payment") rather than natural language descriptions. -Extension keys in "ext" () deserve particular -attention: human-readable values risk exposing sensitive operational -details. See for guidance on using -structured identifiers. - -
-
Storage and Access Control - -ECTs stored in audit ledgers SHOULD be access-controlled so that -only authorized auditors can read them. Implementations SHOULD -consider encryption at rest for ledger storage. ECTs provide -structural records of execution ordering; they are not intended -for public disclosure. - -Full input and output data (corresponding to the hashes in ECTs) -SHOULD be stored separately from the ledger with additional access -controls, since auditors may need to verify hash correctness but -general access to the data values is not needed. - -
-
-
IANA Considerations - -
Media Type Registration - -This document requests registration of the following media type -in the "Media Types" registry maintained by IANA: - -
-
Type name:
-
- application -
-
Subtype name:
-
- wimse-exec+jwt -
-
Required parameters:
-
- none -
-
Optional parameters:
-
- none -
-
Encoding considerations:
-
- 8bit; an ECT is a JWT that is a JWS using the Compact -Serialization, which is a sequence of Base64url-encoded values -separated by period characters. -
-
Security considerations:
-
- See the Security Considerations section of this document. -
-
Interoperability considerations:
-
- none -
-
Published specification:
-
- This document -
-
Applications that use this media type:
-
- Applications that implement agentic workflows requiring execution -context tracing and audit trails. -
-
Additional information:
-
- Magic number(s): none -File extension(s): none -Macintosh file type code(s): none -
-
Person and email address to contact for further information:
-
- Christian Nennemann, ietf@nennemann.de -
-
Intended usage:
-
- COMMON -
-
Restrictions on usage:
-
- none -
-
Author:
-
- Christian Nennemann -
-
Change controller:
-
- IETF -
-
- -
-
HTTP Header Field Registration - -This document requests registration of the following header field -in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA: - -
-
Field name:
-
- Execution-Context -
-
Status:
-
- permanent -
-
Specification document:
-
- This document, -
-
- -
-
JWT Claims Registration - -This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA: - - - Claim Name - Claim Description - Change Controller - Reference - wid - Workflow Identifier - IETF - - exec_act - Action/Task Type - IETF - - par - Parent Task Identifiers - IETF - - inp_hash - Input Data Hash - IETF - - out_hash - Output Data Hash - IETF - - ext - Extension Object - IETF - - - -
-
- - - - - - - - - - - - - - - - JSON Web Signature (JWS) - - - - - - JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. - - - - - - - - JSON Web Key (JWK) - - - - A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. - - - - - - - - JSON Web Token (JWT) - - - - - - JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. - - - - - - - - JSON Web Algorithms (JWA) - - - - This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. - - - - - - - - Universally Unique IDentifiers (UUIDs) - - - - - - This specification defines UUIDs (Universally Unique IDentifiers) -- -also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform -Resource Name namespace for UUIDs. A UUID is 128 bits long and is -intended to guarantee uniqueness across space and time. UUIDs were -originally used in the Apollo Network Computing System (NCS), later -in the Open Software Foundation's (OSF's) Distributed Computing -Environment (DCE), and then in Microsoft Windows platforms. - This specification is derived from the OSF DCE specification with the -kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have -been incorporated into this document. This document obsoletes RFC -4122. - - - - - - - - HTTP Semantics - - - - - - The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. - This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. - - - - - - - - - - Workload Identity in a Multi System Environment (WIMSE) Architecture - - CyberArk - - - Zscaler - - - University of Applied Sciences Bonn-Rhein-Sieg - - - - The increasing prevalence of cloud computing and micro service - architectures has led to the rise of complex software functions being - built and deployed as workloads, where a workload is defined as a - running instance of software executing for a specific purpose. This - document discusses an architecture for designing and standardizing - protocols and payloads for conveying workload identity and security - context information. - - - - - - - - - - - WIMSE Workload-to-Workload Authentication - - Ping Identity - - - CyberArk - - - SPIRL - - - Intuit - - - - The WIMSE architecture defines authentication and authorization for - software workloads in a variety of runtime environments, from the - most basic ones up to complex multi-service, multi-cloud, multi- - tenant deployments. This document defines the simplest, atomic unit - of this architecture: the protocol between two workloads that need to - verify each other's identity in order to communicate securely. The - scope of this protocol is a single HTTP request-and-response pair. - To address the needs of different setups, we propose two protocols, - one at the application level and one that makes use of trusted TLS - transport. These two protocols are compatible, in the sense that a - single call chain can have some calls use one protocol and some use - the other. Workload A can call Workload B with mutual TLS - authentication, while the next call from Workload B to Workload C - would be authenticated at the application level. - - - - - - - - - - Key words for use in RFCs to Indicate Requirement Levels - - - - In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. - - - - - - - - - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words - - - - RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. - - - - - - - - - - - - - - - - - - OAuth 2.0 Token Exchange - - - - - - - - This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. - - - - - - - - - Secure Production Identity Framework for Everyone (SPIFFE) - - - - - - - - - OpenTelemetry Specification - - Cloud Native Computing Foundation - - - - - - - - - - An Architecture for Trustworthy and Transparent Digital Supply Chains - - Fraunhofer SIT - - - Microsoft Research - - - Microsoft Research - - - ARM - - - - - - Traceability in supply chains is a growing security concern. While - verifiable data structures have addressed specific issues, such as - equivocation over digital certificates, they lack a universal - architecture for all supply chains. This document defines such an - architecture for single-issuer signed statement transparency. It - ensures extensibility, interoperability between different - transparency services, and compliance with various auditing - procedures and regulatory requirements. - - - - - - - - - - OAuth 2.0 Demonstrating Proof of Possession (DPoP) - - - - - - - - - This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. - - - - - - - - - Transaction Tokens - - SGNL - - - Practical Identity LLC - - - Defakto Security - - - - Transaction Tokens (Txn-Tokens) are designed to maintain and - propagate user identity and authorization context across workloads - within a trusted domain during the processing of external requests, - such as API calls. They ensure that this context is preserved - throughout the call chain, even when new transactions are initiated - internally, thereby enhancing security and consistency in complex, - multi-service architectures. - - - - - - - - - - - Transaction Tokens For Agents - - Amazon - - - - This document specifies an extension to the OAuth Transaction Tokens - framework (https://drafts.oauth.net/oauth-transaction-tokens/draft- - ietf-oauth-transaction-tokens.html) to support agent context - propagation within Transaction Tokens for agent-based workloads. The - extension defines two new context fields: 'actor' and 'principal'. - The 'actor' field identifies the agent performing the action, while - the 'principal' field identifies the human or system entity that - initiated the agent's action. For autonomous agents operating - independently, the 'principal' field MAY be omitted. These - additional context fields enable services within the call graph to - make more granular access control decisions, thereby enhancing - security. - - - - - - - - - - - - - - - - - -
Use Cases - -This section describes a representative use case demonstrating how -ECTs provide structured execution records. - -Note: task identifiers in this section are abbreviated for -readability. In production, all "jti" values are required to be -UUIDs per . - -
Cross-Organization Financial Trading - -In a cross-organization trading workflow, an investment bank's -agents coordinate with an external credit rating agency. The -agents operate in separate trust domains with a federation -relationship. The DAG records that independent assessments from -both organizations were completed before trade execution. - -
- -The resulting DAG: - -
- -Task 003 has two parents from different trust domains, -demonstrating cross-organizational fan-in. The compliance agent -verifies both parent ECTs — one signed by a local key and one by -a federated key from the rating agency's trust domain. - -
-
-
Related Work - -
WIMSE Workload Identity - -The WIMSE architecture and service-to- -service protocol provide the -identity foundation upon which ECTs are built. WIT/WPT answer -"who is this agent?" and "does it control the claimed key?" while -ECTs record "what did this agent do?" Together they form an -identity-plus-accountability framework for regulated agentic -systems. - -
-
OAuth 2.0 Token Exchange and the "act" Claim - - defines the OAuth 2.0 Token Exchange protocol and -registers the "act" (Actor) claim in the JWT Claims registry. -The "act" claim creates nested JSON objects representing a -delegation chain: "who is acting on behalf of whom." While -the nesting superficially resembles a chain, it is strictly -linear (each "act" object contains at most one nested "act"), -represents authorization delegation rather than task execution, -and carries no task identifiers or input/output integrity -data. The "act" chain cannot represent -branching (fan-out) or convergence (fan-in) and therefore -cannot form a DAG. - -ECTs intentionally use the distinct claim name "exec_act" for the -action/task type to avoid collision with the "act" claim. The -two concepts are orthogonal: "act" records "who authorized whom," -ECTs record "what was done, in what order." - -
-
Transaction Tokens - -OAuth Transaction Tokens -propagate authorization context across workload call chains. -The Txn-Token "req_wl" claim accumulates a comma-separated list -of workloads that requested replacement tokens, which is the -closest existing mechanism to call-chain recording. - -However, "req_wl" cannot form a DAG because: - - - It is linear: a comma-separated string with no branching or -merging representation. When a workload fans out to multiple -downstream services, each receives the same "req_wl" value and -the branching is invisible. - It is incomplete: only workloads that request a replacement -token from the Transaction Token Service appear in "req_wl"; -workloads that forward the token unchanged are not recorded. - It carries no task-level granularity, no parent references, -and no execution content. - It cannot represent convergence (fan-in): when two independent -paths must both complete before a dependent task proceeds, a -linear "req_wl" string cannot express that relationship. - - -Extensions for agentic use cases -() add agent -identity and constraints ("agentic_ctx") but no execution -ordering or DAG structure. - -ECTs and Transaction Tokens are complementary: a Txn-Token -propagates authorization context ("this request is authorized -for scope X on behalf of user Y"), while an ECT records -execution accountability ("task T was performed, depending on -tasks P1 and P2"). An -agent request could carry both a Txn-Token for authorization -and an ECT for execution recording. The WPT "tth" claim -defined in can hash-bind a -WPT to a co-present Txn-Token; a similar binding mechanism -for ECTs is a potential future extension. - -
-
Distributed Tracing (OpenTelemetry) - -OpenTelemetry and similar distributed tracing -systems provide observability for debugging and monitoring. ECTs -differ in several important ways: ECTs are cryptographically -signed per-task with the agent's private key; ECTs are -tamper-evident through JWS signatures; ECTs enforce DAG validation -rules; and ECTs are designed for regulatory audit rather than -operational monitoring. OpenTelemetry data is typically controlled -by the platform operator and can be modified or deleted without -detection. ECTs and distributed traces are complementary: traces -provide observability while ECTs provide signed execution records. -ECTs may reference OpenTelemetry trace identifiers in the "ext" -claim for correlation. - -
-
W3C Provenance Data Model (PROV) - -The W3C PROV Data Model defines an Entity-Activity-Agent ontology -for representing provenance information. PROV's concepts map -closely to ECT structures: PROV Activities correspond to ECT -tasks, PROV Agents correspond to WIMSE workloads, and PROV's -"wasInformedBy" relation corresponds to ECT "par" references. -However, PROV uses RDF/OWL ontologies designed for post-hoc -documentation, while ECTs are runtime-embeddable JWT tokens with -cryptographic signatures. ECT audit data could be exported to -PROV format for interoperability with provenance-aware systems. - -
-
SCITT (Supply Chain Integrity, Transparency, and Trust) - -The SCITT architecture defines a -framework for transparent and auditable supply chain records. -ECTs and SCITT are complementary: the ECT "wid" claim can serve -as a correlation identifier in SCITT Signed Statements, linking -an ECT audit trail to a supply chain transparency record. - -
-
-
Acknowledgments - -The author thanks the WIMSE working group for their foundational -work on workload identity in multi-system environments. The -concepts of Workload Identity Tokens and Workload Proof Tokens -provide the identity foundation upon which execution context -tracing is built. - -
- - - - - - - - diff --git a/draft-nennemann-wimse-ect-01.md b/draft-nennemann-wimse-ect.md similarity index 100% rename from draft-nennemann-wimse-ect-01.md rename to draft-nennemann-wimse-ect.md diff --git a/master-prompt.md b/master-prompt.md deleted file mode 100644 index b156b9a..0000000 --- a/master-prompt.md +++ /dev/null @@ -1,1186 +0,0 @@ -# Master Prompt: WIMSE Extension I-D on Execution Context Tracing - -## Overview -You are drafting an IETF Internet-Draft proposing a WIMSE extension for execution context tracing in distributed agentic workflows. This extension completes the WIMSE architecture for regulated environments by adding cryptographic proof of execution order, policy enforcement, and compliance decisions. - -**Key positioning**: WIMSE handles "who is this agent and does it have authority?"—this extension handles "here's cryptographic proof of what the agent actually did, in what order, with full regulatory provenance." - -**Strategic positioning**: This is not a competing spec; it's what WIMSE needs to complete the regulated agentic system. Your work fills the gap WIMSE itself identified in draft-ni-wimse-ai-agent-identity ("call context must always be visible and preserved"). - ---- - -## Core Design Principles -- **Completes WIMSE, doesn't compete with it** -- **Tight integration with WIT/WPT** (same signing keys, algorithms, concepts) -- **Regulatory compliance by design** (audit trails, policy enforcement, rollback capability) -- **Agent-to-agent communication** as primary use case -- **Horizontal across regulated domains** (medtech, finance, military) -- **Complements WIMSE; optional integration with other identity systems** - ---- - -## Document Structure Template - -### 1. Abstract (150-200 words) -- **What it is**: WIMSE extension adding execution context tracing -- **Why it matters**: Regulated agentic systems need immutable proof of execution order and policy enforcement -- **How it works**: Execution context tokens (JWT format) prove what agents did, in what order, under what policy -- **Integration with WIMSE**: Works with WIT/WPT; same signing model, cryptographic alignment -- **Use cases**: Medtech (FDA audit trails), finance (MiFID II compliance), military (chain of custody) -- **Key innovation**: DAG-structured execution proofs with policy checkpoints - -**Example abstract**: -> This document defines Execution Context Tokens (ECTs), a WIMSE extension for distributed agentic workflows in regulated environments. ECTs provide cryptographic proof of task execution order, policy enforcement, and compliance decisions across agent-to-agent communication. By extending WIMSE workload identity tokens with execution context claims, this specification enables regulated systems (medtech, finance, military) to maintain immutable audit trails and demonstrate compliance with regulatory requirements including FDA 21 CFR Part 11, MiFID II, and EU AI Act provisions. ECTs are designed for tight integration with WIMSE WIT/WPT while remaining compatible with other workload identity systems. - ---- - -### 2. Introduction (2-3 pages) - -#### 2.1 Motivation -- **WIMSE solves identity**: WIT/WPT authenticate workloads and provide proof of possession -- **WIMSE doesn't address execution accountability**: Identity doesn't tell you what happened, what policy was applied, or if decisions were reversible -- **Regulated environments need execution proof**: - - EU AI Act (Article 12): High-risk AI systems must maintain "activity logs... to demonstrate compliance" - - FDA 21 CFR Part 11: Electronic records must be trustworthy, reliable, show non-repudiation for critical decisions - - MiFID II: Transaction reporting must be contemporaneous, immutable, auditable - - Military/Defense: Chain of custody, authorization proof, decision auditability - -- **Why this is a WIMSE extension, not standalone**: - - WIMSE already provides identity foundation - - Execution context extends WIMSE with accountability - - Natural progression: authenticate (WIMSE) → prove action (this extension) - - Uses same signing models, algorithms, concepts - -#### 2.2 Problem Statement -- **Three core gaps in regulated agentic systems**: - 1. WIMSE authenticates agents but doesn't prove what they actually did - 2. No standard way to demonstrate policy enforcement at each decision point - 3. No mechanism to prove rollback/compensation decisions are authorized - -- **Why logging/observability isn't enough**: - - Observability (OpenTelemetry, Jaeger) provides visibility, not proof - - Logging doesn't prevent tampering or prove non-repudiation - - Regulators need cryptographic proof, not just evidence - -- **Why WIMSE identity alone is insufficient**: - - WIT proves "Agent A authorized this request to Agent B" - - Doesn't prove "Agent A actually executed Task X, with Policy Y, producing Output Z" - - Doesn't prove "Human approved override at 15:42 UTC on 2026-02-24" - - Gap: WIMSE covers hop-by-hop; ECT covers end-to-end execution flow - -#### 2.3 Scope and Applicability -- **What this extension addresses**: - - Execution context token format - - DAG structure for task dependencies - - Policy checkpoint recording - - Integration with WIMSE identity framework - - Ledger interface (storage-agnostic) - - Regulatory compliance mapping - -- **What's out of scope** (handled by WIMSE): - - Workload authentication - - Key distribution - - Trust domain management - - Credential provisioning - -- **Primary use cases**: Regulated agentic systems requiring: - - Immutable audit trails - - Policy enforcement proof - - Compensation/rollback capability - - Multi-hop agent workflows - -#### 2.4 Terminology -- **Agent**: Autonomous workload (per WIMSE definition); executes tasks -- **Task**: Discrete unit of agent work; produces output -- **DAG**: Directed acyclic graph representing task dependencies -- **Execution Context Token (ECT)**: JWT proving task execution and policy enforcement -- **Audit Ledger**: Immutable log of all ECTs in workflow -- **Policy Checkpoint**: Point where authorization/compliance decision is recorded in ECT -- **Workload Identity Token (WIT)**: WIMSE credential proving agent identity -- **Workload Proof Token (WPT)**: WIMSE proof of possession for request authentication -- **Trust Domain**: WIMSE concept; organizational boundary with shared identity issuer - ---- - -### 3. How This Extends WIMSE (1-2 pages) - -#### 3.1 WIMSE Architecture Context -- WIMSE defines: - - Workload identity (WIT): "I am Agent X, trust domain Y" - - Proof of possession (WPT): "I control the private key for Agent X" - - Multi-hop authentication: How agents authenticate each other across call chains - -- WIMSE does *not* define: - - What agents actually do with that authentication - - How to prove policy decisions at each hop - - How to maintain immutable execution records - - How to enable rollback/compensation - -#### 3.2 The Extension -ECTs extend WIMSE by adding a new claim layer: - -``` -WIMSE Layer (Identity): - WIT: "I am Agent X (spiffe://trust-domain/agent/x)" - WPT: "I prove I control the key for Agent X" - ↓ -ECT Layer (Execution Accountability): [NEW - this extension] - ECT: "Here's the task I executed, dependencies, policy applied, approval" - ↓ -Ledger Layer (Immutable Record): [implementation concern] - "Append all ECTs to immutable audit log" -``` - -**Why this is an extension, not a new standard**: -- Reuses WIMSE signing model (same algorithm, same keys) -- Extends JWT claims (standard JWT extensibility) -- Maintains WIMSE concepts (trust domains, workload identity) -- Fills explicit gap WIMSE identified (call context visibility) - -#### 3.3 Integration Model -- **ECT references WIT**: - - ECT `kid` points to WIT public key - - ECT `iss` uses WIMSE workload identifier format - - ECT signature verified against WIT public key - -- **Stacking example**: - ``` - HTTP Request from Agent A to Agent B: - Workload-Identity: - Workload-Proof-Token: - Execution-Context: - - Agent B verifies: - 1. WIT/WPT (WIMSE layer): Proves who A is and that request is authorized - 2. ECT (this extension): Proves what A is doing, what policy was applied, what precedent tasks were - 3. Ledger: Records ECT in immutable audit trail - ``` - -- **Key alignment**: - - ECT uses same algorithm as WIT (e.g., both ES256) - - ECT uses same signing key as WPT (agent's private key) - - ECT references WIT explicitly (crypto chain) - - Result: Complete identity + execution proof chain - ---- - -### 4. Technical Architecture (4-5 pages) - -#### 4.1 Execution Context Token (ECT) Format - -**JWT Header**: -```json -{ - "alg": "ES256", // Must match WIT algorithm - "typ": "application/wimse-exec+jwt", - "kid": "" // Reference to WIT public key -} -``` - -**JWT Payload**: -```json -{ - // WIMSE-compatible claims - "iss": "spiffe://trust-domain/agent/agent-1", - "sub": "spiffe://trust-domain/agent/agent-1", - "aud": "spiffe://trust-domain/agent/agent-2", // Next hop - - // Execution context (NEW - this extension) - "act": "process_payment", // Action/task identifier - "tid": "task-uuid-e8f3-4b2a-9c1d-7e5a2f3b4c6d", // Unique task ID - "par": [ - "task-uuid-parent-1", - "task-uuid-parent-2" - ], // Parent task IDs (DAG dependencies) - - // Policy/compliance claims - "pol": "payment_approval_policy_v2", // Policy rule identifier - "pol_decision": "approved", // "approved" | "rejected" | "pending_human_review" - "pol_enforcer": "spiffe://trust-domain/policy/human-review-enforcer", // Who/what enforced policy - "pol_timestamp": "2026-02-24T15:42:30.123Z", // When policy decision was made - - // Data integrity - "inp_hash": "sha256:base64encoded...", // Hash of input (not value) - "out_hash": "sha256:base64encoded...", // Hash of output - "inp_classification": "confidential", // Data sensitivity - - // Timing - "iat": 1708871550, // Token issued - "exp": 1708871610, // Expires (short-lived, ~minutes) - "exec_time_ms": 245, // Actual execution time - - // Regulatory/operational context - "regulated_domain": "medtech", // "medtech" | "finance" | "military" | null - "model_version": "gpt-4-turbo-2024-01", // LLM/AI model version if applicable - - // Optional: Witness/attestation - "witnessed_by": [ - "spiffe://trust-domain/audit-observer/instance-1" - ], // Third parties observing execution - - // Optional: Compensation/rollback - "compensation_required": false, - "compensation_reason": null, - - // Optional: Extensions - "ext": { - "custom_domain_claim": "value" - } -} -``` - -**Signature**: Signed with agent's private key (same key used for WPT) - -#### 4.2 Task Ledger Structure (Reference Model) - -While ledger storage is implementation-specific, ECTs expect to be stored in a structure like: - -``` -Task Entry { - task_id: UUID // Matches "tid" claim in ECT - agent_id: WIMSE workload identifier - action: From ECT "act" claim - parents: [task_id list] // From ECT "par" claim - - // Cryptographic proof - ect_jwt: Full JWT (for verification) - signature_verified: boolean - verification_timestamp: ISO 8601 - - // Ledger metadata - ledger_sequence: integer // Ordering in ledger - inclusion_proof: Merkle tree proof (if using merkle structure) - - // For audit - stored_timestamp: ISO 8601 - storage_location: URI or identifier -} -``` - -**Why storage is out-of-scope**: -- ECT format is portable (JWT) -- Can be stored in: database, blockchain, append-only log, distributed ledger, etc. -- Spec defines what to store (ECT), not where or how -- Regulatory requirements vary; implementation flexibility needed - -#### 4.3 DAG Validation Rules - -When verifying an ECT: - -1. **Task ID uniqueness**: Every `tid` must be globally unique within workflow -2. **Parent validation**: Every `tid` in `par` must exist in ledger (already executed) -3. **Acyclic guarantee**: Verify no circular dependencies (follow parents; should never loop back) -4. **Ordering**: Verify parent tasks happened chronologically before this task (iat of parents < iat of this task) -5. **Policy consistency**: Verify policy applied (`pol` claim) matches trust domain's policy rules - -**Pseudocode for DAG validation**: -``` -validate_dag(ect): - if ect.tid not unique in ledger: - reject("Task ID already exists") - - for parent_id in ect.par: - if parent_id not in ledger: - reject("Parent task not found in ledger") - - parent_ect = ledger[parent_id] - if parent_ect.iat >= ect.iat: - reject("Parent task is not earlier than this task") - - // Recursively verify no cycles - if contains_cycle(ect.tid, parent_id): - reject("Circular dependency detected") - - return true -``` - -#### 4.4 Signature Verification - -**Requirements**: -1. ECT signature must be valid JWS (RFC 7515) -2. Signature algorithm must match WIT algorithm (e.g., both ES256) -3. Signing key must match WIT public key (verify `kid` reference) -4. Key must not be revoked in trust domain -5. All required claims must be present -6. No unknown critical claims (unless understood by implementation) - -**Verification pseudocode**: -``` -verify_ect(ect_jwt, wit_public_key): - // Parse JWT - [header, payload, signature] = decode_jws(ect_jwt) - - // Verify signature - if not verify_signature(signature, [header, payload], wit_public_key): - reject("Invalid signature") - - // Verify claims - if payload.iss != wit.sub: - reject("Issuer doesn't match WIT subject") - - if payload.exp < now(): - reject("ECT expired") - - if payload.alg != wit.alg: - reject("Algorithm mismatch with WIT") - - // Verify DAG - if not validate_dag(payload): - reject("DAG validation failed") - - return true // ECT is valid -``` - -#### 4.5 Claims Semantics - -**Critical Claims**: -- `tid`, `iss`, `aud`, `exp`: Must always be present -- `act`, `par`, `pol`, `pol_decision`: Must always be present -- Receiver must understand all these - -**Important Claims**: -- `pol_enforcer`, `witnessed_by`, `regulated_domain`: Should be present in compliance contexts -- Missing is not fatal (SHOULD, not MUST) - -**Optional Claims**: -- `ext`, `compensation_required`: Can be absent -- Extensions (in `ext` object) can be custom -- If not understood, implementation should warn but not reject - -**Claim Validation Rules**: -- `par`: Must be array of valid task UUIDs -- `pol_decision`: Must be one of ["approved", "rejected", "pending_human_review"] -- `regulated_domain`: If present, must be one of ["medtech", "finance", "military"] (or extensible registry) -- `exec_time_ms`: Must be non-negative integer - ---- - -### 5. Use Cases (2-3 pages) - -#### 5.1 Medical Device Approval Workflow -**Scenario**: AI agent recommends treatment; multiple agents coordinate (clinical reasoning, safety check, dosage calculation); human approval required - -**Workflow**: -``` -Agent A (Clinical Reasoning): - task-1: Recommend treatment based on patient data - ECT-1: tid=task-1, par=[], pol=clinical_rules, pol_decision=approved - -Agent B (Safety Check): - task-2: Validate interaction with known medications - ECT-2: tid=task-2, par=[task-1], pol=safety_policy, pol_decision=approved - -Agent C (Dosage Calculation): - task-3: Calculate safe dosage - ECT-3: tid=task-3, par=[task-2], pol=dosage_rules, pol_decision=approved - -Human Review (witnessed by system): - ECT-1, ECT-2, ECT-3 marked as witnessed_by=[human-reviewer] - -Treatment administered -``` - -**How ECTs add value**: -- Immutable proof that all three agents checked results *before* treatment -- Proof that human reviewed and approved (witnessed_by claim) -- Execution order proves safety checks happened *before* dosage calculation -- If adverse event occurs, regulator can verify complete decision chain -- Can initiate rollback: "Revoke treatment authorization, recompute with new safety data" - -**Regulatory alignment**: -- FDA 21 CFR Part 11: Electronic records with non-repudiation ✓ -- EU MDR (Medical Device Regulation): Audit trail of AI-assisted decisions ✓ -- EU AI Act Article 12: Activity logs for high-risk systems ✓ - ---- - -#### 5.2 Financial Trading Workflow -**Scenario**: Risk assessment, compliance check, execution; multi-agent coordination with policy gates - -**Workflow**: -``` -Agent A (Risk Assessment): - task-1: Calculate risk exposure - ECT-1: tid=task-1, par=[], pol=risk_limits_policy, pol_decision=approved - -Agent B (Compliance Check): - task-2: Verify MiFID II requirements - ECT-2: tid=task-2, par=[task-1], pol=mifid_compliance, pol_decision=approved - -Agent C (Execution): - task-3: Execute trade - ECT-3: tid=task-3, par=[task-2], pol=execution_policy, pol_decision=approved -``` - -**How ECTs add value**: -- Immutable proof that compliance check happened *before* trade (ordering proof via DAG) -- Proof that risk policy was applied and approved -- Proof of compliance decision at each step -- MiFID II transaction reporting: "Here's contemporaneous ECT proving policy checks" -- Post-trade audit: Can reproduce exact decision sequence -- Compensation: Can prove "trade executed validly; here's rollback authorization (if needed)" - -**Regulatory alignment**: -- MiFID II: Contemporaneous transaction reporting ✓ -- DORA (Digital Operational Resilience Act): Audit trail of significant transactions ✓ -- EU AI Act Article 15: Automatic logging of significant decisions ✓ - ---- - -#### 5.3 Military Command & Control -**Scenario**: Intelligence agents feed targeting agents; authorization chain critical; accountability required - -**Workflow**: -``` -Agent A (Intelligence Assessment): - task-1: Assess threat level from signals intelligence - ECT-1: tid=task-1, par=[], pol=intel_policy, pol_decision=approved, - witnessed_by=[military-auditor] - -Agent B (Target Validation): - task-2: Cross-reference with intel databases - ECT-2: tid=task-2, par=[task-1], pol=targeting_rules, pol_decision=approved, - witnessed_by=[military-auditor] - -Human Command: - task-3: Authorize engagement - ECT-3: tid=task-3, par=[task-2], pol=rules_of_engagement, pol_decision=approved, - pol_enforcer=commander, witnessed_by=[military-auditor] - -Agent C (Engagement): - task-4: Execute engagement - ECT-4: tid=task-4, par=[task-3], pol=execution_rules, pol_decision=approved -``` - -**How ECTs add value**: -- Chain of custody proof: "Here's the decision chain leading to this action" -- Accountability: "Commander authorized at this time, witnessed by auditor" -- Non-repudiation: "Intelligence assessment was performed by Agent A, approved by policy" -- Post-action audit: "Reconstruct exact decision sequence for incident investigation" - -**Regulatory alignment**: -- Military accountability rules: Decision chain proof ✓ -- Rules of engagement: Policy enforcement proof ✓ -- International law: Chain of custody for targeting decisions ✓ - ---- - -#### 5.4 Autonomous Logistics Coordination -**Scenario**: Multiple compliance checks before shipment commitment (route, customs, safety, payment) - -**Workflow**: -``` -Agent A (Route Planning): - task-1: Plan optimal route - ECT-1: tid=task-1, par=[], pol=route_policy, pol_decision=approved - -Agent B (Customs/Compliance): - task-2: Validate customs requirements - ECT-2: tid=task-2, par=[task-1], pol=customs_policy, pol_decision=approved - -Agent C (Safety Check): - task-3: Verify cargo safety requirements - ECT-3: tid=task-3, par=[task-2], pol=safety_policy, pol_decision=approved - -Agent D (Payment Authorization): - task-4: Validate payment and insurance - ECT-4: tid=task-4, par=[task-3], pol=payment_policy, pol_decision=approved - -System Commitment: - task-5: Commit shipment - ECT-5: tid=task-5, par=[task-4], pol=commitment_policy, pol_decision=approved -``` - -**How ECTs add value**: -- Proves all checks happened before commitment (dependency proof) -- If compliance violation discovered later, can prove "all required checks passed at execution time" -- Compensation trail: "Revoke commitment with this authorization, revert to task-3 for recheck" -- EU AI Act compliance: Proves human-override capability at each stage - -**Regulatory alignment**: -- EU AI Act Article 14: Human override in high-risk systems ✓ -- Transport regulations: Compliance proof for each stage ✓ - ---- - -### 6. Security Considerations (3-4 pages) - -#### 6.1 Signature Verification -- ECTs MUST be signed with agent's private key -- Signature algorithm MUST match WIT algorithm (both agents, both systems) -- Receivers MUST verify signature against WIT public key -- Receivers MUST verify key hasn't been revoked (check trust domain key store) -- Failure to verify: Reject ECT entirely - -**Implementation note**: Use standard JWS libraries (JOSE); don't implement signature verification from scratch. - -#### 6.2 Replay Attack Prevention -- ECTs include short expiration (minutes, not hours) - - Recommended: 5-15 minutes - - Rationale: Prevents replay of old decisions as new ones -- ECT includes `aud` (next hop); replay to wrong recipient fails -- ECT includes `iat` (issued at); verify not too far in past -- DAG structure prevents arbitrary reordering (parents must exist, be earlier) - -**Best practice**: Use both transport-level (TLS) and application-level (ECT) timestamps; cross-verify. - -#### 6.3 Man-in-the-Middle -- ECTs don't replace TLS/mTLS; use alongside -- WIMSE recommends: Either mTLS or HTTP Message Signatures (RFC 9421) -- ECTs provide application-level proof; TLS provides transport-level proof -- Defense in depth: Both layers prevent MITM - -**Stacking**: -``` -TLS/mTLS (transport): Prevents network-level tampering -WIT/WPT (WIMSE): Proves agent identity and request authorization -ECT (this extension): Proves what agent did and why -Result: Complete integrity chain -``` - -#### 6.4 Key Compromise -- Private key compromise = attacker can forge ECTs -- Mitigation strategies: - 1. **Short-lived keys**: Rotate keys frequently (hours to days, not months) - 2. **Key derivation**: Use different key per time period; don't reuse - 3. **HSM storage**: Keep private keys in hardware security modules - 4. **Rapid revocation**: If compromise suspected, revoke immediately in trust domain - -- **Detection**: - - Audit anomalies: Agent "behaving differently" (different policy decisions, unusual task chains) - - Out-of-band verification: Human reviewer audits suspicious ECTs - - Ledger inspection: Look for tasks that shouldn't exist from that agent - -- **Recovery**: - 1. Revoke compromised key in trust domain - 2. Generate new WIT with fresh key - 3. Invalidate ECTs signed with compromised key (mark in ledger) - 4. Recompute affected workflows with new agent instance - -#### 6.5 Collusion & False Claims -- **Single agent limitation**: Agent cannot claim false parents (DAG validation catches) - - If Agent A claims "my parent is task-2" but task-2 doesn't exist, validation fails - - If Agent A claims "my parent is task-2" but task-2 is from different trust domain, validation fails - -- **Multiple agents colluding**: If agents collude to forge history, detection requires: - 1. Honest ledger maintainer (can't be compromised) - 2. Witness signatures (optional; enables third-party observation) - 3. Out-of-band audit (external auditor comparing ledger to expectations) - -- **Policy enforcement collusion**: If policy enforcer and agent collude to approve invalid action: - - Mitigated by: Witness signatures (external observer), multi-signature requirements - - Detection: Audit deviation from normal policy patterns - - Note: In regulated environments, this is where human accountability comes in - -#### 6.6 Denial of Service -- **ECT verification overhead**: Signature verification is fast (~1ms per ECT) -- **DAG validation overhead**: Linear in parent count (usually small, e.g., 2-5 parents) -- **No external network calls needed**: All info in ECT; no OCSP/CRL lookups required for verification -- **DoS mitigations**: - - Rate limiting at API layer (separate from this spec) - - Signature verification happens after request acceptance (cost is justified) - - DAG validation can be parallelized if needed - -#### 6.7 Privacy of ECT Contents -- ECTs reveal: - - Agent identities (from WIT/`iss` claim) - - Actions being performed (`act` claim) - - Data classification (`inp_classification`, `out_classification`) - - Policy decisions (`pol_decision`) - - Timestamps (necessary for compliance) - -- ECTs do NOT need to reveal: - - Input/output values (hashes instead) - - Internal computation details - - Commercial algorithms or intellectual property - - Sensitive personal data - -**Guidance**: -- Use input/output hashes (`inp_hash`, `out_hash`) for sensitive values -- Only authorized auditors see full input/output (in separate audit log, not in ECT) -- Minimize claim values; use structured identifiers instead of full text -- Consider encryption at rest for ledger storage if needed - -#### 6.8 Regulatory Compliance & Audit Integrity -- ECTs are designed for regulatory audit, not cryptographic perfection -- Assumes regulated environment has governance controls (human oversight, policy review) -- Assumes trust domain has authority to revoke keys and manage policies -- ECTs are evidence; they must be interpreted in context of broader compliance controls - -**Not sufficient alone**: -- ECTs prove "this task happened in this order" but don't prove "this task should have happened" -- Policy evaluation (was policy correct?) is human responsibility -- ECTs enable human auditors to make compliance judgments; don't replace audit - ---- - -### 7. Privacy Considerations (1 page) - -**Data in ECTs**: -- Agent identities: Necessarily revealed (needed for accountability) -- Task/action descriptions: Necessarily revealed (needed for audit) -- Policy rule IDs: Necessarily revealed (need to know which rule was applied) -- Timestamps: Necessarily revealed (temporal ordering required for compliance) -- Data classification: Necessarily revealed (regulators need to know sensitivity level) - -**Data NOT in ECTs** (use hashes instead): -- Input values: Replaced with hash -- Output values: Replaced with hash -- Internal computation details: Not included -- Intermediate steps: Abstracted as single task - -**Storage recommendations**: -- ECTs stored in secure audit ledger (restricted access) -- Full input/output values stored separately, access-controlled -- Consider encryption at rest if ledger storage is sensitive -- Anonymization: Generally not recommended (defeats audit purpose), but possible via separate ledger views - -**Regulator access**: -- Assume regulators (FDA, MiFID II authority, military chain-of-command) have access to full audit trail -- ECTs designed for human expert interpretation; not for public disclosure -- Sensitive details (medical diagnoses, trade algorithms, military intel) remain confidential; ECTs show structural proof only - ---- - -### 8. IANA Considerations (1 page) - -#### 8.1 Media Type Registration - -Request registration in IANA "Media Types" registry: - -``` -Type name: application -Subtype name: wimse-exec+jwt -Required parameters: none -Optional parameters: none -Encoding considerations: 8bit -Security considerations: See RFC [THIS DOCUMENT], Section 6 -Interoperability considerations: JSON Web Token format (RFC 7519) -Published specification: [THIS DOCUMENT] -Applications that use this media type: [YOUR COMPANY], others building regulated agentic systems -Additional information: - Magic number(s): none - File extension(s): none - Macintosh file type code(s): none -Person and email address to contact for further information: [YOUR EMAIL] -Intended usage: COMMON -Restrictions on usage: For use in regulated agentic systems -Author: [YOUR NAME] -Change controller: [YOUR COMPANY] -``` - -#### 8.2 HTTP Header Field Registration - -Request registration in IANA "Message Headers" registry: - -**Header Field Name**: Execution-Context - -``` -Header field name: Execution-Context -Applicable protocol: HTTP/1.1, HTTP/2, HTTP/3 -Status: standard -Author/Change controller: [YOUR COMPANY] -Specification: [THIS DOCUMENT], Section [X] -Related information: Carries Execution Context Token (ECT) for distributed workflow tracing -``` - -#### 8.3 JWT Claim Name Registrations - -Register new claims in IANA "JSON Web Token (JWT) Claims" registry: - -| Claim Name | Description | Change Controller | -|-----------|-------------|------------------| -| `act` | Action/task identifier | [YOUR COMPANY] | -| `tid` | Unique task ID | [YOUR COMPANY] | -| `par` | Parent task IDs (DAG) | [YOUR COMPANY] | -| `pol` | Policy rule identifier | [YOUR COMPANY] | -| `pol_decision` | Policy decision (approved/rejected/pending) | [YOUR COMPANY] | -| `pol_enforcer` | Who enforced the policy | [YOUR COMPANY] | -| `pol_timestamp` | When policy decision was made | [YOUR COMPANY] | -| `inp_hash` | Hash of input data | [YOUR COMPANY] | -| `out_hash` | Hash of output data | [YOUR COMPANY] | -| `inp_classification` | Input data sensitivity | [YOUR COMPANY] | -| `regulated_domain` | Regulatory domain (medtech/finance/military) | [YOUR COMPANY] | -| `model_version` | AI model version if applicable | [YOUR COMPANY] | -| `exec_time_ms` | Execution time in milliseconds | [YOUR COMPANY] | -| `witnessed_by` | Witness/observer identities | [YOUR COMPANY] | -| `compensation_required` | Whether rollback is needed | [YOUR COMPANY] | -| `compensation_reason` | Reason for rollback | [YOUR COMPANY] | - -#### 8.4 Policy Rule ID Registry (Optional Future Extension) - -Recommend creating IANA registry for policy rule identifiers: -- Enables standardized policy names across organizations -- Format: `{domain}.{policy_category}.{policy_name}` -- Examples: `medtech.clinical_rules.treatment_approval_v2`, `finance.mifid.compliance_check_v1` -- Extensibility: Allows new domains and policies to be registered - ---- - -### 9. Related Work & Positioning (2-3 pages) - -#### 9.1 WIMSE Workload Identity -**Relationship**: Foundation; this extension builds on WIMSE - -**How they work together**: -- WIMSE WIT/WPT: Authenticate agents and prove key possession -- ECTs: Prove what agents did with that authentication -- Together: Complete regulated agentic system (identity + execution accountability) - -**Differentiation**: -- WIT/WPT answer "who is this?" and "does it control the key?" -- ECTs answer "what did it do?" and "what policy was applied?" - -**Integration points**: -- ECT references WIT public key (crypto alignment) -- ECT uses same algorithm as WIT (interoperability) -- ECT uses WIMSE workload identifier format (`spiffe://...`) -- ECT integrates with WIMSE trust domain (same issuer) - ---- - -#### 9.2 OAuth 2.0 Transaction Tokens -**Relationship**: Similar concept (contextual tokens), different problem domain - -**How they differ**: -- Transaction tokens: Establish API authorization context (who can access what resource) -- ECTs: Prove execution accountability in regulated workflows (what happened and why) - -**Possible future integration**: -- Transaction tokens establish authorization for agent to access resource -- ECTs prove agent actually used that authorization -- Out of scope here; future work - ---- - -#### 9.3 Distributed Tracing (OpenTelemetry, Jaeger) -**Relationship**: Both observe distributed systems; different approaches - -**How they differ**: -- OpenTelemetry/Jaeger: **Observability** tools - - Show what happened for debugging/monitoring - - Not cryptographically signed - - Not tamper-proof - - Not designed for regulatory audit - -- ECTs: **Compliance proof** mechanism - - Cryptographically signed - - Immutable (prevent tampering) - - Designed for regulatory audit - - Enables non-repudiation - -**Integration potential**: -- OpenTelemetry could carry ECTs as baggage -- ECTs could reference OpenTelemetry trace IDs -- Complementary: Traces provide observability; ECTs provide proof - ---- - -#### 9.4 Blockchain & Distributed Ledgers -**Relationship**: Both provide immutable records; different technology - -**Why this spec is ledger-agnostic**: -- Some environments require blockchain (cross-organizational audit) -- Some use append-only logs (single-org, trusted storage) -- Some use databases with cryptographic commitment proofs -- Spec should not mandate technology; only format - -**This extension**: -- Defines ECT format (transportable, independent of storage) -- Ledger storage is implementation choice (database, blockchain, append-only log, etc.) -- Regulatory compliance doesn't require blockchain; immutability + audit trail sufficient - ---- - -#### 9.5 W3C Verifiable Credentials -**Relationship**: Both use JWT/JWS; different semantics - -**How they differ**: -- W3C VC: Credentials about subjects (identity, qualifications, attributes) -- ECTs: Execution records of actions (what happened, in what order) - -**Possible convergence**: -- Future: Could align formats if both adopt same JWT structures -- Out of scope here - ---- - -### 10. Implementation Guidelines (1-2 pages) - -#### 10.1 Minimal Implementation -**Required**: -1. Create JWT with required claims (`tid`, `act`, `par`, `pol`, `pol_decision`, `iss`, `aud`, `exp`) -2. Sign with agent's private key (same key as WIT) -3. Verify signature against WIT public key -4. Validate DAG (parents exist, are earlier, no cycles) -5. Append to audit ledger - -**Code outline** (pseudocode): -``` -// Create ECT -ect_payload = { - "tid": generate_uuid(), - "iss": agent_identity, - "aud": next_agent_identity, - "act": action_name, - "par": parent_task_ids, - "pol": policy_rule_id, - "pol_decision": "approved", - "iat": now(), - "exp": now() + 600, // 10 minutes - "alg": "ES256" -} - -ect_jwt = sign_jws(ect_payload, agent_private_key) - -// Verify ECT -if not verify_jws(ect_jwt, wit_public_key): - reject("Invalid signature") - -payload = decode_jwt(ect_jwt) - -if not validate_dag(payload.par): - reject("DAG validation failed") - -// Store in ledger -ledger.append({ - "task_id": payload.tid, - "ect": ect_jwt, - "verified_at": now() -}) -``` - -#### 10.2 Full Implementation -**Additional**: -1. Key rotation strategy (new WIT keys periodically) -2. Revocation checking (verify key not revoked in trust domain) -3. Policy validation (verify `pol` is known, `pol_decision` is valid) -4. Witness signatures (optional; enable third-party observation) -5. Merkle tree proofs (enable efficient inclusion proofs for audit) -6. Compression (if high throughput required) - -#### 10.3 Storage Considerations -- **Append-only log**: Simplest; immutability by design -- **Database**: Add cryptographic commitment proofs (periodic hashes) -- **Blockchain**: Maximum immutability; highest cost -- **Hybrid**: Hot storage (database), cold archive (blockchain/IPFS) - -**Recommendation**: Start with append-only log; add complexity if regulators demand it. - -#### 10.4 Performance Notes -- Signature verification: ~1ms per ECT (on modern hardware) -- DAG validation: O(n) where n = number of parents (typically 2-5) -- JSON serialization: < 1ms per ECT -- Total overhead per request: ~5-10ms (acceptable for regulated workflows) - -#### 10.5 Interoperability -- Use standard JWT libraries (JOSE) for signing/verification -- Don't implement custom crypto -- Follow RFC 7519 (JWT) and RFC 7515 (JWS) strictly -- Test with multiple JWT libraries to ensure compatibility - ---- - -### 11. Examples (2-3 pages) - -#### Example 1: Simple Two-Agent Workflow - -**Agent A executes Task 1**: -```json -{ - "alg": "ES256", - "typ": "application/wimse-exec+jwt", - "kid": "agent-a-key-id-123" -} - -{ - "iss": "spiffe://mycompany.com/agent/a", - "sub": "spiffe://mycompany.com/agent/a", - "aud": "spiffe://mycompany.com/agent/b", - "tid": "task-1-e8f3-4b2a-9c1d", - "act": "fetch_patient_data", - "par": [], - "pol": "clinical_data_access_policy_v1", - "pol_decision": "approved", - "iat": 1708871550, - "exp": 1708871610, - "exec_time_ms": 142 -} - -Signature: [JWS signature] -``` - -**Agent B receives Task 1, executes Task 2**: -```json -{ - "alg": "ES256", - "typ": "application/wimse-exec+jwt", - "kid": "agent-b-key-id-456" -} - -{ - "iss": "spiffe://mycompany.com/agent/b", - "sub": "spiffe://mycompany.com/agent/b", - "aud": "spiffe://mycompany.com/system/ledger", - "tid": "task-2-a1b2-c3d4-e5f6", - "act": "validate_safety", - "par": ["task-1-e8f3-4b2a-9c1d"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved", - "iat": 1708871560, - "exp": 1708871620, - "exec_time_ms": 89 -} - -Signature: [JWS signature] -``` - -**Ledger View**: -``` -Task 1 (Agent A): fetch_patient_data - └─ Task 2 (Agent B): validate_safety - └─ (ready for next task) -``` - -**Audit Trail**: Immutable proof that Agent A fetched data, Agent B validated, in that order. - ---- - -#### Example 2: Medical Device Workflow with Witness - -**Multi-step workflow with human oversight**: - -**Task 1 - Clinical Reasoning**: -```json -{ - "tid": "clinical-rec-1", - "iss": "spiffe://hospital.com/agent/clinical", - "act": "recommend_treatment", - "par": [], - "pol": "clinical_rules_v2", - "pol_decision": "approved", - "regulated_domain": "medtech" -} -``` - -**Task 2 - Human Approval** (witnessed by system): -```json -{ - "tid": "human-approval-1", - "iss": "spiffe://hospital.com/human/physician-123", - "act": "approve_treatment_recommendation", - "par": ["clinical-rec-1"], - "pol": "physician_approval_policy", - "pol_decision": "approved", - "pol_enforcer": "spiffe://hospital.com/human/physician-123", - "witnessed_by": ["spiffe://hospital.com/audit/observer-1"], - "regulated_domain": "medtech" -} -``` - -**Task 3 - Safety Check**: -```json -{ - "tid": "safety-check-1", - "iss": "spiffe://hospital.com/agent/safety", - "act": "check_drug_interactions", - "par": ["human-approval-1"], - "pol": "safety_policy_v3", - "pol_decision": "approved", - "regulated_domain": "medtech" -} -``` - -**Regulatory Proof**: -- Clinical reasoning was performed (Task 1) -- Physician approved (Task 2, witnessed) -- Safety check confirmed (Task 3) -- Order proves all checks before treatment - -**FDA Audit Trail**: Complete, cryptographically signed, immutable proof of decision process. - ---- - -#### Example 3: Compensation/Rollback - -**Original trade executed**: -```json -{ - "tid": "trade-1", - "iss": "spiffe://bank.com/agent/trading", - "act": "execute_trade", - "par": ["compliance-1", "risk-1"], - "pol": "trade_execution_policy", - "pol_decision": "approved" -} -``` - -**Later: Compliance violation discovered, rollback initiated**: -```json -{ - "tid": "compensation-trade-1", - "iss": "spiffe://bank.com/agent/operations", - "act": "initiate_rollback", - "par": ["trade-1"], - "pol": "compensation_policy", - "pol_decision": "approved", - "pol_enforcer": "spiffe://bank.com/human/compliance-officer-123", - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" -} -``` - -**Audit Trail Proof**: -- Original trade was authorized (trade-1) -- Violation was discovered and decision made to rollback (compensation-1) -- Both decisions are immutable, verifiable -- Regulator can see: "Trade executed, later revoked by authorized officer with documented reason" - ---- - -### 12. Appendices (Optional) - -#### A. Glossary of Terms -- **Agent**: Autonomous workload (WIMSE term) -- **DAG**: Directed acyclic graph -- **ECT**: Execution Context Token (this spec) -- **Task**: Discrete unit of agent work -- **WIT**: Workload Identity Token (WIMSE) -- **WPT**: Workload Proof Token (WIMSE) -- **Trust Domain**: Organizational identity boundary (WIMSE) -- **Policy Enforcer**: System/person that makes authorization decisions -- **Witness**: Third party observing execution (for accountability) -- **Ledger**: Immutable log of ECTs - -#### B. Reference Implementation Guidance -- **Language**: Rust (type safety for protocol invariants) -- **Serialization**: Cap'n Proto or serde_json (for performance) -- **Cryptography**: `ring` or `p256` crate (audited, performant) -- **JWT**: `jsonwebtoken` crate (standard, well-maintained) -- **Ledger**: `sled` (append-only log) or PostgreSQL (if you want SQL) - -#### C. Regulatory Reference Map - -| Regulation | Requirement | How ECT Helps | -|-----------|-------------|--------------| -| **FDA 21 CFR Part 11** | Electronic records trustworthy, reliable, non-repudiation | ECT provides cryptographic proof | -| **EU MDR (Medical Devices)** | Audit trail of AI-assisted decisions | ECT creates immutable decision log | -| **EU AI Act Art 12** | High-risk AI: Activity logs to demonstrate compliance | ECT is the activity log | -| **EU AI Act Art 14** | Human override capability, logged | ECT captures human approvals | -| **MiFID II** | Transaction reporting, contemporaneous, immutable | ECT timestamps and signs decisions | -| **DORA** | Digital operational resilience, significant transactions logged | ECT is the transaction log | -| **Military regulations** | Chain of custody, authorization proof | ECT proves decision chain | - ---- - -## Prompt Instructions for Using This Master Prompt - -### Iteration 1: WIMSE Extension Positioning (Next Step) -1. Read sections 1-3 -2. Refine positioning: How clear is "extends WIMSE" vs "standalone"? -3. Adjust regulatory emphasis: Which 2-3 verticals are strongest? -4. **Output**: 2-3 page refined abstract + introduction - -Key question to answer: Is the opening statement clear that this is a WIMSE extension, not a new standard? - -### Iteration 2: Technical Architecture -1. Review section 4 (Technical Architecture) -2. Finalize ECT claims: Are these the right ones? Any additions/removals? -3. Decide: Should task ledger structure be normative or informative? -4. **Output**: Complete architecture section with clean JSON examples - -### Iteration 3: Integration & Examples -1. Review section 4.5 (Claims Semantics) and section 11 (Examples) -2. Ensure examples are clear and realistic -3. Verify WIMSE integration is tight and natural -4. **Output**: Examples section that clearly shows WIMSE + ECT integration - -### Iteration 4: Security & Regulatory Mapping -1. Review section 6 (Security) and Appendix C (Regulatory Map) -2. Add/refine threat model if needed -3. Verify regulatory claims are defensible -4. **Output**: Security section with clear regulatory alignment - -### Iteration 5: Use Cases & Messaging -1. Review section 5 (Use Cases) -2. Pick 2-3 strongest use cases for your market -3. Deepen regulatory compliance mapping -4. **Output**: 3-4 page polished use cases section - -### Iteration 6: IANA & Related Work -1. Review section 8 (IANA) and section 9 (Related Work) -2. Finalize claim names and registrations -3. Clarify positioning vs. other work -4. **Output**: IANA considerations + related work sections - -### Iteration 7: Full Draft Assembly -1. Combine all sections -2. Add IETF boilerplate (status, copyright, etc.) -3. Cross-reference sections -4. **Output**: Submission-ready I-D (XML or Markdown) - ---- - -## Key Strategic Decisions - -### 1. WIMSE Extension Positioning -This is now your positioning. Make it clear: -- Opening: "This document defines an extension to the WIMSE architecture..." -- Problem: "WIMSE identity + execution proof = complete regulated agentic system" -- Integration: Tight with WIT/WPT - -### 2. Regulatory Credibility -Lead with regulatory requirements, not technology: -- "FDA 21 CFR Part 11 requires... ECTs provide..." -- "EU AI Act Article 12 requires... ECTs enable..." -- Technology is the answer to regulatory questions - -### 3. Horizontal Applicability -Show ECTs work equally for medtech, finance, military: -- Same ECT format -- Same DAG validation -- Same security model -- Different use cases, same mechanics - -### 4. Identity-Agnostic (But WIMSE-Primary) -- Primary: WIMSE integration -- Secondary: "Compatible with other identity systems" (SPIFFE, custom) -- This allows future extensibility without overcomplicating main spec - ---- - -## Resources & References - -### RFCs to Cite -- RFC 2119, 8174: Keywords -- RFC 7515: JWS -- RFC 7519: JWT -- RFC 8785: JSON Canonicalization -- RFC 3552: Security Considerations template -- RFC 9421: HTTP Message Signatures (for TLS alternative) - -### IETF Drafts to Cite -- draft-ietf-wimse-arch: WIMSE Architecture -- draft-ietf-wimse-workload-creds: WIT -- draft-ietf-wimse-wpt: WPT (if published; otherwise S2S) -- draft-ietf-wimse-s2s-protocol: Service-to-service auth -- draft-ni-wimse-ai-agent-identity: AI agents applicability - -### Standards References -- EU AI Act (compliance context) -- FDA 21 CFR Part 11 -- MiFID II -- DORA - ---- - -## Next Steps - -**Iteration 1 is your next move.** Refine: -1. Abstract: Is "extends WIMSE" clear? -2. Introduction: Is the gap (execution proof) well-motivated? -3. Problem statement: Are regulatory drivers compelling? - -Send me your Iteration 1 output (refined abstract + introduction), and we'll lock positioning before diving into technical sections. - -Good luck. You've got this.