The OMI spec is under heavy development, and every piece of it is subject to change. We are documenting the core primitives for sovereign application lifecycles. Join us in defining the v1.0 draft.

Service Decommissioning & Revocation

Decommissioning is a dual-layered process. One layer is Contractual/Resource-based (telling the provider to stop billing you) and the other is Cryptographic (telling the Registry to stop trusting them).

Objective

Securely terminate a service’s association with an AppID and ensure it can no longer be discovered by the swarm, while simultaneously signaling the provider to release resources.

Prerequisites

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

The Protocol Workflow

  1. Provider Cleanup (Resource Deletion): The developer sends a DELETE request directly to the Domain Service endpoint.

    provisional payload
    {
      "version": "1.0",
      "data": {
        "app_id": "org.omiappreg.alice.business_app.7f8a9d",
        "service_id": "cms-article-77",
        "timestamp": 1705412950,
        "nonce": "k9b2v1x8",
        "context": "permanent_termination",
        "data_handling": "wipe" 
      },
      "signature": "8a7b6c5d4e3f2g1h..." 
    }
    • Action: The service provider wipes the data, stops the bill, and removes the tenant from their systems.
    • Response: The provider returns a signed Termination Receipt.
    provisional payload
    {
      "version": "1.0",
      "data": {
        "app_id": "org.omiappreg.alice.business_app.7f8a9d",
        "service_id": "cms-article-77",
        "status": "success",
        "message": "Instance purged",
        "receipt_id": "RCPT-9921-X"
      },
      "signature": "z1y2x3w4v5..." 
    }
  2. The Revocation Request (The Swarm Purge): The developer sends the signed Unbind Request to the App Registry, optionally including the Termination Receipt as metadata.

    provisional payload
    {
      "version": "1.0",
      "data": {
        "app_id": "org.omiappreg.alice.business_app.7f8a9d",
        "service_id": "cms-article-77",
        "timestamp": 1705412600,
        "nonce": "r4t7y1u9",
        "context": "decommission",
        "provider_receipt": {
          "version": "1.0",
          "data": {
            "app_id": "org.omiappreg.alice.business_app.7f8a9d",
            "service_id": "cms-article-77",
            "status": "success",
            "message": "Instance purged",
            "receipt_id": "RCPT-9921-X"
          },
          "signature": "z1y2x3w4v5..." 
        }
      },
      "signature": "a1b2c3d4e5f6..." 
    }
  3. Registry Validation: The App Registry verifies the signature.

  4. Identity Invalidation: The Registry marks the service as REVOKED.

  5. Propagation: The Registry broadcasts the “Purge” signal to Auth and Billing.

The Registry validates the provider_receipt signature using the Service Public Key currently on file, ensuring the ‘Success’ message actually came from the decommissioned instance.