DSP as a Service · Ooredoo Kuwait
Full picture
Integration architecture · for Ooredoo Kuwait
How Digitrustec's Digital Signing Platform runs on Ooredoo's infrastructure for each business customer, how it connects to PACI, the customer's directory, the Corporate Mobile ID app and the HSM, and who owns what.
High-level design
Architecture
Select a flow to follow it through the components. Every box is a deployable service of the DSP platform or an external party; the lines are the actual integration paths.
Integration points
| Party | Used for | How it connects | Registration & credentials | Held by |
|---|---|---|---|---|
| Identity and trust | ||||
 Kuwait Mobile IDHawiyati · PACI | Legally recognised signatures by citizens, residents and employees; identity assurance for signing | Signing request from the instance, signed result returned by callback (mutual TLS, allow-listed PACI addresses) | Service-provider registration, client certificate and callback URL, one per customer instance (or under Ooredoo’s registration, by agreement with PACI) |  on behalf of the customer |
| Push notifications and mobile platforms | ||||
 Firebase Cloud Messagingpush notifications · Android and iOS | Delivery of approval requests and notifications to the Corporate Mobile ID app on both platforms; Firebase relays to Apple’s push service for iPhones | Outbound call from the instance to Firebase; nothing inbound. A direct Apple push channel can be configured instead for iOS | Firebase project of the published app and its service-account key, installed in each instance |  app publisher |
 AppleApp Store · push service · App Attest | Distribution of the Corporate Mobile ID app on the App Store; push delivery to iPhones; proof that the app and its device key are genuine | Push reaches Apple through Firebase (or directly). App Attest proofs are verified inside the instance against Apple’s attestation root; no call to Apple at approval time | Apple developer account, app identity and push credential of the published app | app publisher |
 GoogleGoogle Play · Android key attestation | Distribution of the app on Google Play; proof that the Android device key is hardware-backed | Key attestations are verified inside the instance against Google’s hardware-attestation root; no call to Google at approval time | Google Play developer account and app identity of the published app | app publisher |
| Customer environment | ||||
 Customer directoryActive Directory / Entra ID | Source of employees and groups; staff single sign-on to the portals; who may enrol a Corporate Mobile ID | Directory read by the instance; staff login redirected to the customer’s identity provider | Read-only service account or app registration; network path from the instance to the directory | Customer |
| Business systemsCRM · ERP · document systems | Submit documents for signing or sealing, request strong authentication, receive results | Request to the instance’s API; signed documents and results returned by callback | API key per system, issued in the instance’s admin console; callback URL and shared secret | Customer |
| Corporate e-mailSMTP relay | Enrolment codes, notifications, signing invitations | Outbound e-mail from the instance | Relay account or allow-listed sender | Customer or Ooredoo relay |
| Ooredoo platform services | ||||
| HSMhardware security module | Generation and use of employee signing keys, organisation seal keys and the instance’s service keys | Private connection from the instance inside the data centre; one partition per customer instance | Partition credentials and key-management roles, initialised by Ooredoo | |
| Timestampingtrusted time source | Trusted timestamps so signatures and seals stay verifiable for years | Outbound request from the instance | Timestamping account, if a commercial service is used | |
Network note. All inbound traffic terminates on Ooredoo's edge. Outbound calls to PACI, Apple and Google leave through Ooredoo's egress; the HSM and data stores are reachable only from inside the instance. The instance has no inbound dependency on Digitrustec systems.
Business model
A three-party model with a clear line of responsibility at every layer. Ooredoo white-labels DSP into its B2B portfolio and provisions a dedicated instance for each customer it signs.
Business customerCustomerSubscribes to the Ooredoo service: instance fee plus usage (signatures, seals, authentications).
Provisions and operates the instance; licenses the software per instance from Digitrustec.
Diyar United Company delivers releases, licences and Level-3 support, and publishes the mobile app.
Responsibilities
| Area | | | Customer |
|---|---|---|---|
| Servers, network, storage, reverse proxy, TLS | Advises sizing | Owns | — |
| HSM and key custody | Key policy design | Owns & operates | — |
| DSP software, releases, security patches | Owns | Applies | — |
| Instance provisioning and configuration | Runbook, first instance together | Owns | Provides inputs |
| Licence per instance | Issues | Activates | — |
| Signer certificates and keys | PACI integration | PACI relationship | Signers' own Hawiyati |
| PACI service-provider registration | Technical onboarding | Owns relationship | Signs forms where PACI requires |
| Directory integration, staff SSO | Supports | Configures | Owns |
| LOB integration (API, callbacks) | SDK, guides | Enablement | Owns |
| Employee enrolment and device pairing | App and enrolment flow | Supports | Owns |
| Corporate Mobile ID app publishing | Owns | — | Distributes to employees |
| Monitoring, backup, disaster recovery | Health endpoints, guidance | Owns | — |
| Support | Level 3 | Level 1 and 2 | Internal first line |
| Documents, audit trail, user data | — | Custodian | Owns |
Deployment model
Onboarding a customer