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.
When consent is used
The project owner and legal function establish the basis for each activity. Consent is not assumed to cover all processing, and a business need does not bypass consent where required. The deployment record identifies consent-dependent activities and withdrawal methods.
Presentation before capture
The interface presents a readable notice, specific purposes, data categories and alternatives. Do not preselect consent or bundle unrelated purposes into an inseparable choice. Operators can explain the notice but must not choose for the person without representative authority.
Consent record
Record the subject reference, purpose, notice version, choice, time, channel, session and representative where applicable. Keep enough information to explain the event without copying palm images into the record. Consent evidence has separate access controls and links to the biometric binding.
Receiving withdrawal
Provide a convenient published channel. The intake operator creates a request ID, verifies the person proportionately, identifies affected purposes and routes to the authorized entity. Do not require raw biometric resubmission merely to withdraw consent. Any temporary restriction during verification follows an approved decision.
Effects on service and data
After confirmation, the responsible entity determines which activities stop, revokes binding use where required and provides an alternative. Withdrawal does not automatically erase evidence under a valid retention obligation; reasons and retained scope must be explained, access-separated and logged.
Changed purposes and re-enrollment
Previous consent cannot be moved to a new purpose by relabeling it. Re-enrollment first checks withdrawal status and creates a fresh notice/record where required. Backup restoration must not reactivate revoked references or consent.
Children and representatives
A dedicated process verifies representative status, authority and expiry. A representative's palm must not be bound as the represented person's palm. Changes in representation are authorization changes, not merely contact-detail updates.
Closure and review
Close only when affected systems confirm the action, the person receives a response and retained items are documented. Responsible staff review delayed requests, exceptions and restoration issues. Handling periods follow applicable obligations and approved procedures; this draft invents no deadline.
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.