Platform capability
Template protection
Separate biometric information from business records.
Template protection
Target model from the specification. Actual product scope requires approval.
Templates still need protection
Feature templates still require biometric protection. Encryption alone does not prove irreversibility, unlinkability or revocability.
Revoke, re-enroll & delete
Revoke active bindings and references. Re-enrollment creates controlled new references. Deletion must cover caches, replicas and backup cycles under policy.
Which data moves where?
Choose a stage to inspect processing location, controls and lifecycle.
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 →Evaluation & evidence requirements
| Area | Requirement |
|---|---|
| Context binding | Organization, purpose, device, session and policy |
| Exception states | Missing data, ambiguous identity, expiry and fallback |
| Required evidence | Versioned report, scope, reviewer and limitations |
| Publication status | No product test report supplied in the website package; deployment is not inferred. |
A controlled biometric data model.
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.