commit ea188f1c22a6911dbdca25b406dd3b9607d6e2a0 Author: Christian Nennemann Date: Tue Feb 24 22:51:22 2026 +0100 Add CBOR/COSE/CWT serialization of WIMSE Execution Context Tokens Companion I-D to draft-nennemann-wimse-execution-context defining ECT semantics mapped to CBOR encoding, COSE_Sign1 signing, and CWT claims for constrained devices and non-HTTP transports (CoAP, MQTT, raw binary). Aligned with JWT draft changes: jti/cti as unified token+task ID (no separate tid), pol/pol_decision optional but paired. Co-Authored-By: Claude Opus 4.6 diff --git a/cbor-variant/README.md b/cbor-variant/README.md new file mode 100644 index 0000000..0026569 --- /dev/null +++ b/cbor-variant/README.md @@ -0,0 +1,63 @@ +# CBOR Serialization of Execution Context Tokens (ECT-CBOR) + +**draft-nennemann-wimse-execution-context-cbor-00** + +This Internet-Draft defines a CBOR/COSE/CWT serialization of Execution Context Tokens (ECTs) for the WIMSE working group. + +## Relationship to the JWT Draft + +This document is a **companion** to [draft-nennemann-wimse-execution-context](https://datatracker.ietf.org/doc/draft-nennemann-wimse-execution-context/), which defines the full ECT semantics using JSON/JOSE/JWT serialization. + +- **JWT draft**: Normative semantic definition (claims, DAG validation, verification, operational modes, security model) +- **CBOR draft** (this document): CBOR/COSE/CWT serialization mapping, constrained-environment transports (CoAP, MQTT, raw binary) + +The two drafts are designed for **independent adoption**: a deployment uses one or the other (or both in mixed-format mode), not both simultaneously for the same token. + +## Files + +| File | Description | +|------|-------------| +| `draft-nennemann-wimse-execution-context-cbor-00.md` | The complete Internet-Draft in kramdown-rfc format | +| `claim-mapping.md` | Standalone claim mapping reference table | +| `README.md` | This file | + +## Building + +### Prerequisites + +- [kramdown-rfc](https://github.com/cabo/kramdown-rfc) (Ruby gem) +- [xml2rfc](https://xml2rfc.tools.ietf.org/) (Python package) + +### Build Commands + +```bash +# Install tools (if not already installed) +gem install kramdown-rfc +pip install xml2rfc + +# Generate XML from kramdown +kramdown-rfc2629 draft-nennemann-wimse-execution-context-cbor-00.md > draft-nennemann-wimse-execution-context-cbor-00.xml + +# Generate text output +xml2rfc draft-nennemann-wimse-execution-context-cbor-00.xml --text + +# Generate HTML output +xml2rfc draft-nennemann-wimse-execution-context-cbor-00.xml --html +``` + +## Key Design Decisions + +1. **UUIDs as 16-byte binary** instead of 36-byte hyphenated text (saves 20 bytes per UUID) +2. **`jti`/`cti` as unified token+task ID** — no separate `tid` claim (matching JWT draft) +3. **`pol`/`pol_decision` OPTIONAL** but must be paired (matching JWT draft) +4. **Integer claim keys** (300-316) instead of string claim names +5. **Structured hash arrays** `[alg_id, hash_bytes]` instead of `"algorithm:base64url"` strings +6. **Integer enumerations** for pol_decision (0/1/2) and regulated_domain (0/1/2) +7. **COSE_Sign1** (single signer) matching the JWT variant's JWS Compact Serialization model +8. **~2.8x size reduction** compared to JWT variant (~365 bytes vs ~1006 bytes for a typical ECT) + +## Author + +Christian Nennemann +Independent Researcher +ietf@nennemann.de diff --git a/cbor-variant/claim-mapping.md b/cbor-variant/claim-mapping.md new file mode 100644 index 0000000..5428763 --- /dev/null +++ b/cbor-variant/claim-mapping.md @@ -0,0 +1,111 @@ +# ECT Claim Mapping: JWT to CWT + +This document provides a standalone reference for mapping JWT claim names from [draft-nennemann-wimse-execution-context](https://datatracker.ietf.org/doc/draft-nennemann-wimse-execution-context/) to CWT integer keys defined in [draft-nennemann-wimse-execution-context-cbor](https://datatracker.ietf.org/doc/draft-nennemann-wimse-execution-context-cbor/). + +## Standard CWT Claims (Existing IANA Registry) + +| JWT Claim | CWT Key | CBOR Type | Req/Opt | Description | Encoding Notes | +|:---:|:---:|:---|:---:|:---|:---| +| iss | 1 | tstr | REQ | Issuer (SPIFFE ID) | Identical text | +| sub | 2 | tstr | OPT | Subject (= iss) | Identical text | +| aud | 3 | tstr / [+ tstr] | REQ | Audience | Identical text; array for multi-audience | +| exp | 4 | int | REQ | Expiration | Integer epoch seconds (no fractions) | +| iat | 6 | int | REQ | Issued At | Integer epoch seconds (no fractions) | +| jti / cti | 7 | bstr .size 16 | REQ | Token ID / Task ID | UUID as 16-byte binary (not 36-byte text); serves as both token and task identifier | + +**Note**: nbf (CWT key 5) is not used in ECTs. The `jti`/`cti` claim serves as both the token identifier (for replay detection) and the task identifier (for DAG parent references in `par`), since each ECT records exactly one task. + +## ECT-Specific Claims (New Registrations) + +| JWT Claim | CWT Key | CBOR Type | Req/Opt | Description | Encoding Notes | +|:---|:---:|:---|:---:|:---|:---| +| wid | 300 | bstr .size 16 | OPT | Workflow ID | UUID as 16-byte binary | +| exec_act | 301 | tstr | REQ | Action/task type | Identical text | +| par | 302 | [* bstr .size 16] | REQ | Parent ECT IDs | Array of parent cti UUIDs (16-byte binary); empty = root | +| pol | 303 | tstr | OPT | Policy rule ID | Identical text; must be paired with pol_decision | +| pol_decision | 304 | uint (0..2) | OPT | Policy decision | 0=approved, 1=rejected, 2=pending_human_review; must be paired with pol | +| pol_enforcer | 305 | tstr | OPT | Policy enforcer | Identical text (SPIFFE ID) | +| pol_timestamp | 306 | int | OPT | Policy timestamp | Integer epoch seconds | +| inp_hash | 307 | [int, bstr] | OPT | Input data hash | [COSE_alg_id, raw_hash_bytes] | +| out_hash | 308 | [int, bstr] | OPT | Output data hash | [COSE_alg_id, raw_hash_bytes] | +| inp_classification | 309 | tstr | OPT | Input classification | Identical text | +| exec_time_ms | 310 | uint | OPT | Execution time (ms) | Identical integer | +| regulated_domain | 311 | uint (0..2) | OPT | Regulatory domain | 0=medtech, 1=finance, 2=military | +| model_version | 312 | tstr | OPT | AI/ML model version | Identical text | +| witnessed_by | 313 | [+ tstr] | OPT | Witness identities | Identical text array (SPIFFE IDs) | +| compensation_required | 314 | bool | OPT | Compensation flag | CBOR true/false | +| compensation_reason | 315 | tstr | OPT | Compensation reason | Identical text | +| ext | 316 | map { tstr => any } | OPT | Extension map | Keys: reverse domain notation; values: any CBOR | + +## Enumeration Mappings + +### Policy Decision Values (pol_decision) + +| CBOR uint | JWT string | Description | +|:---:|:---|:---| +| 0 | "approved" | Policy evaluation succeeded | +| 1 | "rejected" | Policy evaluation failed | +| 2 | "pending_human_review" | Awaiting human judgment | + +### Regulated Domain Values (regulated_domain) + +| CBOR uint | JWT string | Description | +|:---:|:---|:---| +| 0 | "medtech" | Medical technology and devices | +| 1 | "finance" | Financial services and trading | +| 2 | "military" | Military and defense | + +## Hash Algorithm Mapping + +JWT ECTs use the string format `"algorithm:base64url-hash"`. CBOR ECTs use the structured array `[cose_algorithm_id, raw_hash_bytes]`. + +| JWT Hash Algorithm String | COSE Algorithm ID | Reference | +|:---|:---:|:---| +| sha-256 | -16 | RFC 9053 | +| sha-384 | -43 | RFC 9053 | +| sha-512 | -44 | RFC 9053 | + +## COSE Header Parameters + +| JOSE Parameter | COSE Label | CBOR Type | Description | +|:---|:---:|:---|:---| +| alg | 1 | int | Signature algorithm (e.g., -7 = ES256) | +| (content type) | 3 | tstr / uint | "application/wimse-exec+cwt" | +| kid | 4 | bstr | Key identifier from WIT | +| typ | 16 | tstr | "wimse-exec+cwt" | + +## Quick Reference: JWT Example to CBOR Diagnostic + +### JWT Payload + +```json +{ + "iss": "spiffe://example.com/agent/clinical", + "aud": "spiffe://example.com/agent/safety", + "iat": 1772064150, + "exp": 1772064750, + "jti": "550e8400-e29b-41d4-a716-446655440001", + "exec_act": "recommend_treatment", + "par": [], + "pol": "clinical_reasoning_policy_v2", + "pol_decision": "approved", + "regulated_domain": "medtech" +} +``` + +### Equivalent CBOR Diagnostic + +``` +{ + 1: "spiffe://example.com/agent/clinical", + 3: "spiffe://example.com/agent/safety", + 6: 1772064150, + 4: 1772064750, + 7: h'550e8400e29b41d4a716446655440001', + 301: "recommend_treatment", + 302: [], + 303: "clinical_reasoning_policy_v2", + 304: 0, + 311: 0 +} +``` diff --git a/cbor-variant/draft-nennemann-wimse-execution-context-cbor-00.md b/cbor-variant/draft-nennemann-wimse-execution-context-cbor-00.md new file mode 100644 index 0000000..3275d55 --- /dev/null +++ b/cbor-variant/draft-nennemann-wimse-execution-context-cbor-00.md @@ -0,0 +1,1339 @@ +--- +title: "CBOR Serialization of Execution Context Tokens for Distributed Agentic Workflows" +abbrev: "WIMSE ECT-CBOR" +category: std +docname: draft-nennemann-wimse-execution-context-cbor-00 +submissiontype: IETF +number: +date: +v: 3 +area: "Security" +workgroup: "WIMSE" +keyword: + - execution context + - workload identity + - agentic workflows + - CBOR + - COSE + - CWT + - constrained environments + - audit trail + - compliance + +author: + - + fullname: Christian Nennemann + organization: Independent Researcher + email: ietf@nennemann.de + +normative: + RFC8392: + RFC8610: + RFC8949: + RFC9052: + RFC9053: + RFC9338: + RFC9562: + RFC9596: + I-D.ietf-wimse-arch: + I-D.ietf-wimse-s2s-protocol: + I-D.nennemann-wimse-execution-context: + title: "Execution Context Tokens for Distributed Agentic Workflows" + target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-execution-context/ + date: 2026-02 + author: + - name: Christian Nennemann + org: Independent Researcher + +informative: + RFC3552: + RFC7252: + RFC8126: + RFC8613: + RFC9110: + RFC9147: + RFC9421: + RFC9528: + I-D.ni-wimse-ai-agent-identity: + I-D.ietf-scitt-architecture: + I-D.ietf-suit-manifest: + SPIFFE: + title: "Secure Production Identity Framework for Everyone (SPIFFE)" + target: https://spiffe.io/docs/latest/spiffe-about/overview/ + date: false + EU-AI-ACT: + title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)" + target: https://eur-lex.europa.eu/eli/reg/2024/1689 + date: 2024-06-13 + author: + - org: European Parliament and Council of the European Union + FDA-21CFR11: + title: "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures" + target: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 + date: false + author: + - org: U.S. Food and Drug Administration + DORA: + title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)" + target: https://eur-lex.europa.eu/eli/reg/2022/2554 + date: 2022-12-14 + author: + - org: European Parliament and Council of the European Union + EU-MDR: + title: "Regulation (EU) 2017/745 on medical devices (MDR)" + target: https://eur-lex.europa.eu/eli/reg/2017/745 + date: 2017-04-05 + author: + - org: European Parliament and Council of the European Union + MQTT: + title: "MQTT Version 5.0" + target: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html + date: 2019-03-07 + author: + - org: OASIS + EAT: + title: "The Entity Attestation Token (EAT)" + target: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ + date: false + author: + - name: Laurence Lundblade + - name: Giridhar Mandyam + - name: Jeremy O'Donoghue + - name: Carl Wallace + +--- abstract + +This document defines a CBOR/COSE/CWT serialization of Execution +Context Tokens (ECTs) for distributed agentic workflows in regulated +environments. The companion document, +draft-nennemann-wimse-execution-context, defines the full ECT +semantics using JSON/JOSE/JWT serialization. This specification +maps those semantics to CBOR (RFC 8949) encoding, COSE +(RFC 9052) signing structures, and CWT (RFC 8392) claims, +targeting constrained devices, non-HTTP transports (CoAP, MQTT, +Layer 2 protocols), and bandwidth-sensitive deployments. The CBOR +serialization preserves all ECT semantics including DAG-structured +task dependency ordering, policy evaluation recording, and +compliance state tracking while using COSE_Sign1 signatures and +integer-keyed CWT claims for compact representation. + +--- middle + +# Introduction + +## Motivation + +The companion specification +{{I-D.nennemann-wimse-execution-context}} defines Execution Context +Tokens (ECTs) as an extension to the WIMSE architecture +{{I-D.ietf-wimse-arch}} for recording task execution, DAG-structured +dependency ordering, and policy evaluation outcomes in regulated +agentic workflows. That specification uses JSON Web Tokens (JWT) +with JSON Object Signing and Encryption (JOSE) serialization, which +is well suited for HTTP-based deployments. + +However, many deployment scenarios require a more compact +serialization: + +- **Constrained IoT agents**: Medical devices, industrial + controllers, and edge computing nodes operating under tight memory + and bandwidth budgets benefit from binary encoding. + +- **Non-HTTP transports**: Agent-to-agent communication over CoAP + {{RFC7252}}, MQTT {{MQTT}}, or Layer 2 protocols cannot efficiently + carry JSON-encoded tokens. + +- **Bandwidth-sensitive environments**: Satellite links, low-power + wide-area networks, and cellular IoT backhaul incur significant + cost per byte. + +CBOR {{RFC8949}} provides a binary encoding that is substantially +more compact than JSON for the same semantic content. COSE +{{RFC9052}} provides equivalent signing and encryption operations to +JOSE. CWT {{RFC8392}} provides a CBOR-based claim structure +equivalent to JWT. Together, these standards enable a CBOR-native +ECT serialization that achieves approximately 3x size reduction +compared to the JWT variant while preserving identical semantics. + +## Scope + +This document defines **only** the CBOR/COSE/CWT serialization +mapping for ECTs. The following are defined in the companion JWT +specification {{I-D.nennemann-wimse-execution-context}} and apply +identically to CBOR-serialized ECTs: + +- ECT claim semantics and processing rules +- DAG validation algorithm (parent existence, temporal ordering, + cycle detection, policy decision propagation, trust domain + consistency) +- Verification procedure (all 15 steps, adapted for COSE in + {{verification}}) +- Operational modes (point-to-point, deferred ledger, full ledger) +- Audit ledger interface requirements +- Security model and threat analysis +- Privacy considerations + +Implementers MUST read the companion JWT specification for the +complete semantic definition. This document covers: + +- COSE header parameter mapping ({{cose-header}}) +- CWT claim key assignments ({{claim-mapping}}) +- CDDL schema for ECT-CBOR payloads ({{cddl-schema}}) +- COSE_Sign1 structure ({{cose-structure}}) +- Transport mechanisms for CoAP, MQTT, HTTP, and raw binary + ({{transport}}) +- COSE-specific verification steps ({{verification}}) +- Size comparison with the JWT variant ({{size-comparison}}) + +## Terminology + +This document reuses all terminology defined in +{{I-D.nennemann-wimse-execution-context}} Section 2. Additionally: + +CWT: +: CBOR Web Token {{RFC8392}}, the CBOR equivalent of JWT. + +COSE: +: CBOR Object Signing and Encryption {{RFC9052}}, the CBOR + equivalent of JOSE. + +COSE_Sign1: +: A COSE structure for a message with a single signer + {{RFC9052}} Section 4.2. + +CDDL: +: Concise Data Definition Language {{RFC8610}}, used to define + CBOR data structures. + +# Conventions and Definitions + +{::boilerplate bcp14-tagged} + +# COSE Header Parameters {#cose-header} + +The COSE protected header for an ECT-CBOR token MUST contain the +following parameters: + +alg (label 1): +: REQUIRED. The COSE algorithm identifier for the digital + signature. Implementations MUST support ES256 (COSE algorithm + identifier -7) {{RFC9053}}. The algorithm MUST be an asymmetric + signature algorithm. Symmetric MAC algorithms MUST NOT be used, + as ECTs require asymmetric signatures for non-repudiation. The + algorithm MUST match the algorithm in the agent's corresponding + WIT. + +content type (label 3): +: REQUIRED. MUST be set to the string "application/wimse-exec+cwt" + or the equivalent CoAP Content-Format number once assigned. + Identifies the payload as a CBOR-serialized ECT. + +kid (label 4): +: REQUIRED. Key identifier referencing the public key from the + agent's WIT. Encoded as bstr. Used by verifiers to look up the + correct public key for signature verification. + +typ (label 16): +: REQUIRED. MUST be set to "wimse-exec+cwt". Distinguishes + ECT-CBOR tokens from other CWT types, per {{RFC9596}}. + +ECTs MUST use the COSE_Sign1 structure (single signer) defined in +{{RFC9052}} Section 4.2. The COSE_Sign (multi-signer) structure +MUST NOT be used, consistent with the single-agent-signs model of +the JWT variant. + +The unprotected header bucket MUST be empty. All header parameters +MUST be placed in the protected header to ensure integrity +protection. + +Example protected header in CBOR diagnostic notation: + +~~~cbor-diag +{ + / alg / 1: -7, / ES256 / + / content type / 3: "application/wimse-exec+cwt", + / kid / 4: h'6167656e742d612d6b65792d323032362d3032', + / typ / 16: "wimse-exec+cwt" +} +~~~ +{: #fig-cose-header title="ECT COSE Protected Header Example"} + +# CWT Claim Mapping {#claim-mapping} + +This section defines the complete mapping from JWT claim names used +in {{I-D.nennemann-wimse-execution-context}} to CBOR integer keys +used in the CWT payload. + +## Standard CWT Claims + +The following claims reuse existing CWT claim keys from the IANA +"CBOR Web Token (CWT) Claims" registry {{RFC8392}}: + +| JWT Claim | CWT Key | CBOR Type | Description | +|:---:|:---:|:---|:---| +| iss | 1 | tstr | Issuer (SPIFFE ID) | +| sub | 2 | tstr | Subject (MUST equal iss when present) | +| aud | 3 | tstr / \[+ tstr\] | Audience | +| exp | 4 | int | Expiration (epoch seconds) | +| iat | 6 | int | Issued At (epoch seconds) | +| cti | 7 | bstr .size 16 | CWT ID / Task ID (UUID as 16-byte binary) | +{: #table-standard-claims title="Standard CWT Claim Mapping"} + +The nbf (Not Before) claim (CWT key 5) is not used in ECTs, as ECTs +record completed actions. + +### CWT ID Encoding {#cti-encoding} + +The CWT ID (cti, key 7) is the CWT equivalent of the JWT jti claim. +In the companion JWT specification, jti serves as both the token +identifier (for replay detection) and the task identifier (for DAG +parent references in par). Since each ECT represents exactly one +task, a separate task identifier is not needed. + +In the CBOR variant, cti MUST be encoded as a 16-byte binary string +containing the UUID in network byte order per {{RFC9562}} Section 4. +This saves 20 bytes per token. When wid is present, uniqueness of +cti is scoped to the workflow; when wid is absent, uniqueness MUST +be enforced globally across the ECT store. + +Implementations MAY additionally apply CBOR tag 37 to explicitly +mark the value as a UUID. + +### Timestamp Encoding + +Timestamps (exp key 4, iat key 6) use the CWT NumericDate format: +integer seconds since the Unix epoch (1970-01-01T00:00:00Z). This +is semantically identical to JWT NumericDate but without fractional +seconds. Implementations MAY use CBOR tag 1 (epoch-based date/time) +to explicitly tag timestamp values. + +## ECT-Specific Claims {#ect-claims} + +The following claim keys are defined by this specification for +ECT-specific claims. These keys are requested for registration in +the "CBOR Web Token (CWT) Claims" registry (see {{iana}}). + +| JWT Claim | CWT Key | CBOR Type | Req/Opt | Description | +|:---|:---:|:---|:---:|:---| +| wid | 300 | bstr .size 16 | OPT | Workflow ID (UUID binary) | +| exec_act | 301 | tstr | REQ | Action/task type identifier | +| par | 302 | \[* bstr .size 16\] | REQ | Parent ECT cti UUIDs | +| pol | 303 | tstr | OPT | Policy rule identifier | +| pol_decision | 304 | uint | OPT | Policy decision enum | +| pol_enforcer | 305 | tstr | OPT | Policy enforcer identity | +| pol_timestamp | 306 | int | OPT | Policy decision timestamp | +| inp_hash | 307 | \[int, bstr\] | OPT | Input hash \[alg_id, hash\] | +| out_hash | 308 | \[int, bstr\] | OPT | Output hash \[alg_id, hash\] | +| inp_classification | 309 | tstr | OPT | Input data classification | +| exec_time_ms | 310 | uint | OPT | Execution duration (ms) | +| regulated_domain | 311 | uint | OPT | Regulatory domain enum | +| model_version | 312 | tstr | OPT | AI/ML model version | +| witnessed_by | 313 | \[+ tstr\] | OPT | Witness SPIFFE IDs | +| compensation_required | 314 | bool | OPT | Compensation flag | +| compensation_reason | 315 | tstr | OPT | Compensation reason ID | +| ext | 316 | map | OPT | Extension map | +{: #table-ect-claims title="ECT-Specific CWT Claim Mapping"} + +The Req/Opt column indicates whether the claim is REQUIRED or +OPTIONAL, matching the designations in +{{I-D.nennemann-wimse-execution-context}}. + +The pol (key 303) and pol_decision (key 304) claims are OPTIONAL but +MUST be paired: if one is present, the other MUST also be present. +When both are absent, the ECT records task execution without a +policy checkpoint. Regulated deployments SHOULD include policy +claims on all ECTs to maintain complete audit trails. + +The par claim (key 302) contains the cti values of previously +verified parent ECTs. Since cti serves as both the token identifier +and the task identifier, par entries reference cti values directly. + +## Design Decisions + +### UUIDs as Binary {#uuid-binary} + +In the JWT variant, UUIDs (jti, wid, par entries) are encoded as +hyphenated text strings (e.g., "550e8400-e29b-41d4-a716- +446655440001"), consuming 36 bytes per UUID. In the CBOR variant, +UUIDs MUST be encoded as 16-byte binary strings (bstr .size 16) in +network byte order per {{RFC9562}} Section 4. This saves 20 bytes +per UUID. + +For the par claim (key 302), each entry is the cti (16-byte binary +UUID) of a previously verified parent ECT. An empty par array +indicates a root task, identical to the JWT variant semantics. + +Implementations MAY use CBOR tag 37 ({{RFC9562}}) to explicitly tag +UUID values. Receivers MUST accept UUID values both with and +without tag 37. + +### Hash Encoding {#hash-encoding} + +In the JWT variant, hash values use the string format +"algorithm:base64url-encoded-hash" (e.g., +"sha-256:n4bQgYhM..."). In the CBOR variant, hash values +(inp_hash key 307, out_hash key 308) use a structured two-element +CBOR array: + +~~~cbor-diag +[hash_algorithm_id, hash_bytes] +~~~ + +Where: + +- hash_algorithm_id is the integer algorithm identifier from the + IANA "COSE Algorithms" registry. For SHA-256, this is -16. + +- hash_bytes is the raw hash value as a binary string (bstr). + +This structured encoding is more compact (no base64url overhead) +and type-safe (integer algorithm identifiers prevent string +parsing ambiguity). + +Example (SHA-256 hash): + +~~~cbor-diag +/ inp_hash / 307: [-16, h'9f86d081884c7d659a2feaa0c55ad015 + a3bf4f1b2b0b822cd15d6c15b0f00a08'] +~~~ + +Implementations MUST support SHA-256 (algorithm ID -16). Hash +algorithms weaker than SHA-256 MUST NOT be accepted. + +### Policy Decision Enumeration {#pol-decision-enum} + +In the JWT variant, pol_decision uses string values. In the CBOR +variant, pol_decision (key 304) uses unsigned integer enumeration +for compactness: + +| Integer Value | JWT String Value | Description | +|:---:|:---|:---| +| 0 | approved | Policy evaluation succeeded | +| 1 | rejected | Policy evaluation failed | +| 2 | pending_human_review | Awaiting human judgment | +{: #table-pol-decision title="Policy Decision Enumeration"} + +The processing rules are identical to the JWT variant: rejected ECTs +MUST still be appended to the ledger, and rejected parents may only +feed compensation, rollback, or remediation tasks. + +### Regulated Domain Enumeration {#regulated-domain-enum} + +In the JWT variant, regulated_domain uses string values. In the +CBOR variant, regulated_domain (key 311) uses unsigned integer +enumeration: + +| Integer Value | JWT String Value | Description | +|:---:|:---|:---| +| 0 | medtech | Medical technology and devices | +| 1 | finance | Financial services and trading | +| 2 | military | Military and defense | +{: #table-regulated-domain title="Regulated Domain Enumeration"} + +### Extension Map + +The ext claim (key 316) is a CBOR map with text string keys in +reverse domain notation (e.g., "com.example.custom_field"), +identical to the JWT variant. Values MAY be any CBOR type. The +serialized ext map SHOULD NOT exceed 4096 bytes. Map nesting depth +SHOULD NOT exceed 5 levels. Unknown extensions MUST be ignored by +receivers. + +# CDDL Schema {#cddl-schema} + +The following CDDL {{RFC8610}} schema defines the structure of an +ECT-CBOR payload: + +~~~cddl +ect-cbor-payload = { + ; === Standard CWT claims === + 1 => tstr, ; iss - Issuer (SPIFFE ID) + ? 2 => tstr, ; sub - Subject (= iss) + 3 => tstr / [+ tstr], ; aud - Audience + 4 => epoch-time, ; exp - Expiration + 6 => epoch-time, ; iat - Issued At + 7 => bstr .size 16, ; cti - CWT/Task ID (UUID) + + ; === Execution Context claims === + ? 300 => bstr .size 16, ; wid - Workflow ID (UUID) + 301 => tstr, ; exec_act - Action type + 302 => [* bstr .size 16], ; par - Parent ECT cti UUIDs + + ; === Optional policy claims (must be paired) === + ? 303 => tstr, ; pol - Policy rule ID + ? 304 => pol-decision, ; pol_decision + + ? 305 => tstr, ; pol_enforcer + ? 306 => epoch-time, ; pol_timestamp + + ; === Optional data integrity === + ? 307 => hash-entry, ; inp_hash + ? 308 => hash-entry, ; out_hash + ? 309 => tstr, ; inp_classification + + ; === Optional metadata === + ? 310 => uint, ; exec_time_ms + ? 311 => regulated-domain, ; regulated_domain + ? 312 => tstr, ; model_version + ? 313 => [+ tstr], ; witnessed_by + ? 314 => bool, ; compensation_required + ? 315 => tstr, ; compensation_reason + ? 316 => { + tstr => any }, ; ext +} + +; Policy decision: 0=approved, 1=rejected, +; 2=pending_human_review +pol-decision = 0..2 + +; Regulated domain: 0=medtech, 1=finance, 2=military +regulated-domain = 0..2 + +; Hash entry: [algorithm_id, hash_bytes] +; algorithm_id from COSE Algorithms registry (e.g., -16 = SHA-256) +hash-entry = [int, bstr] + +; epoch-time is integer seconds since Unix epoch +epoch-time = int +~~~ +{: #fig-cddl title="CDDL Schema for ECT-CBOR Payload"} + +The COSE_Sign1 wrapper structure is defined in {{cose-structure}}. + +# COSE_Sign1 Structure {#cose-structure} + +An ECT-CBOR token is a COSE_Sign1 message {{RFC9052}} Section 4.2 +with the following structure: + +~~~cddl +ECT-COSE = COSE_Sign1_Tagged + +COSE_Sign1_Tagged = #6.18(COSE_Sign1) + +COSE_Sign1 = [ + protected: bstr, ; Serialized protected header map + unprotected: {}, ; MUST be empty + payload: bstr, ; Serialized ECT-CBOR claims map + signature: bstr ; Digital signature +] +~~~ +{: #fig-cose-structure title="COSE_Sign1 Structure for ECT-CBOR"} + +The components are: + +protected: +: The CBOR-serialized protected header map as defined in + {{cose-header}}. Encoded as a bstr wrapping the CBOR map. + +unprotected: +: MUST be an empty map. No unprotected header parameters are + permitted for ECTs. All parameters reside in the protected bucket + to ensure integrity. + +payload: +: The CBOR-serialized ECT claims map conforming to the CDDL schema + in {{cddl-schema}}. Encoded as a bstr. + +signature: +: The digital signature computed per {{RFC9052}} Section 4.4. For + ES256, this is a 64-byte value containing the (r, s) pair in + fixed-length encoding. + +The Sig_structure for computing the signature is per {{RFC9052}} +Section 4.4: + +~~~cddl +Sig_structure = [ + context: "Signature1", + body_protected: bstr, ; Serialized protected header + external_aad: bstr, ; Empty bstr (h'') unless transport-bound + payload: bstr ; Serialized ECT claims map +] +~~~ +{: #fig-sig-structure title="Sig_structure for ECT Signature Computation"} + +External Additional Authenticated Data (external_aad) is an empty +byte string unless the ECT is bound to a transport-layer context +(e.g., OSCORE {{RFC8613}}). When transport binding is used, the +binding mechanism MUST be documented. + +# Transport Mechanisms {#transport} + +## HTTP Transport {#http-transport} + +When ECT-CBOR tokens are transported over HTTP, the same +Execution-Context header field defined in +{{I-D.nennemann-wimse-execution-context}} is used. The header value +is the Base64url-encoded COSE_Sign1 byte sequence (without padding). + +Receivers can distinguish JWT and CBOR ECTs by examining the first +bytes of the decoded value: + +- JWT ECTs begin with the byte 0x7B (ASCII '{'), as the decoded + JWS header starts with a JSON object. + +- CBOR ECTs begin with the byte 0xD2 (CBOR tag 18 for + COSE_Sign1_Tagged) or 0x84 (CBOR array of length 4 for an + untagged COSE_Sign1). + +Implementations that support both formats MUST perform this +detection. Implementations that support only one format MAY reject +tokens in the unsupported format. + +Example: + +~~~ +GET /api/safety-check HTTP/1.1 +Host: safety-agent.example.com +Workload-Identity: eyJhbGci...WIT... +Workload-Proof-Token: eyJhbGci...WPT... +Execution-Context: 0oRYJ6QBJgMeYXBwbGljYXRp...CBOR-ECT... +~~~ +{: #fig-http-cbor title="HTTP Request with CBOR ECT"} + +When multiple parent tasks contribute context, multiple +Execution-Context header field lines MAY be included, each carrying +either a JWT or CBOR ECT. Receivers MUST individually verify each +ECT regardless of its serialization format. + +## CoAP Transport {#coap-transport} + +For CoAP {{RFC7252}} deployments, ECT-CBOR tokens are carried using +one of the following mechanisms: + +### CoAP Option + +A new CoAP Option is defined: + +| Number | Name | Format | +|:---:|:---|:---| +| TBD1 | Execution-Context | opaque | +{: #table-coap-option title="CoAP Option for ECT-CBOR"} + +The option value is the raw COSE_Sign1 byte sequence (not +Base64url-encoded). CoAP's binary-native transport eliminates the +need for text encoding. + +When the ECT exceeds the CoAP option size limit, implementations +SHOULD use CoAP block-wise transfer {{?RFC7959}} or carry the ECT +in the request payload with the Content-Format set to +application/wimse-exec+cwt (see {{iana}}). + +### Content-Format + +The CoAP Content-Format identifier for ECT-CBOR is registered in +{{iana}}. When ECTs are carried in the CoAP payload body rather +than an option, the Content-Format MUST be set to the registered +identifier for application/wimse-exec+cwt. + +### Transport Security + +CoAP-based ECT transport MUST use DTLS 1.3 {{RFC9147}}, OSCORE +{{RFC8613}}, or EDHOC {{RFC9528}} for transport security. ECT +signatures provide message-level security, but transport-layer +confidentiality and integrity are still REQUIRED. + +## MQTT Transport {#mqtt-transport} + +For MQTT {{MQTT}} deployments, ECT-CBOR tokens MAY be carried as: + +1. **MQTT User Property**: The property name is "Execution-Context" + and the value is the Base64-encoded COSE_Sign1 byte sequence. + Multiple Execution-Context properties MAY be included for + multiple parent ECTs. + +2. **Payload envelope**: The ECT is embedded within the MQTT + application payload as a CBOR-encoded field. The envelope + structure is application-defined. + +MQTT transport MUST use TLS for transport security. MQTT User +Properties are not encrypted by the MQTT protocol itself; ECT +signatures provide message-level integrity but not confidentiality +of claim values. + +## Raw Binary Transport {#binary-transport} + +For Layer 2, fieldbus, or other non-IP protocols, ECT-CBOR tokens +can be embedded directly as COSE_Sign1 byte sequences. The framing +format is: + +~~~ ++----------------+------------------------------+ +| Length (2 or 4 | COSE_Sign1 bytes | +| bytes, network | | +| byte order) | | ++----------------+------------------------------+ +~~~ +{: #fig-binary-framing title="Binary Transport Framing"} + +Implementations MUST use 2-byte length for ECTs up to 65535 bytes +and 4-byte length for larger ECTs. The length field encodes the +number of bytes in the COSE_Sign1 structure that follows. + +Multiple ECTs (for multiple parent tasks) are concatenated using +this framing. + +# Verification Procedure {#verification} + +The verification procedure for ECT-CBOR tokens follows the 15-step +procedure defined in {{I-D.nennemann-wimse-execution-context}} +Section "Signature and Token Verification", with the following +COSE-specific adaptations for the initial steps: + +1. **Parse COSE_Sign1**: Decode the COSE_Sign1 structure per + {{RFC9052}} Section 4.4. Extract the protected header, + payload, and signature. If the input begins with CBOR tag 18, + strip the tag and process the inner array. + +2. **Verify content type**: The protected header parameter content + type (label 3) MUST be present and MUST be + "application/wimse-exec+cwt" or the equivalent registered CoAP + Content-Format number. + +3. **Verify alg**: The protected header parameter alg (label 1) + MUST be present and MUST be an asymmetric signature algorithm. + Symmetric MAC algorithms and absent/null values MUST be + rejected. + +4. **Verify kid**: The protected header parameter kid (label 4) + MUST reference a known, valid public key from a WIT within the + trust domain. + +5. **Verify signature**: Retrieve the public key identified by kid + and verify the COSE_Sign1 signature per {{RFC9052}} + Section 4.4, constructing the Sig_structure as defined in + {{cose-structure}}. + +6. **Verify key not revoked**: Identical to the JWT variant. + +7. **Verify algorithm alignment**: The alg parameter MUST match the + algorithm in the corresponding WIT. + +8. **Verify issuer**: Decode the payload. The iss claim (key 1) + MUST match the sub claim of the WIT associated with the kid + public key. + +9. **Verify audience**: The aud claim (key 3) MUST contain the + verifier's own workload identity. + +10. **Verify expiration**: The exp claim (key 4) MUST indicate the + ECT has not expired. + +11. **Verify iat freshness**: The iat claim (key 6) MUST NOT be + unreasonably far in the past (RECOMMENDED: 15 minutes) and MUST + NOT be in the future beyond clock skew tolerance (RECOMMENDED: + 30 seconds). + +12. **Verify required claims**: The cti (key 7), exec_act + (key 301), and par (key 302) claims MUST all be present and + well-formed per the CDDL schema in {{cddl-schema}}. + +13. **Verify policy claims**: If pol (key 303) or pol_decision + (key 304) is present, verify that both are present and that + pol_decision is 0, 1, or 2. + +14. **Perform DAG validation**: Per the DAG validation rules in + {{I-D.nennemann-wimse-execution-context}}. When comparing task + IDs across JWT and CBOR ECTs in a mixed-format deployment, UUID + comparison MUST be performed at the binary level (converting + text UUIDs to 16-byte binary for comparison). + +15. **Store ECT**: If all checks pass and an audit ledger is + available, the ECT SHOULD be appended. + +Error handling follows the same rules as the JWT variant. +Verification failures MUST be logged. Error messages SHOULD NOT +reveal whether specific parent task IDs exist in the ledger. + +# Audit Ledger Considerations {#ledger} + +The audit ledger interface defined in +{{I-D.nennemann-wimse-execution-context}} applies to CBOR ECTs. +The ledger entry structure carries the raw COSE_Sign1 bytes instead +of the JWS compact serialization: + +~~~cbor-diag +{ + "ledger_sequence": 42, + "ect_jti": h'550e8400e29b41d4a716446655440001', + "agent_id": "spiffe://example.com/agent/clinical", + "action": "recommend_treatment", + "parents": [], + "ect_cose": h'd28443a10126a058...full COSE_Sign1 bytes...', + "signature_verified": true, + "verification_timestamp": 1(1772064151), + "stored_timestamp": 1(1772064151) +} +~~~ +{: #fig-ledger-entry title="Ledger Entry for CBOR ECT"} + +The ect_cose field is the authoritative record. Convenience fields +(agent_id, action, parents) are indexes; if they disagree with the +COSE_Sign1 payload, the COSE_Sign1 content takes precedence. + +Ledgers that store both JWT and CBOR ECTs SHOULD include a format +discriminator field. Alternatively, the format can be detected from +the raw bytes: JWT ECTs (JWS compact serialization) are +ASCII-printable text with period separators, while CBOR ECTs begin +with CBOR-encoded bytes (tag 18 = 0xD2, or array header 0x84). + +# Size Comparison {#size-comparison} + +The following comparison uses the "Complete ECT Example" from +{{I-D.nennemann-wimse-execution-context}} Section 4.8 as the +reference payload. This example contains: iss, sub, aud, iat, exp, +jti, wid, exec_act, par (empty), pol, pol_decision, +pol_enforcer, pol_timestamp, inp_hash, out_hash, +inp_classification, exec_time_ms, regulated_domain, model_version, +and witnessed_by. + +## JWT Variant Size + +| Component | Estimated Bytes | +|:---|---:| +| JOSE header (JSON) | ~70 | +| Payload (JSON) | ~620 | +| ES256 signature (raw) | 64 | +| Base64url encoding overhead (~33%) | ~250 | +| Period separators | 2 | +| **Total (JWS Compact)** | **~1006** | +{: #table-jwt-size title="JWT ECT Size Estimate"} + +## CBOR Variant Size + +| Component | Estimated Bytes | +|:---|---:| +| Protected header (CBOR) | ~55 | +| Payload (CBOR) | ~240 | +| ES256 signature (raw) | 64 | +| COSE_Sign1 array framing | ~6 | +| **Total (COSE_Sign1)** | **~365** | +{: #table-cbor-size title="CBOR ECT Size Estimate"} + +## Analysis + +The CBOR variant achieves approximately **2.8x size reduction** +compared to the JWT variant. Key savings come from: + +- **Integer claim keys** vs. string claim names: ~100 bytes saved + across all claims. + +- **Binary UUIDs** (16 bytes each) vs. hyphenated text UUIDs (36 + bytes each): ~60 bytes saved across jti, wid, and par entries. + +- **Binary hash values** vs. base64url-encoded hash strings: ~22 + bytes saved per hash (two hashes = ~44 bytes). + +- **Integer enumerations** vs. string values for pol_decision and + regulated_domain: ~15 bytes saved. + +- **No Base64url encoding**: COSE_Sign1 is a native binary format, + eliminating the ~33% overhead of Base64url encoding required for + JWS Compact Serialization when carried in binary transports + (CoAP, MQTT payload, raw binary). + +When transported over HTTP (which requires Base64url encoding of +the COSE_Sign1 bytes), the size advantage is reduced but still +significant (~2x reduction). + +# Security Considerations + +The security considerations in +{{I-D.nennemann-wimse-execution-context}} apply in full to +CBOR-serialized ECTs. This section addresses additional +considerations specific to the CBOR/COSE serialization. + +## CBOR Canonicalization + +CBOR allows multiple valid encodings of the same data (e.g., +different integer widths, indefinite-length encoding). To ensure +consistent hashing and signature verification: + +- ECT payloads SHOULD use deterministic CBOR encoding as defined in + {{RFC8949}} Section 4.2 (Core Deterministic Encoding + Requirements). + +- Implementations MUST NOT reject ECTs solely because the payload + uses a non-preferred but valid CBOR encoding, provided the + COSE_Sign1 signature verifies correctly. + +- The protected header MUST use deterministic encoding, as it is + included in the Sig_structure for signature computation. + +## COSE Algorithm Agility + +The same algorithm constraints as the JWT variant apply: symmetric +algorithms MUST NOT be used, and the absence of an algorithm +identifier MUST be rejected. Implementations SHOULD support +algorithm agility by accepting any COSE asymmetric signature +algorithm registered in the IANA "COSE Algorithms" registry, subject +to local policy on minimum security strength. + +## CoAP Transport Security + +When ECTs are transported over CoAP, transport security MUST be +provided by DTLS 1.3 {{RFC9147}}, OSCORE {{RFC8613}}, or EDHOC +{{RFC9528}}. CoAP without transport security MUST NOT be used for +ECT transport, even though ECT signatures provide message-level +integrity. Transport security provides confidentiality of claim +values (ECT signatures do not encrypt the payload). + +## MQTT Transport Security + +When ECTs are transported over MQTT, TLS MUST be used for the MQTT +connection. MQTT User Properties are transmitted in cleartext within +the MQTT protocol layer; TLS provides the necessary confidentiality. +ECT signatures ensure integrity and non-repudiation independent of +the transport. + +## Binary Transport Security + +For raw binary transports ({{binary-transport}}), ECT signatures +provide message-level integrity and authenticity. However, +transport-layer integrity mechanisms (checksums, MACs, link-layer +encryption) are RECOMMENDED as defense in depth. Without transport +security, claim values are transmitted in cleartext. + +## Mixed-Format Deployments + +In deployments where some agents produce JWT ECTs and others produce +CBOR ECTs within the same workflow: + +- DAG validation MUST compare ECT identifiers (jti/cti) at the + binary UUID level. Text UUID representations MUST be converted + to 16-byte binary before comparison. + +- Hash values MUST be compared at the raw byte level. The JWT + base64url-encoded hash MUST be decoded before comparison with + the CBOR binary hash. + +- Policy decision values MUST be compared semantically: the JWT + string "approved" is equivalent to the CBOR integer 0, "rejected" + to 1, and "pending_human_review" to 2. + +- Audit ledgers MUST support both formats and SHOULD normalize + comparison operations to a common representation. + +# Privacy Considerations + +The privacy considerations in +{{I-D.nennemann-wimse-execution-context}} apply identically to +CBOR-serialized ECTs. CBOR's binary encoding does not change the +privacy properties: the same claims are present, carrying the same +information, encoded differently. + +Implementers should note that CBOR's compact encoding does not +provide confidentiality. The binary format may create a false sense +of obscurity, but CBOR-encoded data is trivially decoded by anyone +with access to the byte stream. ECT claim values SHOULD be +protected in transit via transport-layer encryption (TLS, DTLS, +OSCORE) and at rest via storage encryption. + +# IANA Considerations {#iana} + +## Media Type Registration + +This document requests registration of the following media type +in the "Media Types" registry maintained by IANA: + +Type name: +: application + +Subtype name: +: wimse-exec+cwt + +Required parameters: +: none + +Optional parameters: +: none + +Encoding considerations: +: binary; an ECT-CBOR is a COSE_Sign1 structure containing a + CBOR-encoded payload. + +Security considerations: +: See the Security Considerations section of this document. + +Interoperability considerations: +: none + +Published specification: +: This document + +Applications that use this media type: +: Applications that implement regulated agentic workflows requiring + execution context tracing and audit trails in constrained or + binary-transport environments. + +Additional information: +: Magic number(s): none + File extension(s): none + Macintosh file type code(s): none + +Person and email address to contact for further information: +: Christian Nennemann, ietf@nennemann.de + +Intended usage: +: COMMON + +Restrictions on usage: +: none + +Author: +: Christian Nennemann + +Change controller: +: IETF + +## CoAP Content-Format Registration + +This document requests registration of the following Content-Format +in the "CoAP Content-Formats" registry maintained by IANA: + +| Media Type | Encoding | ID | +|:---|:---|:---:| +| application/wimse-exec+cwt | - | TBD2 | +{: #table-content-format title="CoAP Content-Format Registration"} + +## CoAP Option Number Registration + +This document requests registration of the following CoAP Option +in the "CoAP Option Numbers" registry maintained by IANA: + +| Number | Name | Reference | +|:---:|:---|:---| +| TBD1 | Execution-Context | This document | +{: #table-coap-option-reg title="CoAP Option Registration"} + +## CWT Claims Registration {#cwt-claims-registration} + +This document requests registration of the following claims in the +"CBOR Web Token (CWT) Claims" registry maintained by IANA: + +| Claim Name | Claim Key | Claim Value Type | Change Controller | Reference | +|:---|:---:|:---|:---:|:---| +| wid | 300 | bstr | IETF | {{ect-claims}} | +| exec_act | 301 | tstr | IETF | {{ect-claims}} | +| par | 302 | array | IETF | {{ect-claims}} | +| pol | 303 | tstr | IETF | {{ect-claims}} | +| pol_decision | 304 | uint | IETF | {{ect-claims}} | +| pol_enforcer | 305 | tstr | IETF | {{ect-claims}} | +| pol_timestamp | 306 | int | IETF | {{ect-claims}} | +| inp_hash | 307 | array | IETF | {{ect-claims}} | +| out_hash | 308 | array | IETF | {{ect-claims}} | +| inp_classification | 309 | tstr | IETF | {{ect-claims}} | +| exec_time_ms | 310 | uint | IETF | {{ect-claims}} | +| regulated_domain | 311 | uint | IETF | {{ect-claims}} | +| model_version | 312 | tstr | IETF | {{ect-claims}} | +| witnessed_by | 313 | array | IETF | {{ect-claims}} | +| compensation_required | 314 | true/false | IETF | {{ect-claims}} | +| compensation_reason | 315 | tstr | IETF | {{ect-claims}} | +| ext | 316 | map | IETF | {{ect-claims}} | +{: #table-cwt-claims-reg title="CWT Claims Registrations"} + +## ECT-CBOR Policy Decision Values Registry {#cbor-pol-decision-registry} + +This document establishes the "ECT-CBOR Policy Decision Values" +registry. Registration policy is Specification Required per +{{!RFC8126}}. + +The initial contents of the registry are: + +| Integer Value | Description | Change Controller | Reference | +|:---:|:---|:---:|:---| +| 0 | Policy evaluation succeeded (approved) | IETF | {{pol-decision-enum}} | +| 1 | Policy evaluation failed (rejected) | IETF | {{pol-decision-enum}} | +| 2 | Awaiting human judgment (pending_human_review) | IETF | {{pol-decision-enum}} | +{: #table-pol-decision-reg title="ECT-CBOR Policy Decision Values"} + +## ECT-CBOR Regulated Domain Values Registry {#cbor-regulated-domain-registry} + +This document establishes the "ECT-CBOR Regulated Domain Values" +registry. Registration policy is Specification Required per +{{!RFC8126}}. + +The initial contents of the registry are: + +| Integer Value | Description | Change Controller | Reference | +|:---:|:---|:---:|:---| +| 0 | Medical technology and devices (medtech) | IETF | {{regulated-domain-enum}} | +| 1 | Financial services and trading (finance) | IETF | {{regulated-domain-enum}} | +| 2 | Military and defense (military) | IETF | {{regulated-domain-enum}} | +{: #table-regulated-domain-reg title="ECT-CBOR Regulated Domain Values"} + +--- back + +# Related Work +{:numbered="false"} + +## CWT and JWT Relationship +{:numbered="false"} + +CBOR Web Token (CWT) {{RFC8392}} is the CBOR analog of JSON Web +Token (JWT) {{?RFC7519}}. CWT reuses the JWT claim semantics with +integer keys instead of string names and CBOR encoding instead of +JSON. This document follows the same pattern: ECT-CBOR reuses the +ECT-JWT claim semantics with CBOR-native encoding. + +## COSE and JOSE Relationship +{:numbered="false"} + +COSE {{RFC9052}} is the CBOR analog of JOSE {{?RFC7515}}. COSE +provides equivalent signing (COSE_Sign, COSE_Sign1), MAC +(COSE_Mac, COSE_Mac0), and encryption (COSE_Encrypt, COSE_Encrypt0) +operations. ECT-CBOR uses COSE_Sign1, the single-signer structure, +matching the JWS Compact Serialization (single signature) used by +ECT-JWT. + +## Entity Attestation Token (EAT) +{:numbered="false"} + +The Entity Attestation Token (EAT) {{EAT}} uses CWT as its base +and defines claims for hardware and software attestation. EAT and +ECT-CBOR share the CWT foundation and could potentially be +integrated: an EAT providing device attestation could carry ECT +claims to combine hardware trust with execution accountability. +Future work may define an EAT profile for ECT-CBOR. + +## SUIT Manifests +{:numbered="false"} + +The Software Update for IoT (SUIT) manifest +{{I-D.ietf-suit-manifest}} uses CBOR/COSE for secure firmware +update descriptions in constrained environments. SUIT and ECT-CBOR +target overlapping deployment environments (constrained IoT devices) +and share the CBOR/COSE toolchain. An agentic workflow that +includes firmware update tasks could use SUIT manifests for the +update payload and ECT-CBOR for the execution accountability record. + +## SCITT Integration +{:numbered="false"} + +As noted in {{I-D.nennemann-wimse-execution-context}}, ECTs can +integrate with the Supply Chain Integrity, Transparency and Trust +(SCITT) architecture {{I-D.ietf-scitt-architecture}}. SCITT uses +COSE_Sign1 as its signing structure, making ECT-CBOR a natural fit +for SCITT integration: ECT-CBOR tokens can be submitted to SCITT +Transparency Services as COSE_Sign1 signed statements without +format conversion. + +# Examples +{:numbered="false"} + +## Example 1: Simple Two-Agent Workflow +{:numbered="false"} + +Agent A executes a data retrieval task and sends the ECT to Agent B. + +ECT COSE Protected Header (CBOR diagnostic notation): + +~~~cbor-diag +{ + / alg / 1: -7, / ES256 / + / content type / 3: "application/wimse-exec+cwt", + / kid / 4: h'6167656e742d612d6b65792d323032362d3032', + / typ / 16: "wimse-exec+cwt" +} +~~~ + +ECT Payload (CBOR diagnostic notation): + +~~~cbor-diag +{ + / iss / 1: "spiffe://example.com/agent/data-retrieval", + / sub / 2: "spiffe://example.com/agent/data-retrieval", + / aud / 3: "spiffe://example.com/agent/validator", + / exp / 4: 1772064750, + / iat / 6: 1772064150, + / cti / 7: h'550e8400e29b41d4a716446655440001', + + / wid / 300: h'b1c2d3e4f5a67890bcdef01234567890', + / exec_act / 301: "fetch_patient_data", + / par / 302: [], + / pol / 303: "clinical_data_access_policy_v1", + / pol_decision / 304: 0, / approved / + + / inp_hash / 307: [-16, + h'9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08'], + / out_hash / 308: [-16, + h'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'], + / exec_time_ms / 310: 142, + / regulated_domain / 311: 0 / medtech / +} +~~~ + +Agent B receives the ECT, verifies it, executes a validation task, +and creates its own ECT: + +~~~cbor-diag +{ + / iss / 1: "spiffe://example.com/agent/validator", + / sub / 2: "spiffe://example.com/agent/validator", + / aud / 3: "spiffe://example.com/system/ledger", + / exp / 4: 1772064760, + / iat / 6: 1772064160, + / cti / 7: h'550e8400e29b41d4a716446655440002', + + / wid / 300: h'b1c2d3e4f5a67890bcdef01234567890', + / exec_act / 301: "validate_safety", + / par / 302: [h'550e8400e29b41d4a716446655440001'], + / pol / 303: "safety_validation_policy_v2", + / pol_decision / 304: 0, / approved / + + / exec_time_ms / 310: 89, + / regulated_domain / 311: 0 / medtech / +} +~~~ + +The resulting DAG: + +~~~ +task 550e...0001 (fetch_patient_data) + | + v +task 550e...0002 (validate_safety) +~~~ + +Approximate COSE_Sign1 structure (hex, abbreviated): + +~~~ +d2 -- Tag 18 (COSE_Sign1_Tagged) +84 -- Array(4) + 58 37 -- bstr(55) - protected header + a4 01 26 03 78 1e ... -- {1: -7, 3: "application/...", ...} + a0 -- {} - empty unprotected header + 58 c8 -- bstr(200) - payload + b0 01 78 28 ... -- {1: "spiffe://...", ...} + 58 40 -- bstr(64) - signature + <64 bytes ES256 sig> +~~~ + +## Example 2: Medical Device SDLC (Tasks 1 and 5) +{:numbered="false"} + +Task 1 (Spec Review Agent) payload: + +~~~cbor-diag +{ + / iss / 1: "spiffe://meddev.example/agent/spec-reviewer", + / sub / 2: "spiffe://meddev.example/agent/spec-reviewer", + / aud / 3: "spiffe://meddev.example/agent/code-gen", + / exp / 4: 1772064750, + / iat / 6: 1772064150, + / cti / 7: h'a1b2c3d4000100000000000000000001', + + / wid / 300: h'c2d3e4f5a6b78901cdef012345678901', + / exec_act / 301: "review_requirements_spec", + / par / 302: [], + / pol / 303: "spec_review_policy_v2", + / pol_decision / 304: 0, / approved / + + / inp_hash / 307: [-16, + h'9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08'], + / out_hash / 308: [-16, + h'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'], + / regulated_domain / 311: 0, / medtech / + / model_version / 312: "spec-review-v3.1" +} +~~~ + +Task 5 (Human Release Manager Approval) payload: + +~~~cbor-diag +{ + / iss / 1: "spiffe://meddev.example/human/release-mgr-42", + / sub / 2: "spiffe://meddev.example/human/release-mgr-42", + / aud / 3: "spiffe://meddev.example/system/ledger", + / exp / 4: 1772065110, + / iat / 6: 1772064510, + / cti / 7: h'a1b2c3d4000100000000000000000005', + + / wid / 300: h'c2d3e4f5a6b78901cdef012345678901', + / exec_act / 301: "approve_release", + / par / 302: [h'a1b2c3d4000100000000000000000004'], + / pol / 303: "release_approval_policy", + / pol_decision / 304: 0, / approved / + / pol_enforcer / 305: + "spiffe://meddev.example/human/release-mgr-42", + + / witnessed_by / 313: [ + "spiffe://meddev.example/audit/qa-observer-1" + ], + / regulated_domain / 311: 0 / medtech / +} +~~~ + +The five-task DAG: + +~~~ +task ...-0001 (review_requirements_spec) + | + v +task ...-0002 (implement_module) + | + v +task ...-0003 (execute_test_suite) + | + v +task ...-0004 (build_release_artifact) + | + v +task ...-0005 (approve_release) [human, witnessed] +~~~ + +## Example 3: Parallel Execution with Join +{:numbered="false"} + +A financial trading workflow where two tasks execute in parallel +and a third task depends on both: + +~~~ +task ...-0001 (assess_risk) + | \ + v v +task ...-0002 task ...-0003 +(check (verify +compliance) liquidity) + | / + v v +task ...-0004 (execute_trade) +~~~ + +Task 004 ECT payload (CBOR diagnostic notation): + +~~~cbor-diag +{ + / iss / 1: "spiffe://bank.example/agent/execution", + / sub / 2: "spiffe://bank.example/agent/execution", + / aud / 3: "spiffe://bank.example/system/ledger", + / exp / 4: 1772064850, + / iat / 6: 1772064250, + / cti / 7: h'f1e2d3c4000400000000000000000004', + + / wid / 300: h'd3e4f5a6b7c89012def0123456789012', + / exec_act / 301: "execute_trade", + / par / 302: [ + h'f1e2d3c4000200000000000000000002', + h'f1e2d3c4000300000000000000000003' + ], + / pol / 303: "trade_execution_policy_v3", + / pol_decision / 304: 0, / approved / + / regulated_domain / 311: 1 / finance / +} +~~~ + +The par array with two entries records that both compliance checking +and liquidity verification were completed before trade execution. + +# Acknowledgments +{:numbered="false"} + +The author thanks the WIMSE working group for their foundational +work on workload identity in multi-system environments. The +concepts of Workload Identity Tokens and Workload Proof Tokens +provide the identity foundation upon which execution context +tracing is built. + +The CBOR, COSE, and CWT communities have built an excellent +constrained-environment security stack that this document builds +upon. diff --git a/master-prompt.md b/master-prompt.md new file mode 100644 index 0000000..53b5a81 --- /dev/null +++ b/master-prompt.md @@ -0,0 +1,354 @@ +# Master Prompt: Generate CBOR/COSE Variant of WIMSE Execution Context Token Draft + +## Context + +You are an IETF standards author with deep expertise in CBOR (RFC 8949), COSE (RFC 9052, RFC 9053), CWT (RFC 8392), and the WIMSE working group architecture. You have been given the file `draft-nennemann-wimse-execution-context-00.md` which defines **Execution Context Tokens (ECTs)** — a JWT/JWS-based extension to WIMSE for recording task execution, DAG-structured dependency ordering, and policy evaluation outcomes in regulated agentic workflows. + +Your task is to produce a **companion Internet-Draft** that defines the same ECT semantics using **CBOR/COSE/CWT** serialization instead of JSON/JOSE/JWT. The new draft is designed for constrained environments, non-HTTP transports (CoAP, MQTT, Layer 2 protocols), and bandwidth-sensitive deployments. + +## Instructions + +### Step 1 — Read and Analyze the Source Draft + +Read `draft-nennemann-wimse-execution-context-00.md` completely. Extract and internalize: + +1. **All ECT claims** — both standard JWT claims (iss, sub, aud, iat, exp, jti) and ECT-specific claims (wid, tid, exec_act, par, pol, pol_decision, pol_enforcer, pol_timestamp, inp_hash, out_hash, inp_classification, exec_time_ms, regulated_domain, model_version, witnessed_by, compensation_required, compensation_reason, ext). +2. **The JOSE header requirements** — alg, typ ("wimse-exec+jwt"), kid. +3. **The DAG validation algorithm** — parent existence, temporal ordering, cycle detection, policy decision propagation, trust domain consistency. +4. **The verification procedure** — all 15 steps. +5. **The three operational modes** — point-to-point, deferred ledger, full ledger. +6. **The audit ledger interface** — required properties, entry structure. +7. **The HTTP transport mechanism** — Execution-Context header field. +8. **Security considerations** — threat model, self-assertion limitation, witness attestation, replay prevention, key compromise, collusion, DoS, timestamp accuracy, size constraints. +9. **Privacy considerations** — data minimization, storage access control, regulatory access. +10. **IANA registrations** — media type, HTTP header, JWT claims, policy decision values registry, regulated domain values registry. +11. **All normative and informative references**. +12. **The regulatory motivation** — EU AI Act, FDA 21 CFR Part 11, MiFID II, DORA, EU MDR. + +### Step 2 — Create the CBOR Draft + +Create the file `cbor-variant/draft-nennemann-wimse-execution-context-cbor-00.md` in kramdown-rfc format (same XML/markdown format as the source draft, compatible with `kramdown-rfc` / `xml2rfc`). + +#### 2.1 — Metadata and Front Matter + +- **Title**: `"CBOR Serialization of Execution Context Tokens for Distributed Agentic Workflows"` +- **Abbreviation**: `"WIMSE ECT-CBOR"` +- **Document name**: `draft-nennemann-wimse-execution-context-cbor-00` +- **Submission type**: IETF +- **Area**: Security +- **Workgroup**: WIMSE +- **Author**: Christian Nennemann, Independent Researcher, ietf@nennemann.de + +#### 2.2 — Normative References + +Include (at minimum): + +```yaml +normative: + RFC8392: # CBOR Web Token (CWT) + RFC8949: # CBOR + RFC9052: # COSE Signatures, MAC, Encryption + RFC9053: # COSE Algorithms + RFC9338: # COSE Countersignatures + RFC7049: # (if needed for back-compat notes) + RFC9562: # UUID + I-D.ietf-wimse-arch: + I-D.ietf-wimse-s2s-protocol: + I-D.nennemann-wimse-execution-context: # The JWT variant (this is the companion) +``` + +Add informative references as appropriate (CoAP RFC 7252, MQTT, OSCORE RFC 8613, EDHOC, EU AI Act, FDA, etc.). + +#### 2.3 — Abstract + +Write an abstract that: +- States this document defines a CBOR/COSE serialization of Execution Context Tokens (ECTs). +- References the companion JWT-based draft (`draft-nennemann-wimse-execution-context`) for the full semantic definition. +- Highlights the target environments: constrained devices, non-HTTP transports, bandwidth-sensitive deployments. +- Notes that this serialization preserves all ECT semantics (DAG structure, policy evaluation, compliance state) while using COSE_Sign1 and CWT claims. + +#### 2.4 — Introduction + +- Motivate why a CBOR variant is needed alongside the JWT variant. +- Reference the JWT draft as the normative semantic definition. +- Explain the target deployment scenarios: IoT agents, medical devices (constrained environments matching the medtech use case), edge computing agents, CoAP-based agent-to-agent communication. +- Explicitly state: this document defines **only** the serialization mapping. The semantics, DAG validation rules, verification logic, operational modes, and security model are defined in the JWT draft and apply identically here. + +#### 2.5 — COSE Header Parameters + +Define the COSE protected header for ECTs: + +- **alg (1)**: REQUIRED. Algorithm identifier. MUST support ES256 (-7). MUST NOT be a symmetric algorithm or indicate no signature. +- **content type (3)**: REQUIRED. MUST be set to the CoAP Content-Format ID for `application/wimse-exec+cwt` (to be registered). +- **kid (4)**: REQUIRED. Key identifier referencing the public key from the agent's WIT. Encoded as bstr. +- **typ (16)**: REQUIRED. MUST be `wimse-exec+cwt`. (Per RFC 9596 / CWT typ claim.) + +Note: ECTs MUST use `COSE_Sign1` (single signer) structure, not `COSE_Sign` (multi-signer), matching the single-agent-signs model of the JWT variant. + +#### 2.6 — CWT Claim Mapping (CRITICAL SECTION) + +This is the core of the draft. Define a complete mapping table from JWT claim names to CBOR integer keys. + +**Standard CWT claims** (reuse existing IANA CWT claim keys): + +| JWT Claim | CWT Key (int) | CBOR Type | Description | +|-----------|---------------|---------------|--------------------------------| +| iss | 1 | tstr | Issuer (SPIFFE ID) | +| sub | 2 | tstr | Subject (= iss) | +| aud | 3 | tstr / [tstr] | Audience | +| exp | 4 | int (#6.1) | Expiration (epoch seconds) | +| nbf | 5 | (not used) | Not Before (not used in ECTs) | +| iat | 6 | int (#6.1) | Issued At (epoch seconds) | +| cti | 7 | bstr | CWT ID (= jti equivalent, UUID as 16-byte binary) | + +**ECT-specific claims** — request new CBOR integer keys from a private-use or early-allocation range. Use a contiguous block starting from a clearly documented base. Proposed mapping (the exact numbers are illustrative; the draft should request IANA allocation): + +| JWT Claim | Proposed CWT Key | CBOR Type | Notes | +|------------------------|-------------------|--------------------|---------------------------------------------| +| wid | 300 | bstr (16 bytes) | Workflow ID — UUID as binary | +| tid | 301 | bstr (16 bytes) | Task ID — UUID as binary | +| exec_act | 302 | tstr | Action/task type identifier | +| par | 303 | [bstr] | Array of parent task ID UUIDs (binary) | +| pol | 304 | tstr | Policy rule identifier | +| pol_decision | 305 | uint | Policy decision (0=approved, 1=rejected, 2=pending_human_review) | +| pol_enforcer | 306 | tstr | Policy enforcer identity (SPIFFE ID) | +| pol_timestamp | 307 | int (#6.1) | Policy decision timestamp | +| inp_hash | 308 | [int, bstr] | [hash_alg_id, hash_value] — use COSE hash algorithm IDs | +| out_hash | 309 | [int, bstr] | Same format as inp_hash | +| inp_classification | 310 | tstr | Data sensitivity classification | +| exec_time_ms | 311 | uint | Execution duration in milliseconds | +| regulated_domain | 312 | uint | Enumerated: 0=medtech, 1=finance, 2=military | +| model_version | 313 | tstr | AI/ML model version string | +| witnessed_by | 314 | [tstr] | Array of witness SPIFFE IDs | +| compensation_required | 315 | bool | Compensation flag | +| compensation_reason | 316 | tstr | Compensation reason identifier | +| ext | 317 | map | Extension map (keys: tstr in reverse domain notation) | + +**Important design decisions to document:** + +1. **UUIDs as binary**: In CBOR, UUIDs (wid, tid, par entries, cti) MUST be encoded as 16-byte `bstr` rather than text, saving 20 bytes per UUID vs. the hyphenated text form. Reference RFC 9562 Section 4 for UUID binary format. Optionally use CBOR tag 37 (RFC 9562) to explicitly tag UUID bstr values. +2. **Hash encoding**: Instead of the JWT format `"sha-256:base64url-encoded-hash"`, use a structured CBOR array `[hash_algorithm_id, hash_bytes]` where `hash_algorithm_id` is from the COSE Algorithms registry (e.g., SHA-256 = -16) and `hash_bytes` is the raw hash as `bstr`. This is more compact and type-safe. +3. **Policy decision as enum**: Instead of string values, use uint enumeration (0, 1, 2). Define the mapping explicitly and register it. +4. **Regulated domain as enum**: Same approach — uint enumeration instead of strings. +5. **Timestamps**: Use standard CWT NumericDate (integer seconds since epoch), same as JWT but without fractional seconds. Optionally note that tag 1 (epoch-based date/time) MAY be used. + +#### 2.7 — CDDL Schema + +Provide a complete CDDL (RFC 8610) schema for the ECT-CBOR payload. Example structure: + +```cddl +ect-cbor-claims = { + ; Standard CWT claims + 1 => tstr, ; iss — SPIFFE ID + ? 2 => tstr, ; sub — SPIFFE ID (= iss) + 3 => tstr / [+ tstr], ; aud + 4 => int, ; exp + 6 => int, ; iat + 7 => bstr .size 16, ; cti — UUID binary + + ; Execution Context claims + ? 300 => bstr .size 16, ; wid — Workflow ID (UUID) + 301 => bstr .size 16, ; tid — Task ID (UUID) + 302 => tstr, ; exec_act + 303 => [* bstr .size 16], ; par — parent task IDs + 304 => tstr, ; pol + 305 => 0..2, ; pol_decision + + ; Optional policy claims + ? 306 => tstr, ; pol_enforcer + ? 307 => int, ; pol_timestamp + + ; Optional data integrity + ? 308 => [int, bstr], ; inp_hash [alg_id, hash] + ? 309 => [int, bstr], ; out_hash [alg_id, hash] + ? 310 => tstr, ; inp_classification + + ; Optional metadata + ? 311 => uint, ; exec_time_ms + ? 312 => 0..2, ; regulated_domain + ? 313 => tstr, ; model_version + ? 314 => [+ tstr], ; witnessed_by + ? 315 => bool, ; compensation_required + ? 316 => tstr, ; compensation_reason + ? 317 => { + tstr => any }, ; ext +} +``` + +#### 2.8 — COSE Structure + +Define the complete COSE_Sign1 structure for an ECT: + +``` +ECT_COSE = COSE_Sign1 = [ + protected: bstr, ; Serialized COSE protected header + unprotected: {}, ; MUST be empty for ECTs + payload: bstr, ; Serialized CBOR ECT claims map + signature: bstr ; ECDSA signature +] +``` + +- Unprotected headers MUST be empty (all header parameters are in the protected bucket for integrity). +- The payload is the CBOR-serialized ECT claims map. +- External AAD (Additional Authenticated Data) is empty unless bound to a transport-layer context (e.g., OSCORE). + +#### 2.9 — Transport Mechanisms + +Define transport options beyond HTTP: + +**2.9.1 — HTTP Transport** + +Same `Execution-Context` header field as the JWT variant. The value is the Base64url-encoded COSE_Sign1 structure. Receivers distinguish JWT vs. CBOR ECTs by: +- JWT ECTs start with `eyJ` (Base64url of `{"`) — JSON object. +- CBOR ECTs start with `0o` or similar (Base64url of CBOR tag/array prefix `0xd2` for COSE_Sign1 tag 18). + +Alternatively, define a separate header `Execution-Context-CBOR` or use content negotiation. Document the tradeoffs and pick one approach as RECOMMENDED. + +**2.9.2 — CoAP Transport** + +Define a new CoAP Option for carrying ECTs: +- Option Number: TBD (request IANA allocation) +- Name: Execution-Context +- Format: opaque (COSE_Sign1 bytes) +- Reference: This document + +Or use a CoAP Content-Format registration for `application/wimse-exec+cwt`. + +**2.9.3 — MQTT Transport** + +Briefly describe carrying ECTs as MQTT User Properties or within the payload envelope. Keep this informational, not normative. + +**2.9.4 — Raw Binary Transport** + +For Layer 2 / non-IP protocols, ECTs can be embedded directly as COSE_Sign1 byte sequences. Document byte-level framing: length-prefix + COSE_Sign1 bytes. + +#### 2.10 — Verification Procedure + +Reference the JWT draft's verification procedure (Section "Signature and Token Verification") and describe the COSE-specific differences: + +1. Parse the COSE_Sign1 structure per RFC 9052 Section 4.4. +2. Verify the `content type` protected header parameter is `application/wimse-exec+cwt`. +3. Verify the `alg` protected header parameter is not symmetric and not absent. +4. Retrieve the public key using `kid` from the protected header. +5. Verify the COSE_Sign1 signature per RFC 9052 Section 4.4. +6. (All remaining verification steps — key revocation, algorithm alignment with WIT, issuer matching, audience, expiration, iat freshness, required claims, pol_decision, DAG validation — are **identical** to the JWT variant and are incorporated by reference.) + +#### 2.11 — Audit Ledger Considerations + +The ledger entry structure for CBOR ECTs: + +```cbor-diag +{ + "ledger_sequence": 42, + "task_id": h'550e8400e29b41d4a716446655440001', + "agent_id": "spiffe://example.com/agent/clinical", + "action": "recommend_treatment", + "parents": [], + "ect_cose": h'D28443...', ; Full COSE_Sign1 bytes + "signature_verified": true, + "verification_timestamp": 1(1772064151), + "stored_timestamp": 1(1772064151) +} +``` + +Note: Ledgers that need to store both JWT and CBOR ECTs SHOULD use a discriminator field or detect the format from the raw bytes. + +#### 2.12 — Size Comparison + +Include a concrete size comparison between the JWT and CBOR variants for the "Complete ECT Example" from the JWT draft (Section 4.8). Calculate approximate sizes: + +- **JWT variant**: JOSE header (~70 bytes) + payload (~600 bytes JSON) + signature (~88 bytes ES256) + Base64url overhead (~33%) ≈ ~1010 bytes +- **CBOR variant**: Protected header (~15 bytes CBOR) + payload (~250 bytes CBOR) + signature (~64 bytes raw P-256) ≈ ~330 bytes + +This ~3x reduction is significant for constrained environments. Document the exact calculation. + +#### 2.13 — Security Considerations + +Reference the JWT draft's security considerations in full and add CBOR/COSE-specific considerations: + +- **CBOR canonicalization**: Discuss deterministic encoding (RFC 8949 Section 4.2) requirements for ECT payloads to ensure consistent hashing and signature verification. +- **COSE algorithm agility**: Same constraints as JWT variant — no symmetric algorithms, no "none". +- **CoAP-specific**: DTLS or OSCORE MUST be used for transport security when using CoAP. +- **MQTT-specific**: TLS MUST be used. Note that MQTT User Properties are not encrypted by MQTT itself. +- **Binary transport**: Emphasize that ECT signatures provide message-level security, but transport-layer integrity is still RECOMMENDED. + +#### 2.14 — Privacy Considerations + +Reference the JWT draft's privacy considerations. Note that CBOR's binary encoding does not change the privacy properties — the same claims are present, just encoded differently. + +#### 2.15 — IANA Considerations + +Request the following registrations: + +1. **Media Type**: `application/wimse-exec+cwt` +2. **CoAP Content-Format**: For `application/wimse-exec+cwt` (TBD number) +3. **CWT Claims**: Register all ECT-specific claim keys (300-317 or wherever allocated) in the "CBOR Web Token (CWT) Claims" registry (IANA). +4. **ECT-CBOR Policy Decision Values**: Integer enum registry (0=approved, 1=rejected, 2=pending_human_review) +5. **ECT-CBOR Regulated Domain Values**: Integer enum registry (0=medtech, 1=finance, 2=military) +6. **CoAP Option Number** (if defining a CoAP option): TBD + +#### 2.16 — Examples + +Provide CBOR diagnostic notation examples parallel to the JWT draft's examples: + +1. **Simple Two-Agent Workflow** — Show the CBOR diagnostic notation for the same scenario as JWT Example 1. +2. **Medical Device SDLC** — Show at least 2 tasks from the SDLC example in CBOR diagnostic notation. +3. **Parallel Execution with Join** — Show the join task with multiple parents. + +For each example, show: +- The CBOR diagnostic notation of the protected header +- The CBOR diagnostic notation of the payload +- A hex dump of the serialized COSE_Sign1 (abbreviated, showing structure) + +#### 2.17 — Related Work / Appendix + +Add a brief section mapping this draft to the JWT draft and to other CBOR-based standards: +- Reference how CWT relates to JWT (RFC 8392 ↔ RFC 7519) +- Reference how COSE relates to JOSE (RFC 9052 ↔ RFC 7515) +- Note that EAT (Entity Attestation Token, RFC 9711 if published) uses CWT and could be a future integration point. +- Reference SUIT (Software Update for IoT) manifests as another CBOR-based constrained-environment standard. + +### Step 3 — Output Structure + +Create the output in a folder called `cbor-variant/` containing: + +``` +cbor-variant/ +├── draft-nennemann-wimse-execution-context-cbor-00.md # The complete I-D in kramdown-rfc format +├── README.md # Build instructions, relationship to JWT draft +└── claim-mapping.md # Standalone claim mapping reference table +``` + +### Step 4 — Quality Checks + +Before finalizing, verify: + +- [ ] Every claim from the JWT draft has a CBOR mapping +- [ ] All REQUIRED/OPTIONAL designations match the JWT draft +- [ ] The CDDL schema is syntactically valid +- [ ] COSE_Sign1 structure is correctly defined per RFC 9052 +- [ ] All IANA registrations are complete +- [ ] The verification procedure is complete (by reference + COSE-specific steps) +- [ ] The DAG validation is incorporated by reference, not redefined +- [ ] Security considerations cover CBOR/COSE-specific threats +- [ ] Examples use valid CBOR diagnostic notation +- [ ] The kramdown-rfc metadata is well-formed +- [ ] Normative references are complete and correctly formatted +- [ ] The document can be processed by `kramdown-rfc` without errors +- [ ] BCP 14 boilerplate is included +- [ ] The abstract does not contain references (per I-D nits rules) + +## Key Design Principles + +1. **Semantic equivalence**: The CBOR ECT MUST carry exactly the same information as the JWT ECT. No semantic divergence. +2. **Format optimization**: Use CBOR's strengths — binary UUIDs, integer keys, compact encoding, structured hash representation. +3. **Reference, don't redefine**: The JWT draft is the normative semantic definition. This draft defines the encoding and transport mapping. DAG validation, verification logic, operational modes, and security model are incorporated by reference. +4. **IETF conventions**: Follow CBOR/COSE/CWT conventions established by existing RFCs. Don't invent new patterns where existing ones work. +5. **Independent adoption**: The CBOR draft should be usable independently (with the JWT draft as a normative reference for semantics), not require both formats in a single deployment. + +## Author Information + +``` +Christian Nennemann +Independent Researcher +Email: ietf@nennemann.de +```