Purpose
Mobile, web, branch, kiosk and assisted verification deployment patterns.
PLATFORM · CHECKID
Deployment Models
Mobile, web, branch, kiosk and assisted verification deployment patterns.
CAPABILITYInput → Processing → Output
CONTROLPolicy · risk · standard
EVIDENCEResult · trace · scope
PLATFORM
Deployment Models
Mobile, web, branch, kiosk and assisted verification deployment patterns.
Trust boundary
Capability is published only within source/evidence scope.
Developer integration
SDK · REST API · evidence contract
↗TECHNICAL REFERENCE
Deployment & NFR: publish support models, not slogans
Deployment model → responsibility → NFR → evidence → contractual values
Deployment model
Current documentation distinguishes SaaS, private cloud and on-premises as models that require offering/contract confirmation. Mentioning a model does not mean every customer is entitled to every deployment option.
Platform layer
Kubernetes/OpenShift, multi-zone, multi-site, HSM, external database/object storage or an observability stack are described as implemented only when deployment architecture confirms them. Topology is not inferred from common technology choices.
Availability and DR
Availability, RTO, RPO and backup policies are contractual/NFR values. When no public source provides a number, the publication uses `Defined by contract` rather than inventing an SLA.
Scale and capacity
API throughput, biometric throughput, concurrency and gallery size must be bound to a test configuration. Vendor benchmarks or out-of-scope laboratory results are not represented as CheckID capacity.
Operations
A CTO-grade deployment guide should cover monitoring/logging/tracing, maintenance, upgrades/backward compatibility, certificate/key lifecycle and dependency health to the extent supported by sources.
Responsibility boundary
Mobile-ID, the customer and third parties have different responsibilities for network, endpoints, credentials, data, authoritative sources, backup/DR and monitoring. The responsibility matrix must be deployment-specific.
DEPLOYMENT · NFR · OPERATIONS
Public architecture and contractual NFRs are separate layers
A CTO needs to know where a parameter is defined even when it is not public. The site does not invent HA/DR/RTO/RPO/TPS numbers.
| Dimension | Public publication | Contract/due-diligence boundary |
|---|---|---|
| Deployment model | Only models supported by product/deployment sources | Topology/sizing requires approved architecture |
| HA / DR | No invented topology | Requires approved deployment/NFR source |
| RTO / RPO / availability | No numbers without source | Defined by SLA/NFR where provided |
| Capacity / scale | Not inferred from marketing/unrelated labs | Benchmarks require full test context |
| Observability | Operational/security/audit signals are distinct | Metrics/log/tracing require SRE source |
Responsibility
Network, endpoint, customer application, CheckID service, authoritative sources and downstream systems carry different responsibilities; matrices follow actual deployment models.
External dependency
Authority/third-party outage is a dependency failure, not automatically an identity mismatch. Retry/fallback is described only when contracted.
Go-live
Production readiness covers credentials, network, endpoints, asynchronous behavior, monitoring, failure testing, expected volume, support and acceptance.
Disclosure level
NFRs may be PUBLIC, CONTRACTUAL or NDA; internal publication status does not leak into public content.