Slim down draft to core ECT mechanism for -00 submission

Remove all companion draft (ect-pol) references, regulatory
compliance mappings, pre-defined extension keys, witness concept,
pseudocode blocks, implementation guidance appendix, and redundant
examples. Keep only the core token format, DAG validation,
verification procedure, and one cross-organization use case.
Draft reduced from ~40 pages to 27 pages.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-ect-00.md

@@ -14,8 +14,6 @@ keyword:
   - workload identity
   - agentic workflows
   - audit trail
-  - compliance
-  - regulated systems
 
 author:
   -
@@ -38,46 +36,10 @@ informative:
   RFC8693:
   RFC9421:
   I-D.ni-wimse-ai-agent-identity:
-  I-D.nennemann-wimse-ect-pol:
-    title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens"
-    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/
-    date: false
-    author:
-      - fullname: Christian Nennemann
   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/
@@ -92,23 +54,17 @@ informative:
 
 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
+architecture for distributed agentic workflows.  ECTs provide
-environments.  ECTs provide signed, structured records of task
+signed, structured records of task execution order across
-execution order and compliance state across agent-to-agent
+agent-to-agent communication.  By extending WIMSE Workload Identity
-communication.  By extending WIMSE Workload Identity
 Tokens with execution context claims in JSON Web Token (JWT)
-format, this specification enables regulated systems to maintain
+format, this specification enables systems to maintain structured
-structured audit trails that support compliance verification.
+audit trails of agent execution.  ECTs use a directed acyclic
-ECTs use a directed acyclic graph (DAG) structure to represent task
+graph (DAG) structure to represent task dependencies and integrate
-dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
+with WIMSE Workload Identity Tokens (WIT) using the same signing
-using the same signing model and cryptographic primitives.
+model and cryptographic primitives.  A new HTTP header field,
-Policy evaluation and compensation extensions are defined in
-{{I-D.nennemann-wimse-ect-pol}}.  A new
-HTTP header field,
 Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.  ECTs are a technical building block that
+existing WIMSE headers.
-supports, but does not by itself constitute, compliance with
-regulatory frameworks.
 
 --- middle
 
@@ -132,8 +88,6 @@ Regulated environments increasingly deploy autonomous agents that
 coordinate across organizational boundaries.  Domains such as
 healthcare, finance, and logistics require structured, auditable
 records of automated decision-making and execution.
-{{table-regulatory}} in the appendix illustrates how ECTs relate
-to specific regulatory frameworks.
 
 This document defines an extension to the WIMSE architecture that
 addresses the gap between workload identity and execution
@@ -176,8 +130,6 @@ This document defines:
   ({{wimse-integration}})
 - An HTTP header for ECT transport ({{http-header}})
 - Audit ledger interface requirements ({{ledger-interface}})
-- Policy evaluation and compensation extensions are defined
-  separately in {{I-D.nennemann-wimse-ect-pol}}
 
 The following are out of scope and are handled by WIMSE:
 
@@ -186,26 +138,6 @@ The following are out of scope and are handled by WIMSE:
 - 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.  They do not
-independently verify that the claimed execution actually occurred
-as described 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}
@@ -230,8 +162,7 @@ Execution Context Token (ECT):
 
 Audit Ledger:
 : An append-only, immutable log of all ECTs within a workflow or
-  set of workflows, used for regulatory audit and compliance
+  set of workflows, used for audit and verification.
-  verification.
 
 Workload Identity Token (WIT):
 : A WIMSE credential proving a workload's identity within a trust
@@ -246,10 +177,6 @@ Trust Domain:
   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
@@ -351,8 +278,10 @@ The receiving agent (Agent B) verifies in order:
 # 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
+signed as a JSON Web Signature (JWS) {{RFC7515}}.  ECTs MUST use
-Serialization.  JWS JSON Serialization MUST NOT be used for ECTs.
+JWS Compact Serialization (the base64url-encoded
+`header.payload.signature` format) so that they can be carried in
+a single HTTP header value.
 
 ## JOSE Header {#jose-header}
 
@@ -481,7 +410,10 @@ par:
   representing DAG dependencies.  Each element MUST be the "jti"
   value of a previously verified ECT.  An empty array indicates
   a root task with no dependencies.  A workflow MAY contain
-  multiple root tasks.
+  multiple root tasks.  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 ECT store.
 
 ### Data Integrity {#data-integrity-claims}
 
@@ -504,14 +436,6 @@ out_hash:
 : OPTIONAL.  String.  A cryptographic hash of the output data,
   using the same format and algorithm requirements as "inp_hash".
 
-### Compensation and Rollback {#compensation-claims}
-
-Compensation and rollback extensions are defined in
-{{I-D.nennemann-wimse-ect-pol}}.  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 ECT store.
-
 ### Extensions {#extension-claims}
 
 ext:
@@ -529,23 +453,8 @@ nesting depth within the "ext" object SHOULD NOT exceed 5
 levels.  Implementations SHOULD reject ECTs whose "ext" claim
 exceeds these limits.
 
-The following extension keys are defined by this specification
+Extension keys for domain-specific use cases MAY be defined in
-for common use cases.  Because these keys are documented here,
+future documents.
-they use short names without reverse domain prefixes:
-
-- "exec\_time\_ms": Integer.  Execution duration in milliseconds.
-- "regulated\_domain": String.  Regulatory domain (e.g.,
-  "medtech", "finance", "military").
-- "model\_version": String.  AI/ML model version.
-- "witnessed\_by": Array of StringOrURI.  Identifiers of
-  third-party entities that the issuer claims observed the
-  task.  Note: this is self-asserted; for verifiable witness
-  attestation, witnesses should submit independent signed ECTs.
-- "inp\_classification": String.  Data sensitivity classification
-  (e.g., "public", "confidential", "restricted").
-
-Additional extension keys for policy evaluation and compensation
-are defined in {{I-D.nennemann-wimse-ect-pol}}.
 
 ## Complete ECT Example
 
@@ -564,13 +473,7 @@ The following is a complete ECT payload example:
   "par": [],
 
   "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
+  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-
-  "ext": {
-    "exec_time_ms": 245,
-    "regulated_domain": "medtech",
-    "model_version": "clinical-reasoning-v4.2"
-  }
 }
 ~~~
 {: #fig-full-ect title="Complete ECT Payload Example"}
@@ -659,63 +562,10 @@ the following DAG validation steps:
     same trust domain or to a trust domain with which a federation
     relationship has been established.
 
-## DAG Validation Algorithm
+To prevent denial-of-service via extremely deep or wide DAGs,
-
+implementations SHOULD enforce a maximum ancestor traversal limit
-The following pseudocode describes the DAG validation procedure:
+(RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
-
+detection completes, the ECT SHOULD be rejected.
-~~~ pseudocode
-function validate_dag(ect, ect_store, clock_skew_tolerance):
-  // Step 1: Uniqueness check
-  if ect_store.contains(ect.jti, ect.wid):
-    return error("ECT ID already exists")
-
-  // Step 2: Parent existence and temporal ordering
-  for parent_id in ect.par:
-    parent = ect_store.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 (with traversal limit)
-  visited = set()
-  result = has_cycle(ect.jti, ect.par, ect_store, visited,
-                      max_ancestor_limit)
-  if result is error or result is true:
-    return error("Circular dependency or depth limit exceeded")
-
-  return success
-
-function has_cycle(target_jti, parent_ids, ect_store,
-                   visited, max_depth):
-  if visited.size() >= max_depth:
-    return error("Maximum ancestor traversal limit exceeded")
-  for parent_id in parent_ids:
-    if parent_id == target_jti:
-      return true
-    if parent_id in visited:
-      continue
-    visited.add(parent_id)
-    parent = ect_store.get(parent_id)
-    if parent is not null:
-      result = has_cycle(target_jti, parent.par, ect_store,
-                          visited, max_depth)
-      if result is error or result is true:
-        return result
-  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.  To prevent denial-of-service via extremely deep or
-wide DAGs, implementations SHOULD enforce a maximum ancestor
-traversal limit (RECOMMENDED: 10000 nodes).  If the limit is
-reached before cycle detection completes, the ECT SHOULD be
-rejected.  Implementations SHOULD cache cycle detection results
-for previously verified tasks to avoid redundant traversals.
 
 # Signature and Token Verification {#verification}
 
@@ -787,76 +637,6 @@ revealing which specific verification step failed.  The receiving
 agent MUST NOT process the requested action when ECT verification
 fails.
 
-## Verification Pseudocode
-
-~~~ pseudocode
-function verify_ect(ect_jws, verifier_id,
-                     trust_domain_keys, ect_store):
-  // 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 key not revoked
-  if is_key_revoked(header.kid, trust_domain_keys):
-    return reject("Signing key has been revoked")
-
-  // 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 (not too old, not in the future)
-  if payload.iat < current_time() - max_age_threshold:
-    return reject("ECT issued too long ago")
-  if payload.iat > current_time() + clock_skew_tolerance:
-    return reject("ECT issued in the future")
-
-  // Verify required claims
-  for claim in ["jti", "exec_act", "par"]:
-    if claim not in payload:
-      return reject("Missing required claim: " + claim)
-
-  // Validate DAG (against ECT store or inline parent ECTs)
-  result = validate_dag(payload, ect_store,
-                         clock_skew_tolerance)
-  if result is error:
-    return reject("DAG validation failed")
-
-  // All checks passed; record if store is available
-  if ect_store is not null:
-    ect_store.append(payload)
-  return accept
-~~~
-{: #fig-verification title="ECT Verification Pseudocode"}
-
 # Audit Ledger Interface {#ledger-interface}
 
 ECTs MAY be recorded in an immutable audit ledger for compliance
@@ -917,21 +697,8 @@ ECTs do not independently verify that:
 - 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,
+of the signing agent and the integrity of the broader deployment
-regulated environments SHOULD use the "witnessed_by"
+environment.
-extension key (carried in "ext") to include independent
-third-party observers at critical decision points.  However,
-this value is self-asserted by the ECT issuer: the listed
-witnesses do not co-sign the ECT and there is no cryptographic
-evidence within a single ECT that the witnesses actually
-observed the task.  An issuing agent could list witnesses that
-did not participate.
-
-To strengthen witness attestation beyond self-assertion, witnesses
-SHOULD submit their own independent signed ECTs referencing the
-observed task's "jti" in the "par" array.  Auditors can then
-cross-check the "witnessed_by" extension against independent
-witness ECTs in the ECT store.
 
 ## Organizational Prerequisites
 
@@ -1024,8 +791,6 @@ Mitigations include:
 
 - Independent ledger maintenance: The ledger SHOULD be maintained
   by an entity independent of the workflow agents.
-- Witness attestation: Using the "witnessed_by" extension
-  key in "ext" 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
@@ -1103,21 +868,16 @@ structured identifiers.
 ## Storage and Access Control
 
 ECTs stored in audit ledgers SHOULD be access-controlled so that
-only authorized auditors and regulators can read them.
+only authorized auditors can read them.  Implementations SHOULD
-Implementations SHOULD consider encryption at rest for ledger
+consider encryption at rest for ledger storage.  ECTs provide
-storage containing sensitive regulatory data.
+structural records of execution ordering; they are not intended
+for public disclosure.
 
 Full input and output data (corresponding to the hashes in ECTs)
 SHOULD be stored separately from the ledger with additional access
 controls, since auditors may need to verify hash correctness but
 general access to the data values is not needed.
 
-## Regulatory Access
-
-ECTs are designed for interpretation by qualified human auditors
-and regulators.  ECTs provide structural records of execution
-ordering; they are not intended for public disclosure.
-
 # IANA Considerations
 
 ## Media Type Registration
@@ -1152,8 +912,8 @@ Published specification:
 : This document
 
 Applications that use this media type:
-: Applications that implement regulated agentic workflows requiring
+: Applications that implement agentic workflows requiring execution
-  execution context tracing and audit trails.
+  context tracing and audit trails.
 
 Additional information:
 : Magic number(s): none
@@ -1205,110 +965,18 @@ the "JSON Web Token Claims" registry maintained by IANA:
 | ext | Extension Object | IETF | {{extension-claims}} |
 {: #table-claims title="JWT Claims Registrations"}
 
-Policy evaluation claims and the ECT Policy Decision Values
-registry are defined in
-{{I-D.nennemann-wimse-ect-pol}}.
-
 --- back
 
 # Use Cases {#use-cases}
 {:numbered="false"}
 
-This section describes representative use cases demonstrating how
+This section describes a representative use case demonstrating how
-ECTs provide execution records in regulated environments.  These
+ECTs provide structured execution records.
-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 "jti" values are required to be
 UUIDs per {{exec-claims}}.
 
-## Medical Device SDLC Workflow
-{:numbered="false"}
-
-In a medical device software development lifecycle (SDLC),
-AI agents assist across multiple phases from requirements
-analysis through release approval.  Regulatory frameworks
-including {{FDA-21CFR11}} Section 11.10(e) and {{EU-MDR}} require
-audit trails documenting the complete development process for
-software used in medical devices.
-
-~~~
-Agent A (Spec Reviewer):
-  jti: task-001    par: []
-  exec_act: review_requirements_spec
-
-Agent B (Code Generator):
-  jti: task-002    par: [task-001]
-  exec_act: implement_module
-
-Agent C (Test Agent):
-  jti: task-003    par: [task-002]
-  exec_act: execute_test_suite
-
-Agent D (Build Agent):
-  jti: task-004    par: [task-003]
-  exec_act: build_release_artifact
-
-Human Release Manager:
-  jti: task-005    par: [task-004]
-  exec_act: approve_release
-  ext: {witnessed_by: [...]}  (extension metadata)
-~~~
-{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
-
-ECTs record that requirements were reviewed before implementation
-began, that tests were executed against the implemented code, that
-the build artifact was validated, and that a human release manager
-explicitly approved the release.  The DAG structure ensures no
-phase was skipped or reordered.
-
-### FDA Audit with DAG Reconstruction
-{:numbered="false"}
-
-During a regulatory audit, an FDA reviewer requests evidence of
-the development process for a specific software release.  The
-auditing authority retrieves all ECTs sharing the same workflow
-identifier ("wid") from the audit ledger and reconstructs the
-complete DAG:
-
-~~~
-task-001 (review_requirements_spec)
-  |
-  v
-task-002 (implement_module)
-  |
-  v
-task-003 (execute_test_suite)
-  |
-  v
-task-004 (build_release_artifact)
-  |
-  v
-task-005 (approve_release) [human, witnessed]
-~~~
-{: #fig-fda-audit title="Reconstructed DAG for FDA Audit"}
-
-The reconstructed DAG provides cryptographic evidence that:
-
-- Each phase was executed by an identified and authenticated agent.
-- The execution sequence was maintained (no step was bypassed).
-- A human-in-the-loop approved the final release, with independent
-  witness attestation.
-- Timestamps and execution durations are recorded for each step.
-
-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 for the
-  software development lifecycle.
-- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for
-  high-risk AI systems involved in the development process.
-- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
-  oversight events occurred during the release process.
-
 ## Cross-Organization Financial Trading
 {:numbered="false"}
 
@@ -1365,56 +1033,6 @@ demonstrating cross-organizational fan-in.  The compliance agent
 verifies both parent ECTs — one signed by a local key and one by
 a federated key from the rating agency's trust domain.
 
-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
-{:numbered="false"}
-
-Compensation and rollback use cases are described in
-{{I-D.nennemann-wimse-ect-pol}}.  The core
-ECT mechanism supports compensation through the "par" claim,
-which links a remediation ECT to the original task.
-
-## Autonomous Logistics Coordination
-{:numbered="false"}
-
-In a logistics workflow, multiple compliance checks complete
-before shipment commitment.  The DAG structure records that all
-required checks were completed:
-
-~~~
-Agent A (Route Planning):
-  jti: task-001    par: []
-  exec_act: plan_route
-
-Agent B (Customs):
-  jti: task-002    par: [task-001]
-  exec_act: validate_customs
-
-Agent C (Safety):
-  jti: task-003    par: [task-001]
-  exec_act: verify_cargo_safety
-
-Agent D (Payment):
-  jti: task-004    par: [task-002, task-003]
-  exec_act: authorize_payment
-
-System (Commitment):
-  jti: task-005    par: [task-004]
-  exec_act: commit_shipment
-~~~
-{: #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.
-
 # Related Work
 {:numbered="false"}
 
@@ -1439,7 +1057,8 @@ delegation chain: "who is acting on behalf of whom."  While
 the nesting superficially resembles a chain, it is strictly
 linear (each "act" object contains at most one nested "act"),
 represents authorization delegation rather than task execution,
-and carries no task identifiers or input/output integrity data.  The "act" chain cannot represent
+and carries no task identifiers or input/output integrity
+data.  The "act" chain cannot represent
 branching (fan-out) or convergence (fan-in) and therefore
 cannot form a DAG.
 
@@ -1501,357 +1120,14 @@ 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}}.
-
 ## SCITT (Supply Chain Integrity, Transparency, and Trust)
 {:numbered="false"}
 
 The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
-framework for creating transparent and auditable supply chain
+framework for transparent and auditable supply chain records.
-records through Transparency Services, Signed Statements, and
+ECTs and SCITT are complementary: the ECT "wid" claim can serve
-Receipts.  ECTs and SCITT are naturally complementary: the ECT
+as a correlation identifier in SCITT Signed Statements, linking
-"wid" (Workflow Identifier) claim can serve as a correlation
+an ECT audit trail to a supply chain transparency record.
-identifier referenced in SCITT Signed Statements, linking a
-complete ECT audit trail to a supply chain transparency record.
-For example, in a regulated manufacturing workflow, each agent
-step produces an ECT (recording what was done, by whom, under
-under what constraints), while the overall workflow identified by "wid" is
-registered as a SCITT Signed Statement on a Transparency Service.
-This enables auditors to verify both the individual execution
-steps (via ECT DAG validation) and the end-to-end supply chain
-integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs ({{exec-claims}})
-can carry SCITT-specific metadata such as Transparency Service
-identifiers or Receipt references for tighter integration.
-
-## 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).  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 needs to:
-
-1.  Create JWTs with all required claims ("iss", "aud", "iat",
-    "exp", "jti", "exec_act", "par").
-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.  If an audit ledger is deployed, append verified ECTs to it.
-
-## 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 are expected to use established JWT/JWS libraries
-(JOSE) for token creation and verification.  Custom cryptographic
-implementations are strongly discouraged.  Implementations are
-expected to 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",
-  "aud": "spiffe://example.com/agent/validator",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "550e8400-e29b-41d4-a716-446655440001",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "fetch_patient_data",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Agent B receives the ECT, verifies it, executes a validation
-task, and creates its own ECT:
-
-~~~json
-{
-  "iss": "spiffe://example.com/agent/validator",
-  "aud": "spiffe://example.com/system/ledger",
-  "iat": 1772064160,
-  "exp": 1772064760,
-  "jti": "550e8400-e29b-41d4-a716-446655440002",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "validate_safety",
-  "par": ["550e8400-e29b-41d4-a716-446655440001"]
-}
-~~~
-
-The resulting DAG:
-
-~~~
-task-...-0001 (fetch_patient_data)
-  |
-  v
-task-...-0002 (validate_safety)
-~~~
-
-## Example 2: Medical Device SDLC with Release Approval
-{:numbered="false"}
-
-A multi-step medical device software lifecycle workflow with
-autonomous agents and human release approval:
-
-Task 1 (Spec Review Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/spec-reviewer",
-  "aud": "spiffe://meddev.example/agent/code-gen",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000001",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "review_requirements_spec",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Task 2 (Code Generation Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/code-gen",
-  "aud": "spiffe://meddev.example/agent/test-runner",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000002",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "implement_module",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-}
-~~~
-
-Task 3 (Autonomous Test Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/test-runner",
-  "aud": "spiffe://meddev.example/agent/build",
-  "iat": 1772064260,
-  "exp": 1772064860,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000003",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "execute_test_suite",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-}
-~~~
-
-Task 4 (Build Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/build",
-  "aud": "spiffe://meddev.example/human/release-mgr-42",
-  "iat": 1772064310,
-  "exp": 1772064910,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000004",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "build_release_artifact",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
-  "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
-}
-~~~
-
-Task 5 (Human Release Manager Approval):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/human/release-mgr-42",
-  "aud": "spiffe://meddev.example/system/ledger",
-  "iat": 1772064510,
-  "exp": 1772065110,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000005",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "approve_release",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
-  "ext": {
-    "witnessed_by": [
-      "spiffe://meddev.example/audit/qa-observer-1"
-    ]
-  }
-}
-~~~
-
-The resulting DAG records the complete SDLC: spec review preceded
-implementation, implementation preceded testing, testing preceded
-build, and a human release manager approved the final release.
-The "ext" object in task 5 carries witness metadata via
-the "witnessed_by" extension key.
-
-~~~
-task-...-0001 (review_requirements_spec)
-  |
-  v
-task-...-0002 (implement_module)
-  |
-  v
-task-...-0003 (execute_test_suite)
-  |
-  v
-task-...-0004 (build_release_artifact)
-  |
-  v
-task-...-0005 (approve_release) [human]
-~~~
-
-An FDA auditor reconstructs this DAG by querying the audit ledger
-for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
-verifying each signature.  The DAG provides cryptographic evidence
-that the SDLC followed the prescribed process with human oversight
-at the release gate.
-
-## Example 3: Cross-Organization Fan-In
-{:numbered="false"}
-
-A cross-organization workflow where two independent root tasks
-from different trust domains feed into a compliance verification
-step.  This demonstrates DAG fan-in across organizational
-boundaries.
-
-Task 001 (Bank's risk agent — root task):
-
-~~~json
-{
-  "iss": "spiffe://bank.example/agent/risk",
-  "aud": "spiffe://bank.example/agent/compliance",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "f1e2d3c4-0001-0000-0000-000000000001",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "analyze_portfolio_risk",
-  "par": [],
-  "out_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"
-}
-~~~
-
-Task 002 (External rating agency — root task, different trust
-domain):
-
-~~~json
-{
-  "iss": "spiffe://ratings.example/agent/credit",
-  "aud": "spiffe://bank.example/agent/compliance",
-  "iat": 1772064155,
-  "exp": 1772064755,
-  "jti": "f1e2d3c4-0002-0000-0000-000000000002",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "assess_credit_rating",
-  "par": [],
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Task 003 (Bank's compliance agent — joins both parents):
-
-~~~json
-{
-  "iss": "spiffe://bank.example/agent/compliance",
-  "aud": "spiffe://bank.example/agent/execution",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "f1e2d3c4-0003-0000-0000-000000000003",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "verify_trade_compliance",
-  "par": [
-    "f1e2d3c4-0001-0000-0000-000000000001",
-    "f1e2d3c4-0002-0000-0000-000000000002"
-  ]
-}
-~~~
-
-The "par" array in task 003 references two parents from different
-trust domains: `spiffe://bank.example` and
-`spiffe://ratings.example`.  The compliance agent verifies both
-parent ECTs — one signed by a local key and one by a federated
-key — before proceeding.  This demonstrates how ECTs support
-cross-organizational workflows while maintaining cryptographic
-accountability.
 
 # Acknowledgments
 {:numbered="false"}