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.
Documentation
Domain Service
Service Key-Pair

Service Key-Pair

In the OMI lifecycle, the Service Public Key acts as the service’s “badge.” For the swarm to remain secure and decentralized, this key is distributed to three specific entities, each using it for a different defensive purpose.

  1. The App Registry (The Source of Truth) The Registry is the first to receive the key during the Binding Handshake.
    • When: During Step 4 of the Provisioning Domain Services workflow.
    • Why: It stores the key in the “Service DNS” record for your AppID. This allows any other service in the swarm to “resolve” the key to verify if a message truly came from cms-article-77.
  2. The Auth Provider (The Verification Engine) The Auth Provider retrieves the Service Public Key dynamically from the Registry.
    • When: Whenever a service requests a “Service-to-Service” token or when the Auth Provider needs to verify a callback from that service.
    • Why: It ensures that the service requesting access is the same one the developer authorized. This prevents “impersonation” where a fake service tries to act on behalf of your app.
  3. The Developer’s CLI/Dashboard (The Audit Log) The developer receives the key (usually via the Registry’s response) for local verification.
    • When: Immediately after a successful binding.
    • Why: For “Pinning.” If the developer is extra cautious, they can pin that specific public key locally. If the service is ever compromised and tries to rotate its key without permission, the developer’s local tools will flag the mismatch.

So, who has the key?

EntityRoleUsage
App RegistryCustodianServes the key to anyone who asks: “Is this service legit?”
Auth ProviderVerifierUses the key to validate signatures on inbound service requests.
Other ServicesPeer(Optional)A Database might fetch the CMS’s public key to ensure only that specific CMS can write to it.
Who DOESN’T get the key? The Service Private Key remains locked inside the Domain Service’s secure enclave (HSM or Environment Secrets). It is never shared with the Registry, the Auth Provider, or even the Developer.
IdempotencyTelemetry & Monitoring