§13 — Robot Identity Revocation v1.5

RRNs are permanent and never reused — but a robot can be stolen, hacked, or decommissioned. v1.5 adds a revocation mechanism so the fleet can invalidate trust in a compromised robot without disrupting other operations.

Security blocker: Without revocation, a stolen robot retains full cryptographic identity indefinitely. In a factory with 50 robots, a single compromised unit can command its peers forever.

Revocation Status

Registry API Endpoint

GET /api/v1/robots/{rrn}/revocation-status

// Response
{
  "rrn":         "RRN-000000000042",
  "status":      "active",         // "active" | "revoked" | "suspended"
  "revoked_at":  null,             // Unix timestamp if revoked
  "reason":      null,             // Human-readable reason
  "authority":   null              // Who issued the revocation (owner RURI)
}

Revocation Request

POST /api/v1/robots/{rrn}/revoke
Authorization: Bearer <creator-jwt>

{
  "reason": "Device stolen — reported 2026-03-15",
  "status": "revoked"    // or "suspended" for temporary hold
}

Requires creator role JWT. Revocation is irreversible for status: "revoked"; status: "suspended" can be lifted.

ROBOT_REVOCATION Broadcast (MessageType 19)

When the registry marks a robot as revoked, it MUST broadcast a ROBOT_REVOCATION message (type 19) to all reachable peers:

{
  "id":           "uuid-v4",
  "type":         19,
  "source":       "rcan://registry.rcan.dev",
  "target":       "rcan://*/*",          // All peers
  "rcan_version": "1.5",
  "priority":     2,
  "qos":          1,
  "payload": {
    "revoked_rrn": "RRN-000000000042",
    "status":      "revoked",
    "revoked_at":  1741000000,
    "authority":   "rcan://rcan.dev/org/owner/v1/craig"
  }
}

Peer Behavior on Receipt

Any peer receiving ROBOT_REVOCATION MUST immediately:

  1. Invalidate all cached public key material for the revoked RRN
  2. Invalidate all cached consent records granted by or to the revoked RRN
  3. Reject all future messages from source == revoked_rrn (except ESTOP — see below)
  4. Write an audit event recording the revocation broadcast receipt

ESTOP Exception

Protocol 66 Invariant: ESTOP messages from a revoked robot MUST still be accepted. A revoked robot may have legitimate safety concerns (e.g., its operator revoked it after detecting a security breach, but it is still physically operational). RESUME from a revoked robot MUST be rejected.
Message from Revoked RobotAction
SAFETY ESTOP (type 6, cmd=ESTOP)✅ Accept — P66 invariant
SAFETY RESUME (type 6, cmd=RESUME)❌ Reject — revoked robots cannot clear ESTOP
Any other message type❌ Reject with ROBOT_REVOKED error

Revocation Cache

Robots MUST check revocation status on startup and cache results:

  • TTL: 1 hour (3600s)
  • On cache miss or TTL expiry: fetch fresh status from registry
  • If registry unreachable: continue with cached status for up to max_revocation_staleness_s (default: 3600s)
  • After staleness limit exceeded: enter quarantine mode

Quarantine Mode

In quarantine mode (offline + stale revocation data):

  • Only accept commands from same-network, same-owner sources
  • Reject all cross-owner commands
  • Log WARNING audit events every 60s
  • ESTOP always accepted (P66 invariant)
  • Exit quarantine when registry connectivity is restored

Configuration

security:
  revocation:
    check_on_startup: true
    cache_ttl_s: 3600           # 1 hour TTL for revocation status cache
    max_staleness_s: 3600       # Max time to operate with stale cache before quarantine
    quarantine_on_staleness: true

See Also