Service Decommissioning & Revocation

Objective: To securely terminate a service’s association with an AppID and ensure it can no longer be discovered or trusted by other members of the swarm.

Prerequisites

• An active Domain Service currently bound to the AppID.
• The Master Private Key (to authorize the removal).

The Protocol Workflow

1. Initiation: The developer identifies the service_id or binding_id they wish to remove.
2. The Revocation Request: The developer sends a signed Unbind Request to the App Registry.

{
  "version": "1.0",
  "data": {
    "timestamp": 1705412600,
    "nonce": "r4t7y1u9",
    "context": "decommission" 
  },
  "signature": "a1b2c3d4e5f6..." 
}

3. Registry Validation: The App Registry verifies the signature against the Master Public Key.
4. Identity Invalidation: The registry marks the service record as REVOKED or deletes it entirely.
   • The Service Public Key is removed from the active “Service DNS” resolution.
5. Propagation (The Purge): The Registry issues a “Cache Invalidation” signal to core services (like Auth and Billing) to ensure they stop accepting traffic from the decommissioned service’s key.