From 139a4e85e24c50dd41c829b09b9216242667dff2 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Fri, 6 Mar 2026 19:35:12 +0100 Subject: [PATCH] Rename 'par' claim to 'pred' and fix area to SEC Rename the 'par' (Parent Task Identifiers) JWT claim to 'pred' (Predecessor Task Identifiers) to avoid collision with RFC 9126 (Pushed Authorization Requests) which already registers 'par' in the IANA JWT Claims registry. Fix IETF area from ART to SEC since WIMSE is in the Security area. Co-Authored-By: Claude Opus 4.6 --- draft-nennemann-wimse-ect.md | 42 ++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/draft-nennemann-wimse-ect.md b/draft-nennemann-wimse-ect.md index 83d3b6b..e411037 100644 --- a/draft-nennemann-wimse-ect.md +++ b/draft-nennemann-wimse-ect.md @@ -7,7 +7,7 @@ submissiontype: IETF number: date: v: 3 -area: "ART" +area: "SEC" workgroup: "WIMSE" keyword: - execution context @@ -223,7 +223,7 @@ jti: : REQUIRED. String. A unique identifier for both the ECT and the task it records, in UUID format {{RFC9562}}. The "jti" serves as both the token identifier (for replay detection) and - the task identifier (for DAG parent references in "par"). + the task identifier (for DAG parent references in "pred"). Receivers MUST reject ECTs whose "jti" has already been seen within the expiration window. When "wid" is present, uniqueness is scoped to the workflow; when "wid" is absent, @@ -244,8 +244,8 @@ exec_act: "validate_safety"). This claim name avoids collision with the "act" (Actor) claim registered by {{RFC8693}}. -par: -: REQUIRED. Array of strings. Parent task identifiers +pred: +: REQUIRED. Array of strings. Predecessor task identifiers representing DAG dependencies. Each element MUST be the "jti" value of a previously verified ECT. An empty array indicates a root task with no dependencies. A workflow MAY contain @@ -295,7 +295,7 @@ envelope differs. "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789", "exec_act": "recommend_treatment", - "par": [], + "pred": [], "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", @@ -337,7 +337,7 @@ verification steps: 1. Parse the JSON object. 2. Verify that all required claims ("jti", "iat", "exp", - "exec_act", "par") are present and well-formed. + "exec_act", "pred") are present and well-formed. 3. Verify the "exp" claim indicates the ECT has not expired. @@ -487,7 +487,7 @@ verification steps in order: (RECOMMENDED: no more than 30 seconds ahead of the verifier's current time, to account for clock skew). -12. Verify all required claims ("jti", "exec_act", "par") are +12. Verify all required claims ("jti", "exec_act", "pred") are present and well-formed. 13. Perform DAG validation per {{dag-validation}}. @@ -781,7 +781,7 @@ subsequent ECT. # DAG Validation {#dag-validation} ECTs form a Directed Acyclic Graph (DAG) where each task -references its parent tasks via the "par" claim. DAG validation +references its parent tasks via the "pred" claim. DAG validation is performed against the ECT store — either an audit ledger or the set of parent ECTs received inline. @@ -795,7 +795,7 @@ the following DAG validation steps: entire ECT store if "wid" is absent). If an ECT with the same "jti" already exists, the ECT MUST be rejected. -2. Parent Existence: Every task identifier listed in the "par" +2. Parent Existence: Every task identifier listed in the "pred" array MUST correspond to a task that is available in the ECT store (either previously recorded in the ledger or received inline as a verified parent ECT). If any parent task is not @@ -1057,7 +1057,7 @@ A single malicious agent cannot forge parent task references because DAG validation requires parent tasks to exist in the ECT store. However, multiple colluding agents could create a false execution history. Additionally, a malicious agent may omit -actual parent dependencies from "par" to hide influences on its +actual parent dependencies from "pred" to hide influences on its output; because ECTs are self-asserted ({{self-assertion-limitation}}), no mechanism can force complete dependency declaration. @@ -1080,7 +1080,7 @@ policy. 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 +particular set of parent references in "pred", as an authorization grant. Authorization decisions MUST remain with the deployment's identity and authorization layer. @@ -1103,7 +1103,7 @@ higher tolerance and SHOULD document the configured value. ## ECT Size Constraints -Implementations SHOULD limit the "par" array to a maximum of +Implementations SHOULD limit the "pred" array to a maximum of 256 entries. See {{extension-claims}} for "ext" size limits. # Privacy Considerations @@ -1247,7 +1247,7 @@ the "JSON Web Token Claims" registry maintained by IANA: |:---:|:---|:---:|:---:| | wid | Workflow Identifier | IETF | {{exec-claims}} | | exec_act | Action/Task Type | IETF | {{exec-claims}} | -| par | Parent Task Identifiers | IETF | {{exec-claims}} | +| pred | Predecessor Task Identifiers | IETF | {{exec-claims}} | | inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} | | out_hash | Output Data Hash | IETF | {{data-integrity-claims}} | | ext | Extension Object | IETF | {{extension-claims}} | @@ -1282,24 +1282,24 @@ tamper-evident, auditable execution records. ~~~ Trust Domain: bank.example Agent A1 (Portfolio Risk): - jti: task-001 par: [] + jti: task-001 pred:[] iss: spiffe://bank.example/agent/risk exec_act: analyze_portfolio_risk Trust Domain: ratings.example (external) Agent B1 (Credit Rating): - jti: task-002 par: [] + jti: task-002 pred:[] iss: spiffe://ratings.example/agent/credit exec_act: assess_credit_rating Trust Domain: bank.example Agent A2 (Compliance): - jti: task-003 par: [task-001, task-002] + jti: task-003 pred:[task-001, task-002] iss: spiffe://bank.example/agent/compliance exec_act: verify_trade_compliance Agent A3 (Execution): - jti: task-004 par: [task-003] + jti: task-004 pred:[task-003] iss: spiffe://bank.example/agent/execution exec_act: execute_trade ~~~ @@ -1341,15 +1341,15 @@ cryptographic signing is not justified. ~~~ Trust Domain: internal.example Agent S1 (Preprocessor): - jti: task-101 par: [] + jti: task-101 pred:[] exec_act: preprocess_input Agent S2 (Model Inference): - jti: task-102 par: [task-101] + jti: task-102 pred:[task-101] exec_act: run_inference Agent S3 (Postprocessor): - jti: task-103 par: [task-102] + jti: task-103 pred:[task-102] exec_act: format_output ~~~ {: #fig-internal title="Internal Microservice Workflow (L1)"} @@ -1452,7 +1452,7 @@ 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 ECT-issuing agents, and PROV's -"wasInformedBy" relation corresponds to ECT "par" references. +"wasInformedBy" relation corresponds to ECT "pred" 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