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 <noreply@anthropic.com>

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:
+pred:
-: REQUIRED.  Array of strings.  Parent task identifiers
+: 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