Service ownership
Mobile-ID operates the CheckID service plane within the agreed delivery model; infrastructure and tenancy details are disclosed only when supported by the relevant source.
CHECKID · SAAS / MANAGED SERVICE
CheckID SaaS Service Model
CheckID is consumed as a managed identity verification service through APIs/SDKs; SLA, tenancy, entitlement and NFR details are published only when supported by the applicable product or contractual source.
SERVICEPurpose → Method → Result
TRUSTSource → Evidence → Scope
OPERATIONSSaaS · API · SDK · SLA
SAAS SERVICE MODEL
From evaluation to operation and service exit
Evaluate → Due diligence → Sandbox → Provision → Integrate → UAT → Go live → Operate → Change → Exit
Organisation / tenant
Customers are represented through organisation, application/client and environment concepts; no specific isolation mechanism is implied without published security architecture.
Environment
Sandbox/UAT/production are connected into one lifecycle; real endpoints/credentials come only from the current CheckID API contract.
Entitlement
Service/method/quota is described only when commercial/product sources confirm it; the website does not invent service plans.
Data responsibility
CheckID, the customer and authoritative providers have different responsibilities for purpose, credentials, source data, evidence and retention.
Exit
Termination considers credential revocation, access removal, evidence/data handling and contractual retention only where the actual service process defines them.
SHARED RESPONSIBILITY
A regulated SaaS service requires clear responsibility boundaries
Responsibility is not a marketing adjective.
| Stage | Owner | CheckID | Customer |
|---|---|---|---|
| Evaluation | CheckID | Public architecture, services and evidence | Assess business fit |
| Sandbox | Shared | Provision client/environment under the real process | Protect credentials and test integration |
| Production readiness | Shared | Readiness guidance/API contract | Network, failure handling and acceptance |
| Operations | Shared | Service operation within the contract | Channel, business decisions and customer monitoring |
| Authoritative source | Third party | Orchestration/integration where supported | Purpose/permission managed with customer/authority |
| Exit | Shared | Remove access according to process | Data/evidence handling per agreement |
SERVICE CONSUMPTION
Organisation → agreement → client → services → environment → usage
No public pricing is invented.
Service catalogue
Customers can see which services are offered and how each maps to capability/API.
Commercial boundary
Pricing, billable units, quota and overage appear only when an approved commercial source exists.
Usage visibility
Where the service provides usage/reporting, the website describes the report type and scope without inventing metrics.
Contractual NFR
Numeric availability, RTO/RPO, support response or capacity is published only from approved SLA/NFR sources.