diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index 3cb16b6..8aee653 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -1383,28 +1383,25 @@ regulatory frameworks.

4.2.  JWT Claims

@@ -1489,7 +1486,7 @@ regulatory frameworks.

10.2.  Financial Trading Workflow

  • -

    10.3.  Compensation and Rollback

    +

    10.3.  Compensation and Rollback

  • 10.4.  Autonomous Logistics Coordination

    @@ -2101,10 +2098,10 @@ correct public key for signature verification.

    The ECT payload contains both WIMSE-compatible standard JWT claims and execution context claims defined by this specification.

    -
    +
    -

    -4.2.1. WIMSE-Compatible Claims +

    +4.2.1. Standard JWT Claims

    The following standard JWT claims [RFC7519] MUST be present in every ECT:

    @@ -2195,8 +2192,8 @@ ECTs issued by the same agent.¶<
    -

    -4.2.2. Execution Context Claims +

    +4.2.2. Execution Context

    The following claims are defined by this specification:

    @@ -2241,8 +2238,8 @@ multiple root tasks.

    -

    -4.2.3. Policy Claims +

    +4.2.3. Policy Evaluation

    The following claims record policy evaluation outcomes:

    @@ -2310,8 +2307,8 @@ faithfully recorded in the ECT claims defined above.
    -

    -4.2.4. Data Integrity Claims +

    +4.2.4. Data Integrity

    The following claims provide integrity verification for task inputs and outputs without revealing the data itself:

    @@ -2347,10 +2344,11 @@ input (e.g., "public", "confidential", "restricted").
    -

    -4.2.5. Operational Claims +

    +4.2.5. Task Metadata

    -

    The following claims provide additional operational context:

    +

    The following claims provide additional context about task +execution:

    exec_time_ms:
    @@ -2370,19 +2368,10 @@ Values registry (OPTIONAL. String. The version identifier of the AI or ML model used to perform the task, if applicable.

    -
    -
    -
    -
    -
    -
    -

    -4.2.6. Witness Claims -

    -
    -
    witnessed_by:
    -
    -

    OPTIONAL. Array of StringOrURI. Identifiers of third-party +

    +
    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 @@ -2393,59 +2382,59 @@ signed ECTs to the ledger attesting to their observation (see implementations SHOULD use witness attestation for critical decision points to mitigate the risk of single-agent false claims. See also Section 11.2 for the security -implications of self-asserted witness claims.

    +implications of self-asserted witness claims.

    -
    -

    -4.2.7. Compensation Claims +
    +

    +4.2.6. 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 12.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.8. Extension Claims +
    +

    +4.2.7. 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 @@ -2453,7 +2442,7 @@ 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.

    @@ -3261,8 +3250,8 @@ systems.

    -

    -10.3. Compensation and Rollback +

    +10.3. Compensation and Rollback

    When a compliance violation is discovered after execution, ECTs provide a mechanism to record authorized compensation actions with @@ -3654,7 +3643,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.8).

    +5 levels (see also Section 4.2.7).

    @@ -3713,7 +3702,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.7) +

    The "compensation_reason" claim (Section 4.2.6) 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 @@ -3998,7 +3987,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Witness Identities IETF - Section 4.2.6 + Section 4.2.5 @@ -4022,7 +4011,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Compensation Flag IETF - Section 4.2.7 + Section 4.2.6 @@ -4030,7 +4019,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Compensation Reason IETF - Section 4.2.7 + Section 4.2.6 @@ -4038,7 +4027,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Extension Object IETF - Section 4.2.8 + Section 4.2.7 @@ -4238,10 +4227,6 @@ policy is Specification Required per [ Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07>.

    -
    [I-D.ietf-oauth-transaction-tokens-for-agents]
    -
    -"*** BROKEN REFERENCE ***".
    -
    [I-D.ietf-scitt-architecture]
    Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
    @@ -4250,6 +4235,10 @@ policy is Specification Required per [ Yuan, N. and P. C. Liu, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent-identity-01, , <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01>.
    +
    [I-D.oauth-transaction-tokens-for-agents]
    +
    +Raut, A., "Transaction Tokens For Agents", Work in Progress, Internet-Draft, draft-oauth-transaction-tokens-for-agents-04, , <https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04>.
    +
    [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 II)", , <https://eur-lex.europa.eu/eli/dir/2014/65>.
    @@ -4350,7 +4339,7 @@ no policy evaluation outcomes, and no execution content.Extensions for agentic use cases -([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent +([I-D.oauth-transaction-tokens-for-agents]) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure.

    ECTs and Transaction Tokens are complementary: a Txn-Token diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md index 8dc2bc2..eba5b5d 100644 --- a/draft-nennemann-wimse-execution-context-00.md +++ b/draft-nennemann-wimse-execution-context-00.md @@ -80,7 +80,7 @@ informative: - org: Cloud Native Computing Foundation I-D.ietf-scitt-architecture: I-D.ietf-oauth-transaction-tokens: - I-D.ietf-oauth-transaction-tokens-for-agents: + I-D.oauth-transaction-tokens-for-agents: --- abstract @@ -399,7 +399,7 @@ kid: The ECT payload contains both WIMSE-compatible standard JWT claims and execution context claims defined by this specification. -### WIMSE-Compatible Claims +### Standard JWT Claims The following standard JWT claims {{RFC7519}} MUST be present in every ECT: @@ -468,7 +468,7 @@ jti: expiration window. The "jti" value MUST be unique across all ECTs issued by the same agent. -### Execution Context Claims {#exec-claims} +### Execution Context {#exec-claims} The following claims are defined by this specification: @@ -500,7 +500,7 @@ par: a root task with no dependencies. A workflow MAY contain multiple root tasks. -### Policy Claims {#policy-claims} +### Policy Evaluation {#policy-claims} The following claims record policy evaluation outcomes: @@ -552,7 +552,7 @@ 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. -### Data Integrity Claims {#data-integrity-claims} +### Data Integrity {#data-integrity-claims} The following claims provide integrity verification for task inputs and outputs without revealing the data itself: @@ -577,9 +577,10 @@ inp_classification: : OPTIONAL. String. The data sensitivity classification of the input (e.g., "public", "confidential", "restricted"). -### Operational Claims {#operational-claims} +### Task Metadata {#operational-claims} -The following claims provide additional operational context: +The following claims provide additional context about task +execution: exec_time_ms: : OPTIONAL. Integer. The execution duration of the task in @@ -594,8 +595,6 @@ model_version: : OPTIONAL. String. The version identifier of the AI or ML model used to perform the task, if applicable. -### Witness Claims {#witness-claims} - witnessed_by: : OPTIONAL. Array of StringOrURI. Identifiers of third-party entities that the issuing agent claims observed or attested to @@ -610,7 +609,7 @@ witnessed_by: claims. See also {{self-assertion-limitation}} for the security implications of self-asserted witness claims. -### Compensation Claims {#compensation-claims} +### Compensation and Rollback {#compensation-claims} compensation_required: : OPTIONAL. Boolean. Indicates whether this task is a @@ -632,7 +631,7 @@ Note: compensation ECTs reference historical parent tasks via the the ECT itself, not to its validity as a parent reference in the ledger. -### Extension Claims {#extension-claims} +### Extensions {#extension-claims} ext: : OPTIONAL. Object. An extension object for domain-specific @@ -1685,7 +1684,7 @@ the "JSON Web Token Claims" registry maintained by IANA: | out_hash | Output Data Hash | IETF | {{data-integrity-claims}} | | inp_classification | Input Data Classification | IETF | {{data-integrity-claims}} | | exec_time_ms | Execution Time (ms) | IETF | {{operational-claims}} | -| witnessed_by | Witness Identities | IETF | {{witness-claims}} | +| 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}} | @@ -1782,7 +1781,7 @@ However, "req_wl" cannot form a DAG because: no policy evaluation outcomes, and no execution content. Extensions for agentic use cases -({{I-D.ietf-oauth-transaction-tokens-for-agents}}) add agent +({{I-D.oauth-transaction-tokens-for-agents}}) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure. diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt index d19f891..4992725 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/draft-nennemann-wimse-execution-context-00.txt @@ -87,14 +87,13 @@ Table of Contents 4. Execution Context Token Format . . . . . . . . . . . . . . . 9 4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. WIMSE-Compatible Claims . . . . . . . . . . . . . . . 10 - 4.2.2. Execution Context Claims . . . . . . . . . . . . . . 11 - 4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 12 - 4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 13 - 4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 13 - 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 14 - 4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 14 - 4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 14 + 4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 10 + 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.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 15 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15 @@ -106,6 +105,7 @@ Table of Contents 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20 8. Operational Modes . . . . . . . . . . . . . . . . . . . . . . 22 + 8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22 @@ -114,7 +114,6 @@ Nennemann Expires 28 August 2026 [Page 2] Internet-Draft WIMSE Execution Context February 2026 - 8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22 8.2. Deferred Ledger Mode . . . . . . . . . . . . . . . . . . 23 8.3. Full Ledger Mode . . . . . . . . . . . . . . . . . . . . 23 9. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 23 @@ -158,10 +157,11 @@ Internet-Draft WIMSE Execution Context February 2026 WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 42 OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 42 Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 43 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 43 + Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 44 Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 44 SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 44 - W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 44 + W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 45 + Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 45 @@ -170,18 +170,17 @@ Nennemann Expires 28 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 - Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 44 - Minimal Implementation . . . . . . . . . . . . . . . . . . . . 44 + Minimal Implementation . . . . . . . . . . . . . . . . . . . . 45 Storage Recommendations . . . . . . . . . . . . . . . . . . . . 45 Performance Considerations . . . . . . . . . . . . . . . . . . 45 - Interoperability . . . . . . . . . . . . . . . . . . . . . . . 45 + Interoperability . . . . . . . . . . . . . . . . . . . . . . . 46 Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 46 - Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 46 - Example 2: Medical Device SDLC with Release Approval . . . . . 48 - Example 3: Parallel Execution with Join . . . . . . . . . . . . 51 + Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 + Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 47 + Example 2: Medical Device SDLC with Release Approval . . . . . 49 + Example 3: Parallel Execution with Join . . . . . . . . . . . . 52 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction @@ -221,6 +220,7 @@ Internet-Draft WIMSE Execution Context February 2026 + Nennemann Expires 28 August 2026 [Page 4] Internet-Draft WIMSE Execution Context February 2026 @@ -525,7 +525,7 @@ Internet-Draft WIMSE Execution Context February 2026 The ECT payload contains both WIMSE-compatible standard JWT claims and execution context claims defined by this specification. -4.2.1. WIMSE-Compatible Claims +4.2.1. Standard JWT Claims The following standard JWT claims [RFC7519] MUST be present in every ECT: @@ -595,7 +595,7 @@ Internet-Draft WIMSE Execution Context February 2026 expiration window. The "jti" value MUST be unique across all ECTs issued by the same agent. -4.2.2. Execution Context Claims +4.2.2. Execution Context The following claims are defined by this specification: @@ -629,7 +629,7 @@ Internet-Draft WIMSE Execution Context February 2026 task with no dependencies. A workflow MAY contain multiple root tasks. -4.2.3. Policy Claims +4.2.3. Policy Evaluation The following claims record policy evaluation outcomes: @@ -684,7 +684,7 @@ Internet-Draft WIMSE Execution Context February 2026 provided that the evaluation outcome is faithfully recorded in the ECT claims defined above. -4.2.4. Data Integrity Claims +4.2.4. Data Integrity The following claims provide integrity verification for task inputs and outputs without revealing the data itself: @@ -708,9 +708,9 @@ Internet-Draft WIMSE Execution Context February 2026 classification of the input (e.g., "public", "confidential", "restricted"). -4.2.5. Operational Claims +4.2.5. Task Metadata - The following claims provide additional operational context: + 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. @@ -730,8 +730,6 @@ Nennemann Expires 28 August 2026 [Page 13] Internet-Draft WIMSE Execution Context February 2026 -4.2.6. Witness Claims - 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 @@ -745,7 +743,7 @@ Internet-Draft WIMSE Execution Context February 2026 See also Section 11.2 for the security implications of self- asserted witness claims. -4.2.7. Compensation Claims +4.2.6. Compensation and Rollback compensation_required: OPTIONAL. Boolean. Indicates whether this task is a compensation or rollback action for a previous task. @@ -764,7 +762,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.8. Extension Claims +4.2.7. Extensions ext: OPTIONAL. Object. An extension object for domain-specific claims not defined by this specification. Implementations that do @@ -781,6 +779,8 @@ Internet-Draft WIMSE Execution Context February 2026 + + Nennemann Expires 28 August 2026 [Page 14] Internet-Draft WIMSE Execution Context February 2026 @@ -1874,7 +1874,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.8). + exceed a nesting depth of 5 levels (see also Section 4.2.7). 12. Privacy Considerations @@ -1918,7 +1918,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.7) deserves particular + The "compensation_reason" claim (Section 4.2.6) 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, @@ -2064,7 +2064,7 @@ Internet-Draft WIMSE Execution Context February 2026 | | (ms) | | 4.2.5 | +-----------------------+-----------------+------------+-----------+ | witnessed_by | Witness | IETF | Section | - | | Identities | | 4.2.6 | + | | Identities | | 4.2.5 | +-----------------------+-----------------+------------+-----------+ @@ -2081,13 +2081,13 @@ Internet-Draft WIMSE Execution Context February 2026 | | Version | | 4.2.5 | +-----------------------+-----------------+------------+-----------+ | compensation_required | Compensation | IETF | Section | - | | Flag | | 4.2.7 | + | | Flag | | 4.2.6 | +-----------------------+-----------------+------------+-----------+ | compensation_reason | Compensation | IETF | Section | - | | Reason | | 4.2.7 | + | | Reason | | 4.2.6 | +-----------------------+-----------------+------------+-----------+ | ext | Extension | IETF | Section | - | | Object | | 4.2.8 | + | | Object | | 4.2.7 | +-----------------------+-----------------+------------+-----------+ Table 1: JWT Claims Registrations @@ -2259,9 +2259,6 @@ Internet-Draft WIMSE Execution Context February 2026 . - [I-D.ietf-oauth-transaction-tokens-for-agents] - "*** BROKEN REFERENCE ***". - [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and @@ -2277,16 +2274,19 @@ Internet-Draft WIMSE Execution Context February 2026 . + [I-D.oauth-transaction-tokens-for-agents] + Raut, A., "Transaction Tokens For Agents", Work in + Progress, Internet-Draft, draft-oauth-transaction-tokens- + for-agents-04, 10 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 II)", 15 May 2014, . - [OPENTELEMETRY] - Cloud Native Computing Foundation, "OpenTelemetry - Specification", - . @@ -2298,6 +2298,11 @@ Nennemann Expires 28 August 2026 [Page 41] Internet-Draft WIMSE Execution Context February 2026 + [OPENTELEMETRY] + Cloud Native Computing Foundation, "OpenTelemetry + Specification", + . + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, @@ -2341,11 +2346,6 @@ OAuth 2.0 Token Exchange and the "act" Claim branching (fan-out) or convergence (fan-in) and therefore cannot form a DAG. - ECTs intentionally use the distinct claim name "exec_act" for the - action/task type to avoid collision with the "act" claim. The two - concepts are orthogonal: "act" records "who authorized whom," ECTs - record "what was done, in what order, with what policy outcomes." - @@ -2354,6 +2354,11 @@ Nennemann Expires 28 August 2026 [Page 42] Internet-Draft WIMSE Execution Context February 2026 + ECTs intentionally use the distinct claim name "exec_act" for the + action/task type to avoid collision with the "act" claim. The two + concepts are orthogonal: "act" records "who authorized whom," ECTs + record "what was done, in what order, with what policy outcomes." + Transaction Tokens OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] @@ -2377,8 +2382,8 @@ Transaction Tokens policy evaluation outcomes, and no execution content. Extensions for agentic use cases - ([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent identity - and constraints ("agentic_ctx") but no execution ordering or DAG + ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and + constraints ("agentic_ctx") but no execution ordering or DAG structure. ECTs and Transaction Tokens are complementary: a Txn-Token propagates @@ -2391,6 +2396,20 @@ Transaction Tokens WPT to a co-present Txn-Token; a similar binding mechanism for ECTs is a potential future extension. + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 43] + +Internet-Draft WIMSE Execution Context February 2026 + + Distributed Tracing (OpenTelemetry) OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems @@ -2402,14 +2421,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 43] - -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. @@ -2442,6 +2453,19 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) Transparency Service identifiers or Receipt references for tighter integration. + + + + + + + + +Nennemann Expires 28 August 2026 [Page 44] + +Internet-Draft WIMSE Execution Context February 2026 + + W3C Verifiable Credentials W3C Verifiable Credentials represent claims about subjects (e.g., @@ -2459,13 +2483,6 @@ Minimal Implementation 1. Create JWTs with all required claims ("iss", "aud", "iat", "exp", "jti", "tid", "exec_act", "par", "pol", "pol_decision"). - - -Nennemann Expires 28 August 2026 [Page 44] - -Internet-Draft WIMSE Execution Context February 2026 - - 2. Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). @@ -2498,6 +2515,13 @@ Performance Considerations * DAG validation: O(V) where V is the number of reachable ancestor nodes (typically small for shallow workflows). + + +Nennemann Expires 28 August 2026 [Page 45] + +Internet-Draft WIMSE Execution Context February 2026 + + * JSON serialization: sub-millisecond per ECT. * Total per-request overhead: approximately 5-10ms, acceptable for @@ -2511,17 +2535,6 @@ Interoperability expected to be tested against multiple JWT libraries to ensure interoperability. - - - - - - -Nennemann Expires 28 August 2026 [Page 45] - -Internet-Draft WIMSE Execution Context February 2026 - - Regulatory Compliance Mapping The following table summarizes how ECTs can contribute to compliance @@ -2529,6 +2542,42 @@ Regulatory Compliance Mapping block; achieving compliance requires additional organizational measures beyond this specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 46] + +Internet-Draft WIMSE Execution Context February 2026 + + +============+========================+==========================+ | Regulation | Requirement | ECT Contribution | +============+========================+==========================+ @@ -2569,15 +2618,6 @@ Example 1: Simple Two-Agent Workflow ECT JOSE Header: - - - - -Nennemann Expires 28 August 2026 [Page 46] - -Internet-Draft WIMSE Execution Context February 2026 - - { "alg": "ES256", "typ": "wimse-exec+jwt", @@ -2586,6 +2626,14 @@ Internet-Draft WIMSE Execution Context February 2026 ECT Payload: + + + +Nennemann Expires 28 August 2026 [Page 47] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://example.com/agent/data-retrieval", "sub": "spiffe://example.com/agent/data-retrieval", @@ -2627,18 +2675,21 @@ Internet-Draft WIMSE Execution Context February 2026 The resulting DAG: - - -Nennemann Expires 28 August 2026 [Page 47] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (fetch_patient_data) | v task-...-0002 (validate_safety) + + + + + +Nennemann Expires 28 August 2026 [Page 48] + +Internet-Draft WIMSE Execution Context February 2026 + + Example 2: Medical Device SDLC with Release Approval A multi-step medical device software lifecycle workflow with @@ -2667,29 +2718,6 @@ Example 2: Medical Device SDLC with Release Approval Task 2 (Code Generation Agent): - - - - - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 48] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/agent/code-gen", "sub": "spiffe://meddev.example/agent/code-gen", @@ -2709,6 +2737,15 @@ Internet-Draft WIMSE Execution Context February 2026 Task 3 (Autonomous Test Agent): + + + + +Nennemann Expires 28 August 2026 [Page 49] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/test-runner", "sub": "spiffe://meddev.example/agent/test-runner", @@ -2728,24 +2765,6 @@ Internet-Draft WIMSE Execution Context February 2026 Task 4 (Build Agent): - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 49] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/agent/build", "sub": "spiffe://meddev.example/agent/build", @@ -2765,6 +2784,24 @@ Internet-Draft WIMSE Execution Context February 2026 Task 5 (Human Release Manager Approval): + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 50] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/human/release-mgr-42", "sub": "spiffe://meddev.example/human/release-mgr-42", @@ -2790,18 +2827,6 @@ Internet-Draft WIMSE Execution Context February 2026 build, and a human release manager approved the final release with independent witness attestation. - - - - - - - -Nennemann Expires 28 August 2026 [Page 50] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (review_requirements_spec) | v @@ -2822,6 +2847,17 @@ Internet-Draft WIMSE Execution Context February 2026 that the SDLC followed the prescribed process with human oversight at the release gate. + + + + + + +Nennemann Expires 28 August 2026 [Page 51] + +Internet-Draft WIMSE Execution Context February 2026 + + Example 3: Parallel Execution with Join A workflow where two tasks execute in parallel and a third task @@ -2839,25 +2875,6 @@ Example 3: Parallel Execution with Join Task 004 ECT payload: - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 51] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://bank.example/agent/execution", "sub": "spiffe://bank.example/agent/execution", @@ -2888,6 +2905,15 @@ Acknowledgments Workload Identity Tokens and Workload Proof Tokens provide the identity foundation upon which execution context tracing is built. + + + + +Nennemann Expires 28 August 2026 [Page 52] + +Internet-Draft WIMSE Execution Context February 2026 + + Author's Address Christian Nennemann @@ -2909,4 +2935,34 @@ Author's Address -Nennemann Expires 28 August 2026 [Page 52] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 53] diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index 301d638..84ae2a9 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -399,7 +399,7 @@ correct public key for signature verification. The ECT payload contains both WIMSE-compatible standard JWT claims and execution context claims defined by this specification. -

    WIMSE-Compatible Claims +
    Standard JWT Claims The following standard JWT claims MUST be present in every ECT: @@ -482,7 +482,7 @@ ECTs issued by the same agent.
    -
    Execution Context Claims +
    Execution Context The following claims are defined by this specification: @@ -522,7 +522,7 @@ multiple root tasks.
    -
    Policy Claims +
    Policy Evaluation The following claims record policy evaluation outcomes: @@ -583,7 +583,7 @@ or custom solutions) provided that the evaluation outcome is faithfully recorded in the ECT claims defined above.
    -
    Data Integrity Claims +
    Data Integrity The following claims provide integrity verification for task inputs and outputs without revealing the data itself: @@ -615,9 +615,10 @@ input (e.g., "public", "confidential", "restricted").
    -
    Operational Claims +
    Task Metadata -The following claims provide additional operational context: +The following claims provide additional context about task +execution:
    exec_time_ms:
    @@ -636,12 +637,6 @@ Values registry (). OPTIONAL. String. The version identifier of the AI or ML model used to perform the task, if applicable. -
    - -
    -
    Witness Claims - -
    witnessed_by:
    OPTIONAL. Array of StringOrURI. Identifiers of third-party @@ -660,7 +655,7 @@ implications of self-asserted witness claims.
    -
    Compensation Claims +
    Compensation and Rollback
    compensation_required:
    @@ -688,7 +683,7 @@ the ECT itself, not to its validity as a parent reference in the ledger.
    -
    Extension Claims +
    Extensions
    ext:
    @@ -1860,7 +1855,7 @@ the "JSON Web Token Claims" registry maintained by IANA: witnessed_by Witness Identities IETF - + regulated_domain Regulatory Domain IETF @@ -2362,7 +2357,34 @@ been incorporated into this document. This document obsoletes RFC - *** BROKEN REFERENCE *** + + + + Transaction Tokens For Agents + + Amazon + + + + This document specifies an extension to the OAuth Transaction Tokens + framework (https://drafts.oauth.net/oauth-transaction-tokens/draft- + ietf-oauth-transaction-tokens.html) to support agent context + propagation within Transaction Tokens for agent-based workloads. The + extension defines two new context fields: 'actor' and 'principal'. + The 'actor' field identifies the agent performing the action, while + the 'principal' field identifies the human or system entity that + initiated the agent's action. For autonomous agents operating + independently, the 'principal' field MAY be omitted. These + additional context fields enable services within the call graph to + make more granular access control decisions, thereby enhancing + security. + + + + + + + @@ -2371,7 +2393,7 @@ been incorporated into this document. This document obsoletes RFC - +
    Related Work @@ -2430,7 +2452,7 @@ no policy evaluation outcomes, and no execution content. Extensions for agentic use cases -() add agent +() add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure. @@ -2868,579 +2890,580 @@ tracing is built.