Server-side identification
Server-side identification runs biometric recognition on a central service instead of on the capture device. A client captures a face or palm and sends it — as an image or a precomputed template — to the service, which runs the recognition pipeline and matches against a server-side gallery (watchlist). Identities are managed centrally, so one service backs many clients and large galleries — well suited to watchlist screening and identification across many endpoints.
It is built on the Biometric Identification Service (BIS, formerly LFIS) — note that the linked public documentation still uses the LFIS name — which exposes face and palm identification, face verification, liveness, and watchlist management over a REST API. It implements the canonical Identification (1:N), Verification (1:1), and Enrollment flows; this page covers how BIS realises them and the BIS-specific terms.
- Overview & concepts: Biometric Identification Service documentation
- Endpoints & schemas: Biometric Identification Service REST API reference (also browsable via the built-in Swagger UI)
Components
| Component | Role in this use case | Modality | Deployment | Documentation |
|---|---|---|---|---|
| Biometric Identification Service (BIS) | Detection, passive liveness, 1:N identification (face & palm), and face 1:1 verification against a server-side watchlist, over REST. | Face, Palm | Server (REST API) | BIS docs |
Concepts & references
Each concept below links straight to its authoritative source. Flow concepts are defined once in the feature pages (Identification, Verification, Enrollment); BIS-specific terms and endpoints live in the BIS docs and API reference.
| Term | In one line | Reference |
|---|---|---|
| Watchlist | The server-side gallery a probe is matched against. | Watchlists |
| Watchlist member | One enrolled identity; holds face and/or palm biometrics. | Watchlists |
| Template | A precomputed biometric; usable as a probe for identification (SearchByTemplate). | REST API reference |
| Enrollment (registration) | Adding a member - from an image, or by referencing a face/palm already in the system. | Flow · API |
| Identification (1:N) | "Who is this?" - search a probe against a watchlist. Face and palm; image or template. | Flow · API |
| Verification (1:1) | "Is this the claimed person?" - face-to-face comparison. Face only. | Flow · API |
| Passive liveness / spoof check | Rejects presentation attacks (photo, mask, replay), for face and palm. | REST API reference |
| Deduplication | "Already enrolled?" - not a dedicated endpoint; run a 1:N identification before registering. | Flow |
Good to know
A few points that affect how you design the integration (details in the REST API reference):
- Enrollment input: enrollment accepts an image or a system face/palm reference (no externally-supplied template).
- Verification is face-only. Palm supports enrollment, 1:N identification, and liveness, but no 1:1 endpoint.
- Deployment & data: BIS runs on your infrastructure (Docker / Kubernetes / Nomad, on-prem or cloud); recognition needs a network path to the service, and the probe leaves the capture device.
Integration options
The client can hand the server either a raw image or a precomputed template — choose by how much runs on the device:
- Search by image, no client-side processing — the device (or operator's phone) sends a captured photo as-is; the server runs the full pipeline (detection → landmarks → quality → template extraction → match). Works even for multi-face photos — e.g. attendance taken as a single picture of a whole classroom.
- Search by image with guided capture — the device runs a capture component (auto-capture on Android/iOS, or the web capture component) to get a well-framed face, then sends the image; the server still runs its own detection and the rest of the pipeline. Better capture quality without putting biometrics logic on the device.
- Search by template — the device extracts a template on the edge (e.g. with the SFE Toolkit) and sends only the template; the raw image stays on the device. Requires the same extraction algorithm/version on both ends (SFE Toolkit and the SmartFace platform share one algorithm family).
How the server realises each flow step:
| Flow step | On the server |
|---|---|
| Detection · Landmarks · Quality | Run inside the search / enrollment call from a posted image |
| Template extraction | Server-side (search by image) — or on the edge, then posted (search by template) |
| Passive liveness | Inline within the search call (enable in the request), or as a separate spoof-check call (face & palm) |
| 1:N identification | Search a probe (image or template) against a watchlist |
| 1:1 verification | Face-to-face comparison (face only) |
For exact endpoints and schemas, see the REST API reference.
Getting Started
- Deploy BIS on your infrastructure and open its Swagger UI - see the Biometric Identification Service documentation.
- Create a watchlist and register members (face and/or palm).
- Recognize by posting a probe to the identification (1:N) endpoint, or two faces to verification (1:1), with a liveness check.
For exact endpoints, request/response schemas, and configuration, follow the Biometric Identification Service REST API reference.
Related pages
- Identification (1:N), Verification (1:1), and Enrollment (the canonical flows this use case implements)
- On-device identification (the on-device counterpart — the same recognition running locally; face and palm)
- Biometric Identification Service documentation · REST API reference
- License Agreement