Federated Robot Registry No Single Point of Control

RCAN robot identity is federated — like DNS. Anyone can host a registry. Every robot's address encodes its authoritative registry directly in the RURI, so resolution never requires a central intermediary.

⚖️ Governance Charter 📄 Full Protocol Spec

The Registry Is in the Address

A RURI carries the authoritative registry in its scheme — no lookup table required.

rcan://robots.acme-corp.com/acme/logistics-bot/lgb-00a1b2c3

scheme
Always rcan://

registry
Authoritative registry host

manufacturer / model
Namespace within registry

device-id
Unique identifier (≥ 8 chars)

Because the registry host is embedded in the RURI, a resolver never needs to ask "where is this robot registered?" — it simply reads the address.

How Resolution Works

Resolution follows a deterministic chain. Each step is attempted in order; the first success wins.

Local Cache

Check in-memory or on-disk cache. If a valid, non-expired federation proof exists → return it.

Cache hit: ≈0 ms

Parse Registry from RURI

Extract the registry hostname directly from the RURI. No central lookup needed.

robots.acme-corp.com ← parsed from RURI

Query Registry API

HTTP GET to the registry's REST API. The registry returns a signed Federation Proof.

GET https://robots.acme-corp.com/api/rcan/v1/robots/RRN-00042

Federation Proof Returned

A signed JSON object confirms the robot's identity, registration status, and audit chain. Cache it for future lookups.

↓

If registry unreachable: fall back to rcan.dev (if configured) · else return REGISTRY_UNREACHABLE

Federation Proof

Every registry response is a Federation Proof — a signed JSON object:

{
  "registry_url":        "https://robots.acme-corp.com",
  "rrn":                 "RRN-000000000042",
  "robot_name":          "Logistics Bot Alpha",
  "registry_pubkey_hint":"sha256:abc123def456...",
  "timestamp_iso":       "2026-03-04T15:30:00Z",
  "chain_hash":          "sha256:fedcba987654...",
  "attestation":         "active"
}

Field	Description
`registry_url`	Canonical URL of the issuing registry
`rrn`	Robot Registration Number — unique within this registry
`robot_name`	Human-readable robot display name
`registry_pubkey_hint`	SHA-256 fingerprint of the registry's signing key
`timestamp_iso`	Proof generation time (UTC, ISO 8601)
`chain_hash`	SHA-256 link to prior proof — maintains audit chain integrity
`attestation`	`active` · `pending` · `suspended` · `revoked`

Three Registry Types

Root Registry

rcan.dev

Operated by the RCAN Working Group. Acts as registry of last resort and bootstrap anchor for federation. Governed by an independent body.

rcan://rcan.dev/boston-dynamics/spot/bd001a2b3c

Public internet Governed

Organisational Registry

my-org.com

Hosted by a manufacturer, enterprise, or research institution. Authoritative for its own namespace. Registers with root for global discoverability.

rcan://robots.acme-corp.com/acme/bot/lgb-00a1b2c3

Self-hosted Federated

Local Registry

local.rcan

Runs on a private network — LAN, robot cell, or air-gapped facility. Discovered via mDNS (_rcan-registry._tcp). No internet required.

rcan://local.rcan/opencastor/rover/abc12345

Offline-capable mDNS

Run Your Own Registry

Five steps to launch an RCAN-conformant federated registry.

Implement the RCAN Registry API

Your registry must expose these REST endpoints at your chosen api_base:

GET  {api_base}/robots/{rrn}           → federation proof
GET  {api_base}/robots?manufacturer=...  → robot list
POST {api_base}/robots                  → register robot
GET  {api_base}/status                  → health check

Generate and Publish Your Key Pair

Registry federation proofs must be signed. Generate an Ed25519 key pair:

openssl genpkey -algorithm ed25519 -out registry-private.pem
openssl pkey -in registry-private.pem -pubout -out registry-public.pem
# Serve registry-public.pem at /.well-known/rcan-registry.pub

Publish /.well-known/rcan-registry.json

This descriptor lets other registries and resolvers discover your registry's capabilities:

{
  "name":           "ACME Robotics Registry",
  "operator":       "ACME Corporation",
  "rcan_version":   "1.3",
  "api_base":       "https://robots.acme-corp.com/api/rcan/v1",
  "public_key_url": "https://robots.acme-corp.com/.well-known/rcan-registry.pub",
  "federation_root":"https://rcan.dev"
}

Validate Conformance

Run the RCAN conformance checker to verify your implementation before registering:

python3 scripts/conformance/check_l1.py \
  --host your-registry.example.com \
  --port 443 \
  --registry-mode

→ Conformance test details

Submit your registry to rcan.dev to join the global federation index:

POST https://rcan.dev/api/rcan/v1/federation/registries
Content-Type: application/json

{
  "registry_url":   "https://your-registry.example.com",
  "well_known_url": "https://your-registry.example.com/.well-known/rcan-registry.json"
}

The root registry fetches your descriptor, verifies conformance, and adds you to the federation index.

Governance

The root registry rcan.dev is governed by an independent body — not by any single manufacturer, cloud provider, or government. This ensures no single actor can capture the global robot identity namespace.

Governance responsibilities include: setting the RCAN specification, operating the root registry, maintaining the federation index, and publishing all governance decisions publicly.

→ Read the full Governance Charter

→ Full Federation Protocol Spec (Markdown) · → Conformance Tests · → Governance