Provisioning Domain Services (The Swarm)

A Domain Service is a functional “building block” of an OMI application, such as a CMS, CRM, ERP, etc., that provides specific features while delegating identity and governance to the OMI backbone. It binds to an AppID to automatically trust your chosen Auth Provider and follow the global operational rules defined in the App Registry.

Objective

Attaching functional services (CMS, CRM, ERP…) to the app that automatically trust the Auth Provider and integrate with the Operational Backbone.

Prerequisites

• A registered App with an assigned Auth Public Key (from Provisioning the Trust Anchor).
• A valid Master Private Key for signing requests.

The Protocol Workflow

1. Service Selection: The developer selects a Domain Service (e.g., “cms-article”) from the Service Registry.

2. Provisioning Request: The developer sends a signed payload to the Domain Service (article.cms.io):

{
  "version": "1.0",
  "data": {
    "app_id": "org.omiappreg.alice.business_app.7f8a9d",  
    "target_provider": "article.cms.io",
    "service_tier": "pro_cluster",
    "region": "eu-central-1",
    "storage_limit_gb": 50,
    "timestamp": 1705412600,
    "nonce": "z3x9v2n8"
  },
  "signature": "b9c8d7e6f5a4b3c2d1e0..."
}

3. The Verification Lookup:

   • The Domain Service parses the app_id to locate the correct App Registry.
   • It requests the Master Public Key from omiappreg.org to verify the developer’s provisioning signature.
   • Security Check: If the signature is invalid or the nonce is reused, the request is rejected immediately.

4. The Service Binding (Auto-Registration):

   • Upon successful verification, the Domain Service contacts the App Registry again to perform the Binding Handshake.
   • It submits a “Proof of Duty” payload containing:
     • The Developer’s original signature (Proof of Authority).
     • The Service’s own Public Key and Endpoint URL.
     provisional payload

     {
       "version": "1.0",
       "developer_proof": {
         "payload": {
           "app_id": "org.omiappreg.alice.business_app.7f8a9d",
           "target_provider": "article.cms.io",
           "timestamp": 1705412600,
           "nonce": "z3x9v2n8"
         },
         "signature": "b9c8d7e6f5a4b3c2d1e0..."
       },
       "service_binding": {
         "service_id": "cms-article-instance-77",
         "service_type": "cms-article",
         "public_key": "PUB_KEY_SERVICE_ABC123...",
         "endpoint_url": "https://article.cms.io/api/v1",
         "timestamp": 1705412605,
         "nonce": "k9m2p4r1"
       },
       "binding_signature": "f2e1d0c9b8a7f6e5d4..." 
     } 
   • Registry Validation Logic (Security Gates) When the App Registry receives a Binding Handshake, it MUST verify:
     1. Signature Integrity: The developer_proof is valid for the App’s Master Public Key.
     2. Provider Authorization: The identity of the requester matches the target_provider named in the payload.
     3. Nonce Freshness: The nonce has not been used for this AppID before.
     4. Possession: The binding_signature correctly signs the new service metadata, proving the provider owns the keys they are registering.
   • Result: The App Registry updates the “Service DNS” record, officially listing this service under the AppID.

5. Operational Discovery (Context Injection):

   • The App Registry responds to the binding request with the app’s Operational Context.
   • This payload contains the “Backbone Configuration” previously set by the developer, like:
     • Billing service - Where to send usage metrics.
     • Logging service - Where to send error logs.
     • Auth Public Key - The key needed to verify user tokens.
     • … other operational settings

6. Cache & Activate:

   • The Domain Service auto-configures itself using the Operational Context.
   • It caches the Auth Public Key locally for rapid validation.