diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index bd8094a..5403dbb 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -1397,13 +1397,10 @@ regulatory frameworks.

4.2.4.  Data Integrity

  • -

    4.2.5.  Task Metadata

    +

    4.2.5.  Compensation and Rollback

  • -

    4.2.6.  Compensation and Rollback

    -
    • -
  • -

    4.2.7.  Extensions

    +

    4.2.6.  Extensions

    • @@ -1544,9 +1541,6 @@ regulatory frameworks.

  • 12.4.  ECT Policy Decision Values Registry

    -
    • -
  • -

    12.5.  ECT Regulated Domain Values Registry

    • @@ -1656,7 +1650,7 @@ requirements were evaluated at each decision point.[EU-AI-ACT], [FDA-21CFR11], [MIFID-II], and [DORA] — require structured, auditable records of automated -decision-making and execution (see Table 4 for a +decision-making and execution (see Table 3 for a detailed mapping).

    This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution @@ -2241,13 +2235,6 @@ audit trails.

    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.

    @@ -2288,110 +2275,58 @@ computed over the raw octets of the input data.

    OPTIONAL. String. A cryptographic hash of the output data, using the same format and algorithm requirements as "inp_hash".

    - -
    -
    inp_classification:
    -
    -

    OPTIONAL. String. The data sensitivity classification of the -input (e.g., "public", "confidential", "restricted").

    -
    -
    - - - -
    -
    -

    -4.2.5. Task Metadata -

    -

    The following claims provide additional context about task -execution:

    -
    -
    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 MUST be registered in the ECT Regulated Domain -Values registry (Section 12.5).

    -
    -
    -
    model_version:
    -
    -

    OPTIONAL. String. The version identifier of the AI or ML model -used to perform the task, if applicable.

    -
    -
    -
    witnessed_by:
    -
    -

    OPTIONAL. Array of StringOrURI. Identifiers of third-party -entities that the issuing agent claims observed or attested to -the execution of this task. When present, each element SHOULD -use SPIFFE ID format. Note that this claim is self-asserted by -the ECT issuer; witnesses listed here do not co-sign this ECT. -For stronger assurance, witnesses SHOULD submit independent -signed ECTs to the ledger attesting to their observation (see -Section 10.2.1). In regulated environments, -implementations SHOULD use witness attestation for critical -decision points to mitigate the risk of single-agent false -claims. See also Section 10.2 for the security -implications of self-asserted witness claims.

    -
    +

    -4.2.6. Compensation and Rollback +4.2.5. Compensation and Rollback

    -
    -
    compensation_required:
    -
    -

    OPTIONAL. Boolean. Indicates whether this task is a -compensation or rollback action for a previous task.

    +
    +
    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 +

    compensation_reason:
    +
    +

    OPTIONAL. String. A human-readable reason for the compensation action. MUST be present if "compensation_required" is true. Values SHOULD use structured identifiers (e.g., "policy_violation_in_parent_trade") rather than free-form text to minimize the risk of embedding sensitive information. See Section 11.2 for privacy guidance. If "compensation_reason" is present, "compensation_required" -MUST be true.

    +MUST be true.

    -

    Note: compensation ECTs reference historical parent tasks via the +

    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.

    +ledger.

    -
    +

    -4.2.7. Extensions +4.2.6. Extensions

    -
    -
    ext:
    -
    -

    OPTIONAL. Object. An extension object for domain-specific +

    +
    ext:
    +
    +

    OPTIONAL. Object. An extension object for domain-specific claims not defined by this specification. Implementations -that do not understand extension claims MUST ignore them.

    +that do not understand extension claims MUST ignore them.

    -

    To avoid key collisions between different domains, extension +

    To avoid key collisions between different domains, extension key names MUST use reverse domain notation (e.g., "com.example.custom_field"). Implementations MUST NOT use unqualified key names within the "ext" object. To prevent @@ -2399,7 +2334,37 @@ abuse and excessive token size, the serialized JSON representation of the "ext" object SHOULD NOT exceed 4096 bytes, and the JSON nesting depth within the "ext" object SHOULD NOT exceed 5 levels. Implementations SHOULD reject -ECTs whose "ext" claim exceeds these limits.

    +ECTs whose "ext" claim exceeds these limits.

    +

    The following extension keys are RECOMMENDED for common use +cases. These are not registered claims; they are carried +within the "ext" object:

    +
      +
    • +

      "org.ietf.wimse.exec_time_ms": Integer. Execution duration in +milliseconds.

      +
      • +
    • +

      "org.ietf.wimse.regulated_domain": String. Regulatory domain +(e.g., "medtech", "finance", "military").

      +
      • +
    • +

      "org.ietf.wimse.model_version": String. AI/ML model version.

      +
      • +
    • +

      "org.ietf.wimse.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.

      +
      • +
    • +

      "org.ietf.wimse.inp_classification": String. Data sensitivity +classification (e.g., "public", "confidential", "restricted").

      +
      • +
    • +

      "org.ietf.wimse.pol_timestamp": NumericDate. Time at which the +policy decision was made, if distinct from "iat".

      +
      • +
    @@ -2429,18 +2394,16 @@ ECTs whose "ext" claim exceeds these limits. @@ -2918,7 +2881,7 @@ Human Release Manager: exec_act: approve_release pol: release_approval_policy pol_decision: approved pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - witnessed_by: [spiffe://meddev.example/audit/qa-observer-1] + ext: {org.ietf.wimse.witnessed_by: [...]} (extension metadata)
    Figure 8: @@ -3202,22 +3165,23 @@ evaluating the policy).

    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. However, the "witnessed_by" claim 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.

    +regulated environments SHOULD use the "org.ietf.wimse.witnessed_by" +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.

    10.2.1. Witness Attestation Model

    -

    To address the self-assertion limitation of the "witnessed_by" -claim, witnesses SHOULD submit their own independent signed ECTs -to the audit ledger attesting to the observed task. A witness -attestation ECT:

    +

    To address the self-assertion limitation of the +"org.ietf.wimse.witnessed_by" extension, witnesses SHOULD submit their +own independent signed ECTs to the audit ledger attesting to the +observed task. A witness attestation ECT:

    • MUST set "iss" to the witness's own workload identity.

      @@ -3235,11 +3199,11 @@ linking the attestation to the original task.

    -

    When a task's "witnessed_by" claim lists one or more witnesses, -auditors SHOULD verify that corresponding witness attestation -ECTs exist in the ledger for each listed witness. A mismatch -between the "witnessed_by" list and the set of independent witness -ECTs in the ledger SHOULD be flagged during audit review.

    +

    When a task's "org.ietf.wimse.witnessed_by" extension lists one or more +witnesses, auditors SHOULD verify that corresponding witness +attestation ECTs exist in the ledger for each listed witness. A +mismatch between the extension value and the set of independent +witness ECTs in the ledger SHOULD be flagged during audit review.

    This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the witness independently signs their own ECT using their own key, @@ -3387,8 +3351,8 @@ create a false execution history if they control the ledger.

  • -

    Witness attestation: Using the "witnessed_by" claim to include -independent third-party observers.

    +

    Witness attestation: Using the "org.ietf.wimse.witnessed_by" extension +key in "ext" to include independent third-party observers.

  • Cross-verification: Multiple independent ledger replicas can be @@ -3448,7 +3412,7 @@ 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.7).

    +5 levels (see also Section 4.2.6).

    • @@ -3507,7 +3471,7 @@ The "exec_act" claim SHOULD use structured identifier "process_payment") rather than natural language descriptions. The "pol" claim SHOULD reference policy identifiers rather than embedding policy content.

    -

    The "compensation_reason" claim (Section 4.2.6) +

    The "compensation_reason" claim (Section 4.2.5) deserves particular attention: because it is human-readable and may describe the circumstances of a failure or policy violation, it risks exposing sensitive operational details. Implementations @@ -3737,14 +3701,6 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF Section 4.2.3 - - - - pol_timestamp - Policy Decision Timestamp - IETF - - Section 4.2.3 @@ -3761,46 +3717,6 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF Section 4.2.4 - - - - inp_classification - Input Data Classification - IETF - - Section 4.2.4 - - - - exec_time_ms - Execution Time (ms) - IETF - - Section 4.2.5 - - - - witnessed_by - Witness Identities - IETF - - Section 4.2.5 - - - - regulated_domain - Regulatory Domain - IETF - - Section 4.2.5 - - - - model_version - AI/ML Model Version - IETF - - Section 4.2.5 @@ -3808,7 +3724,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Compensation Flag IETF - Section 4.2.6 + Section 4.2.5 @@ -3816,7 +3732,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Compensation Reason IETF - Section 4.2.6 + Section 4.2.5 @@ -3824,7 +3740,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Extension Object IETF - Section 4.2.7 + Section 4.2.6 @@ -3885,59 +3801,6 @@ policy is Specification Required per [ -

    -
    -

    -12.5. ECT Regulated Domain Values Registry -

    -

    This document establishes the "ECT Regulated Domain Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per [RFC8126].

    -

    The initial contents of the registry are:

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -Table 3: -ECT Regulated Domain Values -
    ValueDescriptionChange ControllerReference
    medtechMedical technology and devicesIETF - Section 4.2.5 -
    financeFinancial services and tradingIETF - Section 4.2.5 -
    militaryMilitary and defenseIETF - Section 4.2.5 -
    -
    -
    -
    @@ -4328,9 +4191,9 @@ compliance with various regulatory frameworks. ECTs are a technical building block; achieving compliance requires additional organizational measures beyond this specification.

    - +
    @@ -4414,9 +4277,7 @@ Agent B:

    "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" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } @@ -4435,9 +4296,7 @@ task, and creates its own ECT: @@ -4474,8 +4333,6 @@ autonomous agents and human release approval: @@ -4515,9 +4370,7 @@ autonomous agents and human release approval: @@ -4536,7 +4389,6 @@ autonomous agents and human release approval: @@ -4557,17 +4409,19 @@ autonomous agents and human release approval:

    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 -with independent witness attestation.

    +build, and a human release manager approved the final release. +The "ext" object in task 5 carries witness metadata via +the "org.ietf.wimse.witnessed_by" extension key.

     task-...-0001 (review_requirements_spec)
@@ -4582,7 +4436,7 @@ task-...-0003 (execute_test_suite)
 task-...-0004 (build_release_artifact)
   |
   v
-task-...-0005 (approve_release) [human, witnessed]
+task-...-0005 (approve_release) [human]

    An FDA auditor reconstructs this DAG by querying the audit ledger @@ -4629,8 +4483,7 @@ task-...-0004 (execute_trade) "f1e2d3c4-0003-0000-0000-000000000003" ], "pol": "trade_execution_policy_v3", - "pol_decision": "approved", - "regulated_domain": "finance" + "pol_decision": "approved" } diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md index ccaa072..01b9411 100644 --- a/draft-nennemann-wimse-execution-context-00.md +++ b/draft-nennemann-wimse-execution-context-00.md @@ -529,11 +529,6 @@ pol_enforcer: 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. - This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, distributed to agents, and evaluated are out of scope. @@ -565,42 +560,6 @@ out_hash: : OPTIONAL. String. A cryptographic hash of the output data, using the same format and algorithm requirements as "inp_hash". -inp_classification: -: OPTIONAL. String. The data sensitivity classification of the - input (e.g., "public", "confidential", "restricted"). - -### Task Metadata {#operational-claims} - -The following claims provide additional context about task -execution: - -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 MUST be registered in the ECT Regulated Domain - Values registry ({{regulated-domain-registry}}). - -model_version: -: OPTIONAL. String. The version identifier of the AI or ML model - used to perform the task, if applicable. - -witnessed_by: -: OPTIONAL. Array of StringOrURI. Identifiers of third-party - entities that the issuing agent claims observed or attested to - the execution of this task. When present, each element SHOULD - use SPIFFE ID format. Note that this claim is self-asserted by - the ECT issuer; witnesses listed here do not co-sign this ECT. - For stronger assurance, witnesses SHOULD submit independent - signed ECTs to the ledger attesting to their observation (see - {{witness-attestation-model}}). In regulated environments, - implementations SHOULD use witness attestation for critical - decision points to mitigate the risk of single-agent false - claims. See also {{self-assertion-limitation}} for the security - implications of self-asserted witness claims. - ### Compensation and Rollback {#compensation-claims} compensation_required: @@ -640,6 +599,24 @@ bytes, and the JSON 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 RECOMMENDED for common use +cases. These are not registered claims; they are carried +within the "ext" object: + +- "org.ietf.wimse.exec\_time\_ms": Integer. Execution duration in + milliseconds. +- "org.ietf.wimse.regulated\_domain": String. Regulatory domain + (e.g., "medtech", "finance", "military"). +- "org.ietf.wimse.model\_version": String. AI/ML model version. +- "org.ietf.wimse.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. +- "org.ietf.wimse.inp\_classification": String. Data sensitivity + classification (e.g., "public", "confidential", "restricted"). +- "org.ietf.wimse.pol\_timestamp": NumericDate. Time at which the + policy decision was made, if distinct from "iat". + ## Complete ECT Example The following is a complete ECT payload example: @@ -660,18 +637,16 @@ The following is a complete ECT payload example: "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" - ] + "ext": { + "org.ietf.wimse.pol_timestamp": 1772064145, + "org.ietf.wimse.exec_time_ms": 245, + "org.ietf.wimse.regulated_domain": "medtech", + "org.ietf.wimse.model_version": "clinical-reasoning-v4.2" + } } ~~~ {: #fig-full-ect title="Complete ECT Payload Example"} @@ -1054,7 +1029,7 @@ Human Release Manager: exec_act: approve_release pol: release_approval_policy pol_decision: approved pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - witnessed_by: [spiffe://meddev.example/audit/qa-observer-1] + ext: {org.ietf.wimse.witnessed_by: [...]} (extension metadata) ~~~ {: #fig-medtech-sdlc title="Medical Device SDLC Workflow"} @@ -1245,20 +1220,21 @@ ECTs do not independently verify that: 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. However, the "witnessed_by" claim 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. +regulated environments SHOULD use the "org.ietf.wimse.witnessed_by" +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. ### Witness Attestation Model {#witness-attestation-model} -To address the self-assertion limitation of the "witnessed_by" -claim, witnesses SHOULD submit their own independent signed ECTs -to the audit ledger attesting to the observed task. A witness -attestation ECT: +To address the self-assertion limitation of the +"org.ietf.wimse.witnessed_by" extension, witnesses SHOULD submit their +own independent signed ECTs to the audit ledger attesting to the +observed task. A witness attestation ECT: - MUST set "iss" to the witness's own workload identity. - MUST set "exec_act" to "witness_attestation" (or a domain- @@ -1268,11 +1244,11 @@ attestation ECT: - MUST set "pol_decision" to "approved" to indicate the witness confirms the observation. -When a task's "witnessed_by" claim lists one or more witnesses, -auditors SHOULD verify that corresponding witness attestation -ECTs exist in the ledger for each listed witness. A mismatch -between the "witnessed_by" list and the set of independent witness -ECTs in the ledger SHOULD be flagged during audit review. +When a task's "org.ietf.wimse.witnessed_by" extension lists one or more +witnesses, auditors SHOULD verify that corresponding witness +attestation ECTs exist in the ledger for each listed witness. A +mismatch between the extension value and the set of independent +witness ECTs in the ledger SHOULD be flagged during audit review. This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the @@ -1374,8 +1350,8 @@ 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. +- Witness attestation: Using the "org.ietf.wimse.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 @@ -1564,14 +1540,8 @@ the "JSON Web Token Claims" registry maintained by IANA: | 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 | {{operational-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}} | | ext | Extension Object | IETF | {{extension-claims}} | @@ -1592,21 +1562,6 @@ The initial contents of the registry are: | pending_human_review | Awaiting human judgment | IETF | {{policy-claims}} | {: #table-pol-decision title="ECT Policy Decision Values"} -## ECT Regulated Domain Values Registry {#regulated-domain-registry} - -This document establishes the "ECT Regulated Domain Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per {{!RFC8126}}. - -The initial contents of the registry are: - -| Value | Description | Change Controller | Reference | -|:---:|:---|:---:|:---:| -| medtech | Medical technology and devices | IETF | {{operational-claims}} | -| finance | Financial services and trading | IETF | {{operational-claims}} | -| military | Military and defense | IETF | {{operational-claims}} | -{: #table-regulated-domain title="ECT Regulated Domain Values"} - --- back # Related Work @@ -1840,9 +1795,7 @@ ECT Payload: "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" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } ~~~ @@ -1861,9 +1814,7 @@ task, and creates its own ECT: "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" + "pol_decision": "approved" } ~~~ @@ -1897,8 +1848,6 @@ Task 1 (Spec Review Agent): "par": [], "pol": "spec_review_policy_v2", "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "spec-review-v3.1", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } @@ -1918,9 +1867,7 @@ Task 2 (Code Generation Agent): "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], "pol": "coding_standards_v3", - "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "codegen-v2.4" + "pol_decision": "approved" } ~~~ @@ -1938,9 +1885,7 @@ Task 3 (Autonomous Test Agent): "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], "pol": "test_coverage_policy_v1", - "pol_decision": "approved", - "regulated_domain": "medtech", - "exec_time_ms": 4523 + "pol_decision": "approved" } ~~~ @@ -1959,7 +1904,6 @@ Task 4 (Build Agent): "par": ["a1b2c3d4-0001-0000-0000-000000000003"], "pol": "build_validation_v2", "pol_decision": "approved", - "regulated_domain": "medtech", "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" } ~~~ @@ -1980,17 +1924,19 @@ Task 5 (Human Release Manager Approval): "pol": "release_approval_policy", "pol_decision": "approved", "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", - "witnessed_by": [ - "spiffe://meddev.example/audit/qa-observer-1" - ], - "regulated_domain": "medtech" + "ext": { + "org.ietf.wimse.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 -with independent witness attestation. +build, and a human release manager approved the final release. +The "ext" object in task 5 carries witness metadata via +the "org.ietf.wimse.witnessed_by" extension key. ~~~ task-...-0001 (review_requirements_spec) @@ -2005,7 +1951,7 @@ task-...-0003 (execute_test_suite) task-...-0004 (build_release_artifact) | v -task-...-0005 (approve_release) [human, witnessed] +task-...-0005 (approve_release) [human] ~~~ An FDA auditor reconstructs this DAG by querying the audit ledger @@ -2049,8 +1995,7 @@ Task 004 ECT payload: "f1e2d3c4-0003-0000-0000-000000000003" ], "pol": "trade_execution_policy_v3", - "pol_decision": "approved", - "regulated_domain": "finance" + "pol_decision": "approved" } ~~~ diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt index 8f62e1b..b4bd3bd 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/draft-nennemann-wimse-execution-context-00.txt @@ -91,9 +91,8 @@ Table of Contents 4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 11 4.2.3. Policy Evaluation . . . . . . . . . . . . . . . . . . 12 4.2.4. Data Integrity . . . . . . . . . . . . . . . . . . . 13 - 4.2.5. Task Metadata . . . . . . . . . . . . . . . . . . . . 13 - 4.2.6. Compensation and Rollback . . . . . . . . . . . . . . 14 - 4.2.7. Extensions . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.5. Compensation and Rollback . . . . . . . . . . . . . . 13 + 4.2.6. Extensions . . . . . . . . . . . . . . . . . . . . . 13 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15 @@ -106,6 +105,7 @@ Table of Contents 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 22 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23 @@ -114,7 +114,6 @@ Nennemann Expires 28 August 2026 [Page 2] Internet-Draft WIMSE Execution Context February 2026 - 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 24 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 25 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 25 @@ -142,26 +141,27 @@ Internet-Draft WIMSE Execution Context February 2026 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 34 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 35 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 36 - 12.5. ECT Regulated Domain Values Registry . . . . . . . . . . 36 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 13.2. Informative References . . . . . . . . . . . . . . . . . 38 - Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 40 - WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 40 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 13.2. Informative References . . . . . . . . . . . . . . . . . 37 + Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 39 OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 40 - Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 41 + Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 40 Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 41 - Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 42 - SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 42 + Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 41 + SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 41 W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 42 Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 42 Minimal Implementation . . . . . . . . . . . . . . . . . . . . 42 - Storage Recommendations . . . . . . . . . . . . . . . . . . . . 43 - Performance Considerations . . . . . . . . . . . . . . . . . . 43 + Storage Recommendations . . . . . . . . . . . . . . . . . . . . 42 + Performance Considerations . . . . . . . . . . . . . . . . . . 42 Interoperability . . . . . . . . . . . . . . . . . . . . . . . 43 - Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 44 + Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 44 + Example 2: Medical Device SDLC with Release Approval . . . . . 45 + Example 3: Parallel Execution with Join . . . . . . . . . . . . 48 @@ -170,8 +170,6 @@ Nennemann Expires 28 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 - Example 2: Medical Device SDLC with Release Approval . . . . . 46 - Example 3: Parallel Execution with Join . . . . . . . . . . . . 48 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 @@ -195,7 +193,7 @@ Internet-Draft WIMSE Execution Context February 2026 coordinate across organizational boundaries. Multiple regulatory frameworks — including [EU-AI-ACT], [FDA-21CFR11], [MIFID-II], and [DORA] — require structured, auditable records of automated decision- - making and execution (see Table 4 for a detailed mapping). + making and execution (see Table 3 for a detailed mapping). This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution @@ -218,6 +216,8 @@ Internet-Draft WIMSE Execution Context February 2026 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. @@ -226,9 +226,6 @@ Nennemann Expires 28 August 2026 [Page 4] Internet-Draft WIMSE Execution Context February 2026 - 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 @@ -274,6 +271,9 @@ Internet-Draft WIMSE Execution Context February 2026 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 @@ -282,9 +282,6 @@ Nennemann Expires 28 August 2026 [Page 5] Internet-Draft WIMSE Execution Context February 2026 - 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 @@ -330,6 +327,9 @@ Internet-Draft WIMSE Execution Context February 2026 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. + @@ -338,9 +338,6 @@ Nennemann Expires 28 August 2026 [Page 6] Internet-Draft WIMSE Execution Context February 2026 - Witness: A third-party entity that observes and attests to the - execution of a task, providing additional accountability. - 3. WIMSE Architecture Integration 3.1. WIMSE Foundation @@ -389,6 +386,9 @@ Internet-Draft WIMSE Execution Context February 2026 + + + Nennemann Expires 28 August 2026 [Page 7] Internet-Draft WIMSE Execution Context February 2026 @@ -657,15 +657,15 @@ Internet-Draft WIMSE Execution Context February 2026 (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. - This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, distributed to agents, and evaluated are out of scope. The "pol" claim is an opaque identifier referencing an external policy; the semantics and enforcement of that policy are determined by the + deployment environment. Implementations may use any policy engine or + framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) + provided that the evaluation outcome is faithfully recorded in the + ECT claims defined above. @@ -674,11 +674,6 @@ Nennemann Expires 28 August 2026 [Page 12] Internet-Draft WIMSE Execution Context February 2026 - deployment environment. Implementations may use any policy engine or - framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) - provided that the evaluation outcome is faithfully recorded in the - ECT claims defined above. - 4.2.4. Data Integrity The following claims provide integrity verification for task inputs @@ -699,46 +694,7 @@ Internet-Draft WIMSE Execution Context February 2026 data, using the same format and algorithm requirements as "inp_hash". - inp_classification: OPTIONAL. String. The data sensitivity - classification of the input (e.g., "public", "confidential", - "restricted"). - -4.2.5. Task Metadata - - The following claims provide additional context about task execution: - - 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 MUST be registered in the ECT - Regulated Domain Values registry (Section 12.5). - - model_version: OPTIONAL. String. The version identifier of the AI - or ML model used to perform the task, if applicable. - - witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of - third-party entities that the issuing agent claims observed or - attested to the execution of this task. When present, each - element SHOULD use SPIFFE ID format. Note that this claim is - self-asserted by the ECT issuer; witnesses listed here do not co- - - - -Nennemann Expires 28 August 2026 [Page 13] - -Internet-Draft WIMSE Execution Context February 2026 - - - sign this ECT. For stronger assurance, witnesses SHOULD submit - independent signed ECTs to the ledger attesting to their - observation (see Section 10.2.1). In regulated environments, - implementations SHOULD use witness attestation for critical - decision points to mitigate the risk of single-agent false claims. - See also Section 10.2 for the security implications of self- - asserted witness claims. - -4.2.6. Compensation and Rollback +4.2.5. Compensation and Rollback compensation_required: OPTIONAL. Boolean. Indicates whether this task is a compensation or rollback action for a previous task. @@ -757,7 +713,7 @@ Internet-Draft WIMSE Execution Context February 2026 "exp" time; ECT expiration applies to the verification window of the ECT itself, not to its validity as a parent reference in the ledger. -4.2.7. Extensions +4.2.6. Extensions ext: OPTIONAL. Object. An extension object for domain-specific claims not defined by this specification. Implementations that do @@ -766,12 +722,43 @@ Internet-Draft WIMSE Execution Context February 2026 To avoid key collisions between different domains, extension key names MUST use reverse domain notation (e.g., "com.example.custom_field"). Implementations MUST NOT use + + + +Nennemann Expires 28 August 2026 [Page 13] + +Internet-Draft WIMSE Execution Context February 2026 + + unqualified key names within the "ext" object. To prevent abuse and excessive token size, the serialized JSON representation of the "ext" object SHOULD NOT exceed 4096 bytes, and the JSON 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 RECOMMENDED for common use cases. + These are not registered claims; they are carried within the "ext" + object: + + * "org.ietf.wimse.exec_time_ms": Integer. Execution duration in + milliseconds. + + * "org.ietf.wimse.regulated_domain": String. Regulatory domain + (e.g., "medtech", "finance", "military"). + + * "org.ietf.wimse.model_version": String. AI/ML model version. + + * "org.ietf.wimse.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. + + * "org.ietf.wimse.inp_classification": String. Data sensitivity + classification (e.g., "public", "confidential", "restricted"). + + * "org.ietf.wimse.pol_timestamp": NumericDate. Time at which the + policy decision was made, if distinct from "iat". + 4.3. Complete ECT Example The following is a complete ECT payload example: @@ -781,6 +768,19 @@ Internet-Draft WIMSE Execution Context February 2026 + + + + + + + + + + + + + Nennemann Expires 28 August 2026 [Page 14] Internet-Draft WIMSE Execution Context February 2026 @@ -801,18 +801,16 @@ Internet-Draft WIMSE Execution Context February 2026 "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" - ] + "ext": { + "org.ietf.wimse.pol_timestamp": 1772064145, + "org.ietf.wimse.exec_time_ms": 245, + "org.ietf.wimse.regulated_domain": "medtech", + "org.ietf.wimse.model_version": "clinical-reasoning-v4.2" + } } Figure 4: Complete ECT Payload Example @@ -831,8 +829,10 @@ Internet-Draft WIMSE Execution Context February 2026 An agent sending a request to another agent includes the Execution- Context header alongside the WIMSE Workload-Identity header: - - + GET /api/safety-check HTTP/1.1 + Host: safety-agent.example.com + Workload-Identity: eyJhbGci...WIT... + Execution-Context: eyJhbGci...ECT... @@ -842,11 +842,6 @@ Nennemann Expires 28 August 2026 [Page 15] Internet-Draft WIMSE Execution Context February 2026 - GET /api/safety-check HTTP/1.1 - Host: safety-agent.example.com - Workload-Identity: eyJhbGci...WIT... - Execution-Context: eyJhbGci...ECT... - Figure 5: HTTP Request with ECT Header When multiple parent tasks contribute context to a single request, @@ -889,7 +884,12 @@ Internet-Draft WIMSE Execution Context February 2026 verified parent ECT). If any parent task is not found, the ECT MUST be rejected. - + 3. Temporal Ordering: The "iat" value of every parent task MUST NOT + be greater than the "iat" value of the current task plus a + configurable clock skew tolerance (RECOMMENDED: 30 seconds). + That is, for each parent: parent.iat < child.iat + + clock_skew_tolerance. The tolerance accounts for clock skew + between agents; it does not guarantee strict causal ordering from @@ -898,12 +898,6 @@ Nennemann Expires 28 August 2026 [Page 16] Internet-Draft WIMSE Execution Context February 2026 - 3. Temporal Ordering: The "iat" value of every parent task MUST NOT - be greater than the "iat" value of the current task plus a - configurable clock skew tolerance (RECOMMENDED: 30 seconds). - That is, for each parent: parent.iat < child.iat + - clock_skew_tolerance. The tolerance accounts for clock skew - between agents; it does not guarantee strict causal ordering from timestamps alone. Causal ordering is primarily enforced by the DAG structure (parent existence in the ECT store), not by timestamps. If any parent task violates this constraint, the ECT @@ -943,6 +937,12 @@ Internet-Draft WIMSE Execution Context February 2026 + + + + + + @@ -1271,7 +1271,7 @@ Internet-Draft WIMSE Execution Context February 2026 exec_act: approve_release pol: release_approval_policy pol_decision: approved pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - witnessed_by: [spiffe://meddev.example/audit/qa-observer-1] + ext: {org.ietf.wimse.witnessed_by: [...]} (extension metadata) Figure 8: Medical Device SDLC Workflow @@ -1536,20 +1536,20 @@ Internet-Draft WIMSE Execution Context February 2026 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. - However, the "witnessed_by" claim 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 + environments SHOULD use the "org.ietf.wimse.witnessed_by" 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. 10.2.1. Witness Attestation Model - To address the self-assertion limitation of the "witnessed_by" claim, - witnesses SHOULD submit their own independent signed ECTs to the - audit ledger attesting to the observed task. A witness attestation - ECT: + To address the self-assertion limitation of the + "org.ietf.wimse.witnessed_by" extension, witnesses SHOULD submit + their own independent signed ECTs to the audit ledger attesting to + the observed task. A witness attestation ECT: * MUST set "iss" to the witness's own workload identity. @@ -1570,11 +1570,11 @@ Nennemann Expires 28 August 2026 [Page 28] Internet-Draft WIMSE Execution Context February 2026 - When a task's "witnessed_by" claim lists one or more witnesses, - auditors SHOULD verify that corresponding witness attestation ECTs - exist in the ledger for each listed witness. A mismatch between the - "witnessed_by" list and the set of independent witness ECTs in the - ledger SHOULD be flagged during audit review. + When a task's "org.ietf.wimse.witnessed_by" extension lists one or + more witnesses, auditors SHOULD verify that corresponding witness + attestation ECTs exist in the ledger for each listed witness. A + mismatch between the extension value and the set of independent + witness ECTs in the ledger SHOULD be flagged during audit review. This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the witness @@ -1702,8 +1702,9 @@ Internet-Draft WIMSE Execution Context February 2026 * 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. + * Witness attestation: Using the "org.ietf.wimse.witnessed_by" + extension key in "ext" to include independent third-party + observers. * Cross-verification: Multiple independent ledger replicas can be compared for consistency. @@ -1732,7 +1733,6 @@ Internet-Draft WIMSE Execution Context February 2026 - Nennemann Expires 28 August 2026 [Page 31] Internet-Draft WIMSE Execution Context February 2026 @@ -1762,7 +1762,7 @@ Internet-Draft WIMSE Execution Context February 2026 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.7). + exceed a nesting depth of 5 levels (see also Section 4.2.6). 11. Privacy Considerations @@ -1806,7 +1806,7 @@ Internet-Draft WIMSE Execution Context February 2026 "pol" claim SHOULD reference policy identifiers rather than embedding policy content. - The "compensation_reason" claim (Section 4.2.6) deserves particular + The "compensation_reason" claim (Section 4.2.5) deserves particular attention: because it is human-readable and may describe the circumstances of a failure or policy violation, it risks exposing sensitive operational details. Implementations SHOULD use short, @@ -1933,28 +1933,28 @@ Internet-Draft WIMSE Execution Context February 2026 | pol_enforcer | Policy Enforcer | IETF | Section | | | Identity | | 4.2.3 | +-----------------------+-----------------+------------+-----------+ - | pol_timestamp | Policy Decision | IETF | Section | - | | Timestamp | | 4.2.3 | - +-----------------------+-----------------+------------+-----------+ | inp_hash | Input Data Hash | IETF | Section | | | | | 4.2.4 | +-----------------------+-----------------+------------+-----------+ | out_hash | Output Data | IETF | Section | | | Hash | | 4.2.4 | +-----------------------+-----------------+------------+-----------+ - | inp_classification | Input Data | IETF | Section | - | | Classification | | 4.2.4 | + | compensation_required | Compensation | IETF | Section | + | | Flag | | 4.2.5 | +-----------------------+-----------------+------------+-----------+ - | exec_time_ms | Execution Time | IETF | Section | - | | (ms) | | 4.2.5 | + | compensation_reason | Compensation | IETF | Section | + | | Reason | | 4.2.5 | +-----------------------+-----------------+------------+-----------+ - | witnessed_by | Witness | IETF | Section | - | | Identities | | 4.2.5 | - +-----------------------+-----------------+------------+-----------+ - | regulated_domain | Regulatory | IETF | Section | - | | Domain | | 4.2.5 | + | ext | Extension | IETF | Section | + | | Object | | 4.2.6 | +-----------------------+-----------------+------------+-----------+ + Table 1: JWT Claims Registrations + + + + + Nennemann Expires 28 August 2026 [Page 35] @@ -1962,21 +1962,6 @@ Nennemann Expires 28 August 2026 [Page 35] Internet-Draft WIMSE Execution Context February 2026 - | model_version | AI/ML Model | IETF | Section | - | | Version | | 4.2.5 | - +-----------------------+-----------------+------------+-----------+ - | compensation_required | Compensation | IETF | Section | - | | Flag | | 4.2.6 | - +-----------------------+-----------------+------------+-----------+ - | compensation_reason | Compensation | IETF | Section | - | | Reason | | 4.2.6 | - +-----------------------+-----------------+------------+-----------+ - | ext | Extension | IETF | Section | - | | Object | | 4.2.7 | - +-----------------------+-----------------+------------+-----------+ - - Table 1: JWT Claims Registrations - 12.4. ECT Policy Decision Values Registry This document establishes the "ECT Policy Decision Values" registry @@ -2004,37 +1989,6 @@ Internet-Draft WIMSE Execution Context February 2026 Table 2: ECT Policy Decision Values -12.5. ECT Regulated Domain Values Registry - - This document establishes the "ECT Regulated Domain Values" registry - under the "JSON Web Token (JWT)" group. Registration policy is - Specification Required per [RFC8126]. - - - - -Nennemann Expires 28 August 2026 [Page 36] - -Internet-Draft WIMSE Execution Context February 2026 - - - The initial contents of the registry are: - - +==========+====================+===================+===========+ - | Value | Description | Change Controller | Reference | - +==========+====================+===================+===========+ - | medtech | Medical technology | IETF | Section | - | | and devices | | 4.2.5 | - +----------+--------------------+-------------------+-----------+ - | finance | Financial services | IETF | Section | - | | and trading | | 4.2.5 | - +----------+--------------------+-------------------+-----------+ - | military | Military and | IETF | Section | - | | defense | | 4.2.5 | - +----------+--------------------+-------------------+-----------+ - - Table 3: ECT Regulated Domain Values - 13. References 13.1. Normative References @@ -2055,6 +2009,15 @@ Internet-Draft WIMSE Execution Context February 2026 . + + + + +Nennemann Expires 28 August 2026 [Page 36] + +Internet-Draft WIMSE Execution Context February 2026 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -2064,16 +2027,6 @@ Internet-Draft WIMSE Execution Context February 2026 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . - - - - - -Nennemann Expires 28 August 2026 [Page 37] - -Internet-Draft WIMSE Execution Context February 2026 - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . @@ -2111,6 +2064,16 @@ Internet-Draft WIMSE Execution Context February 2026 resilience for the financial sector (DORA)", 14 December 2022, . + + + + + +Nennemann Expires 28 August 2026 [Page 37] + +Internet-Draft WIMSE Execution Context February 2026 + + [EU-AI-ACT] European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 of the European Parliament and @@ -2122,14 +2085,6 @@ Internet-Draft WIMSE Execution Context February 2026 "Regulation (EU) 2017/745 on medical devices (MDR)", 5 April 2017, . - - - -Nennemann Expires 28 August 2026 [Page 38] - -Internet-Draft WIMSE Execution Context February 2026 - - [FDA-21CFR11] U.S. Food and Drug Administration, "Title 21, Code of Federal Regulations, Part 11: Electronic Records; @@ -2165,6 +2120,16 @@ Internet-Draft WIMSE Execution Context February 2026 . + + + + + +Nennemann Expires 28 August 2026 [Page 38] + +Internet-Draft WIMSE Execution Context February 2026 + + [MIFID-II] European Parliament and Council of the European Union, "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID @@ -2176,16 +2141,6 @@ Internet-Draft WIMSE Execution Context February 2026 Specification", . - - - - - -Nennemann Expires 28 August 2026 [Page 39] - -Internet-Draft WIMSE Execution Context February 2026 - - [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, @@ -2216,6 +2171,21 @@ WIMSE Workload Identity they form an identity-plus-accountability framework for regulated agentic systems. + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 39] + +Internet-Draft WIMSE Execution Context February 2026 + + OAuth 2.0 Token Exchange and the "act" Claim [RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers @@ -2234,14 +2204,6 @@ OAuth 2.0 Token Exchange and the "act" Claim concepts are orthogonal: "act" records "who authorized whom," ECTs record "what was done, in what order, with what policy outcomes." - - - -Nennemann Expires 28 August 2026 [Page 40] - -Internet-Draft WIMSE Execution Context February 2026 - - Transaction Tokens OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] @@ -2272,6 +2234,14 @@ Transaction Tokens ECTs and Transaction Tokens are complementary: a Txn-Token propagates authorization context ("this request is authorized for scope X on behalf of user Y"), while an ECT records execution accountability + + + +Nennemann Expires 28 August 2026 [Page 40] + +Internet-Draft WIMSE Execution Context February 2026 + + ("task T was performed, depending on tasks P1 and P2, with policy Z evaluated and approved"). An agent request could carry both a Txn- Token for authorization and an ECT for execution recording. The WPT @@ -2290,14 +2260,6 @@ Distributed Tracing (OpenTelemetry) 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 - - - -Nennemann Expires 28 August 2026 [Page 41] - -Internet-Draft WIMSE Execution Context February 2026 - - while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. @@ -2328,6 +2290,14 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) "wid" as the shared correlation point. The "ext" claim in ECTs (Section 4.2.2) can carry SCITT-specific metadata such as Transparency Service identifiers or Receipt references for tighter + + + +Nennemann Expires 28 August 2026 [Page 41] + +Internet-Draft WIMSE Execution Context February 2026 + + integration. W3C Verifiable Credentials @@ -2344,16 +2314,6 @@ Minimal Implementation A minimal conforming implementation needs to: - - - - - -Nennemann Expires 28 August 2026 [Page 42] - -Internet-Draft WIMSE Execution Context February 2026 - - 1. Create JWTs with all required claims ("iss", "aud", "iat", "exp", "jti", "exec_act", "par") and policy claims ("pol", "pol_decision") when policy evaluation was performed. @@ -2386,6 +2346,14 @@ Performance Considerations * ES256 signature verification: approximately 1ms per ECT on modern hardware. + + + +Nennemann Expires 28 August 2026 [Page 42] + +Internet-Draft WIMSE Execution Context February 2026 + + * DAG validation: O(V) where V is the number of reachable ancestor nodes (typically small for shallow workflows). @@ -2401,6 +2369,38 @@ Interoperability implementations are strongly discouraged. Implementations are expected to be tested against multiple JWT libraries to ensure interoperability. + +Regulatory Compliance Mapping + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + @@ -2410,13 +2410,6 @@ Nennemann Expires 28 August 2026 [Page 43] Internet-Draft WIMSE Execution Context February 2026 -Regulatory Compliance Mapping - - 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 | +============+========================+==========================+ @@ -2447,7 +2440,7 @@ Regulatory Compliance Mapping | | | trail | +------------+------------------------+--------------------------+ - Table 4: Regulatory Compliance Mapping + Table 3: Regulatory Compliance Mapping Examples @@ -2457,6 +2450,13 @@ Example 1: Simple Two-Agent Workflow ECT JOSE Header: + { + "alg": "ES256", + "typ": "wimse-exec+jwt", + "kid": "agent-a-key-2026-02" + } + + ECT Payload: @@ -2466,14 +2466,6 @@ Nennemann Expires 28 August 2026 [Page 44] Internet-Draft WIMSE Execution Context February 2026 - { - "alg": "ES256", - "typ": "wimse-exec+jwt", - "kid": "agent-a-key-2026-02" - } - - ECT Payload: - { "iss": "spiffe://example.com/agent/data-retrieval", "sub": "spiffe://example.com/agent/data-retrieval", @@ -2487,9 +2479,7 @@ Internet-Draft WIMSE Execution Context February 2026 "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" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } Agent B receives the ECT, verifies it, executes a validation task, @@ -2506,22 +2496,11 @@ Internet-Draft WIMSE Execution Context February 2026 "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" + "pol_decision": "approved" } The resulting DAG: - - - - -Nennemann Expires 28 August 2026 [Page 45] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (fetch_patient_data) | v @@ -2534,6 +2513,15 @@ Example 2: Medical Device SDLC with Release Approval Task 1 (Spec Review Agent): + + + + +Nennemann Expires 28 August 2026 [Page 45] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/spec-reviewer", "sub": "spiffe://meddev.example/agent/spec-reviewer", @@ -2546,8 +2534,6 @@ Example 2: Medical Device SDLC with Release Approval "par": [], "pol": "spec_review_policy_v2", "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "spec-review-v3.1", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } @@ -2565,19 +2551,9 @@ Example 2: Medical Device SDLC with Release Approval "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], "pol": "coding_standards_v3", - "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "codegen-v2.4" + "pol_decision": "approved" } - - - -Nennemann Expires 28 August 2026 [Page 46] - -Internet-Draft WIMSE Execution Context February 2026 - - Task 3 (Autonomous Test Agent): { @@ -2591,11 +2567,17 @@ Internet-Draft WIMSE Execution Context February 2026 "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], "pol": "test_coverage_policy_v1", - "pol_decision": "approved", - "regulated_domain": "medtech", - "exec_time_ms": 4523 + "pol_decision": "approved" } + + + +Nennemann Expires 28 August 2026 [Page 46] + +Internet-Draft WIMSE Execution Context February 2026 + + Task 4 (Build Agent): { @@ -2610,30 +2592,11 @@ Internet-Draft WIMSE Execution Context February 2026 "par": ["a1b2c3d4-0001-0000-0000-000000000003"], "pol": "build_validation_v2", "pol_decision": "approved", - "regulated_domain": "medtech", "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" } Task 5 (Human Release Manager Approval): - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 47] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/human/release-mgr-42", "sub": "spiffe://meddev.example/human/release-mgr-42", @@ -2647,16 +2610,29 @@ Internet-Draft WIMSE Execution Context February 2026 "pol": "release_approval_policy", "pol_decision": "approved", "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", - "witnessed_by": [ - "spiffe://meddev.example/audit/qa-observer-1" - ], - "regulated_domain": "medtech" + "ext": { + "org.ietf.wimse.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 with - independent witness attestation. + build, and a human release manager approved the final release. The + "ext" object in task 5 carries witness metadata via the + "org.ietf.wimse.witnessed_by" extension key. + + + + + + + +Nennemann Expires 28 August 2026 [Page 47] + +Internet-Draft WIMSE Execution Context February 2026 + task-...-0001 (review_requirements_spec) | @@ -2670,7 +2646,7 @@ Internet-Draft WIMSE Execution Context February 2026 task-...-0004 (build_release_artifact) | v - task-...-0005 (approve_release) [human, witnessed] + 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 @@ -2683,13 +2659,6 @@ Example 3: Parallel Execution with Join A workflow where two tasks execute in parallel and a third task depends on both: - - -Nennemann Expires 28 August 2026 [Page 48] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (assess_risk) | \ v v @@ -2702,6 +2671,25 @@ Internet-Draft WIMSE Execution Context February 2026 Task 004 ECT payload: + + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 48] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://bank.example/agent/execution", "sub": "spiffe://bank.example/agent/execution", @@ -2716,8 +2704,7 @@ Internet-Draft WIMSE Execution Context February 2026 "f1e2d3c4-0003-0000-0000-000000000003" ], "pol": "trade_execution_policy_v3", - "pol_decision": "approved", - "regulated_domain": "finance" + "pol_decision": "approved" } The "par" array with two entries records that both compliance @@ -2741,4 +2728,17 @@ Author's Address + + + + + + + + + + + + + Nennemann Expires 28 August 2026 [Page 49] diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index 3d0bf17..d9cf072 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -556,12 +556,6 @@ audit trails. 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. -
    This specification intentionally defines only the recording of @@ -599,51 +593,6 @@ computed over the raw octets of the input data.OPTIONAL. String. A cryptographic hash of the output data, using the same format and algorithm requirements as "inp_hash". -
    inp_classification:
    -
    - OPTIONAL. String. The data sensitivity classification of the -input (e.g., "public", "confidential", "restricted"). -
    - - - -
    Task Metadata - -The following claims provide additional context about task -execution: - -
    -
    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 MUST be registered in the ECT Regulated Domain -Values registry (). -
    -
    model_version:
    -
    - OPTIONAL. String. The version identifier of the AI or ML model -used to perform the task, if applicable. -
    -
    witnessed_by:
    -
    - OPTIONAL. Array of StringOrURI. Identifiers of third-party -entities that the issuing agent claims observed or attested to -the execution of this task. When present, each element SHOULD -use SPIFFE ID format. Note that this claim is self-asserted by -the ECT issuer; witnesses listed here do not co-sign this ECT. -For stronger assurance, witnesses SHOULD submit independent -signed ECTs to the ledger attesting to their observation (see -). In regulated environments, -implementations SHOULD use witness attestation for critical -decision points to mitigate the risk of single-agent false -claims. See also for the security -implications of self-asserted witness claims. -
    @@ -696,6 +645,26 @@ bytes, and the JSON 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 RECOMMENDED for common use +cases. These are not registered claims; they are carried +within the "ext" object: + + + "org.ietf.wimse.exec_time_ms": Integer. Execution duration in +milliseconds. + "org.ietf.wimse.regulated_domain": String. Regulatory domain +(e.g., "medtech", "finance", "military"). + "org.ietf.wimse.model_version": String. AI/ML model version. + "org.ietf.wimse.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. + "org.ietf.wimse.inp_classification": String. Data sensitivity +classification (e.g., "public", "confidential", "restricted"). + "org.ietf.wimse.pol_timestamp": NumericDate. Time at which the +policy decision was made, if distinct from "iat". + +
    Complete ECT Example @@ -718,18 +687,16 @@ ECTs whose "ext" claim exceeds these limits. "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" - ] + "ext": { + "org.ietf.wimse.pol_timestamp": 1772064145, + "org.ietf.wimse.exec_time_ms": 245, + "org.ietf.wimse.regulated_domain": "medtech", + "org.ietf.wimse.model_version": "clinical-reasoning-v4.2" + } } ]]> @@ -1104,7 +1071,7 @@ Human Release Manager: exec_act: approve_release pol: release_approval_policy pol_decision: approved pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - witnessed_by: [spiffe://meddev.example/audit/qa-observer-1] + ext: {org.ietf.wimse.witnessed_by: [...]} (extension metadata) ]]> ECTs record that requirements were reviewed before implementation @@ -1307,20 +1274,21 @@ evaluating the policy). 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. However, the "witnessed_by" claim 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. +regulated environments SHOULD use the "org.ietf.wimse.witnessed_by" +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.
    Witness Attestation Model -To address the self-assertion limitation of the "witnessed_by" -claim, witnesses SHOULD submit their own independent signed ECTs -to the audit ledger attesting to the observed task. A witness -attestation ECT: +To address the self-assertion limitation of the +"org.ietf.wimse.witnessed_by" extension, witnesses SHOULD submit their +own independent signed ECTs to the audit ledger attesting to the +observed task. A witness attestation ECT: MUST set "iss" to the witness's own workload identity. @@ -1332,11 +1300,11 @@ linking the attestation to the original task. confirms the observation. -When a task's "witnessed_by" claim lists one or more witnesses, -auditors SHOULD verify that corresponding witness attestation -ECTs exist in the ledger for each listed witness. A mismatch -between the "witnessed_by" list and the set of independent witness -ECTs in the ledger SHOULD be flagged during audit review. +When a task's "org.ietf.wimse.witnessed_by" extension lists one or more +witnesses, auditors SHOULD verify that corresponding witness +attestation ECTs exist in the ledger for each listed witness. A +mismatch between the extension value and the set of independent +witness ECTs in the ledger SHOULD be flagged during audit review. This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the @@ -1452,8 +1420,8 @@ create a false execution history if they control the ledger. 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. + Witness attestation: Using the "org.ietf.wimse.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 @@ -1704,10 +1672,6 @@ the "JSON Web Token Claims" registry maintained by IANA: Policy Enforcer Identity IETF - pol_timestamp - Policy Decision Timestamp - IETF - inp_hash Input Data Hash IETF @@ -1716,26 +1680,6 @@ the "JSON Web Token Claims" registry maintained by IANA: Output Data Hash IETF - inp_classification - Input Data Classification - IETF - - exec_time_ms - Execution Time (ms) - IETF - - witnessed_by - Witness Identities - IETF - - regulated_domain - Regulatory Domain - IETF - - model_version - AI/ML Model Version - IETF - compensation_required Compensation Flag IETF @@ -1778,34 +1722,6 @@ policy is Specification Required per . -
    -
    ECT Regulated Domain Values Registry - -This document establishes the "ECT Regulated Domain Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per . - -The initial contents of the registry are: - - - Value - Description - Change Controller - Reference - medtech - Medical technology and devices - IETF - - finance - Financial services and trading - IETF - - military - Military and defense - IETF - - -
    @@ -2265,7 +2181,7 @@ been incorporated into this document. This document obsoletes RFC - +
    Related Work @@ -2518,9 +2434,7 @@ Agent B: "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" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } ]]> @@ -2539,9 +2453,7 @@ task, and creates its own ECT: "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" + "pol_decision": "approved" } ]]> @@ -2575,8 +2487,6 @@ autonomous agents and human release approval: "par": [], "pol": "spec_review_policy_v2", "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "spec-review-v3.1", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } @@ -2596,9 +2506,7 @@ autonomous agents and human release approval: "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], "pol": "coding_standards_v3", - "pol_decision": "approved", - "regulated_domain": "medtech", - "model_version": "codegen-v2.4" + "pol_decision": "approved" } ]]> @@ -2616,9 +2524,7 @@ autonomous agents and human release approval: "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], "pol": "test_coverage_policy_v1", - "pol_decision": "approved", - "regulated_domain": "medtech", - "exec_time_ms": 4523 + "pol_decision": "approved" } ]]> @@ -2637,7 +2543,6 @@ autonomous agents and human release approval: "par": ["a1b2c3d4-0001-0000-0000-000000000003"], "pol": "build_validation_v2", "pol_decision": "approved", - "regulated_domain": "medtech", "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" } ]]> @@ -2658,17 +2563,19 @@ autonomous agents and human release approval: "pol": "release_approval_policy", "pol_decision": "approved", "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", - "witnessed_by": [ - "spiffe://meddev.example/audit/qa-observer-1" - ], - "regulated_domain": "medtech" + "ext": { + "org.ietf.wimse.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 -with independent witness attestation. +build, and a human release manager approved the final release. +The "ext" object in task 5 carries witness metadata via +the "org.ietf.wimse.witnessed_by" extension key.
    An FDA auditor reconstructs this DAG by querying the audit ledger @@ -2727,8 +2634,7 @@ task-...-0004 (execute_trade) "f1e2d3c4-0003-0000-0000-000000000003" ], "pol": "trade_execution_policy_v3", - "pol_decision": "approved", - "regulated_domain": "finance" + "pol_decision": "approved" } ]]> @@ -2752,541 +2658,532 @@ tracing is built.
    -Table 4: +Table 3: Regulatory Compliance Mapping