From ff795c72e6ef0e6b89feb90b8ed99fa8f1070e29 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Wed, 25 Feb 2026 21:59:16 +0100 Subject: [PATCH] Implement peer review feedback for draft-nennemann-wimse-ect-00 Address 11 items from peer review: - Fix area designation from Security to ART (WIMSE is in ART area) - Switch inp_hash/out_hash to fixed SHA-256 without algorithm prefix, matching DPoP (RFC 9449) and WIMSE WPT tth claim patterns - Add partial DAG verification guidance for unavailable parents - Add DAG integrity attacks subsection (false parents, pruning, shadow DAGs) - Add privilege escalation subsection (ECTs are not authorization) - Add revocation propagation semantics through the DAG - Add W3C PROV Data Model to Related Work - Strengthen Txn-Token differentiation with fan-in/convergence bullet - Add explicit token binding paragraph to replay prevention - Switch verification step 3 to algorithm allowlist model - Add par/ext claim naming justification notes Co-Authored-By: Claude Opus 4.6 --- draft-nennemann-wimse-ect-00.html | 238 ++++++-- draft-nennemann-wimse-ect-00.md | 152 +++++- draft-nennemann-wimse-ect-00.txt | 594 +++++++++++--------- draft-nennemann-wimse-ect-00.xml | 871 ++++++++++++++++++------------ 4 files changed, 1194 insertions(+), 661 deletions(-) diff --git a/draft-nennemann-wimse-ect-00.html b/draft-nennemann-wimse-ect-00.html index 3272aaf..2161056 100644 --- a/draft-nennemann-wimse-ect-00.html +++ b/draft-nennemann-wimse-ect-00.html @@ -1402,6 +1402,9 @@ existing WIMSE headers.

  • 6.2.  Validation Rules

    +
    • +
  • +

    6.3.  Handling Unavailable Parent ECTs

    • @@ -1444,13 +1447,19 @@ existing WIMSE headers.

    9.8.  Collusion and False Claims

  • -

    9.9.  Denial of Service

    +

    9.9.  DAG Integrity Attacks

  • -

    9.10. Timestamp Accuracy

    +

    9.10. Privilege Escalation via ECTs

  • -

    9.11. ECT Size Constraints

    +

    9.11. Denial of Service

    +
    • +
  • +

    9.12. Timestamp Accuracy

    +
    • +
  • +

    9.13. ECT Size Constraints

    • @@ -1517,7 +1526,10 @@ existing WIMSE headers.

    Distributed Tracing (OpenTelemetry)

  • -

    SCITT (Supply Chain Integrity, Transparency, and Trust)

    +

    W3C Provenance Data Model (PROV)

    +
    • +
  • +

    SCITT (Supply Chain Integrity, Transparency, and Trust)

    • @@ -2036,7 +2048,9 @@ a root task with no dependencies. A workflow MAY con multiple root tasks. Parent ECTs may have passed their own "exp" time; ECT expiration applies to the verification window of the ECT itself, not to its validity as a parent reference -in the ECT store.

    +in the ECT store. Note: "par" is not a registered JWT claim +and does not conflict with OAuth Pushed Authorization Requests +(RFC 9126), which defines an endpoint, not a token claim.

    @@ -2052,22 +2066,19 @@ inputs and outputs without revealing the data itself:
    inp_hash:
    -

    OPTIONAL. String. A cryptographic hash of the input data, -formatted as "hash-algorithm:base64url-encoded-hash" (e.g., -"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The -hash algorithm identifier MUST be a lowercase value from the -IANA Named Information Hash Algorithm Registry (e.g., "sha-256", -"sha-384", "sha-512"). Implementations MUST support "sha-256" -and SHOULD use "sha-256" unless a stronger algorithm is -required. Implementations MUST NOT accept hash algorithms -weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be -computed over the raw octets of the input data.

    +

    OPTIONAL. String. The base64url encoding (without padding) of +the SHA-256 hash of the input data, computed over the raw octets +of the input. This follows the same fixed-algorithm pattern +used by the DPoP "ath" claim [RFC9449] and the WIMSE WPT +"tth" claim [I-D.ietf-wimse-s2s-protocol]: SHA-256 is the +mandatory algorithm with no algorithm prefix in the value.

    out_hash:
    -

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

    +

    OPTIONAL. String. The base64url encoding (without padding) of +the SHA-256 hash of the output data, using the same format as +"inp_hash".

    @@ -2081,9 +2092,12 @@ using the same format and algorithm requirements as "inp_hash".
    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.

    +

    OPTIONAL. Object. A general-purpose extension object for +domain-specific claims not defined by this specification. The +short name "ext" follows the JWT convention of concise claim +names and is chosen over alternatives like "extensions" for +compactness. Implementations that do not understand extension +claims MUST ignore them.

    @@ -2123,8 +2137,12 @@ future documents.

    "exec_act": "recommend_treatment", "par": [], - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + + "ext": { + "com.example.trace_id": "abc123" + } } @@ -2251,6 +2269,35 @@ implementations SHOULD enforce a maximum ancestor tra detection completes, the ECT SHOULD be rejected.

    +
    +
    +

    +6.3. Handling Unavailable Parent ECTs +

    +

    In distributed deployments, a parent ECT referenced in the "par" +array may not yet be available in the local ECT store at the time +of validation — for example, due to replication lag in a +distributed ledger or out-of-order message delivery.

    +

    Implementations MUST distinguish between two cases:

    +
      +
    1. +

      Parent not found and definitively absent: The parent "jti" +does not exist in any accessible ECT store. The ECT MUST be +rejected.

      +
      2. +
    2. +

      Parent not yet available: The parent "jti" is not present +locally but may arrive due to known replication delays. +Implementations MAY defer validation for a bounded period +(RECOMMENDED: no more than 60 seconds).

      +
      3. +
    +

    Deferred ECTs MUST NOT be treated as verified until all parent +references are resolved. If any parent reference remains +unresolved after the deferral period or after the ECT's own "exp" +time (whichever comes first), the ECT MUST be rejected.

    +
    +
    @@ -2274,8 +2321,12 @@ payload, and signature components per [Verify that the "typ" header parameter is "wimse-exec+jwt".

  • -

    Verify that the "alg" header parameter is not "none" and is -not a symmetric algorithm.

    +

    Verify that the "alg" header parameter appears in the +verifier's configured allowlist of accepted signing algorithms. +The allowlist MUST NOT include "none" or any symmetric +algorithm (e.g., HS256, HS384, HS512). Implementations MUST +include ES256 in the allowlist; additional asymmetric algorithms +MAY be included per deployment policy.

  • Verify the "kid" header parameter references a known, valid @@ -2500,6 +2551,11 @@ with the same action can be flagged as a potential replay.Implementations MUST maintain a cache of recently-seen "jti" values to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected.

    +

    Additionally, each ECT is cryptographically bound to the issuing +agent via the JOSE "kid" parameter, which references the agent's +WIT public key. Verifiers MUST confirm that the "kid" resolves +to the "iss" agent's key (step 8 in Section 7), preventing +one agent from replaying another agent's ECT as its own.

    • @@ -2556,6 +2612,15 @@ compromised key and issue a new WIT with a fresh key pair.SHOULD be flagged in the ledger as "signed with subsequently revoked key" for audit purposes.

    +

    ECT revocation does not propagate through the DAG. If a parent +ECT's signing key is later revoked, child ECTs that were verified +and recorded before that revocation remain valid — they captured +a legitimate execution record at the time of issuance. However, +auditors reviewing a workflow SHOULD flag any ECT in the DAG +whose signing key was subsequently revoked, so that the scope of +a potential compromise can be assessed. New ECTs MUST NOT be +created with a "par" reference to an ECT whose signing key is +known to be revoked at creation time.

    @@ -2584,54 +2649,110 @@ contents against expected workflow patterns. +
    -

    -9.9. Denial of Service +

    +9.9. DAG Integrity Attacks

    -

    ECT signature verification is computationally inexpensive +

    Because the DAG structure is the primary mechanism for establishing +execution ordering, attackers may attempt to manipulate it:

    +
      +
    • +

      False parent references: A malicious agent creates an ECT that +references parent tasks from an unrelated workflow, inserting +itself into a legitimate execution history. DAG validation +(Section 6) mitigates this by requiring parent existence +in the ECT store, and the "wid" claim scopes parent references +to a single workflow when present.

      +
      • +
    • +

      Parent omission (pruning): An agent deliberately omits one or +more actual parent dependencies from the "par" array to hide +that certain tasks influenced its output. Because ECTs are +self-asserted (Section 9.2), no mechanism can +force an agent to declare all dependencies. External auditors +can detect omission by comparing the declared DAG against +expected workflow patterns.

      +
      • +
    • +

      Shadow DAGs: Multiple colluding agents fabricate an entire +execution history by creating a sequence of ECTs with mutual +parent references. Independent ledger maintenance and +cross-verification (see Section 9.8 above) +are the primary mitigations.

      +
      • +
    +

    Verifiers SHOULD validate that the declared "wid" of parent ECTs +matches the "wid" of the child ECT, rejecting cross-workflow +parent references unless explicitly permitted by deployment +policy.

    +
    +
    +
    +
    +

    +9.10. Privilege Escalation via ECTs +

    +

    ECTs record execution history; they do not convey authorization. +Verifiers MUST NOT interpret the presence of an ECT, or a +particular set of parent references in "par", as an authorization +grant. The "par" claim demonstrates that predecessor tasks were +recorded, not that the current agent is authorized to act on +their outputs. Authorization decisions MUST remain with the +identity and authorization layer (WIT, WPT, and deployment +policy). As noted in [I-D.ni-wimse-ai-agent-identity], +AI intermediaries introduce novel escalation vectors; ECTs +MUST NOT be used to circumvent authorization boundaries.

    +
    +
    +
    +
    +

    +9.11. Denial of Service +

    +

    ECT signature verification is computationally inexpensive (approximately 1ms per ECT on modern hardware for ES256). DAG validation complexity is O(V) where V is the number of ancestor nodes reachable from the parent references; for typical shallow -DAGs this is efficient.

    -

    Implementations SHOULD apply rate limiting at the API layer to +DAGs this is efficient.

    +

    Implementations SHOULD apply rate limiting at the API layer to prevent excessive ECT submissions. DAG validation SHOULD be performed after signature verification to avoid wasting resources -on unsigned or incorrectly signed tokens.

    +on unsigned or incorrectly signed tokens.

    -
    +

    -9.10. Timestamp Accuracy +9.12. Timestamp Accuracy

    -

    ECTs rely on timestamps ("iat", "exp") for temporal ordering. +

    ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock skew between agents can lead to incorrect ordering judgments. Implementations SHOULD use synchronized time sources (e.g., NTP) and SHOULD allow a configurable clock skew tolerance -(RECOMMENDED: 30 seconds).

    -

    Cross-organizational deployments where agents span multiple trust +(RECOMMENDED: 30 seconds).

    +

    Cross-organizational deployments where agents span multiple trust domains with independent time sources MAY require a higher clock skew tolerance. Deployments using trust domain federation SHOULD document their configured clock skew tolerance value and SHOULD -ensure all participating trust domains agree on a common tolerance.

    -

    The temporal ordering check in DAG validation incorporates the +ensure all participating trust domains agree on a common tolerance.

    +

    The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences -between agents.

    +between agents.

    -
    +

    -9.11. ECT Size Constraints +9.13. ECT Size Constraints

    -

    ECTs with many parent tasks or large extension objects can +

    ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of -5 levels (see also Section 4.2.4).

    +5 levels (see also Section 4.2.4).

    @@ -3000,6 +3121,10 @@ the "JSON Web Token Claims" registry maintained by IANA:Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, , <https://www.rfc-editor.org/rfc/rfc9421>.
    +
    [RFC9449]
    +
    +Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.
    +
    [SPIFFE]
    "Secure Production Identity Framework for Everyone (SPIFFE)", <https://spiffe.io/docs/latest/spiffe-about/overview/>.
    @@ -3157,6 +3282,11 @@ workloads that forward the token unchanged are not recorded.

    It carries no task-level granularity, no parent references, and no execution content.

    + +
  • +

    It cannot represent convergence (fan-in): when two independent +paths must both complete before a dependent task proceeds, a +linear "req_wl" string cannot express that relationship.

    • Extensions for agentic use cases @@ -3194,16 +3324,32 @@ ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation.

    -
    +
    +

    +W3C Provenance Data Model (PROV) +

    +

    The W3C PROV Data Model defines an Entity-Activity-Agent ontology +for representing provenance information. PROV's concepts map +closely to ECT structures: PROV Activities correspond to ECT +tasks, PROV Agents correspond to WIMSE workloads, and PROV's +"wasInformedBy" relation corresponds to ECT "par" references. +However, PROV uses RDF/OWL ontologies designed for post-hoc +documentation, while ECTs are runtime-embeddable JWT tokens with +cryptographic signatures. ECT audit data could be exported to +PROV format for interoperability with provenance-aware systems.

    +
    +
    +
    +

    SCITT (Supply Chain Integrity, Transparency, and Trust)

    -

    The SCITT architecture [I-D.ietf-scitt-architecture] defines a +

    The SCITT architecture [I-D.ietf-scitt-architecture] defines a framework for transparent and auditable supply chain records. ECTs and SCITT are complementary: the ECT "wid" claim can serve as a correlation identifier in SCITT Signed Statements, linking -an ECT audit trail to a supply chain transparency record.

    +an ECT audit trail to a supply chain transparency record.

    diff --git a/draft-nennemann-wimse-ect-00.md b/draft-nennemann-wimse-ect-00.md index f6f6901..f9c736e 100644 --- a/draft-nennemann-wimse-ect-00.md +++ b/draft-nennemann-wimse-ect-00.md @@ -7,7 +7,7 @@ submissiontype: IETF number: date: v: 3 -area: "Security" +area: "ART" workgroup: "WIMSE" keyword: - execution context @@ -47,6 +47,7 @@ informative: author: - org: Cloud Native Computing Foundation I-D.ietf-scitt-architecture: + RFC9449: I-D.ietf-oauth-transaction-tokens: I-D.oauth-transaction-tokens-for-agents: @@ -413,7 +414,9 @@ par: multiple root tasks. Parent ECTs may have passed their own "exp" time; ECT expiration applies to the verification window of the ECT itself, not to its validity as a parent reference - in the ECT store. + in the ECT store. Note: "par" is not a registered JWT claim + and does not conflict with OAuth Pushed Authorization Requests + (RFC 9126), which defines an endpoint, not a token claim. ### Data Integrity {#data-integrity-claims} @@ -421,27 +424,27 @@ The following claims provide integrity verification for task inputs and outputs without revealing the data itself: inp_hash: -: OPTIONAL. String. A cryptographic hash of the input data, - formatted as "hash-algorithm:base64url-encoded-hash" (e.g., - "sha-256:n4bQgYhMfWWaL-qgxVrQFaO\_TxsrC4Is0V1sFbDwCgg"). The - hash algorithm identifier MUST be a lowercase value from the - IANA Named Information Hash Algorithm Registry (e.g., "sha-256", - "sha-384", "sha-512"). Implementations MUST support "sha-256" - and SHOULD use "sha-256" unless a stronger algorithm is - required. Implementations MUST NOT accept hash algorithms - weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be - computed over the raw octets of the input data. +: OPTIONAL. String. The base64url encoding (without padding) of + the SHA-256 hash of the input data, computed over the raw octets + of the input. This follows the same fixed-algorithm pattern + used by the DPoP "ath" claim {{RFC9449}} and the WIMSE WPT + "tth" claim {{I-D.ietf-wimse-s2s-protocol}}: SHA-256 is the + mandatory algorithm with no algorithm prefix in the value. out_hash: -: OPTIONAL. String. A cryptographic hash of the output data, - using the same format and algorithm requirements as "inp_hash". +: OPTIONAL. String. The base64url encoding (without padding) of + the SHA-256 hash of the output data, using the same format as + "inp_hash". ### Extensions {#extension-claims} 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. +: OPTIONAL. Object. A general-purpose extension object for + domain-specific claims not defined by this specification. The + short name "ext" follows the JWT convention of concise claim + names and is chosen over alternatives like "extensions" for + compactness. Implementations that do not understand extension + claims MUST ignore them. To avoid key collisions between different domains, extension key names SHOULD use reverse domain notation (e.g., @@ -472,8 +475,12 @@ The following is a complete ECT payload example: "exec_act": "recommend_treatment", "par": [], - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + + "ext": { + "com.example.trace_id": "abc123" + } } ~~~ {: #fig-full-ect title="Complete ECT Payload Example"} @@ -567,6 +574,29 @@ implementations SHOULD enforce a maximum ancestor traversal limit (RECOMMENDED: 10000 nodes). If the limit is reached before cycle detection completes, the ECT SHOULD be rejected. +## Handling Unavailable Parent ECTs + +In distributed deployments, a parent ECT referenced in the "par" +array may not yet be available in the local ECT store at the time +of validation — for example, due to replication lag in a +distributed ledger or out-of-order message delivery. + +Implementations MUST distinguish between two cases: + +1. Parent not found and definitively absent: The parent "jti" + does not exist in any accessible ECT store. The ECT MUST be + rejected. + +2. Parent not yet available: The parent "jti" is not present + locally but may arrive due to known replication delays. + Implementations MAY defer validation for a bounded period + (RECOMMENDED: no more than 60 seconds). + +Deferred ECTs MUST NOT be treated as verified until all parent +references are resolved. If any parent reference remains +unresolved after the deferral period or after the ECT's own "exp" +time (whichever comes first), the ECT MUST be rejected. + # Signature and Token Verification {#verification} ## Verification Procedure @@ -579,8 +609,12 @@ verification steps in order: 2. Verify that the "typ" header parameter is "wimse-exec+jwt". -3. Verify that the "alg" header parameter is not "none" and is - not a symmetric algorithm. +3. Verify that the "alg" header parameter appears in the + verifier's configured allowlist of accepted signing algorithms. + The allowlist MUST NOT include "none" or any symmetric + algorithm (e.g., HS256, HS384, HS512). Implementations MUST + include ES256 in the allowlist; additional asymmetric algorithms + MAY be included per deployment policy. 4. Verify the "kid" header parameter references a known, valid public key from a WIT within the trust domain. @@ -746,6 +780,12 @@ Implementations MUST maintain a cache of recently-seen "jti" values to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected. +Additionally, each ECT is cryptographically bound to the issuing +agent via the JOSE "kid" parameter, which references the agent's +WIT public key. Verifiers MUST confirm that the "kid" resolves +to the "iss" agent's key (step 8 in {{verification}}), preventing +one agent from replaying another agent's ECT as its own. + ## Man-in-the-Middle Protection ECTs do not replace transport-layer security. ECTs MUST be @@ -780,7 +820,17 @@ ledger before revocation remain valid historical records but SHOULD be flagged in the ledger as "signed with subsequently revoked key" for audit purposes. -## Collusion and False Claims +ECT revocation does not propagate through the DAG. If a parent +ECT's signing key is later revoked, child ECTs that were verified +and recorded before that revocation remain valid — they captured +a legitimate execution record at the time of issuance. However, +auditors reviewing a workflow SHOULD flag any ECT in the DAG +whose signing key was subsequently revoked, so that the scope of +a potential compromise can be assessed. New ECTs MUST NOT be +created with a "par" reference to an ECT whose signing key is +known to be revoked at creation time. + +## Collusion and False Claims {#collusion-and-false-claims} A single malicious agent cannot forge parent task references because DAG validation requires parent tasks to exist in the @@ -796,6 +846,48 @@ Mitigations include: - Out-of-band audit: External auditors periodically verify ledger contents against expected workflow patterns. +## DAG Integrity Attacks + +Because the DAG structure is the primary mechanism for establishing +execution ordering, attackers may attempt to manipulate it: + +- False parent references: A malicious agent creates an ECT that + references parent tasks from an unrelated workflow, inserting + itself into a legitimate execution history. DAG validation + ({{dag-validation}}) mitigates this by requiring parent existence + in the ECT store, and the "wid" claim scopes parent references + to a single workflow when present. +- Parent omission (pruning): An agent deliberately omits one or + more actual parent dependencies from the "par" array to hide + that certain tasks influenced its output. Because ECTs are + self-asserted ({{self-assertion-limitation}}), no mechanism can + force an agent to declare all dependencies. External auditors + can detect omission by comparing the declared DAG against + expected workflow patterns. +- Shadow DAGs: Multiple colluding agents fabricate an entire + execution history by creating a sequence of ECTs with mutual + parent references. Independent ledger maintenance and + cross-verification (see {{collusion-and-false-claims}} above) + are the primary mitigations. + +Verifiers SHOULD validate that the declared "wid" of parent ECTs +matches the "wid" of the child ECT, rejecting cross-workflow +parent references unless explicitly permitted by deployment +policy. + +## Privilege Escalation via ECTs + +ECTs record execution history; they do not convey authorization. +Verifiers MUST NOT interpret the presence of an ECT, or a +particular set of parent references in "par", as an authorization +grant. The "par" claim demonstrates that predecessor tasks were +recorded, not that the current agent is authorized to act on +their outputs. Authorization decisions MUST remain with the +identity and authorization layer (WIT, WPT, and deployment +policy). As noted in {{I-D.ni-wimse-ai-agent-identity}}, +AI intermediaries introduce novel escalation vectors; ECTs +MUST NOT be used to circumvent authorization boundaries. + ## Denial of Service ECT signature verification is computationally inexpensive @@ -1087,6 +1179,9 @@ However, "req_wl" cannot form a DAG because: workloads that forward the token unchanged are not recorded. - It carries no task-level granularity, no parent references, and no execution content. +- It cannot represent convergence (fan-in): when two independent + paths must both complete before a dependent task proceeds, a + linear "req_wl" string cannot express that relationship. Extensions for agentic use cases ({{I-D.oauth-transaction-tokens-for-agents}}) add agent @@ -1120,6 +1215,19 @@ provide observability while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. +## W3C Provenance Data Model (PROV) +{:numbered="false"} + +The W3C PROV Data Model defines an Entity-Activity-Agent ontology +for representing provenance information. PROV's concepts map +closely to ECT structures: PROV Activities correspond to ECT +tasks, PROV Agents correspond to WIMSE workloads, and PROV's +"wasInformedBy" relation corresponds to ECT "par" references. +However, PROV uses RDF/OWL ontologies designed for post-hoc +documentation, while ECTs are runtime-embeddable JWT tokens with +cryptographic signatures. ECT audit data could be exported to +PROV format for interoperability with provenance-aware systems. + ## SCITT (Supply Chain Integrity, Transparency, and Trust) {:numbered="false"} diff --git a/draft-nennemann-wimse-ect-00.txt b/draft-nennemann-wimse-ect-00.txt index 6e8809e..9b7e1f7 100644 --- a/draft-nennemann-wimse-ect-00.txt +++ b/draft-nennemann-wimse-ect-00.txt @@ -77,35 +77,35 @@ Table of Contents 3. WIMSE Architecture Integration . . . . . . . . . . . . . . . 5 3.1. WIMSE Foundation . . . . . . . . . . . . . . . . . . . . 5 3.2. Extension Model . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Integration Points . . . . . . . . . . . . . . . . . . . 6 - 4. Execution Context Token Format . . . . . . . . . . . . . . . 7 + 3.3. Integration Points . . . . . . . . . . . . . . . . . . . 7 + 4. Execution Context Token Format . . . . . . . . . . . . . . . 8 4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 8 4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 10 4.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . 10 - 4.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 10 + 4.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 11 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 11 - 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 11 - 5.1. Execution-Context Header Field . . . . . . . . . . . . . 11 + 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Execution-Context Header Field . . . . . . . . . . . . . 12 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 12 - 7. Signature and Token Verification . . . . . . . . . . . . . . 13 - 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 13 + 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 13 + 6.3. Handling Unavailable Parent ECTs . . . . . . . . . . . . 13 + 7. Signature and Token Verification . . . . . . . . . . . . . . 14 + 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 14 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 15 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Self-Assertion Limitation . . . . . . . . . . . . . . . . 16 - 9.3. Organizational Prerequisites . . . . . . . . . . . . . . 16 - 9.4. Signature Verification . . . . . . . . . . . . . . . . . 16 + 9.3. Organizational Prerequisites . . . . . . . . . . . . . . 17 + 9.4. Signature Verification . . . . . . . . . . . . . . . . . 17 9.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 17 - 9.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 17 - 9.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 17 - 9.8. Collusion and False Claims . . . . . . . . . . . . . . . 18 - 9.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 18 - 9.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 18 - 9.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 19 + 9.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 18 + 9.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 18 + 9.8. Collusion and False Claims . . . . . . . . . . . . . . . 19 + 9.9. DAG Integrity Attacks . . . . . . . . . . . . . . . . . . 19 + 9.10. Privilege Escalation via ECTs . . . . . . . . . . . . . . 20 @@ -114,27 +114,31 @@ Nennemann Expires 29 August 2026 [Page 2] Internet-Draft WIMSE Execution Context February 2026 - 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 - 10.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 19 - 10.2. Data Minimization . . . . . . . . . . . . . . . . . . . 20 - 10.3. Storage and Access Control . . . . . . . . . . . . . . . 20 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Media Type Registration . . . . . . . . . . . . . . . . 20 - 11.2. HTTP Header Field Registration . . . . . . . . . . . . . 21 - 11.3. JWT Claims Registration . . . . . . . . . . . . . . . . 21 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 - 12.2. Informative References . . . . . . . . . . . . . . . . . 23 - Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - Cross-Organization Financial Trading . . . . . . . . . . . . . 25 - Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 26 - OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 26 - Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 26 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 27 - SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 27 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.11. Denial of Service . . . . . . . . . . . . . . . . . . . . 20 + 9.12. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 20 + 9.13. ECT Size Constraints . . . . . . . . . . . . . . . . . . 21 + 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 + 10.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 21 + 10.2. Data Minimization . . . . . . . . . . . . . . . . . . . 22 + 10.3. Storage and Access Control . . . . . . . . . . . . . . . 22 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 11.1. Media Type Registration . . . . . . . . . . . . . . . . 22 + 11.2. HTTP Header Field Registration . . . . . . . . . . . . . 23 + 11.3. JWT Claims Registration . . . . . . . . . . . . . . . . 23 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 12.2. Informative References . . . . . . . . . . . . . . . . . 25 + Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + Cross-Organization Financial Trading . . . . . . . . . . . . . 27 + Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 28 + OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 28 + Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 29 + Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 30 + W3C Provenance Data Model (PROV) . . . . . . . . . . . . . . . 30 + SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 30 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction @@ -156,10 +160,6 @@ Internet-Draft WIMSE Execution Context February 2026 healthcare, finance, and logistics require structured, auditable records of automated decision-making and execution. - This document defines an extension to the WIMSE architecture that - addresses the gap between workload identity and execution - accountability. WIMSE authenticates agents; this extension records - what they did and in what order. @@ -170,6 +170,11 @@ Nennemann Expires 29 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 + This document defines an extension to the WIMSE architecture that + addresses the gap between workload identity and execution + accountability. WIMSE authenticates agents; this extension records + what they did and in what order. + As identified in [I-D.ni-wimse-ai-agent-identity], call context in agentic workflows needs to be visible and preserved. ECTs provide a mechanism to address this requirement with cryptographic assurances. @@ -213,11 +218,6 @@ Internet-Draft WIMSE Execution Context February 2026 * Workload authentication and identity provisioning - * Key distribution and management - - * Trust domain establishment and management - - * Credential lifecycle management @@ -226,6 +226,12 @@ Nennemann Expires 29 August 2026 [Page 4] Internet-Draft WIMSE Execution Context February 2026 + * Key distribution and management + + * Trust domain establishment and management + + * Credential lifecycle management + 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -267,12 +273,6 @@ Internet-Draft WIMSE Execution Context February 2026 The WIMSE architecture [I-D.ietf-wimse-arch] defines: - * Workload Identity Tokens (WIT) that prove a workload's identity - within a trust domain ("I am Agent X in trust domain Y") - - * Workload Proof Tokens (WPT) that prove possession of the private - key associated with a WIT ("I control the key for Agent X") - @@ -282,6 +282,12 @@ Nennemann Expires 29 August 2026 [Page 5] Internet-Draft WIMSE Execution Context February 2026 + * Workload Identity Tokens (WIT) that prove a workload's identity + within a trust domain ("I am Agent X in trust domain Y") + + * Workload Proof Tokens (WPT) that prove possession of the private + key associated with a WIT ("I control the key for Agent X") + * Multi-hop authentication via the service-to-service protocol [I-D.ietf-wimse-s2s-protocol] @@ -325,12 +331,6 @@ Internet-Draft WIMSE Execution Context February 2026 using standard JWT extensibility [RFC7519], and maintains WIMSE concepts including trust domains and workload identifiers. -3.3. Integration Points - - An ECT integrates with the WIMSE identity framework through the - following mechanisms: - - Nennemann Expires 29 August 2026 [Page 6] @@ -338,6 +338,11 @@ Nennemann Expires 29 August 2026 [Page 6] Internet-Draft WIMSE Execution Context February 2026 +3.3. Integration Points + + An ECT integrates with the WIMSE identity framework through the + following mechanisms: + * The ECT JOSE header "kid" parameter MUST reference the public key identifier from the agent's WIT. @@ -376,12 +381,7 @@ Internet-Draft WIMSE Execution Context February 2026 3. Ledger (if deployed): Appends the verified ECT to the audit ledger. -4. Execution Context Token Format - An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed - as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use JWS Compact - Serialization (the base64url-encoded header.payload.signature format) - so that they can be carried in a single HTTP header value. @@ -394,6 +394,13 @@ Nennemann Expires 29 August 2026 [Page 7] Internet-Draft WIMSE Execution Context February 2026 +4. Execution Context Token Format + + An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed + as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use JWS Compact + Serialization (the base64url-encoded header.payload.signature format) + so that they can be carried in a single HTTP header value. + 4.1. JOSE Header The ECT JOSE header MUST contain the following parameters: @@ -432,6 +439,17 @@ Internet-Draft WIMSE Execution Context February 2026 ECT: iss: REQUIRED. StringOrURI. A URI identifying the issuer of the + + + + + + +Nennemann Expires 29 August 2026 [Page 8] + +Internet-Draft WIMSE Execution Context February 2026 + + ECT. In WIMSE deployments, this SHOULD be the workload's SPIFFE ID in the format spiffe:///, matching the "sub" claim of the agent's WIT. Non-WIMSE deployments MAY use @@ -443,13 +461,6 @@ Internet-Draft WIMSE Execution Context February 2026 identifiers of all entities that will verify the ECT. In practice this means: - - -Nennemann Expires 29 August 2026 [Page 8] - -Internet-Draft WIMSE Execution Context February 2026 - - * *Point-to-point delivery*: when an ECT is sent from one agent to a single next agent, "aud" contains that agent's workload identity. The receiving agent verifies the ECT and forwards it @@ -487,6 +498,14 @@ Internet-Draft WIMSE Execution Context February 2026 issuance. jti: REQUIRED. String. A globally unique identifier for both the + + + +Nennemann Expires 29 August 2026 [Page 9] + +Internet-Draft WIMSE Execution Context February 2026 + + ECT and the task it records, in UUID format [RFC9562]. Since each ECT represents exactly one task, "jti" serves as both the token identifier (for replay detection) and the task identifier (for DAG @@ -496,16 +515,6 @@ Internet-Draft WIMSE Execution Context February 2026 is absent, uniqueness MUST be enforced globally across the ECT store. - - - - - -Nennemann Expires 29 August 2026 [Page 9] - -Internet-Draft WIMSE Execution Context February 2026 - - 4.2.2. Execution Context The following claims are defined by this specification: @@ -526,33 +535,24 @@ Internet-Draft WIMSE Execution Context February 2026 root task with no dependencies. A workflow MAY contain multiple root tasks. Parent ECTs may have passed their own "exp" time; ECT expiration applies to the verification window of the ECT itself, - not to its validity as a parent reference in the ECT store. + not to its validity as a parent reference in the ECT store. Note: + "par" is not a registered JWT claim and does not conflict with + OAuth Pushed Authorization Requests (RFC 9126), which defines an + endpoint, not a token claim. 4.2.3. Data Integrity The following claims provide integrity verification for task inputs and outputs without revealing the data itself: - inp_hash: OPTIONAL. String. A cryptographic hash of the input - data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g., - "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash - algorithm identifier MUST be a lowercase value from the IANA Named - Information Hash Algorithm Registry (e.g., "sha-256", "sha-384", - "sha-512"). Implementations MUST support "sha-256" and SHOULD use - "sha-256" unless a stronger algorithm is required. - Implementations MUST NOT accept hash algorithms weaker than - SHA-256 (e.g., MD5, SHA-1). The hash MUST be computed over the - raw octets of the input data. + inp_hash: OPTIONAL. String. The base64url encoding (without + padding) of the SHA-256 hash of the input data, computed over the + raw octets of the input. This follows the same fixed-algorithm + pattern used by the DPoP "ath" claim [RFC9449] and the WIMSE WPT + "tth" claim [I-D.ietf-wimse-s2s-protocol]: SHA-256 is the + mandatory algorithm with no algorithm prefix in the value. - out_hash: OPTIONAL. String. A cryptographic hash of the output - data, using the same format and algorithm requirements as - "inp_hash". - -4.2.4. Extensions - - 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. + out_hash: OPTIONAL. String. The base64url encoding (without @@ -562,6 +562,18 @@ Nennemann Expires 29 August 2026 [Page 10] Internet-Draft WIMSE Execution Context February 2026 + padding) of the SHA-256 hash of the output data, using the same + format as "inp_hash". + +4.2.4. Extensions + + ext: OPTIONAL. Object. A general-purpose extension object for + domain-specific claims not defined by this specification. The + short name "ext" follows the JWT convention of concise claim names + and is chosen over alternatives like "extensions" for compactness. + Implementations that do not understand extension claims MUST + ignore them. + To avoid key collisions between different domains, extension key names SHOULD use reverse domain notation (e.g., "com.example.custom_field") to avoid collisions between independently @@ -589,12 +601,23 @@ Internet-Draft WIMSE Execution Context February 2026 "exec_act": "recommend_treatment", "par": [], - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + + "ext": { + "com.example.trace_id": "abc123" + } } Figure 4: Complete ECT Payload Example + + +Nennemann Expires 29 August 2026 [Page 11] + +Internet-Draft WIMSE Execution Context February 2026 + + 5. HTTP Header Transport 5.1. Execution-Context Header Field @@ -609,15 +632,6 @@ 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: - - - - -Nennemann Expires 29 August 2026 [Page 11] - -Internet-Draft WIMSE Execution Context February 2026 - - GET /api/safety-check HTTP/1.1 Host: safety-agent.example.com Workload-Identity: eyJhbGci...WIT... @@ -649,6 +663,17 @@ Internet-Draft WIMSE Execution Context February 2026 DAG validation is performed against the ECT store — either an audit ledger or the set of parent ECTs received inline. + + + + + + +Nennemann Expires 29 August 2026 [Page 12] + +Internet-Draft WIMSE Execution Context February 2026 + + 6.2. Validation Rules When receiving and verifying an ECT, implementations MUST perform the @@ -665,15 +690,6 @@ Internet-Draft WIMSE Execution Context February 2026 verified parent ECT). If any parent task is not found, the ECT MUST be rejected. - - - - -Nennemann Expires 29 August 2026 [Page 12] - -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). @@ -698,6 +714,35 @@ Internet-Draft WIMSE Execution Context February 2026 (RECOMMENDED: 10000 nodes). If the limit is reached before cycle detection completes, the ECT SHOULD be rejected. +6.3. Handling Unavailable Parent ECTs + + In distributed deployments, a parent ECT referenced in the "par" + array may not yet be available in the local ECT store at the time of + validation — for example, due to replication lag in a distributed + ledger or out-of-order message delivery. + + Implementations MUST distinguish between two cases: + + + +Nennemann Expires 29 August 2026 [Page 13] + +Internet-Draft WIMSE Execution Context February 2026 + + + 1. Parent not found and definitively absent: The parent "jti" does + not exist in any accessible ECT store. The ECT MUST be rejected. + + 2. Parent not yet available: The parent "jti" is not present locally + but may arrive due to known replication delays. Implementations + MAY defer validation for a bounded period (RECOMMENDED: no more + than 60 seconds). + + Deferred ECTs MUST NOT be treated as verified until all parent + references are resolved. If any parent reference remains unresolved + after the deferral period or after the ECT's own "exp" time + (whichever comes first), the ECT MUST be rejected. + 7. Signature and Token Verification 7.1. Verification Procedure @@ -710,8 +755,12 @@ Internet-Draft WIMSE Execution Context February 2026 2. Verify that the "typ" header parameter is "wimse-exec+jwt". - 3. Verify that the "alg" header parameter is not "none" and is not - a symmetric algorithm. + 3. Verify that the "alg" header parameter appears in the verifier's + configured allowlist of accepted signing algorithms. The + allowlist MUST NOT include "none" or any symmetric algorithm + (e.g., HS256, HS384, HS512). Implementations MUST include ES256 + in the allowlist; additional asymmetric algorithms MAY be + included per deployment policy. 4. Verify the "kid" header parameter references a known, valid public key from a WIT within the trust domain. @@ -719,17 +768,6 @@ Internet-Draft WIMSE Execution Context February 2026 5. Retrieve the public key identified by "kid" and verify the JWS signature per [RFC7515] Section 5.2. - - - - - - -Nennemann Expires 29 August 2026 [Page 13] - -Internet-Draft WIMSE Execution Context February 2026 - - 6. Verify that the signing key identified by "kid" has not been revoked within the trust domain. Implementations MUST check the key's revocation status using the trust domain's key lifecycle @@ -739,6 +777,15 @@ Internet-Draft WIMSE Execution Context February 2026 7. Verify the "alg" header parameter matches the algorithm in the corresponding WIT. + + + + +Nennemann Expires 29 August 2026 [Page 14] + +Internet-Draft WIMSE Execution Context February 2026 + + 8. Verify the "iss" claim matches the "sub" claim of the WIT associated with the "kid" public key. @@ -778,14 +825,6 @@ Internet-Draft WIMSE Execution Context February 2026 step failed. The receiving agent MUST NOT process the requested action when ECT verification fails. - - - -Nennemann Expires 29 August 2026 [Page 14] - -Internet-Draft WIMSE Execution Context February 2026 - - 8. Audit Ledger Interface ECTs MAY be recorded in an immutable audit ledger for compliance @@ -796,6 +835,13 @@ Internet-Draft WIMSE Execution Context February 2026 cryptographic commitment schemes, distributed ledgers, or any storage mechanism that provides the required properties. + + +Nennemann Expires 29 August 2026 [Page 15] + +Internet-Draft WIMSE Execution Context February 2026 + + When an audit ledger is deployed, the implementation MUST provide: 1. Append-only semantics: Once an ECT is recorded, it MUST NOT be @@ -835,13 +881,6 @@ Internet-Draft WIMSE Execution Context February 2026 * Time manipulator: An entity attempting to manipulate timestamps to alter perceived execution ordering. - - -Nennemann Expires 29 August 2026 [Page 15] - -Internet-Draft WIMSE Execution Context February 2026 - - 9.2. Self-Assertion Limitation ECTs are self-asserted by the executing agent. The agent claims what @@ -851,6 +890,14 @@ Internet-Draft WIMSE Execution Context February 2026 ECTs do not independently verify that: + + + +Nennemann Expires 29 August 2026 [Page 16] + +Internet-Draft WIMSE Execution Context February 2026 + + * The claimed execution actually occurred as described * The input/output hashes correspond to the actual data processed @@ -889,15 +936,6 @@ Internet-Draft WIMSE Execution Context February 2026 revoked, the ECT MUST be rejected entirely and the failure MUST be logged. - - - - -Nennemann Expires 29 August 2026 [Page 16] - -Internet-Draft WIMSE Execution Context February 2026 - - Implementations MUST use established JWS libraries and MUST NOT implement custom signature verification. @@ -909,6 +947,13 @@ Internet-Draft WIMSE Execution Context February 2026 rejected by Agent C. The "iat" claim enables receivers to reject ECTs that are too old, even if not yet expired. + + +Nennemann Expires 29 August 2026 [Page 17] + +Internet-Draft WIMSE Execution Context February 2026 + + The DAG structure provides additional replay protection: an ECT referencing parent tasks that already have a recorded child task with the same action can be flagged as a potential replay. @@ -917,6 +962,12 @@ Internet-Draft WIMSE Execution Context February 2026 to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected. + Additionally, each ECT is cryptographically bound to the issuing + agent via the JOSE "kid" parameter, which references the agent's WIT + public key. Verifiers MUST confirm that the "kid" resolves to the + "iss" agent's key (step 8 in Section 7), preventing one agent from + replaying another agent's ECT as its own. + 9.6. Man-in-the-Middle Protection ECTs do not replace transport-layer security. ECTs MUST be @@ -947,21 +998,33 @@ Internet-Draft WIMSE Execution Context February 2026 * Trust domains MUST support rapid key revocation. + * Upon suspected compromise, the trust domain MUST revoke the + compromised key and issue a new WIT with a fresh key pair. -Nennemann Expires 29 August 2026 [Page 17] + + + +Nennemann Expires 29 August 2026 [Page 18] Internet-Draft WIMSE Execution Context February 2026 - * Upon suspected compromise, the trust domain MUST revoke the - compromised key and issue a new WIT with a fresh key pair. - ECTs signed with a compromised key that were recorded in the ledger before revocation remain valid historical records but SHOULD be flagged in the ledger as "signed with subsequently revoked key" for audit purposes. + ECT revocation does not propagate through the DAG. If a parent ECT's + signing key is later revoked, child ECTs that were verified and + recorded before that revocation remain valid — they captured a + legitimate execution record at the time of issuance. However, + auditors reviewing a workflow SHOULD flag any ECT in the DAG whose + signing key was subsequently revoked, so that the scope of a + potential compromise can be assessed. New ECTs MUST NOT be created + with a "par" reference to an ECT whose signing key is known to be + revoked at creation time. + 9.8. Collusion and False Claims A single malicious agent cannot forge parent task references because @@ -980,7 +1043,56 @@ Internet-Draft WIMSE Execution Context February 2026 * Out-of-band audit: External auditors periodically verify ledger contents against expected workflow patterns. -9.9. Denial of Service +9.9. DAG Integrity Attacks + + Because the DAG structure is the primary mechanism for establishing + execution ordering, attackers may attempt to manipulate it: + + * False parent references: A malicious agent creates an ECT that + references parent tasks from an unrelated workflow, inserting + itself into a legitimate execution history. DAG validation + (Section 6) mitigates this by requiring parent existence in the + ECT store, and the "wid" claim scopes parent references to a + single workflow when present. + + * Parent omission (pruning): An agent deliberately omits one or more + actual parent dependencies from the "par" array to hide that + certain tasks influenced its output. Because ECTs are self- + + + +Nennemann Expires 29 August 2026 [Page 19] + +Internet-Draft WIMSE Execution Context February 2026 + + + asserted (Section 9.2), no mechanism can force an agent to declare + all dependencies. External auditors can detect omission by + comparing the declared DAG against expected workflow patterns. + + * Shadow DAGs: Multiple colluding agents fabricate an entire + execution history by creating a sequence of ECTs with mutual + parent references. Independent ledger maintenance and cross- + verification (see Section 9.8 above) are the primary mitigations. + + Verifiers SHOULD validate that the declared "wid" of parent ECTs + matches the "wid" of the child ECT, rejecting cross-workflow parent + references unless explicitly permitted by deployment policy. + +9.10. Privilege Escalation via ECTs + + ECTs record execution history; they do not convey authorization. + Verifiers MUST NOT interpret the presence of an ECT, or a particular + set of parent references in "par", as an authorization grant. The + "par" claim demonstrates that predecessor tasks were recorded, not + that the current agent is authorized to act on their outputs. + Authorization decisions MUST remain with the identity and + authorization layer (WIT, WPT, and deployment policy). As noted in + [I-D.ni-wimse-ai-agent-identity], AI intermediaries introduce novel + escalation vectors; ECTs MUST NOT be used to circumvent authorization + boundaries. + +9.11. Denial of Service ECT signature verification is computationally inexpensive (approximately 1ms per ECT on modern hardware for ES256). DAG @@ -993,7 +1105,7 @@ Internet-Draft WIMSE Execution Context February 2026 performed after signature verification to avoid wasting resources on unsigned or incorrectly signed tokens. -9.10. Timestamp Accuracy +9.12. Timestamp Accuracy ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock skew between agents can lead to incorrect ordering judgments. @@ -1005,7 +1117,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 18] +Nennemann Expires 29 August 2026 [Page 20] Internet-Draft WIMSE Execution Context February 2026 @@ -1019,7 +1131,7 @@ Internet-Draft WIMSE Execution Context February 2026 The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences between agents. -9.11. ECT Size Constraints +9.13. ECT Size Constraints ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a @@ -1061,7 +1173,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 19] +Nennemann Expires 29 August 2026 [Page 21] Internet-Draft WIMSE Execution Context February 2026 @@ -1117,7 +1229,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 20] +Nennemann Expires 29 August 2026 [Page 22] Internet-Draft WIMSE Execution Context February 2026 @@ -1173,7 +1285,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 21] +Nennemann Expires 29 August 2026 [Page 23] Internet-Draft WIMSE Execution Context February 2026 @@ -1229,7 +1341,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 22] +Nennemann Expires 29 August 2026 [Page 24] Internet-Draft WIMSE Execution Context February 2026 @@ -1285,7 +1397,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 23] +Nennemann Expires 29 August 2026 [Page 25] Internet-Draft WIMSE Execution Context February 2026 @@ -1323,6 +1435,11 @@ Internet-Draft WIMSE Execution Context February 2026 Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . + [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., + Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of + Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, + September 2023, . + [SPIFFE] "Secure Production Identity Framework for Everyone (SPIFFE)", . @@ -1332,20 +1449,19 @@ Use Cases This section describes a representative use case demonstrating how ECTs provide structured execution records. - Note: task identifiers in this section are abbreviated for - readability. In production, all "jti" values are required to be - UUIDs per Section 4.2.2. - - -Nennemann Expires 29 August 2026 [Page 24] +Nennemann Expires 29 August 2026 [Page 26] Internet-Draft WIMSE Execution Context February 2026 + Note: task identifiers in this section are abbreviated for + readability. In production, all "jti" values are required to be + UUIDs per Section 4.2.2. + Cross-Organization Financial Trading In a cross-organization trading workflow, an investment bank's agents @@ -1381,6 +1497,23 @@ Cross-Organization Financial Trading The resulting DAG: + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 27] + +Internet-Draft WIMSE Execution Context February 2026 + + task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating) [bank.example] [ratings.example] \ / @@ -1394,14 +1527,6 @@ Cross-Organization Financial Trading Figure 7: Cross-Organization DAG - - - -Nennemann Expires 29 August 2026 [Page 25] - -Internet-Draft WIMSE Execution Context February 2026 - - Task 003 has two parents from different trust domains, demonstrating cross-organizational fan-in. The compliance agent verifies both parent ECTs — one signed by a local key and one by a federated key @@ -1435,6 +1560,16 @@ 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." + + + + + +Nennemann Expires 29 August 2026 [Page 28] + +Internet-Draft WIMSE Execution Context February 2026 + + Transaction Tokens OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] @@ -1450,14 +1585,6 @@ Transaction Tokens downstream services, each receives the same "req_wl" value and the branching is invisible. - - - -Nennemann Expires 29 August 2026 [Page 26] - -Internet-Draft WIMSE Execution Context February 2026 - - * It is incomplete: only workloads that request a replacement token from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded. @@ -1465,6 +1592,10 @@ Internet-Draft WIMSE Execution Context February 2026 * It carries no task-level granularity, no parent references, and no execution content. + * It cannot represent convergence (fan-in): when two independent + paths must both complete before a dependent task proceeds, a + linear "req_wl" string cannot express that relationship. + Extensions for agentic use cases ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG @@ -1480,6 +1611,21 @@ Internet-Draft WIMSE Execution Context February 2026 Txn-Token; a similar binding mechanism for ECTs is a potential future extension. + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 29] + +Internet-Draft WIMSE Execution Context February 2026 + + Distributed Tracing (OpenTelemetry) OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems @@ -1494,6 +1640,18 @@ Distributed Tracing (OpenTelemetry) while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. +W3C Provenance Data Model (PROV) + + The W3C PROV Data Model defines an Entity-Activity-Agent ontology for + representing provenance information. PROV's concepts map closely to + ECT structures: PROV Activities correspond to ECT tasks, PROV Agents + correspond to WIMSE workloads, and PROV's "wasInformedBy" relation + corresponds to ECT "par" references. However, PROV uses RDF/OWL + ontologies designed for post-hoc documentation, while ECTs are + runtime-embeddable JWT tokens with cryptographic signatures. ECT + audit data could be exported to PROV format for interoperability with + provenance-aware systems. + SCITT (Supply Chain Integrity, Transparency, and Trust) The SCITT architecture [I-D.ietf-scitt-architecture] defines a @@ -1502,18 +1660,6 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) correlation identifier in SCITT Signed Statements, linking an ECT audit trail to a supply chain transparency record. - - - - - - - -Nennemann Expires 29 August 2026 [Page 27] - -Internet-Draft WIMSE Execution Context February 2026 - - Acknowledgments The author thanks the WIMSE working group for their foundational work @@ -1531,38 +1677,4 @@ Author's Address - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 28] +Nennemann Expires 29 August 2026 [Page 30] diff --git a/draft-nennemann-wimse-ect-00.xml b/draft-nennemann-wimse-ect-00.xml index 3bfa42b..367f565 100644 --- a/draft-nennemann-wimse-ect-00.xml +++ b/draft-nennemann-wimse-ect-00.xml @@ -25,14 +25,14 @@ - Security + ART WIMSE execution context workload identity agentic workflows audit trail - + This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) @@ -59,7 +59,7 @@ existing WIMSE headers. - +
    Introduction @@ -460,7 +460,9 @@ a root task with no dependencies. A workflow MAY contain multiple root tasks. Parent ECTs may have passed their own "exp" time; ECT expiration applies to the verification window of the ECT itself, not to its validity as a parent reference -in the ECT store. +in the ECT store. Note: "par" is not a registered JWT claim +and does not conflict with OAuth Pushed Authorization Requests +(RFC 9126), which defines an endpoint, not a token claim. @@ -473,21 +475,18 @@ inputs and outputs without revealing the data itself:
    inp_hash:
    - OPTIONAL. String. A cryptographic hash of the input data, -formatted as "hash-algorithm:base64url-encoded-hash" (e.g., -"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The -hash algorithm identifier MUST be a lowercase value from the -IANA Named Information Hash Algorithm Registry (e.g., "sha-256", -"sha-384", "sha-512"). Implementations MUST support "sha-256" -and SHOULD use "sha-256" unless a stronger algorithm is -required. Implementations MUST NOT accept hash algorithms -weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be -computed over the raw octets of the input data. + OPTIONAL. String. The base64url encoding (without padding) of +the SHA-256 hash of the input data, computed over the raw octets +of the input. This follows the same fixed-algorithm pattern +used by the DPoP "ath" claim and the WIMSE WPT +"tth" claim : SHA-256 is the +mandatory algorithm with no algorithm prefix in the value.
    out_hash:
    - OPTIONAL. String. A cryptographic hash of the output data, -using the same format and algorithm requirements as "inp_hash". + OPTIONAL. String. The base64url encoding (without padding) of +the SHA-256 hash of the output data, using the same format as +"inp_hash".
    @@ -497,9 +496,12 @@ using the same format and algorithm requirements as "inp_hash".
    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. + OPTIONAL. Object. A general-purpose extension object for +domain-specific claims not defined by this specification. The +short name "ext" follows the JWT convention of concise claim +names and is chosen over alternatives like "extensions" for +compactness. Implementations that do not understand extension +claims MUST ignore them.
    @@ -534,8 +536,12 @@ future documents. "exec_act": "recommend_treatment", "par": [], - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", + "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + + "ext": { + "com.example.trace_id": "abc123" + } } ]]> @@ -630,6 +636,31 @@ implementations SHOULD enforce a maximum ancestor traversal limit (RECOMMENDED: 10000 nodes). If the limit is reached before cycle detection completes, the ECT SHOULD be rejected. +
    +
    Handling Unavailable Parent ECTs + +In distributed deployments, a parent ECT referenced in the "par" +array may not yet be available in the local ECT store at the time +of validation — for example, due to replication lag in a +distributed ledger or out-of-order message delivery. + +Implementations MUST distinguish between two cases: + + + Parent not found and definitively absent: The parent "jti" +does not exist in any accessible ECT store. The ECT MUST be +rejected. + Parent not yet available: The parent "jti" is not present +locally but may arrive due to known replication delays. +Implementations MAY defer validation for a bounded period +(RECOMMENDED: no more than 60 seconds). + + +Deferred ECTs MUST NOT be treated as verified until all parent +references are resolved. If any parent reference remains +unresolved after the deferral period or after the ECT's own "exp" +time (whichever comes first), the ECT MUST be rejected. +
    Signature and Token Verification @@ -643,8 +674,12 @@ verification steps in order: Parse the JWS Compact Serialization to extract the JOSE header, payload, and signature components per . Verify that the "typ" header parameter is "wimse-exec+jwt". - Verify that the "alg" header parameter is not "none" and is -not a symmetric algorithm. + Verify that the "alg" header parameter appears in the +verifier's configured allowlist of accepted signing algorithms. +The allowlist MUST NOT include "none" or any symmetric +algorithm (e.g., HS256, HS384, HS512). Implementations MUST +include ES256 in the allowlist; additional asymmetric algorithms +MAY be included per deployment policy. Verify the "kid" header parameter references a known, valid public key from a WIT within the trust domain. Retrieve the public key identified by "kid" and verify the JWS @@ -812,6 +847,12 @@ with the same action can be flagged as a potential replay. values to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected. +Additionally, each ECT is cryptographically bound to the issuing +agent via the JOSE "kid" parameter, which references the agent's +WIT public key. Verifiers MUST confirm that the "kid" resolves +to the "iss" agent's key (step 8 in ), preventing +one agent from replaying another agent's ECT as its own. +
    Man-in-the-Middle Protection @@ -852,6 +893,16 @@ ledger before revocation remain valid historical records but SHOULD +ECT revocation does not propagate through the DAG. If a parent +ECT's signing key is later revoked, child ECTs that were verified +and recorded before that revocation remain valid — they captured +a legitimate execution record at the time of issuance. However, +auditors reviewing a workflow SHOULD flag any ECT in the DAG +whose signing key was subsequently revoked, so that the scope of +a potential compromise can be assessed. New ECTs MUST NOT be +created with a "par" reference to an ECT whose signing key is +known to be revoked at creation time. +
    Collusion and False Claims @@ -871,6 +922,52 @@ compared for consistency. contents against expected workflow patterns. +
    +
    DAG Integrity Attacks + +Because the DAG structure is the primary mechanism for establishing +execution ordering, attackers may attempt to manipulate it: + + + False parent references: A malicious agent creates an ECT that +references parent tasks from an unrelated workflow, inserting +itself into a legitimate execution history. DAG validation +() mitigates this by requiring parent existence +in the ECT store, and the "wid" claim scopes parent references +to a single workflow when present. + Parent omission (pruning): An agent deliberately omits one or +more actual parent dependencies from the "par" array to hide +that certain tasks influenced its output. Because ECTs are +self-asserted (), no mechanism can +force an agent to declare all dependencies. External auditors +can detect omission by comparing the declared DAG against +expected workflow patterns. + Shadow DAGs: Multiple colluding agents fabricate an entire +execution history by creating a sequence of ECTs with mutual +parent references. Independent ledger maintenance and +cross-verification (see above) +are the primary mitigations. + + +Verifiers SHOULD validate that the declared "wid" of parent ECTs +matches the "wid" of the child ECT, rejecting cross-workflow +parent references unless explicitly permitted by deployment +policy. + +
    +
    Privilege Escalation via ECTs + +ECTs record execution history; they do not convey authorization. +Verifiers MUST NOT interpret the presence of an ECT, or a +particular set of parent references in "par", as an authorization +grant. The "par" claim demonstrates that predecessor tasks were +recorded, not that the current agent is authorized to act on +their outputs. Authorization decisions MUST remain with the +identity and authorization layer (WIT, WPT, and deployment +policy). As noted in , +AI intermediaries introduce novel escalation vectors; ECTs +MUST NOT be used to circumvent authorization boundaries. +
    Denial of Service @@ -1432,6 +1529,23 @@ been incorporated into this document. This document obsoletes RFC + + + OAuth 2.0 Demonstrating Proof of Possession (DPoP) + + + + + + + + + This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. + + + + + @@ -1497,7 +1611,7 @@ been incorporated into this document. This document obsoletes RFC - +
    Use Cases @@ -1616,6 +1730,9 @@ token from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded. It carries no task-level granularity, no parent references, and no execution content. + It cannot represent convergence (fan-in): when two independent +paths must both complete before a dependent task proceeds, a +linear "req_wl" string cannot express that relationship. Extensions for agentic use cases @@ -1650,6 +1767,19 @@ provide observability while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. +
    +
    W3C Provenance Data Model (PROV) + +The W3C PROV Data Model defines an Entity-Activity-Agent ontology +for representing provenance information. PROV's concepts map +closely to ECT structures: PROV Activities correspond to ECT +tasks, PROV Agents correspond to WIMSE workloads, and PROV's +"wasInformedBy" relation corresponds to ECT "par" references. +However, PROV uses RDF/OWL ontologies designed for post-hoc +documentation, while ECTs are runtime-embeddable JWT tokens with +cryptographic signatures. ECT audit data could be exported to +PROV format for interoperability with provenance-aware systems. +
    SCITT (Supply Chain Integrity, Transparency, and Trust) @@ -1675,334 +1805,371 @@ tracing is built.