ietf-wimse-ect/master-prompt.md

# 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: <WIT for Agent A>
    Workload-Proof-Token: <WPT proving A controls key>
    Execution-Context: <ECT proving what A is doing and why>
  
  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": "<WIT key ID>"  // 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.