From eb79c6998a36fe06ce25c80eff3555e24a496d87 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Fri, 6 Mar 2026 19:58:04 +0100 Subject: [PATCH] Apply comprehensive review fixes to draft-nennemann-wimse-ect-01 Critical fixes: - Add RFC 2119/8174 to normative refs, move RFC 9449 to normative - Rewrite level detection algorithm with precise parsing order (JWS first, then base64url-decode for L1) - Add downgrade attack analysis and minimum-level policy requirement - Complete application/wimse-exec+jwt IANA registration template - Fix bare draft-00 citations, fix I-D reference anchor format - Rewrite abstract to remove changelog language Medium fixes: - Add jti replay check to L1 verification procedure - Add L3 async failure handling (notify downstream, treat as L2) - Add L3 sync timeout retry/fallback guidance - Add identity binding security subsection (JWK caching, OCSP failure policy, trust bundle refresh) - Add audit ledger threats subsection (availability, split-view, receipt authenticity, async gap) - Collapse redundant Section 9 into HTTP Error Handling - Remove redundant L3 verification steps for iss/aud - Add L2 use case (multi-vendor SaaS document pipeline) Low fixes: - Strengthen ext object limits from SHOULD NOT to MUST NOT - Add level negotiation future work note - Document L1 DAG validation limitation without ledger - Add alg=none defense-in-depth note - Strengthen self-assertion limitation for L1 - Add workflow topology leakage to privacy considerations - Add cross-workflow correlation to privacy considerations - Add RATS (RFC 9334) to related work - Expand SCITT comparison with L3 audit ledger parallel - Pin SPIFFE reference to specific version URL - Clean up redundant {:numbered="false"} in back matter Co-Authored-By: Claude Opus 4.6 --- draft-nennemann-wimse-ect.md | 436 ++++++++++++++++++++++++++++------- 1 file changed, 352 insertions(+), 84 deletions(-) diff --git a/draft-nennemann-wimse-ect.md b/draft-nennemann-wimse-ect.md index e411037..ae8c529 100644 --- a/draft-nennemann-wimse-ect.md +++ b/draft-nennemann-wimse-ect.md @@ -23,10 +23,13 @@ author: email: ietf@nennemann.de normative: + RFC2119: RFC7515: RFC7517: - RFC7519: RFC7518: + RFC7519: + RFC8174: + RFC9449: RFC9562: RFC9110: @@ -35,8 +38,8 @@ informative: I-D.ietf-wimse-arch: I-D.ietf-wimse-s2s-protocol: SPIFFE: - title: "Secure Production Identity Framework for Everyone (SPIFFE)" - target: https://spiffe.io/docs/latest/spiffe-about/overview/ + title: "SPIFFE ID" + target: https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md date: false OPENTELEMETRY: title: "OpenTelemetry Specification" @@ -45,9 +48,9 @@ informative: author: - org: Cloud Native Computing Foundation I-D.ietf-scitt-architecture: - RFC9449: I-D.ietf-oauth-transaction-tokens: - I-D.oauth-transaction-tokens-for-agents: + I-D.bertocci-oauth-transaction-tokens-for-agents: + RFC9334: --- abstract @@ -61,11 +64,10 @@ agnostic and can operate with any asymmetric key infrastructure including WIMSE WIT/WPT, X.509 certificates, OAuth-based credentials, or plain JWK sets. -This revision introduces three assurance levels — Level 1 -(unsigned JSON), Level 2 (JOSE asymmetric signing), and Level 3 -(JOSE signing with audit ledger) — allowing deployments to choose -the appropriate trade-off between simplicity and regulatory -compliance. +ECTs support three assurance levels — Level 1 (unsigned JSON), +Level 2 (JOSE asymmetric signing), and Level 3 (JOSE signing with +audit ledger) — allowing deployments to choose the appropriate +trade-off between simplicity and regulatory compliance. --- middle @@ -119,7 +121,7 @@ Level 2 (L2) — JOSE Asymmetric Signing: L2 provides non-repudiation and tamper detection. This is the baseline assurance level for cross-organization and peer-to-peer deployments. L2 corresponds to the behavior - defined in draft-nennemann-wimse-ect-00. + defined in Version -00 of this specification. Level 3 (L3) — JOSE Signing with Audit Ledger: : L3 extends L2 by requiring that every ECT be recorded in an @@ -276,8 +278,10 @@ ext: Implementations that do not understand extension claims MUST ignore them. Extension key names SHOULD use reverse domain notation (e.g., "com.example.custom_field") to avoid - collisions. The serialized "ext" object SHOULD NOT exceed - 4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels. + collisions. The serialized "ext" object MUST NOT exceed + 4096 bytes and MUST NOT exceed a nesting depth of 5 levels. + Receivers MUST reject ECTs whose "ext" object exceeds these + limits. ## Complete ECT Payload Example @@ -314,12 +318,14 @@ defined in {{ect-payload}}. No cryptographic signature is applied. ### L1 Transport {#l1-transport} -L1 ECTs are transported as serialized JSON. Two mechanisms are -defined: +L1 ECTs are transported as base64url-encoded JSON (without +padding). Two mechanisms are defined: HTTP Header: : The Execution-Context header field ({{http-header}}) carries - the base64url-encoded JSON payload (without padding). + the base64url-encoded JSON payload (without padding). The + header value is NOT raw JSON; the receiver MUST base64url-decode + the value before parsing. HTTP Body: : When the ECT is the primary request payload, the ECT MAY be @@ -339,14 +345,18 @@ verification steps: 2. Verify that all required claims ("jti", "iat", "exp", "exec_act", "pred") are present and well-formed. -3. Verify the "exp" claim indicates the ECT has not expired. +3. Verify that the "jti" has not been previously seen within the + expiration window, consistent with the replay detection + requirement in {{jwt-claims}}. -4. Verify the "iat" claim is not unreasonably far in the past +4. Verify the "exp" claim indicates the ECT has not expired. + +5. Verify the "iat" claim is not unreasonably far in the past (RECOMMENDED maximum: 15 minutes) and is not unreasonably far in the future (RECOMMENDED: no more than 30 seconds ahead of the verifier's current time). -5. Perform DAG validation per {{dag-validation}}. +6. Perform DAG validation per {{dag-validation}}. If any verification step fails, the ECT MUST be rejected and the failure MUST be logged. @@ -368,6 +378,12 @@ L1 does NOT provide: - Issuer authentication at the ECT layer (identity depends entirely on the transport layer) +Note: At L1, without a deployed audit ledger, DAG parent +existence validation ({{dag-validation}} step 2) is limited to +parent ECTs received inline with the current request. Parents +from prior requests that were not forwarded inline cannot be +verified. + L1 MUST NOT be used across trust domain boundaries. Deployments using L1 SHOULD restrict it to internal environments where all agents are operated by the same organization and @@ -377,7 +393,7 @@ transport security is considered sufficient. At Level 2, an ECT is a JSON Web Token (JWT) {{RFC7519}} signed as a JSON Web Signature (JWS) {{RFC7515}}. L2 corresponds to the -signing behavior defined in draft-nennemann-wimse-ect-00. +signing behavior defined in Version -00 of this specification. ECTs MUST use JWS Compact Serialization (the base64url-encoded `header.payload.signature` format) so that they can be carried in @@ -414,7 +430,7 @@ alg: typ: : REQUIRED. MUST be set to "exec+jwt" to distinguish ECTs from other JWT types. WIMSE deployments MAY use "wimse-exec+jwt" - for backward compatibility with draft-nennemann-wimse-ect-00. + for backward compatibility with Version -00 of this specification. Verifiers MUST accept both values. kid: @@ -575,7 +591,11 @@ Asynchronous Recording: MUST subsequently verify that the ledger accepted the ECT and MUST retain the receipt. If the ledger rejects the ECT, the agent MUST alert the workflow coordinator or log a critical - error. + error. If asynchronous ledger recording fails, the producing + agent MUST notify downstream agents that the ECT's L3 status + is unconfirmed. Downstream agents SHOULD treat such an ECT as + L2-verified (not L3-verified) until ledger confirmation is + independently obtainable. Deployments SHOULD use synchronous recording unless latency constraints make it impractical. The recording mode SHOULD be @@ -586,23 +606,27 @@ documented in the deployment's security policy. L3 verification consists of L2 verification ({{l2-verification}}) followed by ledger verification: +Note: The "iss" and "aud" claims, which are RECOMMENDED at L1 +and verified at L2 (steps 8-9 of {{l2-verification}}), are +REQUIRED at L3. + 1. Perform all L2 verification steps (steps 1 through 14 of {{l2-verification}}). -2. Verify the "iss" claim is present (REQUIRED at L3). - -3. Verify the "aud" claim is present (REQUIRED at L3). - -4. Submit the ECT to the audit ledger for recording per +2. Submit the ECT to the audit ledger for recording per {{l3-recording}}. -5. Verify that the ledger returned a valid receipt containing +3. Verify that the ledger returned a valid receipt containing the sequence number, ECT hash, and cryptographic commitment proof. -6. If synchronous recording is required by deployment policy and +4. If synchronous recording is required by deployment policy and the ledger does not return a receipt within the configured - timeout, the ECT MUST be treated as unverified. + timeout, the agent SHOULD retry with exponential backoff. + If the ledger remains unavailable after a + deployment-configured number of retries, the agent MUST + either reject the ECT or downgrade to L2 verification per + deployment policy. If any L3-specific verification step fails, the ECT MUST be rejected even if L2 verification succeeded. @@ -649,24 +673,33 @@ workflows within the same infrastructure. When agents at different levels interact, the higher level's verification requirements apply to the receiving agent. +This specification does not define a level negotiation mechanism. +Deployments configure the required assurance level out of band. +A future extension MAY define in-band level signaling. + ## Backward Compatibility and Level Detection {#level-detection} A verifier determines the assurance level of a received ECT as follows: -1. If the Execution-Context header value or body content parses - as valid JSON (not JWS Compact Serialization), the ECT is L1. +1. If the raw Execution-Context header value (or body content) + contains exactly two period (".") characters separating three + non-empty segments, attempt to parse the value as JWS Compact + Serialization. If the first segment base64url-decodes to a + JSON object containing an "alg" field, the ECT is L2 or L3. -2. If the value parses as JWS Compact Serialization (three - Base64url-encoded segments separated by periods), the ECT is - L2 or L3. +2. Otherwise, base64url-decode the header value (without padding) + and attempt to parse the result as JSON. If successful, the + ECT is L1. -3. L2 and L3 use the same JWS format. Differentiation between - L2 and L3 is a matter of deployment policy: L3 deployments - require ledger recording ({{l3-ledger}}), while L2 - deployments treat ledger recording as optional. +3. If neither parse succeeds, the ECT MUST be rejected. -Implementations compliant with draft-nennemann-wimse-ect-00 are +L2 and L3 use the same JWS format. Differentiation between +L2 and L3 is a matter of deployment policy: L3 deployments +require ledger recording ({{l3-ledger}}), while L2 +deployments treat ledger recording as optional. + +Implementations compliant with Version -00 of this specification are L2-compatible. No changes to existing -00 implementations are required for L2 interoperability. @@ -778,6 +811,17 @@ parent task IDs across all received ECTs represents the complete set of parent dependencies available for the receiving agent's subsequent ECT. +## HTTP Error Handling + +When ECT verification fails during HTTP request processing, the +receiving agent SHOULD respond with HTTP 403 (Forbidden) if the +agent's identity credential is valid but the ECT is invalid, and +HTTP 401 (Unauthorized) if the ECT signature verification fails. +The response body SHOULD include a generic error indicator without +revealing which specific verification step failed. The receiving +agent MUST NOT process the requested action when ECT verification +fails. + # DAG Validation {#dag-validation} ECTs form a Directed Acyclic Graph (DAG) where each task @@ -830,36 +874,6 @@ locally due to replication lag. Implementations MAY defer validation to allow parent ECTs to arrive, but MUST NOT treat the ECT as verified until all parent references are resolved. -# Signature and Token Verification {#verification} - -## Level Detection - -Before performing verification, the verifier MUST determine the -assurance level of the received ECT per {{level-detection}}. If -the ECT is L1 (unsigned JSON), the verifier follows the L1 -verification procedure ({{l1-verification}}) and skips all -signature-related steps. If the ECT is L2 or L3 (JWS), the -verifier follows the L2 verification procedure -({{l2-verification}}) and, for L3 deployments, the additional -ledger verification steps ({{l3-verification}}). - -## L2/L3 Verification Procedure - -The L2 verification procedure is defined in {{l2-verification}}. -For L3 deployments, the additional steps in {{l3-verification}} -MUST also be performed. - -## HTTP Error Handling - -When ECT verification fails during HTTP request processing, the -receiving agent SHOULD respond with HTTP 403 (Forbidden) if the -agent's identity credential is valid but the ECT is invalid, and -HTTP 401 (Unauthorized) if the ECT signature verification fails. -The response body SHOULD include a generic error indicator without -revealing which specific verification step failed. The receiving -agent MUST NOT process the requested action when ECT verification -fails. - # Audit Ledger Interface {#ledger-interface} ECTs MAY be recorded in an immutable audit ledger for compliance @@ -981,6 +995,24 @@ mechanism ({{l3-ledger}}) provides evidence of submission. Deployments concerned about ledger censorship SHOULD use multiple independent ledger replicas. +## Assurance Level Downgrade Attacks + +The assurance level of an ECT is determined by its format: unsigned +JSON indicates L1, while a JWS compact serialization indicates L2 +or L3. This format-based detection determines what was sent, not +what was expected by the verifier. + +A man-in-the-middle or compromised proxy could strip the JWS +signature from an L2 or L3 ECT and re-encode the payload as an +unsigned L1 JSON object. Because the resulting ECT is +syntactically valid at L1, a verifier that accepts any assurance +level would process it without detecting the downgrade. + +Verifiers MUST be configured with a minimum acceptable assurance +level and MUST reject ECTs whose detected level falls below that +minimum. Format-based level detection alone is insufficient +without a policy-enforced minimum level requirement. + ## Self-Assertion Limitation {#self-assertion-limitation} ECTs are self-asserted by the executing agent. The agent claims @@ -1001,6 +1033,11 @@ environment. ECTs provide a technical mechanism for execution recording; they do not by themselves satisfy any specific regulatory compliance requirement. +At Level 1, the self-assertion limitation is compounded by the +absence of any cryptographic binding; any entity with access to +the transport channel can create ECTs claiming any identity and +any action. + ## Signature Verification For L2 and L3 deployments, ECTs MUST be signed with the agent's @@ -1019,6 +1056,12 @@ be logged. Implementations MUST use established JWS libraries and MUST NOT implement custom signature verification. +The prohibition of "alg": "none" (see {{l2-verification}}) also +serves as defense against level-confusion attacks: an L1 payload +wrapped in a JWS with alg=none would be detected as L2 by format +and rejected at the algorithm allowlist check, preventing an +attacker from bypassing L2 security requirements. + ## Replay Attack Prevention ECTs include short expiration times (RECOMMENDED: 5-15 minutes) @@ -1106,6 +1149,72 @@ higher tolerance and SHOULD document the configured value. Implementations SHOULD limit the "pred" array to a maximum of 256 entries. See {{extension-claims}} for "ext" size limits. +## Identity Binding Security + +### JWK Set Binding + +When identity is bound via JWK Set URI (see {{identity-binding}}), +there is a time-of-check/time-of-use gap between JWK set +refreshes. A key that has been removed from the JWK set may still +be accepted by a verifier whose cached copy has not yet been +refreshed. Implementations SHOULD refresh JWK sets at +configurable intervals (RECOMMENDED: no longer than 5 minutes). + +### X.509 Binding + +When identity is bound via X.509 certificates, revocation checking +depends on OCSP responder or CRL distribution point availability. +If the revocation source is unreachable, the verifier must decide +whether to accept or reject the ECT. Implementations SHOULD +hard-fail for L3 (reject the ECT if revocation status cannot be +determined), as L3 workflows require the strongest assurance. +Implementations MAY soft-fail for L2 with logging, accepting the +ECT but recording the revocation check failure for subsequent +audit review. + +### WIMSE Binding + +When identity is bound via WIMSE trust bundles, the same +time-of-check/time-of-use concern applies to trust bundle +refreshes. Implementations SHOULD refresh trust bundles +frequently to minimize the window during which a revoked or +rotated identity remains accepted. + +## Audit Ledger Threats + +### Availability + +If the audit ledger is unavailable in synchronous recording mode +(see {{l3-ledger}}), all L3 workflows halt because agents cannot +obtain ledger receipts. Deployments SHOULD implement ledger +redundancy (e.g., multiple ledger replicas behind a load balancer) +to prevent the ledger from becoming a single point of failure. + +### Split-View Attacks + +A compromised ledger could present different views to different +verifiers (equivocation), causing inconsistent audit state across +the deployment. Deployments SHOULD use multiple independent +ledger replicas and SHOULD periodically compare their state to +detect divergence. + +### Receipt Authenticity + +If the ledger's signing key is compromised, an attacker can +generate fake receipts for entries that were never recorded. +Ledger signing keys SHOULD be stored in hardware security modules +(HSMs) and SHOULD be rotated regularly. + +### Asynchronous Recording Gap + +In asynchronous recording mode (see {{l3-ledger}}), downstream +agents act on ECTs before ledger confirmation is received. +During this gap, an ECT that will ultimately fail ledger recording +may already have influenced downstream workflow steps. Deployments +using asynchronous recording SHOULD implement reconciliation +procedures to detect and handle ECTs that fail ledger confirmation +after downstream processing has begun. + # Privacy Considerations ## Data Exposure in ECTs @@ -1153,6 +1262,24 @@ SHOULD be stored separately from the ledger with additional access controls, since auditors may need to verify hash correctness but general access to the data values is not needed. +## Workflow Topology Leakage + +The DAG structure of ECTs reveals workflow topology: which agents +interact, fan-out and fan-in patterns, sequential versus parallel +execution, and organizational structure. At L3, this topology is +permanently recorded in the audit ledger. Deployments SHOULD +consider whether workflow topology constitutes sensitive information +and apply appropriate access controls to ECT stores and ledgers. + +## Cross-Workflow Correlation + +Stable agent identifiers in the "iss" claim enable cross-workflow +activity correlation: an observer with access to ECTs from multiple +workflows can track which agents participate in which workflows and +how frequently. Deployments with privacy requirements MAY use +per-workflow or rotating agent identifiers where feasible to limit +cross-workflow correlation. + # IANA Considerations ## Media Type Registrations @@ -1217,11 +1344,61 @@ Change controller: ### application/wimse-exec+jwt This document also registers "application/wimse-exec+jwt" as an -alias for backward compatibility with draft-nennemann-wimse-ect-00. -The registration details are identical to "application/exec+jwt" -above except for the subtype name. WIMSE deployments MAY use -either media type; new deployments SHOULD prefer -"application/exec+jwt". +alias for backward compatibility with Version -00 of this specification. +WIMSE deployments MAY use either media type; new deployments +SHOULD prefer "application/exec+jwt". + +Type name: +: application + +Subtype name: +: wimse-exec+jwt + +Required parameters: +: none + +Optional parameters: +: none + +Encoding considerations: +: 8bit; at Level 2 and Level 3, an ECT is a JWT that is a JWS + using the Compact Serialization, which is a sequence of + Base64url-encoded values separated by period characters. At + Level 1, this media type is not used; L1 ECTs use + application/json. + +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 agentic workflows requiring execution + context tracing and audit trails. + +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 ## HTTP Header Field Registration {#header-registration} @@ -1267,7 +1444,6 @@ readability. In production, all "jti" values are required to be UUIDs per {{exec-claims}}. ## Cross-Organization Financial Trading (L3) -{:numbered="false"} In a cross-organization trading workflow, an investment bank's agents coordinate with an external credit rating agency. The @@ -1326,8 +1502,82 @@ demonstrating cross-organizational fan-in. The compliance agent verifies both parent ECTs — one signed by a local key and one by a federated key from the rating agency's trust domain. +## Multi-Vendor SaaS Integration (L2) + +In a document processing pipeline, a customer's orchestration +agent coordinates with third-party vendor agents across +organizational boundaries. The customer uploads documents that +pass through an OCR vendor for text extraction, then fan out to +a translation vendor for multi-language output, before results +converge back at the customer's storage agent. + +This workflow uses Level 2 (JOSE signing without audit ledger) +because the cross-organization boundary requires non-repudiation +— each vendor must prove it performed its step — but no +regulatory audit ledger is mandated. + +~~~ +Trust Domain: customer.example + Agent C1 (Orchestrator): + jti: task-201 pred:[] + iss: spiffe://customer.example/agent/orchestrator + exec_act: initiate_document_pipeline + +Trust Domain: ocr-vendor.example (external) + Agent V1 (OCR Extractor): + jti: task-202 pred:[task-201] + iss: spiffe://ocr-vendor.example/agent/ocr + exec_act: extract_text + +Trust Domain: translate-vendor.example (external) + Agent V2a (Translator EN→DE): + jti: task-203 pred:[task-202] + iss: spiffe://translate-vendor.example/agent/translate + exec_act: translate_de + + Agent V2b (Translator EN→FR): + jti: task-204 pred:[task-202] + iss: spiffe://translate-vendor.example/agent/translate + exec_act: translate_fr + +Trust Domain: customer.example + Agent C2 (Storage): + jti: task-205 pred:[task-203, task-204] + iss: spiffe://customer.example/agent/storage + exec_act: store_results +~~~ +{: #fig-saas title="Multi-Vendor SaaS Document Pipeline (L2)"} + +The resulting DAG: + +~~~ +task-201 (initiate_document_pipeline) + [customer.example] + | + v +task-202 (extract_text) + [ocr-vendor.example] + / \ + v v +task-203 task-204 +(translate_de) (translate_fr) +[translate-vendor] [translate-vendor] + \ / + v v +task-205 (store_results) + [customer.example] +~~~ +{: #fig-saas-dag title="Multi-Vendor SaaS DAG"} + +Task 202 fans out to two parallel translation tasks (203 and +204) at the translation vendor, demonstrating cross-vendor +fan-out. Task 205 performs fan-in, requiring both translations +to complete before storing the combined results. Each vendor's +ECT is signed with that vendor's private key, providing +cross-organizational non-repudiation without requiring an +external audit ledger. + ## Internal Microservice Mesh (L1) -{:numbered="false"} In an internal AI platform, multiple microservices coordinate to process requests. All agents operate within a single trust domain @@ -1358,7 +1608,6 @@ Trust Domain: internal.example {:numbered="false"} ## WIMSE Workload Identity -{:numbered="false"} The WIMSE architecture {{I-D.ietf-wimse-arch}} and service-to- service protocol {{I-D.ietf-wimse-s2s-protocol}} provide one @@ -1370,7 +1619,6 @@ systems. ECTs define an explicit WIMSE identity binding (see {{wimse-binding}}) but are not limited to WIMSE deployments. ## OAuth 2.0 Token Exchange and the "act" Claim -{:numbered="false"} {{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and registers the "act" (Actor) claim in the JWT Claims registry. @@ -1390,7 +1638,6 @@ two concepts are orthogonal: "act" records "who authorized whom," ECTs record "what was done, in what order." ## Transaction Tokens -{:numbered="false"} OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}} propagate authorization context across workload call chains. @@ -1414,7 +1661,7 @@ However, "req_wl" cannot form a DAG because: linear "req_wl" string cannot express that relationship. Extensions for agentic use cases -({{I-D.oauth-transaction-tokens-for-agents}}) add agent +({{I-D.bertocci-oauth-transaction-tokens-for-agents}}) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure. @@ -1430,7 +1677,6 @@ hash-bind a WPT to a co-present Txn-Token; a similar binding mechanism for ECTs is a potential future extension. ## Distributed Tracing (OpenTelemetry) -{:numbered="false"} OpenTelemetry {{OPENTELEMETRY}} and similar distributed tracing systems provide observability for debugging and monitoring. ECTs @@ -1446,7 +1692,6 @@ ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. ## W3C Provenance Data Model (PROV) -{:numbered="false"} The W3C PROV Data Model defines an Entity-Activity-Agent ontology for representing provenance information. PROV's concepts map @@ -1459,7 +1704,6 @@ cryptographic signatures. ECT audit data could be exported to PROV format for interoperability with provenance-aware systems. ## SCITT (Supply Chain Integrity, Transparency, and Trust) -{:numbered="false"} The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a framework for transparent and auditable supply chain records. @@ -1467,6 +1711,30 @@ ECTs and SCITT are complementary: the ECT "wid" claim can serve as a correlation identifier in SCITT Signed Statements, linking an ECT audit trail to a supply chain transparency record. +There is a notable parallel between SCITT's Transparency Service +and ECT's Level 3 audit ledger: both use append-only logs with +cryptographic commitment to provide tamper-evident recording. +SCITT Signed Statements use COSE for their envelope format while +ECTs use JOSE, but the architectural pattern — transparent, +verifiable recording of statements about artifacts or actions — +is shared. A deployment requiring L3 assurance could use a +SCITT Transparency Service as the audit ledger backend, +recording ECTs as supply chain statements about agent execution. + +## RATS (Remote Attestation Procedures) + +RATS {{RFC9334}} defines an architecture for conveying attestation +evidence about platform trustworthiness. RATS attests "is this +platform in a trustworthy state?" while ECTs record "what did +this agent do?" — both deal with claims about entities but at +different layers. RATS operates at the platform and firmware +layer, establishing that a workload's execution environment has +not been tampered with, whereas ECTs operate at the application +layer, recording the logical sequence of tasks performed by +agents. ECTs could complement RATS by recording execution +context on platforms whose trustworthiness has been established +through RATS attestation. + # Acknowledgments {:numbered="false"}