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

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"}