From a2e4d32ffdc0d3acc9110b18313fbec9d67f3a4c Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Tue, 24 Feb 2026 05:30:37 +0100 Subject: [PATCH] Add IETF Internet-Draft: Execution Context Tokens for WIMSE Initial submission of draft-nennemann-wimse-execution-context-00, defining Execution Context Tokens (ECTs) as a WIMSE extension for distributed agentic workflows in regulated environments. ECTs provide cryptographic proof of task execution order, policy enforcement decisions, and compliance state using JWT/JWS format with DAG-structured task dependencies. Key features: - 17 new JWT claims for execution context tracing - Execution-Context HTTP header for token transport - DAG validation with cycle detection and temporal ordering - Audit ledger interface specification - Integration with WIMSE WIT/WPT signing model - Use cases: medtech, finance, logistics, compensation/rollback Includes master-prompt.md with design rationale and iteration plan. Co-Authored-By: Claude Opus 4.6 --- draft-nennemann-wimse-execution-context-00.md | 1700 +++++++++++++++++ master-prompt.md | 1186 ++++++++++++ 2 files changed, 2886 insertions(+) create mode 100644 draft-nennemann-wimse-execution-context-00.md create mode 100644 master-prompt.md diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md new file mode 100644 index 0000000..8e9bbe5 --- /dev/null +++ b/draft-nennemann-wimse-execution-context-00.md @@ -0,0 +1,1700 @@ +--- +title: "Execution Context Tokens for Distributed Agentic Workflows" +abbrev: "WIMSE Execution Context" +category: std +docname: draft-nennemann-wimse-execution-context-00 +submissiontype: IETF +number: +date: +v: 3 +area: "Security" +keyword: + - execution context + - workload identity + - agentic workflows + - audit trail + - compliance + - regulated systems + +author: + - + fullname: Christian Nennemann + organization: Independent Researcher + email: ietf@nennemann.de + +normative: + RFC2119: + RFC8174: + RFC3339: + RFC7515: + RFC7519: + RFC7518: + RFC9562: + RFC9110: + I-D.ietf-wimse-arch: + I-D.ietf-wimse-s2s-protocol: + +informative: + RFC3552: + RFC7517: + RFC8693: + RFC9421: + I-D.ni-wimse-ai-agent-identity: + SPIFFE: + title: "Secure Production Identity Framework for Everyone (SPIFFE)" + target: https://spiffe.io/docs/latest/spiffe-about/overview/ + date: false + EU-AI-ACT: + title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)" + target: https://eur-lex.europa.eu/eli/reg/2024/1689 + date: 2024-06-13 + author: + - org: European Parliament and Council of the European Union + FDA-21CFR11: + title: "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures" + target: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 + date: false + author: + - org: U.S. Food and Drug Administration + MIFID-II: + title: "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)" + target: https://eur-lex.europa.eu/eli/dir/2014/65 + date: 2014-05-15 + author: + - org: European Parliament and Council of the European Union + DORA: + title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)" + target: https://eur-lex.europa.eu/eli/reg/2022/2554 + date: 2022-12-14 + author: + - org: European Parliament and Council of the European Union + EU-MDR: + title: "Regulation (EU) 2017/745 on medical devices (MDR)" + target: https://eur-lex.europa.eu/eli/reg/2017/745 + date: 2017-04-05 + author: + - org: European Parliament and Council of the European Union + OPENTELEMETRY: + title: "OpenTelemetry Specification" + target: https://opentelemetry.io/docs/specs/otel/ + date: false + author: + - org: Cloud Native Computing Foundation + +--- abstract + +This document defines Execution Context Tokens (ECTs), an extension +to the Workload Identity in Multi System Environments (WIMSE) +architecture for distributed agentic workflows in regulated +environments. ECTs provide cryptographic proof of task execution +order, policy enforcement decisions, and compliance state across +agent-to-agent communication. By extending WIMSE Workload Identity +Tokens with execution context claims in JSON Web Token (JWT) +format, this specification enables regulated systems to maintain +structured audit trails that support compliance verification. +ECTs use a directed acyclic graph (DAG) structure to represent task +dependencies, record policy evaluation outcomes at each decision +point, and integrate with WIMSE Workload Identity Tokens (WIT) and +Workload Proof Tokens (WPT) using the same signing model and +cryptographic primitives. A new HTTP header field, +Execution-Context, is defined for transporting ECTs alongside +existing WIMSE headers. ECTs are a technical building block that +supports, but does not by itself constitute, compliance with +regulatory frameworks. + +--- middle + +# Introduction + +## Motivation + +The Workload Identity in Multi System Environments (WIMSE) +framework {{I-D.ietf-wimse-arch}} provides robust workload +authentication through Workload Identity Tokens (WIT) and Workload +Proof Tokens (WPT). The WIMSE service-to-service protocol +{{I-D.ietf-wimse-s2s-protocol}} defines how workloads authenticate +each other across call chains using the Workload-Identity and +Workload-Proof-Token HTTP headers. + +However, workload identity alone does not address execution +accountability. Knowing who performed an action does not prove +what was done, what policy was applied, or whether compliance +requirements were satisfied at each decision point. + +Regulated environments increasingly deploy autonomous agents that +coordinate across organizational boundaries. Multiple regulatory +frameworks motivate the need for structured execution records: + +- The EU Artificial Intelligence Act {{EU-AI-ACT}} Article 12 + requires high-risk AI systems to be designed with capabilities + enabling automatic recording of events ("logs") while the + system is operating. + +- The U.S. FDA 21 CFR Part 11 {{FDA-21CFR11}} requires + computer-generated, timestamped audit trails that independently + record the date, time, operator identity, and actions taken + (Section 11.10(e)). + +- The Markets in Financial Instruments Directive (MiFID II) + {{MIFID-II}} requires firms to maintain records of transactions + and orders that are sufficient to enable supervisory authorities + to monitor compliance. + +- The Digital Operational Resilience Act (DORA) {{DORA}} Article 12 + requires financial entities to have logging policies that record + ICT activities and anomalies. + +This document defines an extension to the WIMSE architecture that +addresses the gap between workload identity and execution +accountability. WIMSE authenticates agents; this extension records +what they did, in what order, and what policy was evaluated. + +As identified in {{I-D.ni-wimse-ai-agent-identity}}, call context +in agentic workflows must always be visible and preserved. ECTs +provide a mechanism to address this requirement with cryptographic +assurances. + +## Problem Statement + +Three core gaps exist in current approaches to regulated agentic +systems: + +1. WIMSE authenticates agents but does not record what they + actually did. A WIT proves "Agent A is authorized" but not + "Agent A executed Task X, under Policy Y, producing Output Z." + +2. No standard mechanism exists to record policy evaluation + outcomes at each decision point in a multi-agent workflow. + +3. No mechanism exists to cryptographically link compensation and + rollback decisions to original actions. + +Existing observability tools such as distributed tracing +{{OPENTELEMETRY}} provide visibility for debugging and monitoring +but do not provide cryptographic assurances. Tracing data is not +cryptographically signed, not tamper-evident, and not designed for +regulatory audit scenarios. + +## Scope and Applicability + +This document defines: + +- The Execution Context Token (ECT) format ({{ect-format}}) +- DAG structure for task dependency ordering ({{dag-validation}}) +- Policy checkpoint recording ({{policy-claims}}) +- Integration with the WIMSE identity framework + ({{wimse-integration}}) +- 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 + +## Relationship to Regulatory Compliance + +ECTs are a technical mechanism that can support compliance programs +by providing structured, cryptographically signed execution +records. ECTs do not by themselves constitute compliance with any +regulatory framework referenced in this document. + +Compliance with each referenced regulation requires organizational +controls, policies, procedures, validation, and governance measures +beyond the scope of this specification. The regulatory references +in this document are intended to motivate the design requirements, +not to claim that implementing ECTs satisfies these regulations. + +ECTs provide evidence of claimed execution ordering and policy +evaluation. They do not independently verify that the claimed +execution actually occurred as described, that the policy +evaluation was correct, or that 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. + +# 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 and policy evaluation outcomes. + +Audit Ledger: +: An append-only, immutable log of all ECTs within a workflow or + set of workflows, used for regulatory audit and compliance + verification. + +Policy Checkpoint: +: A point in a workflow where a policy evaluation outcome is + recorded within an ECT. + +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. + +Witness: +: A third-party entity that observes and attests to the execution + of a task, providing additional accountability. + +# WIMSE Architecture Integration {#wimse-integration} + +## WIMSE Foundation + +The WIMSE architecture {{I-D.ietf-wimse-arch}} defines: + +- Workload Identity Tokens (WIT) that prove a workload's identity + within a trust domain ("I am Agent X in trust domain Y") +- Workload Proof Tokens (WPT) that prove possession of the private + key associated with a WIT ("I control the key for Agent X") +- Multi-hop authentication via the service-to-service protocol + {{I-D.ietf-wimse-s2s-protocol}} + +The following execution accountability needs are complementary to +the WIMSE scope and are not addressed by workload identity alone: + +- Recording what agents actually do with their authenticated + identity +- Recording policy evaluation outcomes at each hop +- Maintaining structured execution records +- Linking compensation or rollback actions to original tasks + +## Extension Model + +ECTs extend WIMSE by adding an execution accountability layer +between the identity layer and the application layer: + +~~~ ascii-art ++--------------------------------------------------+ +| WIMSE Layer (Identity) | +| WIT: "I am Agent X (spiffe://td/agent/x)" | +| WPT: "I prove I control the key for Agent X" | ++--------------------------------------------------+ + | + v ++--------------------------------------------------+ +| ECT Layer (Execution Accountability) [This Spec]| +| ECT: "Task executed, dependencies met, | +| policy evaluated, outcome recorded" | ++--------------------------------------------------+ + | + v ++--------------------------------------------------+ +| Ledger Layer (Immutable Record) | +| "All ECTs appended to audit ledger" | ++--------------------------------------------------+ +~~~ +{: #fig-layers title="WIMSE Extension Architecture Layers"} + +This extension reuses the WIMSE signing model, extends JWT claims +using standard JWT extensibility {{RFC7519}}, and maintains WIMSE +concepts including trust domains and workload identifiers. + +## Integration Points {#integration-points} + +An ECT integrates with the WIMSE identity framework through the +following mechanisms: + +- The ECT JOSE header "kid" parameter MUST reference the public + key identifier from the agent's WIT. + +- The ECT "iss" claim MUST use the WIMSE workload identifier + format (a SPIFFE ID {{SPIFFE}}). + +- The ECT MUST be signed with the same private key used to + generate the agent's WPT. + +- The ECT signing algorithm (JOSE header "alg" parameter) MUST + match the algorithm used in the corresponding WIT. + +When an agent makes an HTTP request to another agent, the three +tokens are carried in their respective HTTP header fields: + +~~~ ascii-art +HTTP Request from Agent A to Agent B: + Workload-Identity: + Workload-Proof-Token: + Execution-Context: +~~~ +{: #fig-http-headers title="HTTP Header Stacking"} + +The receiving agent (Agent B) verifies in order: + +1. WIT and WPT (WIMSE layer): Proves who Agent A is and that the + request is authentic. + +2. ECT (this extension): Records what Agent A did, what policy was + evaluated, and what precedent tasks exist. + +3. Ledger: Appends the verified ECT to the audit ledger. + +# 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}} using the Compact +Serialization. JWS JSON Serialization MUST NOT be used for ECTs. + +## 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} + +The ECT payload contains both WIMSE-compatible standard JWT claims +and execution context claims defined by this specification. + +### WIMSE-Compatible Claims + +The following standard JWT claims {{RFC7519}} MUST be present in +every ECT: + +iss: +: REQUIRED. StringOrURI. The issuer of the ECT, which MUST be + the workload's SPIFFE ID in the format + `spiffe:///`. This MUST match the "sub" + claim of the agent's WIT. + +sub: +: OPTIONAL. StringOrURI. The subject of the ECT. When present, + MUST equal the "iss" claim. + +aud: +: REQUIRED. StringOrURI or array of StringOrURI. The intended + recipient(s) of the ECT. Typically the next agent in the + workflow or the ledger endpoint. + +iat: +: REQUIRED. NumericDate. The time at which the ECT was issued. + The ECT records a completed action, so the "iat" value reflects + when the record was created, not when task execution began. + +exp: +: REQUIRED. NumericDate. The expiration time of the ECT. + Implementations SHOULD set this to 5 to 15 minutes after "iat" + to limit the replay window while allowing for reasonable clock + skew and processing time. + +jti: +: OPTIONAL. String. A unique identifier for the ECT, useful for + additional replay detection. + +### Execution Context Claims {#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}}. When absent, the "tid" uniqueness requirement + applies globally across the entire ledger. + +tid: +: REQUIRED. String. A globally unique task identifier in UUID + format {{RFC9562}}. Each task MUST have a unique "tid" value. + When "wid" is present, uniqueness is scoped to the workflow; + when "wid" is absent, uniqueness MUST be enforced globally + across the ledger. + +exec_act: +: REQUIRED. String. The action or task type identifier describing + what the agent performed (e.g., "process_payment", + "validate_safety", "calculate_dosage"). Note: this claim is + intentionally named "exec_act" rather than "act" to avoid + collision with the "act" (Actor) claim registered by + {{RFC8693}}. + +par: +: REQUIRED. Array of strings. Parent task identifiers + representing DAG dependencies. Each element MUST be a valid + "tid" from a previously executed task. An empty array indicates + a root task with no dependencies. A workflow MAY contain + multiple root tasks. + +### Policy Claims {#policy-claims} + +The following claims record policy evaluation outcomes: + +pol: +: REQUIRED. String. The identifier of the policy rule that was + evaluated for this task (e.g., + "clinical_data_access_policy_v1"). + +pol_decision: +: REQUIRED. String. The result of the policy evaluation. MUST + be one of: "approved", "rejected", or "pending_human_review". + +pol_enforcer: +: OPTIONAL. StringOrURI. The identity of the entity (system or + person) that evaluated the policy decision. When present, + SHOULD use SPIFFE ID format. + +pol_timestamp: +: OPTIONAL. NumericDate. The time at which the policy decision + was made. When present, MUST be equal to or earlier than the + "iat" claim. + +### Data Integrity Claims {#data-integrity-claims} + +The following claims provide integrity verification for task +inputs and outputs without revealing the data itself: + +inp_hash: +: OPTIONAL. String. A cryptographic hash of the input data, + formatted as "hash-algorithm:base64url-encoded-hash" (e.g., + "sha-256:n4bQgYhMfWWaL-qgxVrQFaO\_TxsrC4Is0V1sFbDwCgg"). The + hash algorithm identifier SHOULD be "sha-256". The hash MUST be + computed over the raw octets of the input data. + +out_hash: +: OPTIONAL. String. A cryptographic hash of the output data, + using the same format as "inp_hash". + +inp_classification: +: OPTIONAL. String. The data sensitivity classification of the + input (e.g., "public", "confidential", "restricted"). + +### Operational Claims {#operational-claims} + +The following claims provide additional operational context: + +exec_time_ms: +: OPTIONAL. Integer. The execution duration of the task in + milliseconds. MUST be a non-negative integer. + +regulated_domain: +: OPTIONAL. String. The regulatory domain applicable to this + task. Values are drawn from an extensible set; initial values + include "medtech", "finance", and "military". + +model_version: +: OPTIONAL. String. The version identifier of the AI or ML model + used to perform the task, if applicable. + +### Witness Claims {#witness-claims} + +witnessed_by: +: OPTIONAL. Array of StringOrURI. Identifiers of third-party + entities that observed or attested to the execution of this + task. When present, each element SHOULD use SPIFFE ID format. + In regulated environments, implementations SHOULD use witness + attestation for critical decision points to mitigate the risk + of single-agent false claims. + +### Compensation Claims {#compensation-claims} + +compensation_required: +: OPTIONAL. Boolean. Indicates whether this task is a + compensation or rollback action for a previous task. + +compensation_reason: +: OPTIONAL. String. A human-readable reason for the compensation + action. MUST be present if "compensation_required" is true. + +Note: compensation ECTs reference historical parent tasks via the +"par" claim. The referenced parent ECTs may have passed their own +"exp" time; ECT expiration applies to the verification window of +the ECT itself, not to its validity as a parent reference in the +ledger. + +### Extension Claims {#extension-claims} + +ext: +: OPTIONAL. Object. An extension object for domain-specific + claims not defined by this specification. Implementations + that do not understand extension claims SHOULD ignore them. + To avoid key collisions between different domains, extension + key names SHOULD use reverse domain notation (e.g., + "com.example.custom_field"). + +The "ext" claim is a generic extension mechanism; it is not +registered in the IANA JWT Claims registry because its semantics +depend on the domain-specific claims within it. + +## Complete ECT Example + +The following is a complete ECT payload example: + +~~~json +{ + "iss": "spiffe://example.com/agent/clinical", + "sub": "spiffe://example.com/agent/clinical", + "aud": "spiffe://example.com/agent/safety", + "iat": 1772064150, + "exp": 1772064750, + + "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789", + "tid": "550e8400-e29b-41d4-a716-446655440001", + "exec_act": "recommend_treatment", + "par": [], + + "pol": "clinical_reasoning_policy_v2", + "pol_decision": "approved", + "pol_enforcer": "spiffe://example.com/policy/clinical-engine", + "pol_timestamp": 1772064145, + + "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "inp_classification": "confidential", + "exec_time_ms": 245, + "regulated_domain": "medtech", + "model_version": "clinical-reasoning-v4.2", + + "witnessed_by": [ + "spiffe://example.com/audit/observer-1" + ] +} +~~~ +{: #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 +and Workload-Proof-Token headers: + +~~~ +GET /api/safety-check HTTP/1.1 +Host: safety-agent.example.com +Workload-Identity: eyJhbGci...WIT... +Workload-Proof-Token: eyJhbGci...WPT... +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. + +# DAG Validation {#dag-validation} + +## Overview + +ECTs form a Directed Acyclic Graph (DAG) where each task +references its parent tasks via the "par" claim. This structure +provides a cryptographically signed record of execution ordering, +enabling auditors to reconstruct the complete workflow and verify +that required predecessor tasks were recorded before dependent +tasks. + +## Validation Rules + +When receiving and verifying an ECT, implementations MUST perform +the following DAG validation steps: + +1. Task ID Uniqueness: The "tid" claim MUST be unique within the + applicable scope (the workflow identified by "wid", or the + entire ledger if "wid" is absent). If a task with the same + "tid" already exists, the ECT MUST be rejected. + +2. Parent Existence: Every task identifier listed in the "par" + array MUST correspond to a task that has been previously + recorded in the ledger. If any parent task is not found, the + ECT MUST be rejected. + +3. Temporal Ordering: The "iat" value of every parent task MUST be + less than the "iat" value of the current task plus a + configurable clock skew tolerance (RECOMMENDED: 30 seconds). + If any parent task has an "iat" that violates this constraint, + the ECT MUST be rejected. + +4. Acyclicity: Following the chain of parent references MUST NOT + lead back to the current task's "tid". 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. + +## DAG Validation Algorithm + +The following pseudocode describes the DAG validation procedure: + +~~~ pseudocode +function validate_dag(ect, ledger, clock_skew_tolerance): + // Step 1: Uniqueness check + if ledger.contains(ect.tid, ect.wid): + return error("Task ID already exists in ledger") + + // Step 2: Parent existence and temporal ordering + for parent_id in ect.par: + parent = ledger.get(parent_id) + if parent is null: + return error("Parent task not found: " + parent_id) + if parent.iat >= ect.iat + clock_skew_tolerance: + return error("Parent task not earlier than current") + + // Step 3: Cycle detection + visited = set() + if has_cycle(ect.tid, ect.par, ledger, visited): + return error("Circular dependency detected") + + return success + +function has_cycle(target_tid, parent_ids, ledger, visited): + for parent_id in parent_ids: + if parent_id == target_tid: + return true + if parent_id in visited: + continue + visited.add(parent_id) + parent = ledger.get(parent_id) + if parent is not null: + if has_cycle(target_tid, parent.par, ledger, visited): + return true + return false +~~~ +{: #fig-dag-validation title="DAG Validation Pseudocode"} + +The cycle detection traverses the ancestor graph rooted at the +current task's parents. The complexity is O(V) where V is the +number of ancestor nodes reachable from the current task's parent +references. For typical workflows with shallow DAGs, this is +efficient. Implementations SHOULD cache cycle detection results +for previously verified tasks to avoid redundant traversals. + +# 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 is not "none" and is + not a symmetric algorithm. + +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 the "alg" header parameter matches the algorithm in the + corresponding WIT. + +7. Verify the "iss" claim matches the "sub" claim of the WIT + associated with the "kid" public key. + +8. Verify the "aud" claim contains the verifier's own workload + identity or an expected recipient identifier. + +9. Verify the "exp" claim indicates the ECT has not expired. + +10. Verify the "iat" claim is not unreasonably far in the past + (implementation-specific threshold, RECOMMENDED maximum of + 15 minutes). + +11. Verify all required claims ("tid", "exec_act", "par", "pol", + "pol_decision") are present and well-formed. + +12. Verify "pol_decision" is one of "approved", "rejected", or + "pending_human_review". + +13. Perform DAG validation per {{dag-validation}}. + +14. If all checks pass, the ECT MUST be appended to the audit + 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 +ledger, to prevent information disclosure. + +## Verification Pseudocode + +~~~ pseudocode +function verify_ect(ect_jws, verifier_id, + trust_domain_keys, ledger): + // Parse JWS + (header, payload, signature) = parse_jws(ect_jws) + + // Verify header + if header.typ != "wimse-exec+jwt": + return reject("Invalid typ parameter") + + if header.alg == "none" or is_symmetric(header.alg): + return reject("Prohibited algorithm") + + // Look up public key + public_key = trust_domain_keys.get(header.kid) + if public_key is null: + return reject("Unknown key identifier") + + // Verify signature + if not verify_jws_signature(header, payload, + signature, public_key): + return reject("Invalid signature") + + // Verify algorithm alignment + wit = get_wit_for_key(header.kid) + if header.alg != wit.alg: + return reject("Algorithm mismatch with WIT") + + // Verify issuer matches WIT subject + if payload.iss != wit.sub: + return reject("Issuer does not match WIT subject") + + // Verify audience + if verifier_id not in payload.aud: + return reject("ECT not intended for this recipient") + + // Verify not expired + if payload.exp < current_time(): + return reject("ECT has expired") + + // Verify iat freshness + if payload.iat < current_time() - max_age_threshold: + return reject("ECT issued too long ago") + + // Verify required claims + for claim in ["tid", "exec_act", "par", + "pol", "pol_decision"]: + if claim not in payload: + return reject("Missing required claim: " + claim) + + // Validate pol_decision value + if payload.pol_decision not in + ["approved", "rejected", "pending_human_review"]: + return reject("Invalid pol_decision value") + + // Validate DAG + result = validate_dag(payload, ledger, + clock_skew_tolerance) + if result is error: + return reject("DAG validation failed") + + // All checks passed; append to ledger + ledger.append(payload) + return accept +~~~ +{: #fig-verification title="ECT Verification Pseudocode"} + +# Audit Ledger Interface {#ledger-interface} + +## Overview + +ECTs are designed to be recorded in an immutable audit ledger for +compliance verification and post-hoc analysis. This specification +defines the logical interface for the ledger but 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. + +## Required Properties + +An audit ledger 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 task ID: The ledger MUST support efficient retrieval + of ECT entries by "tid" 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. + +## Ledger Entry Structure + +Each ledger entry is a logical record containing: + +~~~json +{ + "ledger_sequence": 42, + "task_id": "550e8400-e29b-41d4-a716-446655440001", + "agent_id": "spiffe://example.com/agent/clinical", + "action": "recommend_treatment", + "parents": [], + "ect_jws": "eyJhbGciOiJFUzI1NiIs...", + "signature_verified": true, + "verification_timestamp": "2026-02-24T15:42:31.000Z", + "stored_timestamp": "2026-02-24T15:42:31.050Z" +} +~~~ +{: #fig-ledger-entry title="Ledger Entry Example"} + +The "ect_jws" field contains the full JWS Compact Serialization +and is the authoritative record. The other fields ("agent_id", +"action", "parents") are convenience indexes derived from the +ECT payload; if they disagree with the JWS payload, the JWS +payload takes precedence. + +# Use Cases {#use-cases} + +This section describes representative use cases demonstrating how +ECTs provide execution records in regulated environments. These +examples demonstrate ECT mechanics; production deployments would +include additional domain-specific requirements beyond the scope +of this specification. + +Note: task identifiers in this section are abbreviated for +readability. In production, all "tid" values MUST be UUIDs per +{{RFC9562}}. + +## Medical Device Workflow + +In a medical device workflow, multiple AI agents coordinate to +produce a treatment recommendation. Regulatory frameworks +including {{FDA-21CFR11}} Section 11.10(e) and {{EU-MDR}} require +audit trails of decisions made by or with the assistance of +software systems. + +~~~ +Agent A (Clinical Reasoning): + tid: task-001 par: [] + exec_act: recommend_treatment + pol: clinical_rules_v2 pol_decision: approved + +Agent B (Safety Check): + tid: task-002 par: [task-001] + exec_act: check_drug_interactions + pol: safety_policy_v3 pol_decision: approved + +Agent C (Dosage Calculation): + tid: task-003 par: [task-002] + exec_act: calculate_dosage + pol: dosage_rules_v1 pol_decision: approved + +Human Physician Review: + tid: task-004 par: [task-003] + exec_act: approve_treatment + pol: physician_approval pol_decision: approved + pol_enforcer: spiffe://hospital.com/human/physician-123 + witnessed_by: [spiffe://hospital.com/audit/observer-1] +~~~ +{: #fig-medtech title="Medical Device Workflow"} + +ECTs record that clinical reasoning preceded safety checking, +safety checking preceded dosage calculation, and a human physician +approved the final recommendation. The DAG structure shows that +no step was skipped or reordered. + +This can contribute to compliance with: + +- {{FDA-21CFR11}} Section 11.10(e): Computer-generated audit trails + that record the date, time, and identity of the operator. +- {{EU-MDR}} Annex II: Technical documentation traceability. +- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for + high-risk AI systems. + +## Financial Trading Workflow + +In a financial trading workflow, agents perform risk assessment, +compliance verification, and trade execution. The DAG structure +records that compliance checks were evaluated before trade +execution. + +~~~ +Agent A (Risk Assessment): + tid: task-001 par: [] + exec_act: calculate_risk_exposure + pol: risk_limits_policy_v2 pol_decision: approved + +Agent B (Compliance): + tid: task-002 par: [task-001] + exec_act: verify_compliance + pol: compliance_check_v1 pol_decision: approved + +Agent C (Execution): + tid: task-003 par: [task-002] + exec_act: execute_trade + pol: execution_policy_v3 pol_decision: approved +~~~ +{: #fig-finance title="Financial Trading Workflow"} + +This can contribute to compliance with: + +- {{MIFID-II}}: ECTs provide cryptographic records of the execution + sequence that can support transaction audit requirements. +- {{DORA}} Article 12: ECTs contribute to ICT activity logging. +- {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven + systems. + +## Compensation and Rollback + +When a compliance violation is discovered after execution, ECTs +provide a mechanism to record authorized compensation actions with +a cryptographic link to the original task: + +~~~json +{ + "iss": "spiffe://bank.com/agent/operations", + "sub": "spiffe://bank.com/agent/operations", + "aud": "spiffe://bank.com/system/ledger", + "iat": 1772150550, + "exp": 1772151150, + "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", + "tid": "550e8400-e29b-41d4-a716-446655440099", + "exec_act": "initiate_trade_rollback", + "par": ["550e8400-e29b-41d4-a716-446655440003"], + "pol": "compensation_policy_v1", + "pol_decision": "approved", + "pol_enforcer": "spiffe://bank.com/human/compliance-officer", + "compensation_required": true, + "compensation_reason": "policy_violation_in_parent_trade" +} +~~~ +{: #fig-compensation title="Compensation ECT Example"} + +The "par" claim links the compensation action to the original +trade, creating an auditable chain from execution through +violation discovery to remediation. + +## Autonomous Logistics Coordination + +In a logistics workflow, multiple compliance checks must complete +before shipment commitment. The DAG structure records that all +required checks were completed: + +~~~ +Agent A (Route Planning): + tid: task-001 par: [] + exec_act: plan_route + pol: route_policy_v1 pol_decision: approved + +Agent B (Customs): + tid: task-002 par: [task-001] + exec_act: validate_customs + pol: customs_policy_v2 pol_decision: approved + +Agent C (Safety): + tid: task-003 par: [task-001] + exec_act: verify_cargo_safety + pol: safety_policy_v1 pol_decision: approved + +Agent D (Payment): + tid: task-004 par: [task-002, task-003] + exec_act: authorize_payment + pol: payment_policy_v3 pol_decision: approved + +System (Commitment): + tid: task-005 par: [task-004] + exec_act: commit_shipment + pol: commitment_policy_v1 pol_decision: approved +~~~ +{: #fig-logistics title="Logistics Workflow with Parallel Tasks"} + +Note that tasks 002 and 003 both depend only on task-001 and can +execute in parallel. Task 004 depends on both, demonstrating the +DAG's ability to represent parallel execution with a join point. + +# Security Considerations + +This section addresses security considerations following the +guidance in {{RFC3552}}. + +## Threat Model + +The following threat actors are considered: + +- Malicious agent (insider threat): An agent within the trust + domain that intentionally creates false ECT claims. +- Compromised agent (external attacker): An agent whose private + key has been obtained by an external attacker. +- Ledger tamperer: An entity attempting to modify or delete ledger + entries after they have been recorded. +- Time manipulator: An entity attempting to manipulate timestamps + to alter perceived execution 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., setting "pol_decision" to "approved" without actually +evaluating the policy). + +ECTs do not independently verify that: + +- The claimed execution actually occurred as described +- The policy evaluation was correctly performed +- 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. To mitigate single-agent false claims, +regulated environments SHOULD use the "witnessed_by" mechanism +to include independent third-party observers at critical decision +points. + +## Organizational Prerequisites + +ECTs operate within a broader trust framework. The guarantees +provided by ECTs are only meaningful when the following +organizational controls are in place: + +- Key management governance: Controls over who provisions agent + keys and how keys are protected. +- Ledger integrity governance: The ledger is maintained by an + entity independent of the workflow agents. +- Policy lifecycle management: Policy identifiers in ECTs map to + actual, validated policy rules. +- Agent deployment governance: Agents are deployed and maintained + in a manner that preserves their integrity. + +## 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. + +If signature verification fails, 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) to +limit the window for replay attacks. The "aud" claim restricts +replay to unintended recipients: an ECT intended for Agent B +will be rejected by Agent C. The "iat" claim enables receivers to +reject ECTs that are too old, even if not yet expired. + +The DAG structure provides additional replay protection: an ECT +referencing parent tasks that already have a recorded child task +with the same action can be flagged as a potential replay. + +Implementations SHOULD maintain a cache of recently-seen "jti" +values (when present) to detect replayed ECTs within the +expiration window. + +## Man-in-the-Middle Protection + +ECTs do not replace transport-layer security. ECTs MUST be +transmitted over TLS or mTLS connections. When used with the WIMSE +service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}}, +transport security is already established. HTTP Message Signatures +{{RFC9421}} provide an alternative channel binding mechanism. + +The defense-in-depth model provides: + +- TLS/mTLS (transport layer): Prevents network-level tampering. +- WIT/WPT (WIMSE identity layer): Proves agent identity and + request authorization. +- ECT (execution accountability layer): Records what the agent did + and under what policy. + +## Key Compromise + +If an agent's private key is compromised, an attacker can forge +ECTs that appear to originate from that agent. To mitigate this +risk: + +- Implementations SHOULD use short-lived keys and rotate them + frequently (hours to days, not months). +- Private keys SHOULD be stored in Hardware Security Modules (HSMs) + or equivalent secure key storage. +- Trust domains MUST support rapid key revocation. +- Upon suspected compromise, the trust domain MUST revoke the + compromised key and issue a new WIT with a fresh key pair. + +ECTs signed with a compromised key that were recorded in the +ledger before revocation remain valid historical records but SHOULD +be flagged in the ledger as "signed with subsequently revoked key" +for audit purposes. + +## Collusion and False Claims + +A single malicious agent cannot forge parent task references +because DAG validation requires parent tasks to exist in the +ledger. However, multiple colluding agents could potentially +create a false execution history if they control the ledger. + +Mitigations include: + +- Independent ledger maintenance: The ledger SHOULD be maintained + by an entity independent of the workflow agents. +- Witness attestation: Using the "witnessed_by" claim to include + independent third-party observers. +- Cross-verification: Multiple independent ledger replicas can be + compared for consistency. +- Out-of-band audit: External auditors periodically verify ledger + contents against expected workflow patterns. + +## Denial of Service + +ECT signature verification is computationally inexpensive +(approximately 1ms per ECT on modern hardware for ES256). DAG +validation complexity is O(V) where V is the number of ancestor +nodes reachable from the parent references; for typical shallow +DAGs this is efficient. + +Implementations SHOULD apply rate limiting at the API layer to +prevent excessive ECT submissions. DAG validation SHOULD be +performed after signature verification to avoid wasting resources +on unsigned or incorrectly signed tokens. + +## Timestamp Accuracy + +ECTs rely on timestamps ("iat", "exp") for temporal ordering. +Clock skew between agents can lead to incorrect ordering +judgments. Implementations SHOULD use synchronized time sources +(e.g., NTP) and SHOULD allow a configurable clock skew tolerance +(RECOMMENDED: 30 seconds). + +The temporal ordering check in DAG validation incorporates the +clock skew tolerance to account for minor clock differences +between agents. + +## ECT Size Constraints + +ECTs with many parent tasks or large extension objects can +increase HTTP header size. Implementations SHOULD limit the "par" +array to a reasonable size and SHOULD set maximum size limits for +the "ext" object to prevent abuse. + +# Privacy Considerations + +## Data Exposure in ECTs + +ECTs necessarily reveal: + +- Agent identities ("iss", "aud") for accountability purposes +- Action descriptions ("exec_act") for audit trail completeness +- Policy evaluation outcomes ("pol", "pol_decision") for + compliance verification +- 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. +The "pol" claim SHOULD reference policy identifiers rather than +embedding policy content. + +## Storage and Access Control + +ECTs stored in audit ledgers SHOULD be access-controlled so that +only authorized auditors and regulators can read them. +Implementations SHOULD consider encryption at rest for ledger +storage containing sensitive regulatory data. + +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. + +## Regulatory Access + +ECTs are designed for interpretation by qualified human auditors +and regulators. ECTs provide structural records of execution +ordering and policy evaluation; they are not intended for public +disclosure. + +# 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 regulated 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}} | +| tid | Task Identifier | IETF | {{exec-claims}} | +| exec_act | Action/Task Type | IETF | {{exec-claims}} | +| par | Parent Task Identifiers | IETF | {{exec-claims}} | +| pol | Policy Rule Identifier | IETF | {{policy-claims}} | +| pol_decision | Policy Decision Result | IETF | {{policy-claims}} | +| pol_enforcer | Policy Enforcer Identity | IETF | {{policy-claims}} | +| pol_timestamp | Policy Decision Timestamp | IETF | {{policy-claims}} | +| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} | +| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} | +| inp_classification | Input Data Classification | IETF | {{data-integrity-claims}} | +| exec_time_ms | Execution Time (ms) | IETF | {{operational-claims}} | +| witnessed_by | Witness Identities | IETF | {{witness-claims}} | +| regulated_domain | Regulatory Domain | IETF | {{operational-claims}} | +| model_version | AI/ML Model Version | IETF | {{operational-claims}} | +| compensation_required | Compensation Flag | IETF | {{compensation-claims}} | +| compensation_reason | Compensation Reason | IETF | {{compensation-claims}} | +{: #table-claims title="JWT Claims Registrations"} + +--- back + +# 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?" and "what policy was +evaluated?" Together they form an identity-plus-accountability +framework for regulated agentic systems. + +## OAuth 2.0 Token Exchange +{:numbered="false"} + +{{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and +registers the "act" (Actor) claim in the JWT Claims registry. +ECTs intentionally use the distinct claim name "exec_act" for the +action/task type to avoid collision with the "act" claim. +Transaction tokens in OAuth establish API authorization context; +ECTs serve the complementary purpose of recording execution +accountability across multi-step workflows. + +## 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. + +## Blockchain and Distributed Ledgers +{:numbered="false"} + +Both ECTs and blockchain systems provide immutable records. This +specification intentionally defines only the ECT token format and +is agnostic to the storage mechanism. ECTs can be stored in +append-only logs, databases with cryptographic commitments, +blockchain networks, or any storage providing the required +properties defined in {{ledger-interface}}. + +## W3C Verifiable Credentials +{:numbered="false"} + +W3C Verifiable Credentials represent claims about subjects (e.g., +identity, qualifications). ECTs represent execution records of +actions (what happened, in what order, under what policy). While +both use JWT/JWS as a serialization format, their semantics and +use cases are distinct. + +# Implementation Guidance +{:numbered="false"} + +## Minimal Implementation +{:numbered="false"} + +A minimal conforming implementation should: + +1. Create JWTs with all required claims ("iss", "aud", "iat", + "exp", "tid", "exec_act", "par", "pol", "pol_decision"). +2. Sign ECTs with the agent's private key using an algorithm + matching the WIT (ES256 recommended). +3. Verify ECT signatures against WIT public keys. +4. Perform DAG validation (parent existence, temporal ordering, + cycle detection). +5. Append verified ECTs to an audit ledger. + +## Storage Recommendations +{:numbered="false"} + +- Append-only log: Simplest approach; immutability by design. +- Database with hash chains: Periodic cryptographic commitments + over batches of entries. +- Distributed ledger: Maximum immutability guarantees for + cross-organizational audit. +- Hybrid: Hot storage in a database, cold archive in immutable + storage. + +## Performance Considerations +{:numbered="false"} + +- ES256 signature verification: approximately 1ms per ECT on + modern hardware. +- DAG validation: O(V) where V is the number of reachable ancestor + nodes (typically small for shallow workflows). +- JSON serialization: sub-millisecond per ECT. +- Total per-request overhead: approximately 5-10ms, acceptable + for regulated workflows where correctness is prioritized over + latency. + +## Interoperability +{:numbered="false"} + +Implementations should use established JWT/JWS libraries (JOSE) +for token creation and verification. Custom cryptographic +implementations should not be used. Implementations should be +tested against multiple JWT libraries to ensure interoperability. + +# Regulatory Compliance Mapping +{:numbered="false"} + +The following table summarizes how ECTs can contribute to +compliance with various regulatory frameworks. ECTs are a +technical building block; achieving compliance requires +additional organizational measures beyond this specification. + +| Regulation | Requirement | ECT Contribution | +|:---|:---|:---| +| FDA 21 CFR Part 11 | Audit trails recording date, time, operator, actions (11.10(e)) | Cryptographic signatures and append-only ledger contribute to audit trail requirements | +| EU MDR | Technical documentation traceability (Annex II) | ECTs provide signed records of AI-assisted decision sequences | +| EU AI Act Art. 12 | Automatic logging capabilities for high-risk AI | ECTs contribute cryptographic activity logging | +| EU AI Act Art. 14 | Human oversight capability | ECTs can record evidence that human oversight events occurred | +| MiFID II | Transaction records for supervisory authorities | ECTs provide cryptographic execution sequence records | +| DORA Art. 12 | ICT activity logging policies | ECT ledger contributes to ICT activity audit trail | +{: #table-regulatory title="Regulatory Compliance Mapping"} + +# Examples +{:numbered="false"} + +## Example 1: Simple Two-Agent Workflow +{:numbered="false"} + +Agent A executes a data retrieval task and sends the ECT to +Agent B: + +ECT JOSE Header: + +~~~json +{ + "alg": "ES256", + "typ": "wimse-exec+jwt", + "kid": "agent-a-key-2026-02" +} +~~~ + +ECT Payload: + +~~~json +{ + "iss": "spiffe://example.com/agent/data-retrieval", + "sub": "spiffe://example.com/agent/data-retrieval", + "aud": "spiffe://example.com/agent/validator", + "iat": 1772064150, + "exp": 1772064750, + "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", + "tid": "550e8400-e29b-41d4-a716-446655440001", + "exec_act": "fetch_patient_data", + "par": [], + "pol": "clinical_data_access_policy_v1", + "pol_decision": "approved", + "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "exec_time_ms": 142, + "regulated_domain": "medtech" +} +~~~ + +Agent B receives the ECT, verifies it, executes a validation +task, and creates its own ECT: + +~~~json +{ + "iss": "spiffe://example.com/agent/validator", + "sub": "spiffe://example.com/agent/validator", + "aud": "spiffe://example.com/system/ledger", + "iat": 1772064160, + "exp": 1772064760, + "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", + "tid": "550e8400-e29b-41d4-a716-446655440002", + "exec_act": "validate_safety", + "par": ["550e8400-e29b-41d4-a716-446655440001"], + "pol": "safety_validation_policy_v2", + "pol_decision": "approved", + "exec_time_ms": 89, + "regulated_domain": "medtech" +} +~~~ + +The resulting DAG: + +~~~ +task-...-0001 (fetch_patient_data) + | + v +task-...-0002 (validate_safety) +~~~ + +## Example 2: Medical Workflow with Human Oversight +{:numbered="false"} + +A multi-step clinical workflow with physician approval: + +Task 1 (Clinical Reasoning Agent): + +~~~json +{ + "iss": "spiffe://hospital.example/agent/clinical", + "sub": "spiffe://hospital.example/agent/clinical", + "aud": "spiffe://hospital.example/agent/safety", + "iat": 1772064150, + "exp": 1772064750, + "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", + "tid": "a1b2c3d4-0001-0000-0000-000000000001", + "exec_act": "recommend_treatment", + "par": [], + "pol": "clinical_rules_v2", + "pol_decision": "approved", + "regulated_domain": "medtech", + "model_version": "clinical-reasoning-v4.2" +} +~~~ + +Task 2 (Human Physician Approval): + +~~~json +{ + "iss": "spiffe://hospital.example/human/physician-456", + "sub": "spiffe://hospital.example/human/physician-456", + "aud": "spiffe://hospital.example/agent/dosage", + "iat": 1772064210, + "exp": 1772064810, + "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", + "tid": "a1b2c3d4-0001-0000-0000-000000000002", + "exec_act": "approve_treatment_recommendation", + "par": ["a1b2c3d4-0001-0000-0000-000000000001"], + "pol": "physician_approval_policy", + "pol_decision": "approved", + "pol_enforcer": "spiffe://hospital.example/human/physician-456", + "witnessed_by": [ + "spiffe://hospital.example/audit/observer-1" + ], + "regulated_domain": "medtech" +} +~~~ + +Task 3 (Dosage Calculation Agent): + +~~~json +{ + "iss": "spiffe://hospital.example/agent/dosage", + "sub": "spiffe://hospital.example/agent/dosage", + "aud": "spiffe://hospital.example/system/ledger", + "iat": 1772064230, + "exp": 1772064830, + "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", + "tid": "a1b2c3d4-0001-0000-0000-000000000003", + "exec_act": "calculate_dosage", + "par": ["a1b2c3d4-0001-0000-0000-000000000002"], + "pol": "dosage_rules_v1", + "pol_decision": "approved", + "regulated_domain": "medtech" +} +~~~ + +The resulting DAG records: clinical reasoning preceded physician +approval, which preceded dosage calculation. The physician +approval was independently witnessed. + +~~~ +task-...-0001 (recommend_treatment) + | + v +task-...-0002 (approve_treatment) [physician, witnessed] + | + v +task-...-0003 (calculate_dosage) +~~~ + +## Example 3: Parallel Execution with Join +{:numbered="false"} + +A workflow where two tasks execute in parallel and a third task +depends on both: + +~~~ +task-...-0001 (assess_risk) + | \ + v v +task-...-0002 task-...-0003 +(check (verify +compliance) liquidity) + | / + v v +task-...-0004 (execute_trade) +~~~ + +Task 004 ECT payload: + +~~~json +{ + "iss": "spiffe://bank.example/agent/execution", + "sub": "spiffe://bank.example/agent/execution", + "aud": "spiffe://bank.example/system/ledger", + "iat": 1772064250, + "exp": 1772064850, + "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", + "tid": "f1e2d3c4-0004-0000-0000-000000000004", + "exec_act": "execute_trade", + "par": [ + "f1e2d3c4-0002-0000-0000-000000000002", + "f1e2d3c4-0003-0000-0000-000000000003" + ], + "pol": "trade_execution_policy_v3", + "pol_decision": "approved", + "regulated_domain": "finance" +} +~~~ + +The "par" array with two entries records that both compliance +checking and liquidity verification were completed before trade +execution. + +# 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/master-prompt.md b/master-prompt.md new file mode 100644 index 0000000..b156b9a --- /dev/null +++ b/master-prompt.md @@ -0,0 +1,1186 @@ +# 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.