A Capability-Oriented Intent Routing Protocol

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Non-Goals

The following topics are explicitly outside the scope of this specification:¶

• Orchestration, coordination, or workflow semantics between endpoints.¶
• Economic models, billing, pricing, or monetization of capabilities.¶
• Reputation, ranking, or quality-of-service scoring of providers.¶
• Capability namespace governance beyond the reserved prefix defined in Section 5.4.¶
• Registry federation synchronization protocol. (Federation is acknowledged but defined in a companion specification.)¶
• Application payload interpretation, validation, or transformation.¶
• NAT traversal mechanisms beyond registry-mediated locator distribution.¶

3.1. Layer Model

The protocol operates at Layer 1 in the following conceptual stack:¶

+---------------------------------------------------+
| Layer 3: Domain Applications                      |
|   DSL-specific logic, vertical solutions          |
+---------------------------------------------------+
| Layer 2: Implementation Ecosystems                |
|   Agent frameworks, SDKs, runtime environments    |
+---------------------------------------------------+
| Layer 1: Intent Routing Transport  [this document]|
|   Capability addressing, discovery, sessions,     |
|   invocation envelopes, receipts                  |
+---------------------------------------------------+
| Layer 0: Cryptographic Identity                   |
|   Ed25519 keypairs, EID derivation                |
+---------------------------------------------------+

This document specifies Layer 1. Layers above the transport are unconstrained by this specification: any agent framework, domain-specific language, or application architecture may operate over CIRP provided it uses the defined capability addressing, session establishment, and invocation envelope formats.¶

Layer 0 is the identity foundation. An Endpoint Identifier (EID) is the Ed25519 public key of a node. Because EID equals the public key, identity verification requires no certificate authority, no public key infrastructure, and no trusted third party. A node proves its identity by signing messages with the corresponding private key.¶

3.2. Protocol Roles

Three roles participate in the protocol:¶

Registry

A Registry provides two services: capability discovery (mapping capability identifiers to Provider endpoints) and session authorization (issuing ConnectTickets that permit direct peer-to-peer sessions). A Registry does not participate in data plane communication and never observes invocation content or session keys. Multiple Registries MAY operate concurrently, and endpoints MAY interact with different Registries for different capabilities.¶

Consumer

A Consumer discovers capabilities through a Registry, obtains authorization via a ConnectTicket, and initiates a direct session with a Provider to send invocations and receive fulfillments.¶

Provider

A Provider advertises capabilities to one or more Registries via presence announcements, accepts authorized sessions from Consumers, processes invocations, and returns fulfillment responses.¶

A single endpoint MAY act as both Consumer and Provider simultaneously for different capabilities. The protocol does not impose a fixed client-server relationship; any endpoint with a cryptographic identity may assume either role.¶

3.3. Trust Assumptions

The protocol operates under the following trust model:¶

Endpoints are self-sovereign

Each endpoint generates its own Ed25519 keypair and derives its EID from the public key. No registration authority or certificate issuer is required. Identity is established through cryptographic proof, not through delegation.¶

Registries are semi-trusted

Registries are trusted to perform discovery and authorization honestly, but they are not trusted with session content. The protocol is designed so that a compromised or malicious Registry cannot forge endpoint identities, decrypt data plane traffic, or tamper with invocation records. A detailed analysis of what a Registry can and cannot do is provided in Section 11.¶

The network is untrusted

The protocol assumes an active network attacker who can observe, inject, modify, and replay messages. All data plane communication is encrypted and authenticated. Control plane messages are signed. Tickets are bound to specific identities and time-limited.¶

4.1. Control Plane

The control plane handles registry-mediated operations: presence registration, capability advertisement, discovery queries, admission control, and ConnectTicket issuance. Control plane messages are exchanged between endpoints and registries.¶

Control plane messages are small, fixed-structure, and designed to fit within a single transport datagram for typical deployments. This design prioritizes low-latency registry interactions and avoids fragmentation on common network paths.¶

The control plane does not carry invocation content. It handles only the metadata necessary for discovery and session authorization.¶

4.2. Data Plane

The data plane handles peer-to-peer communication between consumer and provider after session establishment. All data plane traffic is encrypted using session keys derived during key exchange (Section 7.4). The registry is not involved in data plane operations: it does not relay data, does not possess session keys, and cannot observe invocation content.¶

The data plane carries invocation envelopes, response envelopes, and fulfillment records as defined in Section 9 and Section 10. Payload content within these envelopes is opaque to the transport.¶

4.3. Transport Binding

This specification defines the protocol abstractly in terms of messages exchanged between roles. A transport binding maps these abstract messages onto a concrete network transport.¶

The initial transport binding is UDP. Control plane messages are exchanged as UDP datagrams between endpoints and registries. Data plane encrypted frames are exchanged as UDP datagrams between peers. Implementations are responsible for handling MTU constraints and chunking large payloads into multiple datagrams as needed.¶

The protocol does not rely on TCP semantics. It does not assume ordered delivery, connection state, or stream-oriented framing at the transport layer. Each protocol message is self-contained within its datagram.¶

Future transport bindings (for example, QUIC) may be defined in companion specifications. The protocol's message semantics are transport-independent; only the framing and delivery characteristics change with the binding.¶

4.4. Congestion Control

Implementations using the UDP transport binding MUST conform to the guidelines in [RFC8085]. In particular:¶

The control plane (Section 4.1) is self-limiting: each discovery query produces at most one response, presence announcements are periodic with configurable intervals, and admission exchanges are bounded by session establishment rate. Deployments MUST ensure that control plane traffic does not constitute sustained high-rate uncontrolled UDP transmission.¶

The data plane (Section 4.2) carries application traffic within encrypted frames. Implementations that sustain high-rate data plane traffic MUST implement appropriate congestion control. CIRP does not define a congestion control algorithm; implementations MAY use any mechanism that provides appropriate congestion response, including rate limiting, application-level pacing, or integration with a congestion-controlled transport (such as QUIC in a future binding).¶

Implementations SHOULD implement per-destination rate limiting on control plane transmissions to prevent amplification. A registry that receives a high rate of discovery queries for a single capability SHOULD apply local rate limits rather than forwarding unbounded traffic to providers.¶

4.5. Flow Control

CIRP does not define a protocol-level flow control mechanism. Each endpoint manages its own resource consumption locally. Implementations SHOULD enforce local limits on:¶

Maximum inbound frame rate per session. Maximum encrypted frame size (bounded by the MTU of the underlying transport binding). Maximum concurrent sessions per endpoint.¶

If an endpoint's local capacity is exceeded, it SHOULD stop reading from the transport socket, allowing natural backpressure. The sending peer will observe increased loss (for UDP) or reduced throughput (for future congestion-controlled bindings) and adapt accordingly.¶

Sessions that exceed locally configured resource bounds MAY be terminated via the idle timeout mechanism (Section 8.7) or via an authenticated close frame.¶

5.1. URI Syntax

A capability URI uses the "cap" scheme and has the following structure:¶

cap-uri   = "cap:" path "/" version
path      = segment 1*("." segment)
segment   = ALPHA *(ALPHA / DIGIT / "-")
version   = "v" major "." minor
major     = 1*DIGIT
minor     = 1*DIGIT

The path component consists of dot-delimited segments forming a hierarchical namespace. The grammar requires at least two segments (one dot), establishing a minimum structure of namespace.action. Deeper hierarchies are permitted (e.g., "acme.robotics.arm.wave").¶

Segments MUST begin with an ASCII letter and MAY contain ASCII letters, digits, and hyphens. Segments are case-sensitive.¶

Examples of valid capability URIs:¶

cap:echo.ping/v1.0
cap:robot.wave/v1.0
cap:acme.robotics.arm.wave/v2.1
cap:org.medical.imaging.analyze/v1.0

Examples of invalid capability URIs:¶

cap:echo/v1.0          (single segment, no dot)
cap:robot.wave         (missing version)
cap:robot.wave/1.0     (version missing "v" prefix)
cap:123.test/v1.0      (segment begins with digit)

5.2. Versioning

Every capability URI MUST include a version component in the format "v" followed by major.minor integers. Both the major and minor version numbers are REQUIRED.¶

Version matching in this specification uses exact semantics: a Provider advertising cap:x.y/v1.2 MUST NOT fulfill requests for cap:x.y/v1.3 unless the Provider explicitly advertises that version as well. Consumers MUST include the complete version in all discovery requests and invocation envelopes.¶

Compatible-range version matching (where a request for v1.2 could be fulfilled by a Provider advertising v1.3) is not defined in this specification. Future revisions MAY define version compatibility semantics.¶

5.3. Capability Hashing

For wire efficiency, capabilities are referenced in protocol messages by their hash rather than their full URI string. The capability hash is the SHA-256 digest of the capability's canonical name string.¶

The canonical name string is the path component of the capability URI including the version suffix, without the "cap:" scheme prefix. For the capability URI "cap:acme.robotics.arm.wave/v1.0", the canonical name string is the exact UTF-8 byte sequence of "acme.robotics.arm.wave/v1.0". The format is "{path}/v{major}.{minor}" where {path} is the dotted capability path and "v{major}.{minor}" follows the version grammar defined in Section 5.2.¶

The hash input is case-sensitive. No case folding, Unicode normalization, or whitespace removal is applied. The hash is computed over the exact UTF-8 byte sequence.¶

For indexed lookups, the cap64 index key is the first 8 bytes of the 32-byte SHA-256 digest, interpreted as a big-endian unsigned 64-bit integer.¶

The following test vectors are normative. Any implementation that produces a different digest for either input has a conformance error.¶

Vector 1: Input "system.echo/v1.0" produces SHA-256 e81664e525710d5a2d0cece876c00f10ed79dec5d6c775869c5723fff7018ca7 and cap64 0xe81664e525710d5a.¶

Vector 2: Input "acme.robotics.arm.wave/v1.0" produces SHA-256 386ed68f47809bde0663dc04a322766fd55aa9cdd41d7b6a1e147a90f9d96b85 and cap64 0x386ed68f47809bde.¶

Capability hashes are used in Authorization Requests (Section 7.2), ConnectTickets (Section 7.2.1), and presence advertisements. The full URI string is carried only in invocation envelopes (Section 9) where human readability and version information are required.¶

5.4. Namespace Considerations

The prefix "cap:proto." is RESERVED for capabilities defined by this protocol and its companion specifications. Implementations MUST NOT advertise capabilities under the "proto" namespace unless those capabilities are defined in a CIRP specification document.¶

Namespace allocation and governance beyond the reserved prefix is a deployment concern. A registry for well-known capability namespaces may be established in a future revision of this specification. Deployments SHOULD use organizational domain names in reverse notation (e.g., "com.example.service.action") to minimize namespace collisions.¶

6.1. Discovery Queries

A Consumer discovers Providers by sending a FIND_EX_REQUEST (TLV type 0x76) to a Registry. The request is a fixed-size 64-byte payload:¶

capability_hash (32 bytes)

The SHA-256 hash of the desired capability, computed as specified in Section 5.3.¶

initiator_eid (32 bytes)

The Consumer's Endpoint Identifier.¶

The Consumer does not need to be authenticated to submit a discovery query, but the Registry MAY require the Consumer to be in an admitted state depending on deployment policy.¶

Future revisions of this specification may define additional discovery message types that carry parameters such as result limits or locality hints. These are out of scope for the initial protocol binding.¶

6.2. Discovery Responses

The Registry responds with a FIND_EX_RESPONSE (TLV type 0x77) containing at most one Provider entry. The response includes a status code indicating the outcome and, on success, the following fields:¶

provider_eid (32 bytes)

The Provider's Endpoint Identifier.¶

provider_locator (7 or 19 bytes)

The Provider's network locator, consisting of an address type indicator (1 byte: 0x04 for IPv4, 0x06 for IPv6), a port number (2 bytes, big-endian), and the IP address (4 or 16 bytes). The locator reflects the Provider's observed network address as determined by the Registry, not a self-reported value.¶

The Registry uses the Provider's observed network address (the source address of the Provider's most recent presence message) as the authoritative locator. Self-reported addresses in presence messages are not used for routing, preventing stale or spoofed locators from directing traffic to incorrect endpoints.¶

Providers whose most recent presence beacon is older than a deployment-configured freshness threshold are excluded from query results. The freshness check uses the original beacon timestamp as recorded by the originating Registry, not timestamps assigned during inter-Registry synchronization. This prevents synchronized records from appearing artificially fresh.¶

When a Registry applies policy that modifies the result set (e.g., scope restrictions or tier-based limits), the response SHOULD include a Policy Receipt indicating the nature and reason for the modification. This supports the principle that policy enforcement is permitted but silent policy enforcement is not: consumers and diagnostic tools can observe how policies affect discovery results.¶

6.3. Capability Scoping

Capability advertisements carry a scope descriptor that controls their visibility during discovery. Scope enforcement is performed by the Registry during query processing, not by peer-side filtering logic. This ensures that scope is enforced consistently regardless of Consumer implementation.¶

Five scope levels are defined:¶

Scope Descriptor
+-------+------+----------------------------------------+
|Offset | Size | Field                                  |
+-------+------+----------------------------------------+
|   0   |   1  | scope_level                            |
|   1   | 0/32 | qualifier (present for levels 0x01-0x03)|
+-------+------+----------------------------------------+

Total size:
  Global (0x04):        1 byte
  Local (0x00):         1 byte
  Identity (0x01):     33 bytes (1 + 32-byte target EID)
  Trust Domain (0x02): 33 bytes (1 + 32-byte anchor hash)
  Organization (0x03): 33 bytes (1 + 32-byte anchor hash)

6.4. Federated Discovery

In deployments with multiple Registries, Providers may register with different Registries. To provide a consistent view of available capabilities, Registries MAY synchronize presence information through a federation protocol.¶

When a Registry includes federated records in Discovery Responses, the freshness of those records MUST be evaluated using the original beacon timestamp as recorded by the Provider's home Registry, not the timestamp at which the record was received via federation. This prevents synchronized records from bypassing freshness filters.¶

The federation synchronization protocol is outside the scope of this specification and will be defined in a companion document.¶

6.5. Per-Capability Discovery Index

A Provider that advertises multiple capabilities SHOULD emit a TLV_CAP_LIST frame (type 0x41) alongside each Presence announcement. A Provider that advertises multiple capabilities and does not emit TLV_CAP_LIST will not be discoverable by individual capability and will only be reachable via aggregate-hash discovery. The payload format is:¶

+--------+-----------------+------------------------------------------+
| 0x41   | Length (BE u16) | eid[32] | cap_hash_0[32] | ... | cap_N  |
+--------+-----------------+------------------------------------------+

The first 32 bytes of the payload are the Provider's Endpoint Identifier. The remainder is a sequence of 32-byte capability hashes, one per advertised capability. There is no explicit count field; the number of capabilities is derived from the payload length: cap_count = (payload_length - 32) / 32.¶

If the payload length is less than 32 bytes, or if (payload_length - 32) is not evenly divisible by 32, the frame is malformed and MUST be silently discarded per standard TLV processing rules.¶

TLV_CAP_LIST is a companion to the Presence announcement and MAY arrive in the same transport datagram or in a separate datagram. If a TLV_CAP_LIST arrives before any Presence record exists for the given EID, the Registry SHOULD hold it in a short-lived pending cache (RECOMMENDED 5-second TTL, bounded to a deployment-configurable maximum entry count) and apply it when the next Presence announcement for that EID arrives.¶

The Registry MUST maintain a per-capability discovery index that maps the first 8 bytes of each individual capability hash to sets of EIDs. When processing a Discovery Query, the Registry MUST check the per-capability index first. If results are found, those are returned. If the per-capability index contains no entries for the requested hash, the Registry MUST fall back to the aggregate capability index for backward compatibility with Providers that do not emit TLV_CAP_LIST.¶

6.6. Discovery Scope Exclusions

The following functions are explicitly outside the scope of the discovery mechanism defined in this specification:¶

Capability name resolution. The protocol operates exclusively on capability hashes. Translation from human-readable names, aliases, partial strings, or natural-language descriptions to canonical capability identifiers is a client-side concern and is not defined by this specification. Implementations MAY provide resolution libraries or local catalogs, but these are not part of the protocol.¶

Capability enumeration. The protocol does not provide a mechanism for a Consumer to enumerate all capabilities available on the network. Discovery is query-by-hash only. A Consumer MUST know the hash of the capability it seeks. Registry-wide enumeration would create privacy and scalability concerns incompatible with the protocol's design goals.¶

Fuzzy or semantic matching. The Registry performs exact hash comparison only. Approximate matching, natural-language understanding, embedding-based similarity, and recommendation are application-layer concerns above the transport protocol. The protocol's hash-based discovery ensures deterministic, reproducible results regardless of implementation.¶

Capability ranking or recommendation. Within a given scope, discovery results are unranked. The protocol does not define ordering, scoring, or preferential treatment of Providers. Any ranking, prioritization, or recommendation of discovery results is a platform concern outside the scope of this specification.¶

7.1. Registry Discovery

A Consumer MAY be aware of multiple Registries through configuration, DNS service records, or prior interaction. When multiple Registries are available, the Consumer SHOULD select the Registry with the lowest measured round-trip latency to minimize authorization delay.¶

Latency measurement is performed by sending a Probe message to each candidate Registry and measuring the time until a ProbeResponse is received. The Probe message contains an 8-byte nonce; the ProbeResponse echoes the nonce and MAY include the Registry's geographic locality hint. Registries MUST process Probe messages before any authentication or admission checks to ensure the measured latency reflects network conditions rather than processing overhead.¶

Probe messages are subject to a separate rate limit from other Registry interactions to prevent measurement traffic from interfering with authorization and discovery operations.¶

7.2. Authorization and Ticket Issuance

To establish a session with a Provider of a given capability, the Consumer sends an Authorization Request to a Registry. The request contains the SHA-256 hash of the desired capability URI and the Consumer's Endpoint Identifier (EID).¶

Upon receiving an Authorization Request, the Registry performs the following steps in order:¶

1. Validates that the Consumer is in an admitted state. If not, the Registry returns a NotAdmitted status and takes no further action.¶
2. Checks per-Consumer, per-capability rate limits. If the request exceeds the Consumer's rate allocation, the Registry returns a RateLimited status.¶
3. Queries its capability directory for Providers currently advertising the requested capability. Providers whose most recent presence beacon is older than a freshness threshold (measured from original beacon timestamp, not from any intermediate synchronization event) are excluded from the candidate set.¶
4. Applies any applicable visibility scope restrictions (see Section 6).¶
5. Selects a Provider from the eligible candidate set.¶
6. Mints a ConnectTicket binding the Consumer, the selected Provider, and the requested capability.¶
7. Signs the ConnectTicket with the Registry's current signing key.¶
8. Returns an Authorization Response containing the Provider's EID, the Provider's network locator, and the signed ConnectTicket.¶

ConnectTicket (272 bytes)
+-------+------+----------------------------------------+
|Offset | Size | Field                                  |
+-------+------+----------------------------------------+
|   0   |  32  | consumer_eid                           |
|  32   |  32  | consumer_vk                            |
|  64   |  32  | provider_eid                           |
|  96   |  32  | capability_hash                        |
| 128   |   1  | scope_flags                            |
| 129   |   1  | tier                                   |
| 130   |   2  | rate_window_secs (BE)                  |
| 132   |   1  | rate_limit                             |
| 133   |   8  | issued_at (Unix seconds, BE)           |
| 141   |   8  | expires_at (Unix seconds, BE)          |
| 149   |  16  | nonce                                  |
| 165   |   8  | bucket_id                              |
| 173   |  32  | issuer_eid                             |
| 205   |   1  | issuer_key_id                          |
| 206   |   2  | issuer_locality (top 16 bits)          |
| 208   |  64  | signature (Ed25519, over bytes 0..208) |
+-------+------+----------------------------------------+

7.3. Cryptographic Suite Negotiation

After receiving an Authorization Response with a ConnectTicket, the Consumer initiates a direct connection to the Provider. Before exchanging key material, the peers MUST negotiate a cryptographic suite.¶

Suite negotiation occurs as the first exchange on the peer-to-peer channel, before any key exchange messages. This keeps the Registry out of cryptographic decisions and avoids coupling Registry upgrades to cipher suite changes.¶

CIRP_X25519_ED25519_CHACHA20POLY1305_SHA256

  Key agreement:          X25519 [RFC7748]
  Authentication:         Ed25519 [RFC8032]
  Symmetric encryption:   ChaCha20-Poly1305 [RFC8439]
  Key derivation:         HKDF-SHA-256 [RFC5869]

CIRP_X25519MLKEM768_ED25519_CHACHA20POLY1305_SHA256

  Key agreement:          X25519 [RFC7748] combined with
                          ML-KEM-768 [FIPS203]
  Authentication:         Ed25519 [RFC8032]
  Symmetric encryption:   ChaCha20-Poly1305 [RFC8439]
  Key derivation:         HKDF-SHA-256 [RFC5869]

7.4. Key Exchange

After suite negotiation, the peers perform a key exchange to establish shared session keys. The key exchange protocol depends on the negotiated suite but follows a uniform structure.¶

For classical suites:
  ikm = classical_ss

For hybrid suites:
  ikm = classical_ss || pq_ss

PRK   = HKDF-Extract(salt=session_id, ikm)
key   = HKDF-Expand(PRK, info, L=32)

where:
  session_id = 16-byte session identifier
  info       = "cirp-hybrid-kx" || suite_id ||
               consumer_eid || provider_eid
  L          = 32 (256 bits, for ChaCha20-Poly1305)

7.5. Encrypted Session

Once session keys are derived, the peers communicate using authenticated encrypted frames. Each frame uses ChaCha20-Poly1305 [RFC8439] for authenticated encryption with associated data (AEAD).¶

The encrypted frame format is:¶

Encrypted Frame
+-------+------+----------------------------------------+
|Offset | Size | Field                                  |
+-------+------+----------------------------------------+
|   0   |   4  | magic (0x41 0x49 0x43 0x46)            |
|   4   |  16  | session_id                             |
|  20   |   8  | counter (monotonic, BE)                |
|  28   |  12  | nonce (ChaCha20-Poly1305)              |
|  40   |   N  | ciphertext                             |
| 40+N  |  16  | authentication_tag (Poly1305)          |
+-------+------+----------------------------------------+
Minimum frame size: 56 bytes (empty payload)

The counter field is a monotonically increasing 64-bit integer, incremented for each frame sent within a session. Receivers MUST reject frames with a counter value less than or equal to the highest counter previously accepted in the same session. This provides replay protection without requiring synchronized state beyond the highest seen counter.¶

The nonce is constructed deterministically from the counter and session key material. Implementations MUST NOT reuse a nonce with the same key.¶

The protocol imposes no semantic limit on payload size within encrypted frames. Implementations MAY enforce practical limits based on the underlying transport binding. For UDP transport, implementations typically target application payloads that fit within common path MTU limits and handle larger payloads through fragmentation and reassembly at the session layer.¶

The ciphertext is opaque to the transport layer. It carries application data (including intent invocation envelopes as defined in Section 9) without interpretation, canonicalization, or transformation by the transport.¶

7.6. Session Capability Binding

Prior to establishing a session, the Provider MUST verify that the capability_hash field of the presented ConnectTicket identifies a capability that the Provider actively advertises. Formally, the Provider MUST confirm that ticket.capability_hash is a member of the set of per-capability hashes for which the Provider maintains current presence advertisements. If the capability_hash does not match any actively advertised capability, the Provider MUST reject the connection attempt with reason CapabilityNotServed (0x04).¶

Upon successful session establishment, the session MUST retain the authorized capability_hash as immutable session state. The capability binding is fixed at session creation and MUST NOT change for the lifetime of the session. Implementations MUST NOT permit rebinding of a session to a different capability after establishment.¶

The bound capability_hash MUST be available to the application layer for the purposes of session routing and audit. Providers serving multiple capabilities MUST use this binding to dispatch inbound sessions to the appropriate capability handler.¶

The capability match verification set and the per-capability advertisement set MUST be maintained as a single atomic unit. If these sets can diverge, a ticket issued for a discovered capability could be rejected after discovery, or a ticket for a withdrawn capability could be accepted.¶

7.7. Session Lifecycle and Teardown

A CIRP session transitions through five states: IDLE, DISCOVERY, AUTHORIZED, ESTABLISHED, and CLOSED. Once ESTABLISHED, the session remains active until one of the following conditions is met:¶

Idle Timeout. If no encrypted frame (as defined in Section 7.5) is received from the remote peer within the locally configured inactivity window, the endpoint MUST transition the session to CLOSED and release all associated resources. The idle timeout is the normative teardown mechanism for CIRP sessions.¶

Implementations SHOULD use a default idle timeout of 120 seconds. Deployments MAY configure smaller values for resource-constrained or latency-sensitive environments. The idle timeout is a local configuration parameter; it is not negotiated between peers and need not be symmetric. Each endpoint independently manages its own session lifetime.¶

Authenticated Close. An endpoint MAY send an encrypted control frame (type 0x01) within the AEAD-protected channel to signal intentional session termination. This frame carries a CloseReason code: 0x00 Normal (orderly shutdown), 0x01 GoingAway (endpoint shutting down), 0x02 PolicyViolation (peer violated session constraints), 0x03 InternalError (unrecoverable local failure).¶

Receipt of an authenticated close frame SHOULD cause the local endpoint to transition the session to CLOSED. The authenticated close is a courtesy notification; the idle timeout provides the normative guarantee that abandoned sessions do not persist indefinitely.¶

Unauthenticated Close Prohibition. Implementations MUST NOT transition session state based on receipt of any unauthenticated message. In particular, plaintext frames carrying session identifiers MUST be silently discarded without affecting session state. Any session teardown signal that is not protected by the session's AEAD keys is indistinguishable from a spoofed packet and MUST be ignored.¶

Session Identifier Uniqueness. Each session MUST use a unique session_id generated from a cryptographically secure random source. A session_id MUST NOT be reused across sessions between the same pair of endpoints. Implementations SHOULD use 128-bit (16-octet) random values.¶

Key Material Erasure. Upon transition to CLOSED, implementations MUST erase all ephemeral key material associated with the session, including X25519 private keys, derived session encryption keys, and AEAD nonce state. Implementations SHOULD use explicit memory zeroization rather than relying on garbage collection or deallocation.¶

7.8. Backward Compatibility

The per-capability discovery mechanism (TLV_CAP_LIST, type 0x41) is designed for incremental deployment with no flag day. Implementations MUST NOT require coordinated upgrades. Each side may upgrade independently. Full per-capability discovery activates when both Provider and Registry support TLV_CAP_LIST.¶

Pre-0x41 Provider with pre-0x41 Registry: discovery operates via the aggregate capability index only. Single-capability Providers are discoverable; multi-capability Providers require exact aggregate hash match.¶

Pre-0x41 Provider with 0x41-aware Registry: the Provider does not emit TLV_CAP_LIST. The Registry receives no per-capability hashes. FIND_EX queries fall back to the aggregate index. No degradation.¶

0x41-aware Provider with pre-0x41 Registry: the Provider emits TLV_CAP_LIST (0x41). The Registry does not recognize type 0x41 and silently ignores it per standard TLV processing rules. Discovery continues via the aggregate index. No error, no degradation.¶

0x41-aware Provider with 0x41-aware Registry: the Provider emits TLV_CAP_LIST alongside Presence announcements. The Registry indexes each individual capability hash. Multi-capability Providers are fully discoverable by any single capability they advertise.¶

7.9. Wire Compatibility

The changes described in this revision introduce no modifications to existing wire formats. The Presence beacon (TLV 0x35) format is unchanged. The ConnectTicket wire format (272 octets) is unchanged. The FIND_EX_REQUEST (TLV 0x76) and FIND_EX_RESPONSE (TLV 0x77) formats are unchanged.¶

TLV_CAP_LIST (type 0x41) is a new, additive TLV frame type. It does not replace or modify any existing frame. Per the TLV forward-compatibility rule, receivers that do not recognize type 0x41 silently ignore the frame.¶

The encrypted frame format (Section 7.5) is unchanged. The addition of an authenticated close control frame (type 0x01 within the AEAD-protected channel) uses the existing encrypted frame envelope and does not modify the frame header.¶

No existing TLV type codes have been reassigned or removed. Implementations conforming to the previous revision will interoperate with implementations conforming to this revision without modification.¶

8.1. Control Plane Framing

Control plane messages between endpoints and Registries use a type-length-value (TLV) envelope:¶

Control Plane TLV Envelope
+-------+------+----------------------------------------+
|Offset | Size | Field                                  |
+-------+------+----------------------------------------+
|   0   |   1  | message_type                           |
|   1   |   2  | payload_length (BE)                    |
|   3   | var  | payload                                |
+-------+------+----------------------------------------+

The message_type field identifies the control plane operation (e.g., presence announcement, discovery query, authorization request). The payload_length field is a 16-bit big-endian unsigned integer specifying the number of bytes following the header.¶

8.2. Data Plane Framing

Data plane messages between peers use magic-byte prefixed frames. Two frame types are defined:¶

Key Exchange Frame (magic: 0x41 0x49 0x4B 0x58, ASCII "AIKX")

Carries suite negotiation, ephemeral public keys, and signatures during session establishment (Section 7.4). Fixed structure: magic (4 bytes) + session_id (16) + role (1) + ephemeral_pk (32) + signature (64) = 117 bytes for classical suites. Hybrid suites include additional key material.¶

Encrypted Frame (magic: 0x41 0x49 0x43 0x46, ASCII "AICF")

Carries encrypted application data including invocation and fulfillment envelopes. Structure defined in Section 7.5: magic (4) + session_id (16) + counter (8) + nonce (12) + ciphertext (N) + tag (16). Minimum 56 bytes.¶

Receivers distinguish control plane from data plane messages by inspecting the first byte: TLV type values occupy a different range from the ASCII 'A' (0x41) that begins both data plane magic sequences.¶

8.3. Framing Properties

The framing layer provides the following guarantees:¶

Payload opacity

The framing layer does not inspect, parse, or transform the contents of encrypted frames. Ciphertext is carried as opaque bytes.¶

Byte safety

No canonicalization, character encoding conversion, or normalization is applied to payload data at any layer of the protocol. Binary payloads are preserved exactly as submitted.¶

Replay protection

Encrypted frames carry a monotonically increasing counter. Receivers reject frames with counter values not greater than the highest previously accepted value in the same session.¶

9.1. Request Envelope

The invocation request envelope contains the following fields, encoded as a CBOR map with integer keys:¶

The Consumer MUST generate the invocation_id using a cryptographically secure random number generator. Invocation identifiers are used for correlation between requests, responses, error frames, and fulfillment records.¶

The signature is computed over the canonical CBOR encoding of a map containing keys 1 through 7 with their values. The Consumer uses its Ed25519 signing key (the private key corresponding to consumer_eid) to produce the signature. This binds the invocation content to the Consumer's identity and prevents tampering in transit.¶

9.2. Response Envelope

The Provider responds to an invocation with a fulfillment response encoded as a CBOR map:¶

The Provider MUST include the request_hash computed over the entire request envelope as received. This cryptographically binds the response to the specific request, preventing a malicious party from associating a valid response with a different request.¶

When the fulfillment_status is 0x02 (application error), the payload field carries application-specific error information. The protocol does not define the structure of application-level errors; they are opaque bytes interpreted solely by the Consumer and Provider.¶

9.3. Error Semantics

CIRP distinguishes between protocol-level errors and application-level errors. Application-level errors are carried inside the response payload (fulfillment_status 0x02) and are opaque to the protocol. Protocol-level errors indicate failures in session establishment, authorization, or transport that prevent an invocation from reaching the Provider or a response from reaching the Consumer.¶

Protocol-level errors are conveyed in signed error frames. Signing error frames prevents an active network attacker from injecting spurious errors to disrupt communication.¶

An error frame is encoded as a CBOR map:¶

10.1. Fulfillment Record Structure

The fulfillment record is encoded as a CBOR map using deterministic encoding ([RFC8949], Section 4.2). The record is constructed in two phases:¶

10.2. Timestamp Model

The fulfillment record contains four timestamps representing the complete round-trip of an invocation:¶

Consumer              Provider
   |                     |
   |-- consumer_send_ts  |
   |   (request sent)    |
   |                     |
   |         provider_recv_ts --
   |         (request received) |
   |                     |
   |         provider_send_ts --
   |         (response sent)    |
   |                     |
   |-- consumer_recv_ts  |
   |   (response received)|
   |                     |

Timestamps are encoded as unsigned 64-bit integers representing milliseconds since the Unix epoch (1970-01-01T00:00:00Z).¶

Clock synchronization between Consumer and Provider is NOT assumed. Each party records timestamps using its own local clock. The timestamp model is designed for relative timing analysis rather than absolute time agreement:¶

Provider processing time

provider_send_ts - provider_recv_ts (single clock, reliable).¶

Observed round-trip time

consumer_recv_ts - consumer_send_ts (single clock, reliable).¶

Estimated one-way latency

(consumer_recv_ts - consumer_send_ts) - (provider_send_ts - provider_recv_ts), divided by two. This estimate requires no clock synchronization because the subtracted intervals are each measured on a single clock.¶

The consumer_send_ts and provider_send_ts fields are REQUIRED (MUST be present). The provider_recv_ts and consumer_recv_ts fields SHOULD be present; omitting them degrades the usefulness of the receipt for latency analysis but does not invalidate the record.¶

Implementations MUST NOT reject receipts solely because timestamps appear inconsistent (e.g., provider_recv_ts earlier than consumer_send_ts). Such inconsistency indicates clock skew, not necessarily fraud. Implementations MAY flag such records for review.¶

10.3. Hash Chaining

Each invocation request envelope includes a prev_invocation_hash field (see Section 9.1) that references the SHA-256 hash of the immediately preceding request envelope in the same Consumer-Provider relationship. For the first invocation between a given Consumer and Provider, this field is set to 32 zero bytes.¶

This creates a hash chain that provides the following properties:¶

Ordering evidence

Each invocation cryptographically references its predecessor, establishing an order that cannot be rearranged without detection.¶

Deletion detection

Removing an invocation from the chain breaks the hash reference in the subsequent invocation, making omission detectable.¶

Per-relationship isolation

The chain is scoped to a specific Consumer-Provider pair. Invocations between different pairs maintain independent chains.¶

Hash chains are maintained by the Consumer. A Consumer MUST track the hash of its most recent request envelope for each active Provider relationship. If a Consumer loses this state (e.g., due to a restart), it SHOULD set prev_invocation_hash to 32 zero bytes, effectively starting a new chain. The Provider MAY note chain resets for audit purposes but MUST NOT reject invocations solely because the hash chain was reset.¶

11.1. Threat Model

The protocol is designed to resist the following adversaries:¶

Active network attacker

An adversary positioned on the network path who can observe, inject, modify, delay, replay, and drop messages. This is the standard Dolev-Yao network attacker model.¶

Compromised Registry

A Registry that deviates from protocol specification, either through compromise or malicious operation. The analysis bounds what such a Registry can achieve.¶

Compromised peer

An endpoint whose long-term signing key has been compromised. The analysis addresses the impact on past and future sessions.¶

Harvest-now-decrypt-later attacker

An adversary who records encrypted traffic today with the expectation of decrypting it in the future using advances in cryptanalysis or quantum computing.¶

11.2. Mutual Authentication

Every endpoint in CIRP is identified by its Ed25519 [RFC8032] public key. The Endpoint Identifier (EID) is the public key itself, not a hash or derivative. This identity model has several consequences:¶

• No certificate authority is required. Identity is self-asserted and verified by checking signatures against the claimed EID.¶
• Impersonation requires possession of the victim's Ed25519 private key. There is no weaker path (such as compromising a CA) to forge an identity.¶
• All protocol messages that assert identity (ConnectTickets, SuiteOffer, SuiteSelect, KeyExchange, invocation envelopes, response envelopes, error frames, and fulfillment records) are signed by the originator's Ed25519 key.¶

During session establishment, mutual authentication is achieved through the following chain: the Consumer proves identity by signing the SuiteOffer (which includes the ConnectTicket naming the Consumer's EID), and the Provider proves identity by signing the SuiteSelect and KeyExchange messages using the key corresponding to the EID named in the ticket's provider_eid field. Both parties verify these signatures before proceeding to key exchange.¶

11.3. Registry Trust Boundary

Registries occupy a semi-trusted role. The following analysis enumerates what a Registry can and cannot do, and provides cryptographic justification for each boundary.¶

11.4. Ticket Security

The ConnectTicket (Section 7.2.1) is the authorization boundary between the control plane and the data plane. Its security depends on several properties:¶

Identity binding

The ticket names both Consumer and Provider by EID. The Consumer must sign the SuiteOffer using the private key corresponding to the consumer_eid in the ticket. A stolen ticket is useless without the Consumer's private key.¶

Time bounding

The ticket carries an expires_at field. Implementations SHOULD use a 30-second validity window. Providers MUST reject expired tickets. Short validity limits the window for ticket theft and replay.¶

Nonce-based replay resistance

The ticket contains a 16-byte nonce. Providers track seen nonces and reject tickets with previously used nonces. Combined with time bounding, this limits replay to the narrow validity window.¶

Capability scoping

The ticket binds authorization to a specific capability hash. A ticket issued for one capability cannot be used to invoke a different capability.¶

Local verifiability

Providers verify the Registry's signature on the ticket using the Registry's known public key. No round-trip to the Registry is needed. This means ticket verification succeeds even if the Registry becomes temporarily unreachable after ticket issuance.¶

11.5. Forward Secrecy

Each session uses freshly generated ephemeral X25519 keypairs for key exchange. Session keys are derived from the ephemeral shared secret, not from the peers' long-term Ed25519 keys. Compromise of a peer's long-term signing key allows an attacker to impersonate that peer in future sessions, but it does not expose the session keys of previously established sessions because the ephemeral X25519 private keys are discarded after key derivation.¶

Long-term Ed25519 keys are used solely for authentication (signing key exchange messages and protocol artifacts), not for key agreement. The key agreement function (X25519) operates on independent ephemeral key material.¶

11.6. Replay Protection

Replay attacks are addressed at multiple layers:¶

Encrypted frames

Each encrypted frame carries a monotonically increasing counter (Section 7.5). Receivers reject frames with counter values less than or equal to the highest previously accepted counter in the session. Because the counter is included in the authenticated encryption, an attacker cannot modify it without detection.¶

ConnectTickets

Tickets are time-bounded (expires_at) and nonce-tracked at the Provider. Replaying an expired ticket or reusing a seen nonce results in rejection.¶

Key exchange messages

Each KeyExchange message is bound to a specific session_id and signed by the sender's long-term key. Replaying a KeyExchange message from a previous session in a new session produces a mismatched session_id, causing verification failure.¶

11.7. Downgrade Protection

Two mechanisms prevent cryptographic downgrade attacks:¶

Suite selection validation

The Consumer MUST abort the connection if the Provider selects a suite that was not present in the Consumer's SuiteOffer (Section 7.3.2). This prevents an active attacker from substituting the SuiteSelect message to force a weaker suite. Both the SuiteOffer and SuiteSelect are signed, so the attacker cannot modify them without detection.¶

Hybrid exchange integrity

When a hybrid post-quantum suite is negotiated, both the classical and post-quantum key exchanges MUST succeed (Section 7.4.2). If either fails, session establishment fails entirely. An attacker cannot force fallback to classical-only key agreement after both peers have agreed to hybrid protection.¶

11.8. Post-Quantum Transition

CIRP addresses the threat of harvest-now-decrypt-later attacks through its cryptographic agility framework and hybrid key exchange construction.¶

The protocol supports hybrid post-quantum key establishment via negotiated cipher suites. In hybrid mode, session keys are derived from both a classical X25519 shared secret and a post-quantum shared secret (e.g., from ML-KEM-768 as specified in [FIPS203]), combined through HKDF (Section 7.4.3). This construction ensures that the session key is at least as strong as the stronger of the two components: even if the post-quantum algorithm is later found to be weak, the classical component still provides security, and vice versa.¶

The suite negotiation mechanism (Section 7.3) allows new cryptographic suites to be deployed without protocol revision. As post-quantum algorithms mature and new key encapsulation mechanisms are standardized, they can be registered in the CIRP Crypto Suite Registry and adopted by implementations through normal suite negotiation.¶

Implementations MUST support suite negotiation as defined in Section 7.3. Implementations MUST support at least the mandatory classical suite. Implementations SHOULD support at least one hybrid post-quantum suite. Future revisions of this specification may strengthen the hybrid requirement to MUST as post-quantum algorithms achieve broader deployment maturity.¶

11.9. Invocation Integrity

Invocation envelopes and response envelopes are signed by the originating party using Ed25519. The signature covers the deterministic CBOR encoding of all fields except the signature itself (Section 9.1, Section 9.2). This provides:¶

• Authentication: the envelope was produced by the claimed originator.¶
• Integrity: the envelope has not been modified since signing.¶
• Non-repudiation: the originator cannot deny having produced the envelope without claiming key compromise.¶

The response envelope includes a request_hash field that binds the response to a specific request. This prevents an attacker from associating a legitimate response with a different request.¶

Fulfillment records extend these properties through cooperative dual-signing (Section 10.1), creating a mutually attested audit trail that neither party can unilaterally repudiate.¶

11.10. Error Frame Security

Protocol-level error frames are signed by the originating entity (Section 9.3). This prevents an active network attacker from injecting spurious error messages to disrupt communication. A receiver MUST verify the signature on an error frame before acting on it. Unsigned or incorrectly signed error frames MUST be discarded.¶

11.11. Scope Enforcement Security

Capability visibility scoping (Section 6.3) is enforced by the Registry during discovery. Because scope enforcement depends on the Registry correctly evaluating scope rules, a compromised Registry could bypass scope restrictions and expose capabilities intended to be private.¶

Deployments with strict confidentiality requirements for capability visibility SHOULD use dedicated Registries operated within the trust domain. Capability scoping provides defense in depth but does not replace network-level access controls where confidentiality of capability existence is critical.¶

11.12. Denial of Service Considerations

Several protocol elements are susceptible to denial of service attacks:¶

Discovery flooding

An attacker may send a high volume of discovery queries to exhaust Registry resources. Registries SHOULD implement per-source rate limiting on discovery queries. The admission control mechanism provides a first line of defense: unadmitted endpoints can be rejected before query processing begins.¶

Ticket exhaustion

An attacker may request ConnectTickets at high rate to exhaust Provider nonce tracking state. Per-consumer, per-capability rate limiting at the Registry bounds the rate at which tickets are issued. The short ticket validity window (30 seconds) limits the volume of unexpired tickets in circulation.¶

Probe flooding

An attacker who obtains valid ConnectTickets may flood a Provider with connection probes. Providers SHOULD implement per-source connection rate limits. The four-phase validation order (structural, cryptographic, semantic, replay) ensures that invalid probes are rejected with minimal processing, with cryptographically invalid probes silently dropped to prevent oracle attacks.¶

11.13. Time Skew Considerations

The protocol relies on timestamp comparison for ConnectTicket expiration checking. Clock skew between the Registry (which sets issued_at and expires_at) and the Provider (which checks expiration) may cause valid tickets to be incorrectly rejected or expired tickets to be incorrectly accepted.¶

Implementations MUST apply bounded clock skew tolerance as defined in Section 7.2.1. The RECOMMENDED 10-second leeway accommodates typical NTP drift across cloud regions (2-5 seconds) with margin. The future-rejection rule (rejecting tickets where issued_at exceeds now + leeway) prevents acceptance of tickets with severely desynchronized or maliciously future-dated issuance timestamps. Without this check, a compromised Registry could issue tickets with far-future issued_at values that would remain valid indefinitely under expiry-only validation. Deployments operating across geographically distributed infrastructure SHOULD ensure that Registry and Provider clocks are synchronized to within a few seconds using NTP or equivalent mechanisms.¶

Fulfillment record timestamps (Section 10.2) explicitly do not assume clock synchronization between Consumer and Provider. Each party records timestamps on its own clock. The timestamp model is designed for single-clock interval analysis (processing time, round-trip time) rather than cross-clock absolute time comparisons.¶

11.14. Session Teardown Security

The prohibition on unauthenticated close (Section 7.7) eliminates a denial-of-service vector present in protocols that permit unsigned session teardown. An on-path attacker who observes a session_id during session establishment cannot forge a teardown message, because all state-changing messages after session establishment are protected by AEAD encryption with keys derived from the ephemeral key exchange.¶

The idle timeout mechanism ensures that sessions are eventually reclaimed even if both endpoints lose connectivity simultaneously or if one endpoint crashes without sending an authenticated close. The combination of authenticated close (best-effort notification) and idle timeout (guaranteed reclamation) provides both promptness and reliability.¶

Implementations MUST erase ephemeral key material on session close to preserve forward secrecy. An attacker who later compromises an endpoint's long-term signing key MUST NOT be able to derive past session keys.¶

11.15. Locator Integrity and Misdirection Attacks

The FIND_EX response envelope, including the Provider's RLOC (routing locator), is not independently signed. An active attacker between Consumer and Registry could modify the RLOC to redirect the Consumer to a different network address. However, the attacker cannot complete the subsequent key exchange because it does not possess the Provider's private key. This is a misdirection-for-DoS vector, not a confidentiality or integrity compromise.¶

Deployments requiring authenticated locator distribution SHOULD use a transport binding that provides channel integrity (e.g., DTLS or QUIC).¶

12.1. CIRP Crypto Suite Registry

IANA is requested to create a "CIRP Crypto Suite Registry" with the following initial entries. New entries require Specification Required registration policy.¶

Each suite identifier encodes its component algorithms in the name: key agreement, authentication, AEAD, and KDF, separated by underscores. The algorithms for each initial entry are specified in Section 7.3.1.¶

Suite identifiers are ASCII strings. The naming convention concatenates the key agreement, authentication, AEAD, and KDF algorithm names separated by underscores, prefixed with "CIRP_".¶

The ML-KEM-768 algorithm in the hybrid suite is as specified in [FIPS203].¶

12.2. URI Scheme Registration

IANA is requested to register the "cap" URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry per [RFC7595].¶

Scheme name

cap¶

Status

Permanent¶

Applications/protocols that use this scheme

CIRP (Capability-Oriented Intent Routing Protocol)¶

Contact

IESG¶

Change controller

IETF¶

Reference

This document, Section 5.1¶

12.3. CIRP Protocol Parameters Registry

IANA is requested to create a "CIRP Protocol Parameters" registry with the following sub-registries. New entries in each sub-registry require Specification Required registration policy.¶

B.1. Multi-Capability Provider Registration

A compliance agent advertises three capabilities: compliance.assess/v1.0, compliance.report/v1.0, and compliance.audit/v1.0. The agent computes per-capability hashes:¶

cap_hash_1 = SHA-256("compliance.assess/v1.0")
cap_hash_2 = SHA-256("compliance.report/v1.0")
cap_hash_3 = SHA-256("compliance.audit/v1.0")

sorted = sort(["compliance.assess/v1.0",
                "compliance.audit/v1.0",
                "compliance.report/v1.0"])
caps_hash = SHA-256(join(sorted, "\n"))

The agent sends a single UDP datagram containing two coalesced TLVs:¶

+------+--------+------------------------------------------+
| 0x35 | len    | Presence beacon (v2)                     |
|      |        |   eid[32] + flags[1] + rloc[7] +         |
|      |        |   ttl[4] + caps_hash[32] + vk[32] +      |
|      |        |   signature[64] + token[74]?              |
+------+--------+------------------------------------------+
| 0x41 | len    | TLV_CAP_LIST                             |
|      |        |   eid[32] +                               |
|      |        |   cap_hash_1[32] +                        |
|      |        |   cap_hash_2[32] +                        |
|      |        |   cap_hash_3[32]                          |
+------+--------+------------------------------------------+

Total: 3-byte TLV header + presence payload + 3-byte TLV header + 128-byte cap list payload. Both TLVs fit within the 1400-byte MTU budget. The Registry processes both TLVs: the Presence beacon updates the aggregate index; the cap list creates three entries in the per-capability index.¶

B.2. Discovery by Individual Capability

A Consumer agent needs compliance reporting. It computes:¶

query_hash = SHA-256("compliance.report/v1.0")

The Consumer sends FIND_EX_REQUEST (TLV 0x76):¶

+------+--------+------------------------------------------+
| 0x76 | 0x0040 | capability_hash[32] + initiator_eid[32]  |
+------+--------+------------------------------------------+

The Registry checks the per-capability index for query_hash. It finds the compliance agent registered in Example B.1, because cap_hash_2 from the agent's TLV_CAP_LIST matches query_hash exactly. The Registry issues a FIND_EX_RESPONSE (TLV 0x77) containing status Success (0x00), the compliance agent's EID and RLOC, and a ConnectTicket (272 octets) binding initiator_eid + responder_eid + query_hash.¶

B.3. Capability Mismatch Rejection

A compliance agent advertises three capabilities. An attacker obtains a valid ConnectTicket where capability_hash = SHA-256("compliance.report/v1.0") and attempts to misuse it in two ways.¶

Scenario A: Ticket tampering. The attacker modifies the ticket's capability_hash field to SHA-256("compliance.audit/v1.0") before presenting the DirectProbe. The Provider verifies the ticket's Ed25519 signature. Because capability_hash is within the signed preimage (octets 0-207), the modification invalidates the signature. The Provider silently drops the probe per Phase 2 (cryptographic validation).¶

Scenario B: Session misuse. The attacker presents the unmodified ticket and successfully establishes a session. The session is bound to SHA-256("compliance.report/v1.0") at establishment time per Section 7.6. This binding is immutable. The Provider dispatches this session to the compliance.report handler. The attacker cannot reach a different capability handler through this session regardless of payload content.¶

B.4. Aggregate Index Fallback

An agent running a pre-0x41 SDK sends a Presence beacon with caps_hash but does NOT emit TLV_CAP_LIST. The agent advertises a single capability: system.echo/v1.0.¶

A Consumer queries FIND_EX with:¶

query_hash = SHA-256("system.echo/v1.0")

The Registry checks the per-capability index. No entry exists (agent did not send TLV_CAP_LIST). The Registry falls back to the aggregate index. For a single-capability agent, caps_hash equals the individual cap_hash, so the aggregate lookup succeeds. The Consumer receives a valid FIND_EX_RESPONSE and proceeds normally. The legacy agent is fully discoverable without any upgrade.¶