Trusted Palm ID / identity servicesProtect references.
Protect references.
Secure bindings.
Separate purposes.
Mobile-ID confirms that the Trusted Palm ID data-organization model follows ISO/IEC 24745:2022. Deployment versions, testing and exceptions require separate supporting records.
Separate stores. Govern the binding.
Within the customer environment
Biometric vault
biometricRefReference protected under the profile.
↔bindingRefControlled binding
Business identity store
subjectRefHIS / SIS / HRM / eGov
Tenant + purpose scoped. No cross-customer sharing by default.
Six stages. A clear boundary at each one.
Choose a stage for inputs, processing, exceptions and evidence.
RGB / IR images
Capture within an authorized session.
- Input
- Person, purpose and fresh capture session.
- Processing location
- Device sensor by model; the profile determines edge or server processing.
- Controls
- Device identity, participant continuity, session expiry and approved transport.
- Output
- Capture data and session reference, not an identity decision.
- Lifecycle
- No default image retention; exceptions need an approved purpose and time limit.
- Exceptions and evidence
- Failed capture: retry or assistance. Record outcome/configuration without putting images in logs.
Explore the workflow and records →Subject to the approved deployment profile
Quality and PAD
Check conditions before matching.
- Input
- Images and device context from the same session.
- Processing location
- Quality/PAD component under the approved version and profile.
- Controls
- Thresholds, assessed attacks, sensor and report scope.
- Output
- Accepted, retry or review required; not yet an identity verification.
- Lifecycle
- Minimal technical result; diagnostic data only under permitted exceptions.
- Exceptions and evidence
- Do not bypass PAD to increase success. Link reports to the actual model/version.
Explore the workflow and records →Subject to the approved deployment profile
Feature extraction
From capture to a biometric representation.
- Input
- Capture accepted under the configured quality/PAD checks.
- Processing location
- At the edge or server named in the deployment profile.
- Controls
- Algorithm version, memory boundary and sensor compatibility.
- Output
- Features and configuration reference; not automatically anonymous data.
- Lifecycle
- Dispose of transient data, caches and crash artifacts under approved schedules.
- Exceptions and evidence
- Incompatible version: block use and reassess; retain version references rather than raw data.
Explore the workflow and records →Subject to the approved deployment profile
Protected reference
Separate reference, identity and business record.
- Input
- Features, purpose, processing authority and binding version.
- Processing location
- A vault separated from identity and business-data stores.
- Controls
- Access control, key management and protection under the actual profile.
- Output
- A biometricRef governed by a binding to subjectRef.
- Lifecycle
- Revocation, re-enrollment and deletion are distinct; biology itself is not replaced.
- Exceptions and evidence
- Encryption does not prove irreversibility. Mechanism, access and evaluation records are required.
Explore the workflow and records →Subject to the approved deployment profile
Purpose-bound matching
Verify 1:1 or identify in an authorized gallery.
- Input
- Fresh session, probe, authorized gallery/identity and purpose.
- Processing location
- Matcher within the declared processing boundary.
- Controls
- Thresholds, organization scope, revocation state and caller authority.
- Output
- An identity result, not an unrestricted authorization.
- Lifecycle
- Do not expand searches or reuse references beyond the authorized purpose.
- Exceptions and evidence
- Non-match or ambiguity: assist or step up; do not automatically merge records.
Explore the workflow and records →Subject to the approved deployment profile
Decision and event
A contextual result for the relying application.
- Input
- Identity result, policy, resource and requested action.
- Processing location
- Decision layer and authorized business application.
- Controls
- Separate verification from authorization; check expiry, purpose and enforcement authority.
- Output
- identityResult, authorizationDecision, nextAction and evidenceRef under the contract.
- Lifecycle
- Retain minimal evidence under schedule; exclude images/templates from public logs.
- Exceptions and evidence
- A hash is not a signature. Trusted timestamping requires a confirmed TSA configuration.
Explore the workflow and records →Subject to the approved deployment profile
Source identity, biometric references, business records and evidence have separate boundaries. Revocation and deletion remain controlled after each decision.
Explore data lifecycle →Data classes & responsibilities.
Actual retention periods need organizational approval. Do not use a single period for every data class.
| Data | Purpose | Location | Access | Retention | Lifecycle |
|---|---|---|---|---|---|
| Palm capture images | Quality, PAD, extraction | Processing memory; retention exceptions require approval | Session-scoped processing engine | No default retention; explicitly time-bound exceptions | Clear buffers; inspect logs, dumps and backups |
| Biometric reference | Scoped matching | Separated biometric vault | Authorized matching service | Purpose and approved retention schedule | Revoke/renew under the scheme; delete replicas |
| Identity reference | Resolve the subject | Domain identity store | Binding service / source system | Only permitted minimum attributes | Unlink and process data-rights requests |
| Binding record | Bind biometric and identity references | Versioned binding store | Authorized API; reviewer | Lifecycle and change reasons | Revocation differs from deletion; minimal evidence retained |
| Notice & processing basis | Document purpose and authority | Organization governance store | Privacy function | Notice version and applicable basis | Handle withdrawal; record lawful exceptions |
| Device record | Capture context | Device management store | Authorized operations team | Model, firmware and state; no palm payload | Document revocation, replacement and retirement |
| Evidence / audit | Trace decisions | Access-controlled evidence store | Purpose-bound audit access | Minimized; no raw image, template or source token | Deletion / legal hold under approved schedule |
Describe biometric protection precisely.
| Do not equate | Correct interpretation |
|---|---|
| Template = anonymous data | A reference may still identify a person and needs protection and processing authority. |
| Encryption = impossible reversal | Do not infer non-invertibility/unlinkability. The mechanism and evaluation must support the claim. |
| Revocation = changing the palm | Revoking a binding/credential does not alter biology. Renewability depends on the protection scheme. |
| Encrypted storage = encrypted-domain matching | Describe decryption and engine-processing boundaries according to the real deployment. |
Map controls without inventing clause numbers.
| Objective | Reference control | Evidence to review |
|---|---|---|
| Confidentiality / integrity | Vault, access permissions, protected channel | Configuration and test report |
| Secure BR / identity binding | Session, participant continuity, binding version | State matrix, review and audit event |
| Lifecycle / revocation | Re-enrollment, revocation, replica deletion | Test results and retention practice |
Reference sources: SRC-ISO ↗
Start with a controlled PoC.
Define purpose, devices, risks and acceptance criteria before scaling.