



Individual Submission                                           S. Verma
Internet-Draft                                               Independent
Intended status: Standards Track                        22 February 2026
Expires: 26 August 2026


             A Capability-Oriented Intent Routing Protocol
                          draft-verma-cirp-01

Abstract

   This document specifies a transport-layer protocol for routing
   capability-oriented intent between cryptographically identified
   endpoints across heterogeneous trust domains.  The protocol defines
   capability identifiers with mandatory versioning, scoped discovery
   across five visibility levels, ticket-based session authorization,
   negotiated cryptographic suites including hybrid post-quantum key
   establishment, encrypted peer-to-peer session establishment, and
   mutually attested invocation receipts with hash-chained integrity.
   Payload semantics are opaque to the transport layer.

   This revision clarifies session-level capability binding semantics,
   aligns discovery behavior with deployed FIND_EX wire formats, and
   refines session teardown security properties.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Verma                    Expires 26 August 2026                 [Page 1]

Internet-Draft                    CIRP                     February 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Layer Model . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Protocol Roles  . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Trust Assumptions . . . . . . . . . . . . . . . . . . . .   8
   4.  Transport Model . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Control Plane . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Transport Binding . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Congestion Control  . . . . . . . . . . . . . . . . . . .   9
     4.5.  Flow Control  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Capability Identifiers and Versioning . . . . . . . . . . . .  10
     5.1.  URI Syntax  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Versioning  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Capability Hashing  . . . . . . . . . . . . . . . . . . .  12
     5.4.  Namespace Considerations  . . . . . . . . . . . . . . . .  12
   6.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Discovery Queries . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Discovery Responses . . . . . . . . . . . . . . . . . . .  13
     6.3.  Capability Scoping  . . . . . . . . . . . . . . . . . . .  14
       6.3.1.  Scope Levels  . . . . . . . . . . . . . . . . . . . .  14
       6.3.2.  Scope Encoding  . . . . . . . . . . . . . . . . . . .  15
       6.3.3.  Scope Enforcement . . . . . . . . . . . . . . . . . .  16
     6.4.  Federated Discovery . . . . . . . . . . . . . . . . . . .  16
     6.5.  Per-Capability Discovery Index  . . . . . . . . . . . . .  17
     6.6.  Discovery Scope Exclusions  . . . . . . . . . . . . . . .  17
   7.  Session Establishment . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Registry Discovery  . . . . . . . . . . . . . . . . . . .  19
     7.2.  Authorization and Ticket Issuance . . . . . . . . . . . .  19
       7.2.1.  ConnectTicket Structure . . . . . . . . . . . . . . .  20
       7.2.2.  Authorization Status Codes  . . . . . . . . . . . . .  21
     7.3.  Cryptographic Suite Negotiation . . . . . . . . . . . . .  22
       7.3.1.  Suite Identifiers . . . . . . . . . . . . . . . . . .  22
       7.3.2.  Negotiation Protocol  . . . . . . . . . . . . . . . .  23



Verma                    Expires 26 August 2026                 [Page 2]

Internet-Draft                    CIRP                     February 2026


     7.4.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .  24
       7.4.1.  Classical Key Exchange  . . . . . . . . . . . . . . .  24
       7.4.2.  Hybrid Post-Quantum Key Exchange  . . . . . . . . . .  25
       7.4.3.  Key Schedule  . . . . . . . . . . . . . . . . . . . .  26
     7.5.  Encrypted Session . . . . . . . . . . . . . . . . . . . .  26
     7.6.  Session Capability Binding  . . . . . . . . . . . . . . .  27
     7.7.  Session Lifecycle and Teardown  . . . . . . . . . . . . .  28
     7.8.  Backward Compatibility  . . . . . . . . . . . . . . . . .  29
     7.9.  Wire Compatibility  . . . . . . . . . . . . . . . . . . .  30
   8.  Message Framing and Encapsulation . . . . . . . . . . . . . .  30
     8.1.  Control Plane Framing . . . . . . . . . . . . . . . . . .  30
     8.2.  Data Plane Framing  . . . . . . . . . . . . . . . . . . .  31
     8.3.  Framing Properties  . . . . . . . . . . . . . . . . . . .  31
   9.  Intent Invocation . . . . . . . . . . . . . . . . . . . . . .  31
     9.1.  Request Envelope  . . . . . . . . . . . . . . . . . . . .  32
     9.2.  Response Envelope . . . . . . . . . . . . . . . . . . . .  34
     9.3.  Error Semantics . . . . . . . . . . . . . . . . . . . . .  35
       9.3.1.  Protocol Error Codes  . . . . . . . . . . . . . . . .  36
   10. Receipts and Integrity  . . . . . . . . . . . . . . . . . . .  37
     10.1.  Fulfillment Record Structure . . . . . . . . . . . . . .  37
       10.1.1.  Phase 1: Provider Attestation  . . . . . . . . . . .  38
       10.1.2.  Phase 2: Consumer Finalization . . . . . . . . . . .  38
       10.1.3.  Receipt Verification . . . . . . . . . . . . . . . .  39
     10.2.  Timestamp Model  . . . . . . . . . . . . . . . . . . . .  40
     10.3.  Hash Chaining  . . . . . . . . . . . . . . . . . . . . .  41
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  42
     11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  42
     11.2.  Mutual Authentication  . . . . . . . . . . . . . . . . .  42
     11.3.  Registry Trust Boundary  . . . . . . . . . . . . . . . .  43
       11.3.1.  Actions a Registry Can Perform . . . . . . . . . . .  43
       11.3.2.  Actions a Registry Cannot Perform  . . . . . . . . .  43
     11.4.  Ticket Security  . . . . . . . . . . . . . . . . . . . .  44
     11.5.  Forward Secrecy  . . . . . . . . . . . . . . . . . . . .  45
     11.6.  Replay Protection  . . . . . . . . . . . . . . . . . . .  45
     11.7.  Downgrade Protection . . . . . . . . . . . . . . . . . .  46
     11.8.  Post-Quantum Transition  . . . . . . . . . . . . . . . .  46
     11.9.  Invocation Integrity . . . . . . . . . . . . . . . . . .  47
     11.10. Error Frame Security . . . . . . . . . . . . . . . . . .  47
     11.11. Scope Enforcement Security . . . . . . . . . . . . . . .  47
     11.12. Denial of Service Considerations . . . . . . . . . . . .  48
     11.13. Time Skew Considerations . . . . . . . . . . . . . . . .  48
     11.14. Session Teardown Security  . . . . . . . . . . . . . . .  49
     11.15. Locator Integrity and Misdirection Attacks . . . . . . .  49
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  49
     12.1.  CIRP Crypto Suite Registry . . . . . . . . . . . . . . .  50
     12.2.  URI Scheme Registration  . . . . . . . . . . . . . . . .  50
     12.3.  CIRP Protocol Parameters Registry  . . . . . . . . . . .  51
       12.3.1.  Error Codes  . . . . . . . . . . . . . . . . . . . .  51



Verma                    Expires 26 August 2026                 [Page 3]

Internet-Draft                    CIRP                     February 2026


       12.3.2.  Scope Types  . . . . . . . . . . . . . . . . . . . .  51
       12.3.3.  Message Types  . . . . . . . . . . . . . . . . . . .  51
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  51
     13.2.  Informative References . . . . . . . . . . . . . . . . .  52
   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  52
     B.1.  Multi-Capability Provider Registration  . . . . . . . . .  52
     B.2.  Discovery by Individual Capability  . . . . . . . . . . .  53
     B.3.  Capability Mismatch Rejection . . . . . . . . . . . . . .  54
     B.4.  Aggregate Index Fallback  . . . . . . . . . . . . . . . .  54
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  55

1.  Introduction

   Existing transport protocols provide general-purpose data delivery
   between network endpoints.  They do not address the requirements of
   systems that need to discover capabilities by function, route
   structured invocations to providers of those capabilities, and
   produce cryptographically verifiable records of fulfillment.  These
   requirements arise in domains including autonomous systems,
   industrial control, medical device coordination, software service
   composition, and other environments where heterogeneous endpoints
   must locate and invoke capabilities across trust boundaries.

   The Capability-Oriented Intent Routing Protocol (CIRP) is a
   transport-layer protocol that addresses these requirements.  It
   provides: structured capability identifiers with mandatory
   versioning; scoped discovery that respects organizational and
   cryptographic trust boundaries; ticket-based session authorization
   that removes the authorizing registry from the data path; encrypted
   peer-to-peer sessions with cryptographic agility including hybrid
   post-quantum key exchange; typed invocation envelopes with opaque
   payloads; and mutually attested fulfillment receipts.

   CIRP operates at the transport layer.  It does not interpret payload
   semantics, evaluate business logic, rank providers, manage economic
   relationships, or implement domain-specific processing.  These
   concerns belong to application layers built above the transport.  The
   protocol is designed to carry executable intent for any domain: the
   payload may contain JSON, binary protocol encodings, robotics command
   sequences, medical device instructions, industrial control messages,
   or any other octet sequence.  The concept of an "Internet of Intent"
   describes a network infrastructure where such invocations can be
   routed across heterogeneous trust domains using a common transport
   protocol.






Verma                    Expires 26 August 2026                 [Page 4]

Internet-Draft                    CIRP                     February 2026


   This document specifies the protocol messages, encoding formats,
   cryptographic operations, and security properties of CIRP.  It
   defines an initial transport binding for UDP and establishes IANA
   registries for cryptographic suites, capability URI schemes, and
   protocol parameters.

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.

2.  Terminology

   Intent  A cryptographically signed, versioned invocation of a
      capability that is routable over the network and produces a
      verifiable fulfillment response.

   Capability  A named, versioned unit of functionality addressable via
      a structured URI (Section 5).

   Endpoint Identifier (EID)  A node's cryptographic identity, equal to



Verma                    Expires 26 August 2026                 [Page 5]

Internet-Draft                    CIRP                     February 2026


      its public verification key.

   Registry  Infrastructure that provides capability discovery and
      session authorization.  Registries do not participate in data
      plane communication.

   Consumer  The party that initiates an invocation.

   Provider  The party that fulfills an invocation.

   ConnectTicket  A signed, time-bounded authorization artifact issued
      by a Registry that permits a Consumer to establish a direct
      session with a Provider.

   Trust Domain  A set of identities sharing a common trust anchor, used
      to restrict capability visibility.

   Suite  A named combination of cryptographic algorithms used for key
      exchange, authentication, encryption, and key derivation within a
      session.

   Fulfillment Record  A dual-signed receipt attesting that a specific
      invocation was processed and fulfilled, constructed cooperatively
      by Provider and Consumer (Section 10.1).

   Scope  A visibility descriptor attached to a capability advertisement
      that restricts which Consumers may discover it.  Five scope levels
      are defined (Section 6.3).

   Policy Receipt  A diagnostic record included in discovery responses
      when the Registry applies policy that modifies the result set.

3.  Architecture Overview

   CIRP defines a layered architecture for routing capability-oriented
   intent between cryptographically identified endpoints.  The
   architecture separates concerns into distinct layers, each with well-
   defined responsibilities and trust boundaries.

3.1.  Layer Model

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









Verma                    Expires 26 August 2026                 [Page 6]

Internet-Draft                    CIRP                     February 2026


   +---------------------------------------------------+
   | 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.



Verma                    Expires 26 August 2026                 [Page 7]

Internet-Draft                    CIRP                     February 2026


   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.  Transport Model

   CIRP separates protocol operations into two planes with distinct
   security properties and operational characteristics.

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.




Verma                    Expires 26 August 2026                 [Page 8]

Internet-Draft                    CIRP                     February 2026


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.





Verma                    Expires 26 August 2026                 [Page 9]

Internet-Draft                    CIRP                     February 2026


   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.  Capability Identifiers and Versioning

   Capabilities in CIRP are addressed using structured URIs that combine
   a hierarchical namespace with mandatory version information.  This
   addressing scheme enables precise discovery, prevents semantic drift
   across protocol versions, and supports independent evolution of
   capabilities within distinct organizational namespaces.

5.1.  URI Syntax

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





Verma                    Expires 26 August 2026                [Page 10]

Internet-Draft                    CIRP                     February 2026


   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.






Verma                    Expires 26 August 2026                [Page 11]

Internet-Draft                    CIRP                     February 2026


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.






Verma                    Expires 26 August 2026                [Page 12]

Internet-Draft                    CIRP                     February 2026


   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.  Discovery

   Discovery is the process by which a Consumer locates Providers of a
   given capability.  The protocol defines a query-response mechanism
   mediated by Registries and a scoping model that controls capability
   visibility across organizational and trust boundaries.

   Within an admitted scope, discovery results are unranked; however,
   Registries may apply policy controls including admission, scope
   enforcement, rate limiting, or denial of service.  The protocol
   defines no preference ordering among eligible results.  Visibility is
   governed by scope, not by policy ranking or commercial preference.

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.




Verma                    Expires 26 August 2026                [Page 13]

Internet-Draft                    CIRP                     February 2026


   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:

6.3.1.  Scope Levels

    +==============+=======+=============+============================+
    | Level        | Value | Qualifier   | Semantics                  |
    +==============+=======+=============+============================+
    | Local        | 0x00  | None        | Visible only to the        |
    |              |       |             | advertising endpoint       |
    |              |       |             | itself.  Used for internal |
    |              |       |             | bookkeeping or credential- |
    |              |       |             | agent patterns where a     |
    |              |       |             | capability serves only its |



Verma                    Expires 26 August 2026                [Page 14]

Internet-Draft                    CIRP                     February 2026


    |              |       |             | owner.                     |
    +--------------+-------+-------------+----------------------------+
    | Identity     | 0x01  | target_eid  | Visible only to the        |
    |              |       | (32 bytes)  | endpoint identified by     |
    |              |       |             | target_eid.  Used for pre- |
    |              |       |             | arranged point-to-point    |
    |              |       |             | capabilities.              |
    +--------------+-------+-------------+----------------------------+
    | Trust Domain | 0x02  | anchor_hash | Visible to endpoints whose |
    |              |       | (32 bytes)  | identity chain includes    |
    |              |       |             | the trust anchor           |
    |              |       |             | identified by anchor_hash. |
    +--------------+-------+-------------+----------------------------+
    | Organization | 0x03  | anchor_hash | Visible to endpoints       |
    |              |       | (32 bytes)  | within the organization    |
    |              |       |             | identified by anchor_hash. |
    |              |       |             | Semantically equivalent to |
    |              |       |             | Trust Domain but           |
    |              |       |             | conventionally used for    |
    |              |       |             | organizational boundaries. |
    +--------------+-------+-------------+----------------------------+
    | Global       | 0x04  | None        | Visible to all endpoints   |
    |              |       |             | without restriction.       |
    +--------------+-------+-------------+----------------------------+

                                  Table 1

6.3.2.  Scope Encoding

   The scope descriptor is carried in capability advertisements as a
   compact binary encoding:

   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)





Verma                    Expires 26 August 2026                [Page 15]

Internet-Draft                    CIRP                     February 2026


   The anchor_hash for Trust Domain and Organization scopes is the
   SHA-256 hash of the trust anchor's Ed25519 public key.  This allows
   scope enforcement without transmitting the full public key in every
   advertisement.

6.3.3.  Scope Enforcement

   When processing a Discovery Query, the Registry evaluates the scope
   of each candidate Provider's capability advertisement against the
   querying Consumer's identity:

   Global  No restriction.  The capability is included in results for
      any Consumer.

   Organization / Trust Domain  The Registry checks whether the
      Consumer's identity chain includes the trust anchor identified by
      anchor_hash.  If not, the capability is excluded from results.

   Identity  The Registry checks whether the Consumer's EID matches the
      target_eid in the scope qualifier.  If not, the capability is
      excluded from results.

   Local  The capability is never included in Discovery Responses.
      Local capabilities are visible only through the advertising
      endpoint's own internal interfaces.

   The mechanism by which a Registry determines membership in a trust
   domain is deployment-specific.  Possible approaches include signed
   membership assertions from the trust anchor, pre-configured identity-
   to-domain mappings, or delegation chains.  This specification defines
   the scope encoding and enforcement semantics but does not mandate a
   specific trust domain membership protocol.

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.



Verma                    Expires 26 August 2026                [Page 16]

Internet-Draft                    CIRP                     February 2026


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



Verma                    Expires 26 August 2026                [Page 17]

Internet-Draft                    CIRP                     February 2026


   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.  Session Establishment

   Session establishment in CIRP follows a three-phase model that
   separates discovery, authorization, and cryptographic session setup.
   The critical architectural property is that the Registry participates
   only in the first two phases.  Once authorization is complete, the
   Registry exits the protocol path entirely.  All subsequent
   communication occurs on a peer-to-peer encrypted channel that the
   Registry can neither observe nor influence.

   The three phases are:

   1.  Registry Discovery: The Consumer selects a Registry based on
       measured network latency.

   2.  Authorization and Ticket Issuance: The Consumer requests
       authorization to contact a Provider of a given capability.  The
       Registry issues a signed ConnectTicket encoding the authorization
       decision.

   3.  Peer Session: The Consumer contacts the Provider directly,
       presenting the ConnectTicket.  The peers negotiate a
       cryptographic suite, perform key exchange, and establish an
       encrypted channel.



Verma                    Expires 26 August 2026                [Page 18]

Internet-Draft                    CIRP                     February 2026


   This design ensures that connection throughput scales with the number
   of endpoints, not with Registry capacity.  The Registry handles O(1)
   authorization per connection; it does not relay ongoing session
   traffic.

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.



Verma                    Expires 26 August 2026                [Page 19]

Internet-Draft                    CIRP                     February 2026


   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.

7.2.1.  ConnectTicket Structure

   The ConnectTicket is a fixed-size, binary-encoded authorization
   artifact.  Its structure is as follows:

   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) |
   +-------+------+----------------------------------------+

   The signature covers the first 208 bytes of the ticket (all fields
   except the signature itself).  The signature is computed using the
   Registry's Ed25519 signing key identified by issuer_key_id.

   The ConnectTicket has the following security properties:

   Identity-bound  The ticket names both the Consumer and Provider by




Verma                    Expires 26 August 2026                [Page 20]

Internet-Draft                    CIRP                     February 2026


      EID.  Because EID equals the node's Ed25519 public key, the
      Consumer must prove possession of the corresponding private key
      when using the ticket (by signing the session initiation message).
      A stolen ticket is useless without the Consumer's private key.

   Time-bounded  The expires_at field limits the ticket's validity
      window.  Implementations SHOULD use a validity period of 30
      seconds.  Providers MUST apply bounded clock skew tolerance when
      validating ticket timestamps.  A ticket is valid if: now_secs is
      less than or equal to expires_at + leeway.  A ticket MUST be
      rejected with a ClockSkew error if: issued_at exceeds now_secs +
      leeway.  The RECOMMENDED default leeway is 10 seconds.  This value
      accommodates typical NTP drift across cloud regions (2-5 seconds)
      with margin, while keeping the effective ticket validity window
      short enough that replay concerns remain bounded.  The leeway
      SHOULD be deployment-configurable.

   Capability-scoped  The ticket authorizes contact for a specific
      capability only, identified by capability_hash.

   Locally verifiable  The Provider verifies the ticket by checking the
      Registry's signature using the Registry's public key.  No round-
      trip to the Registry is required.  The Provider learns the
      Registry's public key through control plane interactions (e.g.,
      presence acknowledgments that carry the Registry's verifying key).

   Replay-resistant  The nonce field, combined with nonce-tracking at
      the Provider, limits reuse of a single ticket.  Tickets MAY be
      presented multiple times within their TTL (RECOMMENDED maximum 3
      uses) to accommodate retransmission over lossy transports.
      Providers MUST check session idempotency (whether a session for
      this ticket already exists) before consuming a nonce slot.  The
      nonce tracking window (RECOMMENDED 60 seconds) MUST exceed the
      worst-case ticket validity window (TTL + leeway) to ensure replay
      protection covers the entire period during which a ticket could be
      presented.

   The issuer_key_id field supports key rotation.  Registries maintain a
   keyring of signing keys indexed by rotation identifier.  When a
   Provider receives a ticket, it extracts issuer_key_id and looks up
   the corresponding verifying key.  This allows Registries to rotate
   signing keys without invalidating tickets issued by the previous key
   during an overlap window.

7.2.2.  Authorization Status Codes

   The Authorization Response includes a status byte indicating the
   outcome:



Verma                    Expires 26 August 2026                [Page 21]

Internet-Draft                    CIRP                     February 2026


       +======+=====================+==============================+
       | Code | Name                | Description                  |
       +======+=====================+==============================+
       | 0x00 | Success             | Ticket issued; Provider EID  |
       |      |                     | and locator included.        |
       +------+---------------------+------------------------------+
       | 0x01 | NoMatchingProviders | No Provider currently        |
       |      |                     | advertises the capability.   |
       +------+---------------------+------------------------------+
       | 0x02 | RateLimited         | Consumer has exceeded its    |
       |      |                     | rate allocation.             |
       +------+---------------------+------------------------------+
       | 0x03 | NotAdmitted         | Consumer is not in an        |
       |      |                     | admitted state.              |
       +------+---------------------+------------------------------+
       | 0x04 | PolicyBlocked       | A visibility or scope policy |
       |      |                     | prevents the request.        |
       +------+---------------------+------------------------------+

                                  Table 2

   When the status is not Success, the response MUST NOT contain a
   ConnectTicket.  Implementations SHOULD include a policy receipt (see
   Section 6) with non-Success responses to support transparent
   diagnostics.

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.

7.3.1.  Suite Identifiers

   A suite identifier is a string token registered in the CIRP Crypto
   Suite Registry (see Section 12.1).  Each suite identifier specifies
   the complete set of algorithms used for a session:

   Key agreement  The algorithm(s) used to establish a shared secret
      (e.g., X25519, X25519 combined with ML-KEM-768).

   Authentication  The signature algorithm used to authenticate key



Verma                    Expires 26 August 2026                [Page 22]

Internet-Draft                    CIRP                     February 2026


      exchange messages and verify identity (e.g., Ed25519).

   Symmetric encryption  The authenticated encryption algorithm used for
      session data (e.g., ChaCha20-Poly1305).

   Key derivation  The key derivation function used to derive session
      keys from the shared secret (e.g., HKDF-SHA-256).

   The following suite is mandatory to implement:

   CIRP_X25519_ED25519_CHACHA20POLY1305_SHA256

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

   The following hybrid suite is defined for post-quantum transition:

   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.3.2.  Negotiation Protocol

   Suite negotiation consists of two messages:

   SuiteOffer (Consumer to Provider)  Contains the Consumer's
      ConnectTicket, the Consumer's session identifier, and an ordered
      list of supported suite identifiers.  The first entry is the
      Consumer's most preferred suite.  The Consumer MUST sign the
      SuiteOffer with its Ed25519 private key to prove ownership of the
      EID named in the ticket.

   SuiteSelect (Provider to Consumer)  Contains the Provider's selected
      suite identifier (a single value).  The Provider MUST sign the
      SuiteSelect with its Ed25519 private key.

   Upon receiving a SuiteOffer, the Provider:

   1.  Validates the ConnectTicket (verifies the Registry's signature,
       checks expiration, confirms the Provider's own EID matches the
       ticket's provider_eid, and verifies the Consumer's signature on
       the SuiteOffer against the consumer_vk in the ticket).



Verma                    Expires 26 August 2026                [Page 23]

Internet-Draft                    CIRP                     February 2026


   2.  Selects the first suite from the Consumer's ordered list that the
       Provider also supports.

   3.  If no common suite exists, the Provider silently drops the
       connection.  The Consumer will observe a timeout.

   4.  Returns a signed SuiteSelect containing the chosen suite
       identifier.

   Upon receiving a SuiteSelect, the Consumer:

   1.  Verifies the Provider's signature.

   2.  Confirms the selected suite was present in the Consumer's
       original SuiteOffer.  If the selected suite was NOT offered, the
       Consumer MUST abort the connection.  This prevents downgrade
       attacks where a network attacker substitutes the SuiteSelect
       message.

   3.  Proceeds to key exchange using the negotiated suite.

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.

7.4.1.  Classical Key Exchange

   For suites using X25519 as the sole key agreement algorithm, the key
   exchange proceeds as follows:

   1.  Each peer generates an ephemeral X25519 keypair for this session.

   2.  Each peer sends a KeyExchange message containing: the session
       identifier, a role indicator (0x01 for Consumer, 0x02 for
       Provider), its ephemeral X25519 public key (32 bytes), and an
       Ed25519 signature over these fields using the peer's long-term
       identity key.

   3.  Each peer performs X25519 Diffie-Hellman using its ephemeral
       private key and the other peer's ephemeral public key, producing
       a 32-byte shared secret.

   4.  Session keys are derived from the shared secret using the key
       schedule defined in Section 7.4.3.





Verma                    Expires 26 August 2026                [Page 24]

Internet-Draft                    CIRP                     February 2026


   The Ed25519 signatures on the KeyExchange messages bind the ephemeral
   keys to the peers' long-term identities.  An attacker who intercepts
   the ephemeral public keys cannot forge the signatures without
   possessing the peers' long-term private keys.

   Ephemeral keys MUST be generated fresh for each session and MUST NOT
   be reused.  This provides forward secrecy: compromise of a peer's
   long-term Ed25519 signing key does not expose the session keys of
   previously established sessions.

7.4.2.  Hybrid Post-Quantum Key Exchange

   For suites combining X25519 with a post-quantum key encapsulation
   mechanism (such as ML-KEM-768 as specified in [FIPS203]), the key
   exchange produces two independent shared secrets that are combined
   via the key schedule.

   The hybrid exchange proceeds as follows:

   1.  The Consumer generates an ephemeral X25519 keypair and an
       ephemeral ML-KEM-768 keypair.  The Consumer sends both ephemeral
       public keys in its KeyExchange message, signed with its Ed25519
       identity key.

   2.  The Provider generates an ephemeral X25519 keypair.  The Provider
       performs X25519 Diffie-Hellman to obtain the classical shared
       secret.  The Provider encapsulates against the Consumer's ML-
       KEM-768 public key to obtain a PQ ciphertext and the PQ shared
       secret.  The Provider sends its X25519 ephemeral public key and
       the ML-KEM-768 ciphertext, signed with its Ed25519 identity key.

   3.  The Consumer performs X25519 Diffie-Hellman to obtain the
       classical shared secret.  The Consumer decapsulates the ML-
       KEM-768 ciphertext to obtain the PQ shared secret.

   4.  Both peers now hold two shared secrets: classical_ss (from
       X25519) and pq_ss (from ML-KEM-768).  Session keys are derived
       using the key schedule in Section 7.4.3.

   When operating in hybrid mode, both the classical and post-quantum
   key exchanges MUST succeed.  If either exchange fails, session
   establishment MUST fail.  An implementation MUST NOT fall back to
   classical-only key agreement when a hybrid suite has been negotiated.
   This prevents downgrade to classical-only security when both peers
   have agreed to hybrid protection.






Verma                    Expires 26 August 2026                [Page 25]

Internet-Draft                    CIRP                     February 2026


7.4.3.  Key Schedule

   Regardless of the negotiated suite, session keys are derived using
   HKDF [RFC5869] with SHA-256 as the hash function, following the
   extract-then-expand paradigm of [NIST-SP-800-56C]:

   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)

   The info string binds the derived key material to the session context
   and both peer identities.  The suite_id is the ASCII-encoded suite
   identifier string as negotiated.  The consumer_eid and provider_eid
   are the 32-byte EIDs of the respective peers.

   Using the same KDF structure for both classical and hybrid suites
   simplifies implementation and allows the key derivation path to be
   verified independently of the key agreement mechanism.

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:














Verma                    Expires 26 August 2026                [Page 26]

Internet-Draft                    CIRP                     February 2026


   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).





Verma                    Expires 26 August 2026                [Page 27]

Internet-Draft                    CIRP                     February 2026


   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.



Verma                    Expires 26 August 2026                [Page 28]

Internet-Draft                    CIRP                     February 2026


   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.




Verma                    Expires 26 August 2026                [Page 29]

Internet-Draft                    CIRP                     February 2026


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.  Message Framing and Encapsulation

   CIRP uses distinct framing for control plane and data plane messages
   to enable demultiplexing on shared transport sockets.

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.





Verma                    Expires 26 August 2026                [Page 30]

Internet-Draft                    CIRP                     February 2026


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.  Intent Invocation

   Intent invocation is the mechanism by which a Consumer requests
   execution of a capability and receives a fulfillment response from a
   Provider.  Invocation messages are carried within the encrypted peer-
   to-peer session established in Section 7.  The transport layer does
   not interpret, validate, or transform the payload contents of
   invocations or fulfillments.




Verma                    Expires 26 August 2026                [Page 31]

Internet-Draft                    CIRP                     February 2026


   Invocation envelopes are encoded using CBOR [RFC8949] with
   deterministic encoding as specified in Section 4.2 of that document.
   Deterministic encoding ensures that the same logical content always
   produces identical byte sequences, which is essential for stable
   signatures and hash computation.  CBOR map keys are encoded as
   unsigned integers for compactness.

9.1.  Request Envelope

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

   +===+======================+======+==========+======================+
   |Key| Field                | CBOR | Size     | Description          |
   |   |                      | Type |          |                      |
   +===+======================+======+==========+======================+
   |1  | invocation_id        | bstr | 16       | Unique identifier    |
   |   |                      |      |          | for this             |
   |   |                      |      |          | invocation,          |
   |   |                      |      |          | generated randomly   |
   |   |                      |      |          | by the Consumer.     |
   +---+----------------------+------+----------+----------------------+
   |2  | capability_uri       | tstr | variable | Full capability URI  |
   |   |                      |      |          | including version    |
   |   |                      |      |          | (e.g.,               |
   |   |                      |      |          | "cap:robot.wave/     |
   |   |                      |      |          | v1.0").  This is     |
   |   |                      |      |          | the human-readable   |
   |   |                      |      |          | form; the hash used  |
   |   |                      |      |          | during discovery     |
   |   |                      |      |          | can be recomputed    |
   |   |                      |      |          | from this value.     |
   +---+----------------------+------+----------+----------------------+
   |3  | payload_type         | tstr | variable | Identifier for the   |
   |   |                      |      |          | payload encoding.    |
   |   |                      |      |          | This MAY be a MIME   |
   |   |                      |      |          | type or an           |
   |   |                      |      |          | application-defined  |
   |   |                      |      |          | type string.  The    |
   |   |                      |      |          | protocol does not    |
   |   |                      |      |          | interpret this       |
   |   |                      |      |          | value.               |
   +---+----------------------+------+----------+----------------------+
   |4  | payload              | bstr | variable | Opaque payload       |
   |   |                      |      |          | bytes.  The          |
   |   |                      |      |          | protocol does not    |
   |   |                      |      |          | parse,               |
   |   |                      |      |          | canonicalize, or     |



Verma                    Expires 26 August 2026                [Page 32]

Internet-Draft                    CIRP                     February 2026


   |   |                      |      |          | transform this       |
   |   |                      |      |          | field.  Content      |
   |   |                      |      |          | interpretation is    |
   |   |                      |      |          | entirely the         |
   |   |                      |      |          | responsibility of    |
   |   |                      |      |          | the Consumer and     |
   |   |                      |      |          | Provider.            |
   +---+----------------------+------+----------+----------------------+
   |5  | consumer_eid         | bstr | 32       | Consumer's Endpoint  |
   |   |                      |      |          | Identifier.          |
   +---+----------------------+------+----------+----------------------+
   |6  | consumer_send_ts     | uint | 8        | Consumer's local     |
   |   |                      |      |          | send timestamp,      |
   |   |                      |      |          | unsigned 64-bit      |
   |   |                      |      |          | milliseconds since   |
   |   |                      |      |          | Unix epoch.          |
   +---+----------------------+------+----------+----------------------+
   |7  | prev_invocation_hash | bstr | 32       | SHA-256 hash of the  |
   |   |                      |      |          | previous invocation  |
   |   |                      |      |          | envelope in this     |
   |   |                      |      |          | Consumer-Provider    |
   |   |                      |      |          | relationship.  Set   |
   |   |                      |      |          | to 32 zero bytes     |
   |   |                      |      |          | for the first        |
   |   |                      |      |          | invocation.  See     |
   |   |                      |      |          | Section 10.3.        |
   +---+----------------------+------+----------+----------------------+
   |8  | consumer_signature   | bstr | 64       | Ed25519 signature    |
   |   |                      |      |          | computed over the    |
   |   |                      |      |          | deterministic CBOR   |
   |   |                      |      |          | encoding of fields   |
   |   |                      |      |          | 1 through 7 (all     |
   |   |                      |      |          | fields except the    |
   |   |                      |      |          | signature itself).   |
   +---+----------------------+------+----------+----------------------+

                                  Table 3

   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.



Verma                    Expires 26 August 2026                [Page 33]

Internet-Draft                    CIRP                     February 2026


9.2.  Response Envelope

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

   +=====+====================+======+==========+=====================+
   | Key | Field              | CBOR | Size     | Description         |
   |     |                    | Type |          |                     |
   +=====+====================+======+==========+=====================+
   | 1   | invocation_id      | bstr | 16       | Copied from the     |
   |     |                    |      |          | request for         |
   |     |                    |      |          | correlation.        |
   +-----+--------------------+------+----------+---------------------+
   | 2   | fulfillment_status | uint | 1        | Status of the       |
   |     |                    |      |          | fulfillment: 0x00   |
   |     |                    |      |          | for success, 0x01   |
   |     |                    |      |          | for partial, 0x02   |
   |     |                    |      |          | for application     |
   |     |                    |      |          | error (details in   |
   |     |                    |      |          | payload).           |
   +-----+--------------------+------+----------+---------------------+
   | 3   | payload_type       | tstr | variable | Identifier for the  |
   |     |                    |      |          | response payload    |
   |     |                    |      |          | encoding.           |
   +-----+--------------------+------+----------+---------------------+
   | 4   | payload            | bstr | variable | Opaque response     |
   |     |                    |      |          | payload.  Not       |
   |     |                    |      |          | parsed by the       |
   |     |                    |      |          | protocol.           |
   +-----+--------------------+------+----------+---------------------+
   | 5   | provider_eid       | bstr | 32       | Provider's Endpoint |
   |     |                    |      |          | Identifier.         |
   +-----+--------------------+------+----------+---------------------+
   | 6   | provider_recv_ts   | uint | 8        | Provider's local    |
   |     |                    |      |          | timestamp when the  |
   |     |                    |      |          | request was         |
   |     |                    |      |          | received.           |
   +-----+--------------------+------+----------+---------------------+
   | 7   | provider_send_ts   | uint | 8        | Provider's local    |
   |     |                    |      |          | timestamp when the  |
   |     |                    |      |          | response was sent.  |
   +-----+--------------------+------+----------+---------------------+
   | 8   | request_hash       | bstr | 32       | SHA-256 hash of the |
   |     |                    |      |          | complete request    |
   |     |                    |      |          | envelope (all bytes |
   |     |                    |      |          | including the       |
   |     |                    |      |          | Consumer's          |
   |     |                    |      |          | signature).  Binds  |



Verma                    Expires 26 August 2026                [Page 34]

Internet-Draft                    CIRP                     February 2026


   |     |                    |      |          | the response to a   |
   |     |                    |      |          | specific request.   |
   +-----+--------------------+------+----------+---------------------+
   | 9   | provider_signature | bstr | 64       | Ed25519 signature   |
   |     |                    |      |          | over the            |
   |     |                    |      |          | deterministic CBOR  |
   |     |                    |      |          | encoding of fields  |
   |     |                    |      |          | 1 through 8.        |
   +-----+--------------------+------+----------+---------------------+

                                 Table 4

   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:















Verma                    Expires 26 August 2026                [Page 35]

Internet-Draft                    CIRP                     February 2026


    +=====+================+======+==================================+
    | Key | Field          | CBOR | Description                      |
    |     |                | Type |                                  |
    +=====+================+======+==================================+
    | 1   | invocation_id  | bstr | Correlation identifier from the  |
    |     |                |      | request, if available.  Set to   |
    |     |                |      | 16 zero bytes if the error is    |
    |     |                |      | not associated with a specific   |
    |     |                |      | invocation.                      |
    +-----+----------------+------+----------------------------------+
    | 2   | error_code     | uint | Numeric error code from the CIRP |
    |     |                |      | Error Code registry.             |
    +-----+----------------+------+----------------------------------+
    | 3   | error_detail   | tstr | Optional human-readable          |
    |     |                |      | description.  Implementations    |
    |     |                |      | MUST NOT rely on the content of  |
    |     |                |      | this field for programmatic      |
    |     |                |      | error handling.                  |
    +-----+----------------+------+----------------------------------+
    | 4   | error_origin   | uint | Indicates which component        |
    |     |                |      | generated the error: 0x01 for    |
    |     |                |      | Registry (authorization phase),  |
    |     |                |      | 0x02 for Provider (invocation    |
    |     |                |      | phase), 0x03 for transport       |
    |     |                |      | (timeout or connection failure). |
    +-----+----------------+------+----------------------------------+
    | 5   | originator_eid | bstr | EID of the entity that generated |
    |     |                |      | the error.                       |
    +-----+----------------+------+----------------------------------+
    | 6   | signature      | bstr | Ed25519 signature over fields 1  |
    |     |                |      | through 5.                       |
    +-----+----------------+------+----------------------------------+

                                 Table 5

9.3.1.  Protocol Error Codes

   The following error codes are defined.  Additional codes may be
   registered in the CIRP Protocol Parameters Registry (Section 12.3).












Verma                    Expires 26 August 2026                [Page 36]

Internet-Draft                    CIRP                     February 2026


     +======+=======================+===============================+
     | Code | Name                  | Description                   |
     +======+=======================+===============================+
     | 0x01 | CAPABILITY_NOT_FOUND  | No Provider advertises the    |
     |      |                       | requested capability.         |
     +------+-----------------------+-------------------------------+
     | 0x02 | PROVIDER_UNAVAILABLE  | The Provider is not reachable |
     |      |                       | or has become unresponsive.   |
     +------+-----------------------+-------------------------------+
     | 0x03 | AUTHORIZATION_EXPIRED | The ConnectTicket has         |
     |      |                       | expired.                      |
     +------+-----------------------+-------------------------------+
     | 0x04 | TICKET_INVALID        | The ConnectTicket failed      |
     |      |                       | validation.                   |
     +------+-----------------------+-------------------------------+
     | 0x05 | SUITE_MISMATCH        | No common cryptographic suite |
     |      |                       | exists between the peers.     |
     +------+-----------------------+-------------------------------+
     | 0x06 | RATE_LIMITED          | The request exceeds the       |
     |      |                       | Consumer's rate allocation.   |
     +------+-----------------------+-------------------------------+
     | 0x07 | SCOPE_DENIED          | The Consumer's identity does  |
     |      |                       | not satisfy the capability's  |
     |      |                       | scope requirements.           |
     +------+-----------------------+-------------------------------+
     | 0x08 | TIMEOUT               | The operation exceeded the    |
     |      |                       | applicable time limit.        |
     +------+-----------------------+-------------------------------+
     | 0x09 | INTERNAL_ERROR        | An unspecified internal error |
     |      |                       | occurred.                     |
     +------+-----------------------+-------------------------------+

                                 Table 6

10.  Receipts and Integrity

   CIRP provides a mutually attested record of each invocation-
   fulfillment exchange.  This record, called a fulfillment receipt, is
   constructed cooperatively by the Provider and Consumer through a two-
   phase signing ceremony.  The receipt establishes a tamper-evident,
   non-repudiable audit trail without relying on a trusted third party
   or synchronized clocks.

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:



Verma                    Expires 26 August 2026                [Page 37]

Internet-Draft                    CIRP                     February 2026


10.1.1.  Phase 1: Provider Attestation

   After processing an invocation and generating a response, the
   Provider constructs a partial fulfillment record containing the
   following fields:

   +=====+====================+======+================================+
   | Key | Field              | CBOR | Description                    |
   |     |                    | Type |                                |
   +=====+====================+======+================================+
   | 1   | invocation_id      | bstr | Identifier of the invocation   |
   |     |                    | (16) | this receipt covers.           |
   +-----+--------------------+------+--------------------------------+
   | 2   | request_hash       | bstr | SHA-256 hash of the complete   |
   |     |                    | (32) | request envelope as received.  |
   +-----+--------------------+------+--------------------------------+
   | 3   | response_hash      | bstr | SHA-256 hash of the complete   |
   |     |                    | (32) | response envelope as sent.     |
   +-----+--------------------+------+--------------------------------+
   | 4   | provider_recv_ts   | uint | Provider's local clock reading |
   |     |                    |      | when the request was received  |
   |     |                    |      | (milliseconds since epoch).    |
   +-----+--------------------+------+--------------------------------+
   | 5   | provider_send_ts   | uint | Provider's local clock reading |
   |     |                    |      | when the response was sent.    |
   +-----+--------------------+------+--------------------------------+
   | 6   | provider_eid       | bstr | Provider's Endpoint            |
   |     |                    | (32) | Identifier.                    |
   +-----+--------------------+------+--------------------------------+
   | 7   | provider_signature | bstr | Ed25519 signature over the     |
   |     |                    | (64) | deterministic CBOR encoding of |
   |     |                    |      | fields 1 through 6.            |
   +-----+--------------------+------+--------------------------------+

                                 Table 7

   The Provider sends this partial record alongside the response
   envelope.  The Provider's signature attests that the Provider
   processed the identified request and produced the identified response
   at the stated times.

10.1.2.  Phase 2: Consumer Finalization

   Upon receiving the response and the Provider's partial record, the
   Consumer appends additional fields and produces the final fulfillment
   record:





Verma                    Expires 26 August 2026                [Page 38]

Internet-Draft                    CIRP                     February 2026


     +=====+====================+========+===========================+
     | Key | Field              | CBOR   | Description               |
     |     |                    | Type   |                           |
     +=====+====================+========+===========================+
     | 1-7 | (Provider fields)  | (as    | All fields from Phase 1   |
     |     |                    | above) | including the Provider's  |
     |     |                    |        | signature.                |
     +-----+--------------------+--------+---------------------------+
     | 8   | consumer_send_ts   | uint   | Consumer's local clock    |
     |     |                    |        | reading when the request  |
     |     |                    |        | was sent.                 |
     +-----+--------------------+--------+---------------------------+
     | 9   | consumer_recv_ts   | uint   | Consumer's local clock    |
     |     |                    |        | reading when the response |
     |     |                    |        | was received.             |
     +-----+--------------------+--------+---------------------------+
     | 10  | consumer_eid       | bstr   | Consumer's Endpoint       |
     |     |                    | (32)   | Identifier.               |
     +-----+--------------------+--------+---------------------------+
     | 11  | consumer_signature | bstr   | Ed25519 signature over    |
     |     |                    | (64)   | the deterministic CBOR    |
     |     |                    |        | encoding of fields 1      |
     |     |                    |        | through 10 (including the |
     |     |                    |        | Provider's signature).    |
     +-----+--------------------+--------+---------------------------+

                                  Table 8

   The Consumer's signature covers the entire record including the
   Provider's signature at field 7.  This creates a nested attestation:
   the Consumer attests that it received the Provider's signed partial
   record and that the Consumer's own timestamps are accurate.  Neither
   party can tamper with the other's attested fields without
   invalidating the corresponding signature.

10.1.3.  Receipt Verification

   A third party verifying a fulfillment record performs the following
   checks:

   1.  Reconstruct the CBOR map of fields 1 through 6 using
       deterministic encoding.  Verify the Provider's signature (field
       7) against this encoding using the provider_eid as the
       verification key.







Verma                    Expires 26 August 2026                [Page 39]

Internet-Draft                    CIRP                     February 2026


   2.  Reconstruct the CBOR map of fields 1 through 10 using
       deterministic encoding.  Verify the Consumer's signature (field
       11) against this encoding using the consumer_eid as the
       verification key.

   3.  Confirm that the provider_eid and consumer_eid match the expected
       parties.

   4.  Optionally verify that request_hash and response_hash match the
       actual request and response envelopes if those are available.

   If both signatures verify, the receipt cryptographically establishes
   that both parties participated in the exchange and attested to its
   contents.

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).



Verma                    Expires 26 August 2026                [Page 40]

Internet-Draft                    CIRP                     February 2026


   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.







Verma                    Expires 26 August 2026                [Page 41]

Internet-Draft                    CIRP                     February 2026


11.  Security Considerations

   This section analyzes the security properties of CIRP under a threat
   model that assumes an active network attacker, potentially
   compromised Registries, and potentially compromised peer endpoints.
   The analysis addresses each threat class and identifies the
   cryptographic mechanisms that mitigate it.

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.






Verma                    Expires 26 August 2026                [Page 42]

Internet-Draft                    CIRP                     February 2026


   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.3.1.  Actions a Registry Can Perform

   Deny service  A Registry can refuse to process discovery queries or
      authorization requests, preventing new sessions from being
      established through that Registry.  Mitigation: endpoints can use
      alternative Registries.

   Filter discovery results  A Registry can omit Providers from
      discovery responses, effectively hiding capabilities.  Mitigation:
      Policy Receipts make filtering observable; multi-Registry
      deployments provide independent views.

   Refuse ticket issuance  A Registry can decline to issue
      ConnectTickets, blocking specific Consumer-Provider pairs.
      Mitigation: same as denial of service.

   Shape visibility via scoping  A Registry enforces scope restrictions
      during discovery.  A malicious Registry could misapply scope rules
      to restrict or expand visibility beyond the Provider's intent.

   Observe authorization metadata  A Registry necessarily observes which
      Consumer requested authorization to contact which Provider for
      which capability.  This metadata is visible to the Registry by
      design.

11.3.2.  Actions a Registry Cannot Perform

   Forge endpoint identities  Because EID equals the Ed25519 public key
      and there is no certificate authority, a Registry cannot create a
      valid identity for an endpoint it does not control.  Signing a
      message as a given EID requires the corresponding private key,
      which the Registry does not possess.

   Decrypt data plane traffic  Session keys are derived from ephemeral



Verma                    Expires 26 August 2026                [Page 43]

Internet-Draft                    CIRP                     February 2026


      X25519 [RFC7748] Diffie-Hellman exchanges performed directly
      between peers.  The Registry is not a party to the key exchange
      and does not receive ephemeral key material.  Without the shared
      secret, the Registry cannot derive session keys or decrypt any
      data plane frame.

   Observe invocation content  Invocation envelopes, fulfillment
      responses, and application payloads are carried exclusively on the
      data plane within encrypted frames.  The Registry is
      architecturally excluded from the data plane (Section 4.2).  It
      never receives, relays, or processes data plane messages.

   Tamper with invocation records  Fulfillment records are dual-signed:
      the Provider signs fields 1 through 6, and the Consumer signs
      fields 1 through 10 including the Provider's signature
      (Section 10.1).  Modifying any field invalidates the corresponding
      signature.  Since the Registry possesses neither party's signing
      key, it cannot produce valid replacement signatures.

   Issue tickets for endpoints it does not serve  A ConnectTicket is
      signed by the issuing Registry's key.  A Provider verifies the
      ticket signature against the Registry's known public key.  A
      Registry cannot issue tickets that will be accepted by Providers
      that trust a different Registry, unless it possesses that other
      Registry's signing key.

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



Verma                    Expires 26 August 2026                [Page 44]

Internet-Draft                    CIRP                     February 2026


      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.







Verma                    Expires 26 August 2026                [Page 45]

Internet-Draft                    CIRP                     February 2026


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.




Verma                    Expires 26 August 2026                [Page 46]

Internet-Draft                    CIRP                     February 2026


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.







Verma                    Expires 26 August 2026                [Page 47]

Internet-Draft                    CIRP                     February 2026


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.





Verma                    Expires 26 August 2026                [Page 48]

Internet-Draft                    CIRP                     February 2026


   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.  IANA Considerations

   This document requests the creation of the following registries upon
   publication.






Verma                    Expires 26 August 2026                [Page 49]

Internet-Draft                    CIRP                     February 2026


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.

    +=====================================================+===========+
    | Suite Identifier                                    |Status     |
    +=====================================================+===========+
    | CIRP_X25519_ED25519_CHACHA20POLY1305_SHA256         |Mandatory  |
    +-----------------------------------------------------+-----------+
    | CIRP_X25519MLKEM768_ED25519_CHACHA20POLY1305_SHA256 |Recommended|
    +-----------------------------------------------------+-----------+

                                  Table 9

   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






Verma                    Expires 26 August 2026                [Page 50]

Internet-Draft                    CIRP                     February 2026


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.

12.3.1.  Error Codes

   Initial entries are as defined in Section 9.3.1.  The registry
   contains: code (uint8), name (string), and description (string).

   Error codes are scoped to their enclosing TLV message type.
   Identical numeric values in different message types carry different
   semantics (e.g., 0x01 is TicketExpired in DirectAck but
   CapabilityNotFound in FindExStatus).  Implementations MUST interpret
   error codes in the context of the message type that carries them.
   Four allocation ranges are defined: 0x00-0x3F for protocol-defined
   codes, 0x40-0xBF for profile-defined codes, 0xC0-0xFE for private
   use, and 0xFF reserved for future use.

12.3.2.  Scope Types

   Initial entries are the five scope levels defined in Section 6.3.1.
   The registry contains: value (uint8), name (string), qualifier size
   (uint8), and description (string).

12.3.3.  Message Types

   This sub-registry tracks control plane TLV message types and data
   plane magic-byte prefixes.  Initial entries include the message types
   referenced in Section 8.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.




Verma                    Expires 26 August 2026                [Page 51]

Internet-Draft                    CIRP                     February 2026


   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, January 2016,
              <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, June 2018,
              <https://www.rfc-editor.org/info/rfc8439>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC7595]  Thaler, D., Hansen, T., and T. Hardie, "Guidelines and
              Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, June 2015,
              <https://www.rfc-editor.org/info/rfc7595>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, March 2017,
              <https://www.rfc-editor.org/info/rfc8085>.

13.2.  Informative References

   [FIPS203]  NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", FIPS 203, August 2024.

   [NIST-SP-800-56C]
              NIST, "Recommendation for Key-Derivation Methods in Key-
              Establishment Schemes", SP 800-56C Rev. 2, August 2020,
              <https://csrc.nist.gov/publications/detail/sp/800-56c/rev-
              2/final>.

Examples

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:








Verma                    Expires 26 August 2026                [Page 52]

Internet-Draft                    CIRP                     February 2026


   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]  |
   +------+--------+------------------------------------------+










Verma                    Expires 26 August 2026                [Page 53]

Internet-Draft                    CIRP                     February 2026


   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.





Verma                    Expires 26 August 2026                [Page 54]

Internet-Draft                    CIRP                     February 2026


Author's Address

   Saurabh Verma
   Independent
   United States
   Email: saurabh.sbay@gmail.com













































Verma                    Expires 26 August 2026                [Page 55]
