9.1. Medical Device SDLC Workflow
-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 "jti" values are required to be -UUIDs per Section 4.2.2.¶
-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)
-
-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.¶
-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] --
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.¶
-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): - jti: task-001 par: [] - exec_act: calculate_risk_exposure - -Agent B (Compliance): - jti: task-002 par: [task-001] - exec_act: verify_compliance - -Agent C (Execution): - jti: task-003 par: [task-002] - exec_act: execute_trade --
This can contribute to compliance with:¶
- -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.¶
-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 --
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.¶
-This section addresses security considerations following the -guidance in [RFC3552].¶
+This section addresses security considerations following the +guidance in [RFC3552].¶
The following threat actors are considered:¶
+The following threat actors are considered:¶
Malicious agent (insider threat): An agent within the trust -domain that intentionally creates false ECT claims.¶
+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.¶
+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.¶
+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.¶
+Time manipulator: An entity attempting to manipulate timestamps +to alter perceived execution ordering.¶
ECTs are self-asserted by the executing agent. The agent claims +
ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims -(e.g., claiming an action was performed when it was not).¶
-ECTs do not independently verify that:¶
+(e.g., claiming an action was performed when it was not).¶ +ECTs do not independently verify that:¶
The claimed execution actually occurred as described¶
+The claimed execution actually occurred as described¶
The input/output hashes correspond to the actual data processed¶
+The input/output hashes correspond to the actual data processed¶
The agent faithfully performed the stated action¶
+The agent faithfully performed the stated action¶
The trustworthiness of ECT claims depends on the trustworthiness +
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" extension key (carried in "ext") to include independent @@ -2977,424 +2745,424 @@ 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 +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.¶
+witness ECTs in the ECT store.¶ECTs operate within a broader trust framework. The guarantees +
ECTs operate within a broader trust framework. The guarantees provided by ECTs are only meaningful when the following -organizational controls are in place:¶
+organizational controls are in place:¶Key management governance: Controls over who provisions agent -keys and how keys are protected.¶
+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.¶
+Ledger integrity governance: The ledger is maintained by an +entity independent of the workflow agents.¶
Agent deployment governance: Agents are deployed and maintained -in a manner that preserves their integrity.¶
+Agent deployment governance: Agents are deployed and maintained +in a manner that preserves their integrity.¶
ECTs MUST be signed with the agent's private key using JWS +
ECTs MUST be signed with the agent's private key using JWS [RFC7515]. The signature algorithm MUST match the algorithm specified in the agent's WIT. Receivers MUST verify the ECT signature against the WIT public key before processing any claims. Receivers MUST verify that the signing key has not been revoked within the trust domain (see step 6 in -Section 7).¶
-If signature verification fails or if the signing key has been +Section 7).¶
+If signature verification fails or if the signing key has been revoked, the ECT MUST be rejected entirely and the failure MUST -be logged.¶
-Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification.¶
+be logged.¶ +Implementations MUST use established JWS libraries and MUST NOT +implement custom signature verification.¶
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to +
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 +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 MUST maintain a cache of recently-seen "jti" +with the same action can be flagged as a potential replay.¶
+Implementations MUST maintain a cache of recently-seen "jti" values to detect replayed ECTs within the expiration window. -An ECT with a duplicate "jti" value MUST be rejected.¶
+An ECT with a duplicate "jti" value MUST be rejected.¶ECTs do not replace transport-layer security. ECTs MUST be +
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:¶
+[RFC9421] provide an alternative channel binding mechanism.¶ +The defense-in-depth model provides:¶
TLS/mTLS (transport layer): Prevents network-level tampering.¶
+TLS/mTLS (transport layer): Prevents network-level tampering.¶
WIT/WPT (WIMSE identity layer): Proves agent identity and -request authorization.¶
+WIT/WPT (WIMSE identity layer): Proves agent identity and +request authorization.¶
ECT (execution accountability layer): Records what the agent did.¶
+ECT (execution accountability layer): Records what the agent did.¶
If an agent's private key is compromised, an attacker can forge +
If an agent's private key is compromised, an attacker can forge ECTs that appear to originate from that agent. To mitigate this -risk:¶
+risk:¶Implementations SHOULD use short-lived keys and rotate them -frequently (hours to days, not months).¶
+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.¶
+Private keys SHOULD be stored in Hardware Security Modules (HSMs) +or equivalent secure key storage.¶
Trust domains MUST support rapid key revocation.¶
+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.¶
+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 +
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.¶
+for audit purposes.¶A single malicious agent cannot forge parent task references +
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:¶
+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.¶
+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.¶
+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.¶
+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.¶
+Out-of-band audit: External auditors periodically verify ledger +contents against expected workflow patterns.¶
ECT signature verification is computationally inexpensive +
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 +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.¶
+on unsigned or incorrectly signed tokens.¶ECTs rely on timestamps ("iat", "exp") for temporal ordering. +
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).¶
-Cross-organizational deployments where agents span multiple trust +(RECOMMENDED: 30 seconds).¶
+Cross-organizational deployments where agents span multiple trust domains with independent time sources MAY require a higher clock skew tolerance. Deployments using trust domain federation SHOULD document their configured clock skew tolerance value and SHOULD -ensure all participating trust domains agree on a common tolerance.¶
-The temporal ordering check in DAG validation incorporates the +ensure all participating trust domains agree on a common tolerance.¶
+The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences -between agents.¶
+between agents.¶ECTs with many parent tasks or large extension objects can +
ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of -5 levels (see also Section 4.2.5).¶
+5 levels (see also Section 4.2.5).¶ECTs necessarily reveal:¶
+ECTs necessarily reveal:¶
Agent identities ("iss", "aud") for accountability purposes¶
+Agent identities ("iss", "aud") for accountability purposes¶
Action descriptions ("exec_act") for audit trail completeness¶
+Action descriptions ("exec_act") for audit trail completeness¶
Timestamps ("iat", "exp") for temporal ordering¶
+Timestamps ("iat", "exp") for temporal ordering¶
ECTs are designed to NOT reveal:¶
+ECTs are designed to NOT reveal:¶
Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash")¶
+Actual input or output data values (replaced with cryptographic +hashes via "inp_hash" and "out_hash")¶
Internal computation details or intermediate steps¶
+Internal computation details or intermediate steps¶
Proprietary algorithms or intellectual property¶
+Proprietary algorithms or intellectual property¶
Personally identifiable information (PII)¶
+Personally identifiable information (PII)¶
Implementations SHOULD minimize the information included in ECTs. +
Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. Extension keys in "ext" (Section 4.2.5) deserve particular attention: human-readable values risk exposing sensitive operational details. See Section 4.2.5 for guidance on using -structured identifiers.¶
+structured identifiers.¶ECTs stored in audit ledgers SHOULD be access-controlled so that +
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) +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.¶
+general access to the data values is not needed.¶ECTs are designed for interpretation by qualified human auditors +
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.¶
+ordering; they are not intended for public disclosure.¶This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:¶
-application¶
+This document requests registration of the following media type +in the "Media Types" registry maintained by IANA:¶
+application¶
wimse-exec+jwt¶
+wimse-exec+jwt¶
none¶
+none¶
none¶
+none¶
8bit; an ECT is a JWT that is a JWS using the Compact +
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.¶
+separated by period characters.¶See the Security Considerations section of this document.¶
+See the Security Considerations section of this document.¶
none¶
+none¶
This document¶
+This document¶
Applications that implement regulated agentic workflows requiring -execution context tracing and audit trails.¶
+Applications that implement regulated agentic workflows requiring +execution context tracing and audit trails.¶
Magic number(s): none +
Magic number(s): none File extension(s): none -Macintosh file type code(s): none¶
+Macintosh file type code(s): none¶Christian Nennemann, ietf@nennemann.de¶
+Christian Nennemann, ietf@nennemann.de¶
COMMON¶
+COMMON¶
none¶
+none¶
Christian Nennemann¶
+Christian Nennemann¶
IETF¶
+IETF¶
This document requests registration of the following header field +
This document requests registration of the following header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA:¶
-This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA:¶
+This document requests registration of the following claims in +the "JSON Web Token Claims" registry maintained by IANA:¶