Fix build errors: duplicate anchors, missing ref, back-matter numbering

- Add unique anchors for security subsections that collided with
  protocol section anchors (level-1/2/3, x509-binding, wimse-binding)
- Fix broken {{jwt-claims}} reference to {{exec-claims}}
- Fix I-D.oauth-transaction-tokens-for-agents reference (add manual
  entry since bibxml3 lookup fails)
- Remove RFC2119/8174 from YAML normative block (bcp14-tagged
  boilerplate adds them automatically)
- Add {:numbered="false"} to all back-matter subsections

Build now succeeds: XML, TXT, and HTML generated cleanly.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-ect.md

@@ -23,12 +23,10 @@ author:
     email: ietf@nennemann.de
 
 normative:
-  RFC2119:
   RFC7515:
   RFC7517:
   RFC7518:
   RFC7519:
-  RFC8174:
   RFC9449:
   RFC9562:
   RFC9110:
@@ -49,7 +47,12 @@ informative:
       - org: Cloud Native Computing Foundation
   I-D.ietf-scitt-architecture:
   I-D.ietf-oauth-transaction-tokens:
-  I-D.bertocci-oauth-transaction-tokens-for-agents:
+  I-D.oauth-transaction-tokens-for-agents:
+    title: "Transaction Tokens for Agentic AI Systems"
+    target: https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/
+    date: 2025
+    author:
+      - fullname: Vittorio Bertocci
   RFC9334:
 
 --- abstract
@@ -347,7 +350,7 @@ verification steps:
 
 3.  Verify that the "jti" has not been previously seen within the
     expiration window, consistent with the replay detection
-    requirement in {{jwt-claims}}.
+    requirement in {{exec-claims}}.
 
 4.  Verify the "exp" claim indicates the ECT has not expired.
 
@@ -959,7 +962,7 @@ perceived ordering.
 
 ## Level-Specific Security Properties {#level-security}
 
-### Level 1
+### Level 1 {#sec-level-1}
 
 L1 provides no cryptographic binding between the ECT and its
 issuer.  A compromised or malicious intermediary with access to
@@ -974,14 +977,14 @@ organization, the transport channel is fully trusted (e.g.,
 service mesh with mTLS), and the deployment does not require
 non-repudiation or tamper evidence beyond transport security.
 
-### Level 2
+### Level 2 {#sec-level-2}
 
 L2 inherits all security properties of the JWS-based ECT
 mechanism defined in this document.  The existing security
 analysis (signature verification, replay prevention, key
 compromise, collusion) applies directly to L2.
 
-### Level 3
+### Level 3 {#sec-level-3}
 
 L3 provides all L2 security properties plus tamper-evident
 history via the audit ledger's hash chain and cryptographic
@@ -1151,7 +1154,7 @@ Implementations SHOULD limit the "pred" array to a maximum of
 
 ## Identity Binding Security
 
-### JWK Set Binding
+### JWK Set Binding {#sec-jwk-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
@@ -1160,7 +1163,7 @@ 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
+### X.509 Binding {#sec-x509-binding}
 
 When identity is bound via X.509 certificates, revocation checking
 depends on OCSP responder or CRL distribution point availability.
@@ -1172,7 +1175,7 @@ Implementations MAY soft-fail for L2 with logging, accepting the
 ECT but recording the revocation check failure for subsequent
 audit review.
 
-### WIMSE Binding
+### WIMSE Binding {#sec-wimse-binding}
 
 When identity is bound via WIMSE trust bundles, the same
 time-of-check/time-of-use concern applies to trust bundle
@@ -1444,6 +1447,7 @@ 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
@@ -1503,6 +1507,7 @@ 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)
+{:numbered="false"}
 
 In a document processing pipeline, a customer's orchestration
 agent coordinates with third-party vendor agents across
@@ -1578,6 +1583,7 @@ 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
@@ -1608,6 +1614,7 @@ 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
@@ -1619,6 +1626,7 @@ 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.
@@ -1638,6 +1646,7 @@ 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.
@@ -1661,7 +1670,7 @@ However, "req_wl" cannot form a DAG because:
   linear "req_wl" string cannot express that relationship.
 
 Extensions for agentic use cases
-({{I-D.bertocci-oauth-transaction-tokens-for-agents}}) add agent
+({{I-D.oauth-transaction-tokens-for-agents}}) add agent
 identity and constraints ("agentic_ctx") but no execution
 ordering or DAG structure.
 
@@ -1677,6 +1686,7 @@ 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
@@ -1692,6 +1702,7 @@ 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
@@ -1704,6 +1715,7 @@ 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.
@@ -1722,6 +1734,7 @@ SCITT Transparency Service as the audit ledger backend,
 recording ECTs as supply chain statements about agent execution.
 
 ## RATS (Remote Attestation Procedures)
+{:numbered="false"}
 
 RATS {{RFC9334}} defines an architecture for conveying attestation
 evidence about platform trustworthiness.  RATS attests "is this