c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: polish draft-01 for submission — claim renames, review fixes, refimpl docs

Browse Source 
Draft improvements:
- Rename ext -> ect_ext, clarify iss/aud requirements per level
- Add algorithm agility guidance and RFC 8725 reference
- Add HTTP header size constraints and body transport fallback
- Add cross-level parent reference semantics
- Add emerging agent protocols (A2A, MCP) to Related Work
- Fix HTTP error handling (403 not 401), IANA +jwt suffix note
- Add workflow consistency check to DAG validation
- Add defense-in-depth note for acyclicity check

Supporting files:
- Fix blog post outdated claim names (par -> pred, ext -> ect_ext)
- Update refimpl README with -00 vs -01 migration mapping
- Add refimpl IMPROVEMENTS.md section 6 with -01 migration tasks
This commit is contained in:
Christian Nennemann
2026-04-03 07:49:36 +02:00
parent bd2a5f819a
commit 8cf0d8aade
4 changed files with 163 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
blog-ect-assurance-levels.md
View File

@@ -19,7 +19,7 @@ ECTs originated as an extension to the IETF WIMSE (Workload Identity in Multi-Sy
The key properties:
- **Per-task granularity.** One ECT per task, not one per session or per request chain.
- **DAG ordering.** Parent references (`par` claim) create a verifiable execution graph. Fan-out, fan-in, parallel branches — all representable.
- **DAG ordering.** Parent references (`pred` claim) create a verifiable execution graph. Fan-out, fan-in, parallel branches — all representable.
- **Data integrity without data exposure.** Input and output hashes (`inp_hash`, `out_hash`) prove what was processed without revealing the data itself.
- **Identity-framework agnostic.** ECTs work with WIMSE WIT/WPT, X.509 certificates, OAuth credentials, or plain JWK sets. The spec defines abstract identity binding requirements and concrete profiles for each framework.
@@ -121,7 +121,7 @@ A single deployment can use different levels for different workflows. Your inter
## The Upgrade Path
This is arguably the most important design property of the assurance levels: **the payload is the same at every level.** The same `jti`, `iss`, `aud`, `iat`, `exp`, `exec_act`, `par`, `inp_hash`, `out_hash`, and `ext` claims appear in every ECT, whether it's unsigned JSON or a ledger-committed JWS token.
This is arguably the most important design property of the assurance levels: **the payload is the same at every level.** The same `jti`, `iss`, `aud`, `iat`, `exp`, `exec_act`, `pred`, `inp_hash`, `out_hash`, and `ect_ext` claims appear in every ECT, whether it's unsigned JSON or a ledger-committed JWS token.
What changes is the envelope and the verification procedure. This means upgrading from L1 to L2 means adding a JWS wrapper around the same payload. Upgrading from L2 to L3 means deploying an audit ledger and adding the ledger recording step after JWS verification.