Identification (1:N)
Identification answers "who is this?" — the complete process of recognising a person from a live capture by searching the probe against a gallery of enrolled identities and returning the best match(es) above a score threshold, or none. No identity is claimed up front.
How it works
Identification is a full pipeline, not a single call:
Matching operates on templates — compact binary representations of the biometric sample (for scale: a face template in the SFE Toolkit is 522 bytes) — so the application's gallery holds templates rather than images.
Liveness is the security check. Where the use case calls for it, passive liveness typically runs before template extraction and matching: if a probe fails liveness, abort and don't match a spoofed input. Depending on the integration it can also run after matching. See Liveness.
Modalities
The same feature is implemented by several SDKs, each covering different modalities. Pick by the modality you need and where matching runs:
| SDK | Runs | Face | Iris | Palm | Fingerprint |
|---|---|---|---|---|---|
| SFE Toolkit | On-device | ✓ | ✓ | ✓ | — |
| Biometric Identification Service | Server | ✓ | — | ✓ | — |
| IDKit | On-device | — | — | — | ✓ |
| Enrollment SDK | Desktop / server / Android | ✓ | ✓ | — | ✓ |
Notes:
- SFE Toolkit face, palm and iris templates are 522 bytes.
- Proprietary fingerprint template size is ~2KB.
- Enrollment SDK covers face, iris and fingerprint (no palm).
SFE Toolkit implementation
On the SFE Toolkit (face, palm, iris), each pipeline step maps to a capability — follow a link for the per-capability detail:
| Pipeline step | Face | Palm | Iris |
|---|---|---|---|
| Detection | Face Detection | Palm detection | Iris detection |
| Landmarks / keypoints | Face Landmarks | Palm landmarks | — |
| Quality / attributes | Face Quality | Palm Attributes | — |
| Template extraction | Face Template Extraction | Palm Template Extraction | Iris Template Extraction |
| 1:N identification | Face Identification | Palm Identification | Iris Identification |
Passive liveness is a separate feature — see Liveness.
IDKit implementation
IDKit covers the fingerprint modality. Its pipeline steps map to:
| Pipeline step | IDKit capability |
|---|---|
| Quality / presence | Fingerprint quality and presence |
| Template extraction | Template extraction |
| 1:N identification | Identification (one-to-many) |
Fingerprint capture and enrollment are handled by the Enrollment SDK.
Enrollment SDK implementation
On the Enrollment SDK (face, iris, fingerprint), each pipeline step maps to a function:
| Pipeline step | Face | Iris | Fingerprint |
|---|---|---|---|
| Detection | FaceDetector::Detect | IrisDetector::Detect | PrintExecutor::AlgoSegment / NeuralSegment |
| Landmarks / keypoints | FaceExecutor::GetKeypoint | — | — |
| Quality / attributes | OFIQFace | IrisExecutor::IrisQuality | PrintExecutor::CalculateNFIQ2 |
| Template extraction | Applicant::AddFace | Applicant::AddIris | ICSExtractor::Extract · Applicant::AddPrint |
| 1:N identification | IndexedModalitiesGallery::IdentifyModalities | IndexedModalitiesGallery::IdentifyModalities | IndexedModalitiesGallery::IdentifyModalities |
Full signatures: API Reference.
Key considerations
- Gate on quality before liveness and extraction. Reject low-quality captures early, and check the extracted template (not just the image) — an acceptable image can still yield a weak template.
- Tune the threshold to your FMR/FNMR target on representative data; vendor/example values are illustrative, not production security settings. Only candidates at/above the matching-score threshold are returned.
- Gallery size vs latency — 1:N cost grows with gallery size; size the compute (threads / instances) to your latency target.
- Enroll several samples per person and match by the best per-identity score — robust to pose, lighting, and ageing.
- Keep the extraction algorithm/version consistent between gallery and probe; templates are only comparable within one algorithm family.
- Validate on the platform and data you deploy — quantized edge models don't reproduce desktop/server float results exactly; revalidate FAR/FRR and liveness operating points per target.