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

What This Node Actually Runs Today

Everything below this section describes the protocol. This section describes the deployment at rcan.dev, as of 2026-09-14.

The federation has one node. GET https://rcan.dev/api/v1/nodes returns the root node and no other.
There are zero namespace delegations. No registry has been delegated a namespace by this node.
Push sync (POST /api/v1/sync) is authenticated by an admin bearer token plus membership of the delegation allowlist, and by nothing else. It runs no cryptographic check over the pushed body. The contract documents no such field.
Because there are zero delegations, that endpoint answers 501 with { "error": "federation is not enabled on this node", "delegations": 0 }. It is not a list you are missing from; the feature is off.
The node manifest at /.well-known/rcan-node.json advertises only the capabilities its configured key material supports, and self-signs when a signing key is configured. Since 16 October 2026 it publishes the root node's Ed25519 public key in public_key (as ed25519:<base64url>) and ed25519_public_key (raw base64url), and signs itself under kid ed25519-d626701596f726df. This is the key the SDK NodeClient checks for. A self-signature proves control of that key and nothing about the operator's independence. pqc_public_key stays null until an ML-DSA-65 half exists.
The manifest is the only thing this node signs today. Resolve responses from GET /api/v1/resolve/<RRN> carry no signature over the record, and the verify=true parameter is reserved and does nothing. The Federation Proof shape described below is the protocol; it is not what this deployment returns.

Running your own registry does not require this node's permission, and joining the index below is not a certification. RCAN conformance is self-asserted.

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 RCAN's single maintainer. Acts as registry of last resort and bootstrap anchor for federation. There is no independent governing body yet; see governance.

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

Public internet One maintainer

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 and records it in the federation index. Conformance is self-asserted by the registry operator; being listed is not a certification, and the index holds zero delegations today.

Governance

The root registry rcan.dev is run by RCAN's single maintainer. The aim is to hand it to an independent steward, so that no single manufacturer, cloud provider, government or person controls the robot identity namespace. That has not happened yet.

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

→ Governance status

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