This is the full text published in the Phase 7 package. Effective dates, responsible contacts and contract-specific parameters are maintained in the corresponding release and deployment records.
Integration contract and environments
Before connecting, integrators confirm the API contract, version, granted scope, test environment and production-entry conditions. Website OpenAPI and examples remain illustrative; they do not establish a production endpoint or permission. Test data is synthetic or authorized under a separate assessment.
Authentication and access material
Applications use approved authentication; tokens, secrets and keys are issued to machine/application identities and are not casually shared. mTLS, server verification and certificates follow the technical contract. Compromised or expired access material is revoked/replaced and active sessions reviewed; TLS validation must not be disabled to continue connectivity.
Contextual authorization
The server evaluates organization, purpose, action, resource, device and session rather than trusting client-asserted values alone. Proofing must be fresh before enrollment/binding. VERIFIED does not itself authorize dispensing, machine operation or payment; the relying application still applies business policy.
Request and response data
Schemas constrain permitted fields, types and size. Use contracted session/object references instead of embedding images/templates in logging fields or request IDs. Responses expose only necessary attributes and do not leak out-of-scope identities on non-match or denial. Errors do not disclose secrets, queries or vault structure.
Replay, retry and idempotency
Use nonce/challenge, expiry and session references under the actual protocol. Mutating operations need agreed idempotency and duplicate-handling rules. After a timeout, inspect state or apply designed retries rather than blindly creating multiple bindings. Timeouts, limits and deduplication windows are contractual.
Events and callbacks
Webhook verification checks origin, integrity, freshness and approved key/certificate configuration. Consumers handle duplicate, out-of-order and indeterminate events. Accept callbacks only at registered controlled endpoints; a JSON field reading ALLOW is not sufficient authority for a sensitive action. Verification keys have lifecycle and revocation procedures.
Traceability and evidence
Use requestId/correlationId for tracing without treating identifiers as cryptographic proof. Logs capture minimal state, organization, purpose and events while masking tokens and excluding raw biometrics. Evidence retrieval still checks caller authorization. Signatures, timestamps or eSeals are described only where corresponding keys, policy and verification procedures are deployed.
Versioning, retirement and incidents
Schema, error-model or security changes require versions, compatibility assessment and agreed communication. Inventory consumers and migration plans before retiring a version. Suspected credential compromise or cross-scope queries trigger authorized restriction, log preservation and incident handling. Samples are revalidated whenever the contract changes.
Responsibility & deployment annex
Detailed responsibilities are determined by activity and deployment records; this public document does not replace customer-specific contractual annexes.
- The relying organization defines business purposes, populations and operational authority within the deployment.
- Mobile-ID supplies and operates components within the agreed scope, including integration, control configuration and related evidence.
- Device suppliers support models, firmware, SDKs and maintenance within authorization; data access is never implicit.
- Legal, security and service ownership assignments are maintained in each organization’s operating records.
Execution and evidence cycle
- Record purpose, organization, data/device scope and the business reference.
- Verify authority, applicable conditions, configuration and relevant obligations.
- Execute with data minimization, authorization and necessary evidence.
- Close with confirmations from relevant systems, response handling and remaining exceptions.
Legal and reference sources
Detailed obligations, periods and exceptions apply according to law, contract and the actual service configuration.