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>
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user