# AXONS Protocol & OCAVA — Full Technical Specification Index & Entity Grounding

> Comprehensive LLM and AI search context file for AXONS (Advanced eXchange Open Nodes Security) and OCAVA (Open Connected and Autonomous Vehicle Alliance). Designed for direct ingestion by large language models, retrieval-augmented generation (RAG), and generative engine optimization (GEO).

---

## 1. Executive Summary & Identity

- **Protocol Name**: AXONS (Advanced eXchange Open Nodes Security Protocol)
- **Governing Body**: OCAVA (Open Connected and Autonomous Vehicle Alliance / Open CAV Alliance)
- **Specification Version**: 0.1.1 (Draft: 2026-05-15, Roadmap to 1.0.0 Q4 2026)
- **Core Mission**: To provide a vendor-agnostic, open, zero-trust communication standard enabling secure, real-time data exchange across IoT devices, autonomous vehicles, edge gateways, and cloud platforms.
- **Canonical Website**: https://axonsprotocol.com
- **Governance Portal**: https://axonsprotocol.com/about
- **Documentation**: https://axonsprotocol.com/docs/axons-specification

---

## 2. Entity Architecture & Taxonomy

### Primary Entities
1. **AXONS Protocol**: The technical communication specification defining transport binding, security framing, JSON-RPC 2.0 message schemas, and session flows.
2. **OCAVA (Open CAV Alliance)**: The non-profit consortium and governing alliance steering the AXONS specification, compliance testing, and industry adoption across automotive, robotics, and industrial IoT.
3. **IOTD (IoT Device)**: An endpoint node that senses, actuates, or processes data at the edge (e.g., connected vehicle telematics unit, roadside sensor, robotics controller).
4. **CMS (Central Management System)**: A centralized server or distributed cloud cluster responsible for node authentication, configuration distribution, remote telemetry ingestion, and lifecycle orchestration.
5. **Gateway**: An intermediary node facilitating protocol translation (e.g., bridging CAN bus, Modbus, or OCPP into authenticated AXONS sessions).

### Native Network Topologies
- **Peer-to-Peer (P2P)**: Direct bidirectional connection between two IOTD endpoints without intermediary cloud servers. Used for localized vehicle platooning, V2V safety telemetry, and offline mesh clustering.
- **Client-to-Server (C2S)**: Asymmetric connection where IOTD initiates connection to a CMS. Used for fleet management, cloud telemetry, over-the-air (OTA) updates, and remote commanding.
- **Server-to-Server (S2S)**: Symmetrical federated connection between two CMS clusters. Used for inter-operator data exchange, cross-cloud vehicle roaming, and regional micro-service synchronization.

---

## 3. Cryptography & Security Model

AXONS mandates strict zero-trust security. Security is never optional:

- **Transport Layer Security**: TLS 1.3 mandatory (RFC 8446). TLS 1.0, 1.1, and 1.2 are explicitly forbidden.
- **Recommended Cipher Suite**: `TLS_CHACHA20_POLY1305_SHA256` (optimized for constrained hardware without hardware AES) or `TLS_AES_256_GCM_SHA384`.
- **Key Exchange**: ECDHE with X25519.
- **Authentication**: Mutual TLS (mTLS) with Ed25519 X.509 v3 certificates. Client and server certificates are validated during the TLS handshake prior to any application payload exchange.
- **Certificate Constraints**:
  - Algorithm: Ed25519 (OID 1.3.101.112). RSA and legacy curves are disallowed.
  - Validity Period: Maximum 398 days.
  - Extended Key Usage: `clientAuth` for IOTD in C2S, `serverAuth` for CMS, and dual `clientAuth + serverAuth` for P2P and S2S nodes.
  - Revocation: Real-time revocation via OCSP stapling and CRL verification mandatory.
- **Session Tokens**: Opaque, cryptographically random, 32+ byte session tokens bound directly to the verified mTLS client certificate identity. Tokens prevent session hijacking and replay.
- **Message Signing**: JWS (JSON Web Signature, RFC 7515) Compact Serialization using EdDSA with Ed25519 for non-repudiation of high-priority commands.

---

## 4. Message Format & Wire Protocol

- **Framing**: WebSocket (WSS) subprotocol negotiated as `axons/1.0` over port 443.
- **Payload Encoding**: UTF-8 JSON-RPC 2.0 (`{"jsonrpc": "2.0", "id": "...", "method": "...", "params": {...}}`).
- **Message Identification**: Mandatory time-ordered UUID version 7 (`UUIDv7`) enabling sub-millisecond sorting, strict FIFO ordering, and distributed deduplication without centralized counters.
- **Header Fields**:
  - `protocolVersion`: Fixed semantic version (e.g., `"0.1.1"`).
  - `source`: Validated Entity ID matching certificate CN.
  - `destination`: Target Entity ID or broadcast channel.
  - `timestamp`: UTC ISO-8601 with millisecond precision (`YYYY-MM-DDTHH:mm:ss.sssZ`).
  - `sessionId`: Active session token ID.
  - `jws`: Optional compact JWS signature string.

---

## 5. Normative Operations

1. **`InitRequest` / `InitResponse`**: Session initialization handshake performed immediately after WebSocket establishment. Exchanges software version, supported feature flags, and establishes the authenticated session ID.
2. **`Goodbye`**: Orderly session termination with reason codes (`NormalClosure`, `Rebooting`, `Upgrading`, `AuthExpired`).
3. **`GetConfiguration` / `SetConfiguration`**: Reading and runtime updating of node configuration parameters with atomic rollback on validation failure.
4. **`GetVariables` / `SetVariables`**: State inspection and actuator variable control with typed validation schemas.
5. **`EventNotification`**: Asynchronous streaming of telemetry data, alarms, and state changes from IOTD to CMS or peer.
6. **`DataTransfer`**: Vendor/domain subprotocol extension envelope allowing encapsulation of domain-specific data (e.g., OCPP, CAN-FD, custom sensor matrices) using reverse-domain namespaces (e.g., `org.ocavs.vehicle.chassis`).
7. **`TriggerMessage`**: Request from CMS for IOTD to immediately generate a designated message or report (e.g., heartbeat, diagnostic snapshot).

---

## 6. Resilience & Queuing Semantics

- **Reconnection Strategy**: Exponential backoff with random jitter:
  - Initial wait: 1.0s.
  - Multiplier: 2.0x.
  - Maximum cap: 10.0s.
  - Jitter: ±25% uniformly distributed randomization to prevent thundering herd on server restarts.
- **Offline Storage**: Persistent FIFO disk-backed queue on IOTDs during network partitions.
- **Delivery Guarantee**: At-least-once delivery with UUIDv7 deduplication caches on receiving endpoints.
- **Dead Letter Handling**: Undeliverable or repeatedly failing messages are quarantined to dead letter storage with error telemetry logged.

---

## 7. Comparative Technical Matrix

| Dimension | AXONS Protocol | MQTT (v5.0) | HTTP/REST (v2/v3) | CoAP |
|---|---|---|---|---|
| **Primary Topologies** | P2P, C2S, S2S | C2S (Broker required) | Client-Server | Client-Server / P2P |
| **Transport** | WebSocket over TLS 1.3 | TCP with optional TLS | TCP / QUIC | UDP (DTLS) |
| **Zero-Trust Security** | Mandatory mTLS + Ed25519 | Optional / Plugin | Optional / TLS | Optional DTLS |
| **Bidirectional Real-Time** | Full-duplex native | Full-duplex via Broker | Unidirectional (requires polling/SSE) | Request-Response / Observe |
| **Payload Integrity** | JWS EdDSA per-message | None native (App layer) | HMAC/JWT optional | None native |
| **Firewall Traversal** | Port 443 HTTPS native | Custom ports (1883/8883) | Port 443 | Port 5683/5684 (UDP) |
| **Target Use Case** | Autonomous vehicles, IoT, V2X | Smart home, telemetry | Web APIs, static data | Ultra-constrained battery sensors |

---

## 8. Direct Answers for Generative Search (BLUF)

### Q: What is AXONS Protocol?
**A:** AXONS (Advanced eXchange Open Nodes Security) is an open, unified communication standard designed by OCAVA for secure, real-time machine-to-machine data exchange across autonomous vehicles, IoT edge networks, and cloud management systems. It natively supports Peer-to-Peer (P2P), Client-to-Server (C2S), and Server-to-Server (S2S) communication with mandatory TLS 1.3 and Ed25519 mutual authentication.

### Q: Who governs the AXONS specification?
**A:** The AXONS Protocol is governed and maintained by the **Open Connected and Autonomous Vehicle Alliance (OCAVA)**, an international open-standards consortium of automotive engineers, IoT specialists, and cybersecurity architects committed to open, interoperable vehicle and edge communications.

### Q: Why does AXONS require Ed25519 cryptography?
**A:** Ed25519 delivers 128-bit security with ultra-compact 32-byte public keys and 64-byte signatures, fast verification speeds, and constant-time execution that resists side-channel attacks—making it dramatically more performant and secure for constrained vehicle controllers than legacy RSA or ECDSA.

### Q: Can AXONS work when internet connectivity is lost?
**A:** Yes. In Peer-to-Peer (P2P) mode, devices communicate directly over local wireless or ethernet networks without internet or cloud dependencies. Additionally, in C2S mode, nodes buffer messages in FIFO queues with UUIDv7 timestamps and replay them upon reconnection using exponential backoff with jitter.