Information technology - Biometric application programming interface - Part 4: Biometric sensor function provider interface

ISO/IEC 19784-4:2011 specifies a biometric sensor interface for a Biometric Service Provider (BSP, see ISO/IEC 19784-1). The interface supports a BSP wishing to provide the BioAPI Service Provider Interface (SPI) functions, whilst removing device handling activity from the BSP. ISO/IEC 19784-4:2011 provides an interface that can be used by all types of biometric sensor, including inter alia image streaming sensors (infrared, face, iris, finger, etc.), voice streaming sensors and digital tablets providing dynamic signature data. It is not in the scope of ISO/IEC 19784-4:2011 to define security and privacy requirements for capturing and transferring of biometric data across the Sensor Function Provider Interface (SFPI).

Technologies de l'information — Interface de programmation d'applications biométriques — Partie 4: Interface du fournisseur de fonction du capteur biométrique

General Information

Status
Published
Publication Date
15-Feb-2011
Current Stage
9093 - International Standard confirmed
Start Date
15-Jul-2022
Completion Date
30-Oct-2025

Overview

ISO/IEC 19784-4:2011 - Biometric sensor function provider interface - defines a standardized low-level interface that lets a Biometric Service Provider (BSP) interact with biometric sensors supplied by a separate Biometric Sensor Function Provider (BSFP). The standard is part of the BioAPI family (ISO/IEC 19784) and targets interoperability between BSPs and a wide range of biometric sensors (image cameras, voice sensors, digital signature tablets, etc.). Note: ISO/IEC 19784-4:2011 does not specify security or privacy requirements for capture or transfer across the Sensor Function Provider Interface (SFPI).

Key topics and technical requirements

  • Scope & purpose: Provides an SFPI to offload device handling from BSPs so BSPs remain independent of vendor-specific sensor details while supporting specific biometric modalities (finger, face, iris, voice, signature).
  • Conformance: A BSFP shall implement the functions in Clause 8 and the normative annexes; some functions may legitimately return the BioAPIERR_FUNCTION_NOT_SUPPORTED error when optional.
  • Interface architecture: Defined mechanisms for selecting/loading sensor providers, unit attach/detach, control and status, and event/callback handling.
  • Core function set (examples from Clause 8):
    • BioSFPI_BSFPLoad, BioSFPI_UnitAttach, BioSFPI_UnitDetach
    • BioSFPI_QueryUnits, BioSFPI_ControlUnit, BioSFPI_Cancel
    • BioSFPI_GetPackets, BioSFPI_DataTransfer (data capture/transfer interfaces)
    • Power mode, GUI callbacks, calibration, indicator control
  • Data transfer modes: Single data transfers, packetized transfers, and streaming (stream interface explained in Annex C). Annexes provide modality-specific data schemas.
  • Normative annexes:
    • Annex A: Imaging biometric sensor units (image parameters, pixel formats, streaming)
    • Annex B: Signature sensor units (coordinate systems, sample rates, dynamic signature data)
    • Annex C (informative): Strategies for obtaining sensor data across SFPI (memory management, streaming)

Applications and who uses it

  • BSP developers looking to support multiple sensors without embedding device drivers.
  • Sensor manufacturers / BSFP implementers building standardized drivers or middleware to enable plug-and-play use of biometric hardware.
  • System integrators deploying multi-vendor biometric solutions for access control, identity verification, enrollment stations, or forensic capture.
  • Test labs and compliance teams validating BioAPI-compatible sensor/BSP interoperability.

Related standards

  • ISO/IEC 19784-1 - BioAPI core specification (required context for BSP/SPI)
  • ISO/IEC 19794-7 and other biometric data format standards for data representation

Keywords: ISO/IEC 19784-4:2011, Biometric sensor function provider interface, BioAPI, BSP, BSFP, SFPI, biometric sensors, image streaming, signature sensor, data transfer, interoperability.

Standard

ISO/IEC 19784-4:2011 - Information technology -- Biometric application programming interface

English language
38 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 19784-4:2011 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Biometric application programming interface - Part 4: Biometric sensor function provider interface". This standard covers: ISO/IEC 19784-4:2011 specifies a biometric sensor interface for a Biometric Service Provider (BSP, see ISO/IEC 19784-1). The interface supports a BSP wishing to provide the BioAPI Service Provider Interface (SPI) functions, whilst removing device handling activity from the BSP. ISO/IEC 19784-4:2011 provides an interface that can be used by all types of biometric sensor, including inter alia image streaming sensors (infrared, face, iris, finger, etc.), voice streaming sensors and digital tablets providing dynamic signature data. It is not in the scope of ISO/IEC 19784-4:2011 to define security and privacy requirements for capturing and transferring of biometric data across the Sensor Function Provider Interface (SFPI).

ISO/IEC 19784-4:2011 specifies a biometric sensor interface for a Biometric Service Provider (BSP, see ISO/IEC 19784-1). The interface supports a BSP wishing to provide the BioAPI Service Provider Interface (SPI) functions, whilst removing device handling activity from the BSP. ISO/IEC 19784-4:2011 provides an interface that can be used by all types of biometric sensor, including inter alia image streaming sensors (infrared, face, iris, finger, etc.), voice streaming sensors and digital tablets providing dynamic signature data. It is not in the scope of ISO/IEC 19784-4:2011 to define security and privacy requirements for capturing and transferring of biometric data across the Sensor Function Provider Interface (SFPI).

ISO/IEC 19784-4:2011 is classified under the following ICS (International Classification for Standards) categories: 35.040 - Information coding; 35.240.15 - Identification cards. Chip cards. Biometrics. The ICS classification helps identify the subject area and facilitates finding related standards.

You can purchase ISO/IEC 19784-4:2011 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO/IEC
STANDARD 19784-4
First edition
2011-03-01
Information technology — Biometric
application programming interface —
Part 4:
Biometric sensor function provider
interface
Technologies de l'information — Interface de programmation
d'applications biométriques —
Partie 4: Interface du fournisseur de fonction du capteur biométrique

Reference number
©
ISO/IEC 2011
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved

Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Conformance.1
3 Normative references.1
4 Terms and definitions .1
5 Symbols, abbreviated terms, data structure definitions and error codes.2
5.1 Symbols and abbreviated terms .2
5.2 Data structure definitions and error codes.2
6 Interface architecture.3
7 Selecting and loading BFPs and BioAPI_Units.4
7.1 Obtaining information about BFPs and BioAPI_Units .4
7.2 Loading BFPs .5
7.2.1 Loading BFPs when attaching to an unspecified BioAPI_Unit .5
7.2.2 Loading BFPs when attaching to a specific BioAPI_Unit .5
8 BSFPI Definition .5
8.1 BSFPI data structures.5
8.1.1 Control codes .5
8.1.2 BioSFPI_EventHandler.6
8.1.3 BioSFPI_GUI_RESPONSE .6
8.1.4 BioSFPI_GUI_PROGRESS_EVENT_HANDLER .6
8.2 BSFP Functions.7
8.2.1 BioSFPI_BSFPLoad.7
8.2.2 BioSFPI_UnitAttach.8
8.2.3 BioSFPI_UnitDetach.9
8.2.4 BioSFPI_QueryUnits .9
8.2.5 BioSFPI_Free .10
8.2.6 BioSFPI_ControlUnit.11
8.2.7 BioSFPI_Cancel.11
8.2.8 BioSFPI_SetPowerMode.12
8.2.9 BioSFPI_SetGUICallbacks.13
8.2.10 BioSFPI_QueryFormatInfo .13
8.2.11 BioSFPI_GetPackets .14
8.2.12 BioSFPI_DataTransfer.15
8.2.13 BioSFPI_SetIndicatorStatus.16
8.2.14 BioSFPI_GetIndicatorStatus .16
8.2.15 BioSFPI_CalibrateSensor .17
8.2.16 BioSFPI_SubscribeToGUIEvents.17
8.2.17 BioSFPI_UnsubscribeFromGUIEvents.18
Annex A (normative) Imaging biometric sensor units .20
A.1 General.20
A.1.1 Bit and Byte ordering.20
A.1.2 Scan sequence.20
A.1.3 Pixel aspect ratio.20
A.1.4 Greyscale pixel depth .20
A.1.5 Colour space.20
A.1.6 Video interlacing.21
© ISO/IEC 2011 – All rights reserved iii

A.2 BioSFPI_BSFPImagePropertyID. 21
A.3 BioSFPI_BSFPImagePropertySchema . 21
A.4 BioSFPI_UnitImagePropertyID. 22
A.5 BioSFPI_UnitImagePropertySchema. 22
A.6 Image sensor functions . 23
A.6.1 BioSFPI_GetImageParameters. 23
A.6.2 BioSFPI_SetImageParameters . 24
A.6.3 BioSFPI_Pause. 25
A.6.4 BioSFPI_Play. 25
Annex B (normative) Signature sensor units. 27
B.1 General. 27
B.1.1 Bit and byte ordering. 27
B.1.2 Coordinate system . 27
B.1.3 Channel inclusion field . 28
B.1.4 Sequence of sample points . 29
B.1.5 Sample Rate. 29
B.1.6 ChannelDescriptions. 29
B.2 BioSFPI_BSFPSignaturePropertyID . 29
B.3 BioSFPI_BSFPSignaturePropertySchema . 30
B.4 BioSFPI_UnitSignaturePropertyID. 30
B.5 BioSFPI_UnitSignaturePropertySchema. 31
B.6 Signature Sensor Functions. 32
B.6.1 BioSFPI_GetSignatureParameters. 32
B.6.2 BioSFPI_SetSignatureParameters . 33
Annex C (informative) Obtaining biometric sensor data across the SFPI. 35
C.1 Overall functionality . 35
C.2 Fundamentals of the data transfer interfaces. 36
C.3 Memory management. 36
C.4 Components forming the interface. 36
C.5 Implementation options for use of the data transfer interface . 36
Bibliography. 38

iv © ISO/IEC 2011 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 19784-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 37, Biometrics.
ISO/IEC 19784 consists of the following parts, under the general title Information technology — Biometric
application programming interface:
⎯ Part 1: BioAPI specification
⎯ Part 2: Biometric archive function provider interface
⎯ Part 4: Biometric sensor function provider interface
© ISO/IEC 2011 – All rights reserved v

Introduction
This part of ISO/IEC 19784 specifies a low-level interface that enables a Biometric Service Provider (BSP)
module (see ISO/IEC 19784-1) to interact with a biometric sensor from a different vendor [a Biometric Sensor
Function Provider (BSFP) module], using only the specification of the standardized interface. The biometric
sensor is a physical device with a small amount of associated software. The interface enables a biometric
sensor to interwork with any BSP that is designed to handle the technology supported by that sensor. It also
enables the BSP module to be independent of details of the actual sensor, although it will remain dependent
on the biometric technology it supports (finger, face, vein, etc.).
Biometric sensors can have very different working principles. Also the data formats vary very much depending
on the biometric feature and the sensor type. To cover the resulting different requirements for a generic
function provider, normative annexes contain the specific functions and data structures for typical sensor
device classes or biometric modalities. The philosophy of this part of ISO/IEC 19784 is to add such normative
annexes whenever the existing annexes do not cover the requirements for a typical sensor class.
Currently there are two normative annexes. Annex A provides type definitions and function calls designed to
support biometric sensors designed to return images (either still images or a sequence of images). Annex B
provides type definitions and function calls designed to support biometric sensors designed to return
sequences of pen movements.
The major function of a BSP module performing a capture is to produce a complete Biometric Information
Record (BIR) for returning to a biometric application (usually via a BioAPI framework).
The major function of a BSFP is to do a capture and to return data in an identified format, either as a single
piece of data (use of BioSFPI_DataTransfer) or as a series of packets (use of BioSFPI_GetPackets)
containing the captured information, or via a stream interface (see Annex C).
The BSP is responsible for turning this data into a Biometric Data Block (BDB) within a BIR for returning
across the Service Provider Interface (SPI).
Additional (minor) functions relate to control of the biometric sensor and the parameters of its operation.

vi © ISO/IEC 2011 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 19784-4:2011(E)

Information technology — Biometric application programming
interface —
Part 4:
Biometric sensor function provider interface
1 Scope
This part of ISO/IEC 19784 specifies a biometric sensor interface for a Biometric Service Provider (BSP,
see ISO/IEC 19784-1). The interface supports a BSP wishing to provide the BioAPI Service Provider Interface
(SPI) functions, whilst removing device handling activity from the BSP. This part of ISO/IEC 19784 provides
an interface that can be used by all types of biometric sensor, including inter alia image streaming sensors
(infrared, face, iris, finger, etc.), voice streaming sensors and digital tablets providing dynamic signature data.
It is not in the scope of this part of ISO/IEC 19784 to define security and privacy requirements for capturing
and transferring of biometric data across the Sensor Function Provider Interface (SFPI).
2 Conformance
A BSFP shall support all the functions in Clause 8 of this part of ISO/IEC 19784 and all those in the two
normative annexes. However, those functions that have a permissible error return of
BioAPIERR_FUNCTION_NOT_SUPPORTED can always return this error. Functions that do not list this error
as an allowed return are required to perform the function as described, subject to other error returns listed.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 19784-1, Information technology — Biometric application programming interface — Part 1: BioAPI
specification
ISO/IEC 19794-7, Information technology — Biometric data interchange formats — Part 7: Signature/sign time
series data
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19784-1 and the following apply.
NOTE Function names and data element names are not included here, but are defined within the body of this part of
ISO/IEC 19784.
© ISO/IEC 2011 – All rights reserved 1

4.1
Biometric Sensor Function Provider
BSFP
BioAPI component, attached to a BSP via its interface, for managing and providing information from a
biometric sensor
NOTE The biometric sensor can be a camera, a fingerprint device, an iris scanner, or a signature reader using
images, pressure, or sound, or any other type of biometric sensor.
4.2
Biometric Sensor Function Provider Interface
BSFPI
BSP-to-BSFP interface that supports the functions needed to provide biometric data and to manage the BSFP
itself and the associated device
4.3
packet
fragment of a BDB passing across the SFPI as the result of a single BioSFPI_GetPackets call
4.4
streaming data
data passing across an interface from a source that is operating continuously
5 Symbols, abbreviated terms, data structure definitions and error codes
5.1 Symbols and abbreviated terms
API – Application Programming Interface
BDB – Biometric Data Block
BFP – BioAPI Function Provider
BSP – Biometric Service Provider
BSFPI – Biometric Sensor Function Provider Interface
FPI – Function Provider Interface
ID – Identity/Identification/Identifier
SPI – Service Provider Interface
sRGB – Standard Red Green Blue (see ITU-R BT.709-5)
UUID – Universally Unique Identifier
5.2 Data structure definitions and error codes
For the purposes of this document, the data structure definitions and error codes defined in ISO/IEC 19784-1
apply.
2 © ISO/IEC 2011 – All rights reserved

6 Interface architecture
6.1 ISO/IEC 19784-1:2006 specifies the interface at the top of the BioAPI Framework, which a biometric
application uses to interact with BSPs, and through that to biometric sensors either directly or through BFPs
(see Figure 1 and Figure 2 of ISO/IEC 19784-1:2006).
6.2 The BSFPI contains two types of functions:
6.2.1 General BFP management functions, which are called by the BSP to manage the BFP and its
associated BioAPI Units. These functions are not directly related to SPI functions.
⎯ BioSFPI_BSFPLoad (see Clause 7)
⎯ BioSFPI_UnitAttach (called in the context of BioAPI_BSPAttach and BioSPI_BSPAttach, see Clauses 8
and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_UnitDetach (called in the context of BioAPI_BSPDetach and BioSPI_BSPDetach, see Clauses 8
and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_QueryUnits (this function is directly related to the SPI function BioSPI_QueryUnits which is
related to the API function BioAPI_QueryUnits, see Clauses 8 and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_Free (the relation of this function to the corresponding SPI call depends on the behaviour of the
BSP – when the BSP copies data that the BFP has allocated memory for, then it can immediately send
BioSFPI_Free to the BFP, otherwise the BSP will call this function when itself is requested to free the
memory for this data)
6.2.2 Unit management functions, which are called by the BSP to manage BioAPI Units directly. These
functions are directly related to SPI functions.
⎯ BioSFPI_ControlUnit (this function is directly related to the SPI function BioSPI_ControlUnit which is
related to the API function BioAPI_ControlUnit, see Clauses 8 and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_Cancel (this function can be called in relation to the corresponding calls of the SPI or the
application, but can also be called when there is no corresponding request from the BioAPI framework or
application, see Clauses 8 and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_SetPowerMode (this function is directly related to the SPI function BioSPI_SetPowerMode
which is related to the API function BioAPI_SetPowerMode, see Clauses 8 and 9 of
ISO/IEC 19784-1:2006)
⎯ BioSFPI_SetGUICallbacks (this function is directly related to the SPI function BioSPI_SetGUICallbacks
which is related to the API function BioAPI_SetGUICallbacks, see Clauses 8 and 9 of
ISO/IEC 19784-1:2006)
⎯ BioSFPI_SetIndicatorStatus (this function is directly related to the SPI function BioSPI_SetIndicatorStatus
which is related to the API function BioAPI_SetIndicatorStatus, see Clauses 8 and 9 of
ISO/IEC 19784-1:2006)
⎯ BioSFPI_GetIndicatorStatus (this function is directly related to the SPI function
BioSPI_GetIndicatorStatus which is related to the API function BioAPI_GetIndicatorStatus, see Clauses 8
and 9 of ISO/IEC 19784-1:2006)
⎯ BioSFPI_CalibrateSensor (this function is directly related to the SPI function BioSPI_CalibrateSensor
which is related to the API function BioAPI_CalibrateSensor, see Clauses 8 and 9 of
ISO/IEC 19784-1:2006)
© ISO/IEC 2011 – All rights reserved 3

The following functions are important for the interface between a BSP and an SFP, but do not map directly to
any function across the SPI between a BSP and the framework (or an application for frameworkless
operation).
⎯ BioSFPI_QueryFormatInfo (this function is not related to the SPI)
⎯ BioSFPI_ActivateSensor (this function is not related to the SPI)
⎯ BioSFPI_GetPackets (this function is not related to the SPI)
⎯ BioSFPI_DataTransfer (this function is not related to the SPI)
⎯ BioSFPI_SubscribeToGUIEvents (this function is not related to the SPI)
⎯ BioSFPI_UnsubscribeFromGUIEvents (this function is not related to the SPI)
7 Selecting and loading BFPs and BioAPI_Units
7.1 Obtaining information about BFPs and BioAPI_Units
The component registry contains information about the BioAPI framework, BSPs and BFPs (see 6.3 of
ISO/IEC 19784-1:2006).
BFP information is stored in a structure called BioAPI_BFP_SCHEMA (see 7.3 of ISO/IEC 19784-1:2006).
The BioAPI_BFP_SCHEMA contains data elements BFPPropertyID and BFPProperty. The BFPPropertyID is
a UUID identifying the type of data structure of the BFPProperty data.
Each BFP that is compliant with ISO/IEC 19784-1 and this part of ISO/IEC 19784 has to provide a
standardized BFPPropertyID and a related BFPPropertySchema. Two BSFPPropertyIDs and two related
BSFPPropertySchemas are defined in Annexes A and B. Annex A defines a BSFPPropertySchema suitable
for image devices, and Annex B defines one suitable for signature devices. These can be used in
ISO/IEC 19784-1 calls as BFPPropertyIDs and BFPPropertySchemas.
The information given in the BFPPropertySchema is stored at BFP installation time (see 6.4 of
ISO/IEC 19784-1:2006) in the component registry.
An application can obtain this information by calling BioAPI_EnumBFPs and BioAPI_QueryBFPs (see 8.1.10
and 8.1.11 of ISO/IEC 19784-1:2006).
A BSP can obtain this information by using the BioSPI_BFP_ENUMERATION_HANDLER (see 9.2.2 of
ISO/IEC 19784-1:2006).
An application can retrieve information about all BioAPI_Units supported by a particular BSP by calling the
function BioAPI_QueryUnits (see 8.1.9 of ISO/IEC 19784-1:2006). This function also works if no attach
session is established yet.
A BSP can browse the component registry for all installed BFPs by using the callback mechanism of
BioSPI_BFP_ENUMERATION_HANDLER. The BSP analyses the BFPPropertySchemas and decides which
BFPs it can support.
Note: The criteria for that decision are out of the scope of this part of ISO/IEC 19784.
During the call BioSPI_QueryUnits the BSP may load the supported BFPs. A loaded BFP automatically
detects the supported BioAPI_Units and reports the BioAPI_UNIT_SCHEMAs in the return of the
BioSFPI_QueryUnits call to the BSP, which reports them to the application.
4 © ISO/IEC 2011 – All rights reserved

The BSP may create a list of all BFPUuids and the UnitIDs of the supported devices for each BFP. Additional
information can be found in the parameter UnitManagerUuid of the BioAPI_UNIT_SCHEMA.
7.2 Loading BFPs
7.2.1 Loading BFPs when attaching to an unspecified BioAPI_Unit
This sub-clause describes how a BFP is loaded if the application does not choose a specific BioAPI_Unit in a
call of BioAPI_Attach. (If the application selects a specific BioAPI_Unit, see 7.2.2).
In this case the application calls the function BioAPI_BSPAttach with the value BioAPI_DONT_CARE in the
particular element of the parameter UnitList.
The BSP then performs the operation described in 7.1 using the callback mechanism of
BioSPI_BFP_ENUMERATION_HANDLER and followed by a call of BioSFPI_QueryUnits. As a result, the
BSP has a list of all units supported and their supporting BFPs. The BSP chooses one of the BioAPI_Units
and then loads the appropriate BSFP and completes the operation with a BioSFPI_BSFPLoad function call
followed by a BioSFPI_BSFPAttach function call.
Note: The criteria used to choose one of the supported BioAPI_Units are not defined in this part of ISO/IEC 19784.
7.2.2 Loading BFPs when attaching to a specific BioAPI_Unit
After issuing a BioAPI_BSPLoad, the framework will load the BSP (if supported) and issue a
BioSPI_BSPLoad.
On return, the application calls the function BioAPI_QueryUnits to determine the units supported by that BSP,
and then calls BioAPI_Attach giving the specific Unit it wishes to use. The application retrieves the
UnitSchemaArray from the BioAPI_QueryUnits and can browse this for the BioAPI_Unit information. The
application selects the UnitId it wants to attach to and calls the function BioAPI_BSPAttach. The BSP may
decide to load an appropriate BFP at this time depending on either the list being built as described at the end
of 7.1 or by analysing the parameter UnitManagerUuid of the BioAPI_UNIT_SCHEMA.
If the BSP can support at least one BSFP supporting the requested Unit, it proceeds as specified in 7.1. If it
cannot, it will give an error return. If there are multiple choices of BSFP for the selected Unit, the BSP makes a
choice (the criteria for doing this are not standardised).
8 BSFPI Definition
8.1 BSFPI data structures
8.1.1 Control codes
The function BioSFPI_ControlUnit uses 32bit values as codes to indicate a specific operation to be performed.
To avoid conflicts between standardized and vendor-specific codes these control codes are structured.
The upper 16 bits are used to structure the purpose of control codes. The lower 16 bits are used to identify
control codes of each category.
The following three categories are standardized:
#define BioSFPI_BFPControlCode (0x8000)
#define BioSFPI_BioAPIUnitControlCode (0x4000)
#define BioSFPI_VendorSpecificControlCode (0x1000)

All other category values are reserved for future use.
© ISO/IEC 2011 – All rights reserved 5

8.1.2 BioSFPI_EventHandler
This sub-clause defines the event handler interface to receive asynchronous notification of events of type
BioAPI_EVENT from a BioAPI Unit. Example events include insertion or removal of a BioAPI Unit (e.g.
insertion or withdrawal of a biometric sensor device).
This event handler is passed to the BSFP during BioSFPI_BFPLoad. This is the single event handler that all
BioAPI Units managed by this BSFP should use to notify the BSP of event types that occur in a loaded BSFP.
typedef BioAPI_RETURN (BioAPI *BioSFPI_EventHandler)
(const BioAPI_UUID *BSFPUuid,
BioAPI_UNIT_ID UnitID,
BioAPI_UNIT_SCHEMA *UnitSchema,
BioAPI_ EVENT EventType);
BSFPUuid (input) - The UUID of the BSFP raising the event.
UnitID (input) – The unit ID of the BioAPI Unit (biometric sensor device) associated with the event.
UnitSchema (input) – The schema of the BioAPI Unit raising the event.
EventType (input) - The BioAPI_ EVENT that has occurred.
8.1.3 BioSFPI_GUI_RESPONSE
An enumeration of the possible actions to be performed by a BFP after a GUI event notification callback made
by the BFP has returned control to the BFP. Before returning from a notification callback, a BSP assigns a
value of this type to an output parameter of the callback (Response).
typedef uint8_t BioSFPI_GUI_RESPONSE;

#define BioSFPI_GUI_RESPONSE_PROGRESS_CONTINUE (1)
#define BioSFPI_GUI_RESPONSE_PROGRESS_ABORT (2)

The value BioSFPI_GUI_RESPONSE_PROGRESS_CONTINUE can only be returned in response to a GUI
progress event notification callback. It indicates that the BFP should continue performing the biometric capture.
The value BioSFPI_GUI_RESPONSE_PROGRESS_ABORT can only be returned in response to a GUI
progress event notification callback. It indicates that the BFP should abort the biometric capture and produce
an error code. After this response from the BSP, an error return from the original call is expected from the BFP.
If a BSP returns a response value other than those permitted in each situation, the BFP shall abort the
biometric capture and cause the original function call to return an error code. No further GUI event notification
callbacks are expected from the BFP for the same function.
8.1.4 BioSFPI_GUI_PROGRESS_EVENT_HANDLER
Callback function
typedef BioAPI_RETURN (BioAPI *BioSFPI_GUI_PROGRESS_EVENT_HANDLER)
(BioAPI_UNIT_ID UnitID,
const void *GUIProgressEventHandlerCtx,
const BioAPI_GUI_BITMAP_ARRAY *Bitmaps,
BioSFPI_GUI_RESPONSE *Response);

Description
This is a function pointer type for a BSP's GUI event handler function that is to handle GUI progress event
notification callbacks coming from a BFP. In order to receive GUI progress event notifications, a BSP shall
register a callback function of type BioSFPI_GUI_PROGRESS_EVENT_HANDLER by providing the callback
address of the function, along with a context address, in a call to BioSFPI_SubscribeToGUIEvents (see
8.2.16).
6 © ISO/IEC 2011 – All rights reserved

The framework makes a callback to an application function of this type each time it receives an incoming
callback to a function of type BioSPI_GUI_PROGRESS_EVENT_HANDLER which it exposes to a BFP. The
parameters of the callback (except GUIProgressEventHandlerCtx) shall be set from the parameters of the
incoming callback with the same names; the parameter GUIProgressEventHandlerCtx shall be set from the
GUI progress context address originally provided by the BSP in its call to BioSFPI_SubscribeToGUIEvents;
and the callback address shall be set from the GUI progress callback address originally provided by the BSP
in the call to BioSFPI_SubscribeToGUIEvents.
A BFP can generate GUI progress events only during the execution of a call to BioSFPI_DataTransfer,
BioSFPI_Play or any other function that involves a biometric capture. They can be generated at any time,
even multiple times, during any biometric capture.
The main purpose of the GUI progress event notification is to send to the BSP streaming data (as a series of
bitmaps) collected by the biometric sensor. One possible use of this information is for the BSPs to show the
bitmaps to the subject or an operator. The BSP shall respond to each GUI progress notification by indicating
whether the biometric capture should continue or abort (see 8.1.3).
The GUI progress event handler function and any functions invoked (directly or indirectly) by that function
shall not call any BioSFPI function.
If the BSP returns a value different from BioAPI_OK, the BFP shall cancel the current biometric capture and
produce an error code.
Parameters
UnitID (input) – The unit ID of the biometric sensor unit of the BSP to which the GUI event is related.
GUIProgressEventHandlerCtx (input) – The context address originally
provided by the subscriber application as part of the GUI event
subscription.
Bitmaps (input) – An array of bitmaps containing image(s) of the samples
captured in the biometric capture, which are intended for display to the
subject or to an operator. This array usually contains zero or one bitmaps,
but may contain multiple bitmaps if the BFP has the ability to capture
multiple instances of a biometric modality in a single capture operation.
Response (output) – A value indicating the response from the BSP to the GUI select event
notification (see 8.1.3).
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The value BioAPI_OK
indicates success. All other values represent an error condition.
Errors
BioAPIERR_USER_CANCELLED
BioAPIERR_FUNCTION_FAILED
BioAPIERR_FUNCTION_NOT_SUPPORTED

8.2 BSFP Functions
8.2.1 BioSFPI_BSFPLoad
BioAPI_RETURN BioAPI BioSFPI_BSFPLoad
(const BioAPI_UUID *BSFPUuid,
BioSFPI_EventHandler BioSFPINotifyCallback);
© ISO/IEC 2011 – All rights reserved 7

Description
This function initializes a BFP. Initialization includes registering the BSP event handler for the specified BFP
and enabling all events. The BSP can choose to provide an event handler function to receive notification of
events. Many BSP's can independently and concurrently load the same BFP, and each BSP can establish its
own event handler. They will all receive notification of an event. The same or different event handlers can be
used if a BSP loads multiple BFPs.
A BSP may establish as many event handlers as it wishes, for a given BFP, by calling BioSFPI_BSFPLoad
one or more times for that BFP. An event handler is identified by the address of the notification.
When an event occurs in a BFP, the BFP may send an event notification to the BSP by calling the BSP's
event handler.
If a BSP has set up multiple event handlers, they shall be called one at a time (in any order chosen by the
BFP) rather than concurrently.
Event notification may occur at any time, either during a BioSPI call (related or unrelated to the event) or while
there is no BioSPI call in execution. BSP writers should ensure that all callbacks are properly and safely
handled by the BSP, no matter when the BSP receives them.
NOTE: This usually requires the use of thread synchronization techniques and discipline in the actions performed by the
BSP code placed in event handlers.
When a BFP is loaded (BioSFPI_BSFPLoad), it shall raise an “insert” event immediately for each present
BioAPI Unit. This will indicate to the BSP that it can go ahead and do a BioSFPI_UnitAttach. If the hardware
component for a specific functionality is not present, the “insert” event cannot be raised until the hardware
component has been plugged in.
The function BioSFPI_UnitAttach can be invoked multiple times for each call to BioSFPI_BSFPLoad. The
BSFPUuid identifies the invoked BFP.
The BioSFPINotifyCallback defines a callback used to notify the BSP of events of type BioAPI_EVENT. The
BSFP shall retain this information for later use.
Parameters
BSFPUuid (input) – The UUID of the invoked BSFP. Used to locate the component’s directory entry.
BioSFPINotifyCallback (input) – A function pointer for the event handler that manages events of type
BioAPI_ EVENT.
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The value
BioAPI_OK indicates success. All other values represent an error condition.
Errors
BioAPIERR_MODULE_LOAD_FAIL
BioAPIERR_INVALID_UUID
8.2.2 BioSFPI_UnitAttach
BioAPI_RETURN BioAPI BioSFPI_UnitAttach
(BioAPI_UNIT_ID UnitID);
Description
This function creates an Attach Session.
8 © ISO/IEC 2011 – All rights reserved

There is no requirement that the unit ID value provided by a BSP as input to this function be the same unit ID
value that the framework provided to the BSP in the original call to BioSPI_BSPAttach (if any), provided that
the two unit ID values identify the same BioAPI unit (see 8.2.4).
Parameters
UnitID (input) – The ID of that BioAPI Unit defined by a prior call to BioSFPI_QueryUnits. The UnitID
has been filled into the UnitId field of each element of the BioAPI_UNIT_SCHEMA by the BSFP.
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The value
BioAPI_OK indicates success. All other values represent an error condition.
Errors
BioAPIERR_INVALID_UNIT_ID
BioAPIERR_UNIT_IN_USE
8.2.3 BioSFPI_UnitDetach
BioAPI_RETURN BioAPI BioSFPI_UnitDetach
(BioAPI_UNIT_ID UnitID);
Description
This function terminates an Attach Session.
There is no requirement that the unit ID value provided by a BSP as input to this function be the same unit ID
value that the framework provided to the BSP in the original call to BioSPI_BSPAttach (if any), provided that
the two unit ID values identify the same BioAPI unit (see 8.2.4).
Parameters
UnitID (input) – The ID of that BioAPI Unit defined by a prior call to BioSFPI_QueryUnits. The UnitID
has been filled into the UnitId field of each element of the BioAPI_UNIT_SCHEMA by the BSFP.
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The value
BioAPI_OK indicates success. All other values represent an error condition.
Errors
BioAPIERR_INVALID_UNIT_ID
8.2.4 BioSFPI_QueryUnits
BioAPI_RETURN BioAPI BioSFPI_QueryUnits
(const BioAPI_UUID *BsfpUuid,
BioAPI_UNIT_SCHEMA **UnitSchemaArray,
uint32_t *NumberOfElements);
Description
This function returns an array of BioAPI Unit schemas (see 7.55 of ISO/IEC 19784-1:2006), which are
managed by the given BSFP and are currently in the inserted state.
NOTE When the BSP calls the function BioSFPI_QueryUnits of a BFP, the BFP allocates memory for the data to be
returned to the BSP. In some implementation architectures, the BSP will simply pass to the framework the data and the
addresses exactly as returned by the BFP because the framework will interpret the addresses in the same way as the BFP
and will be able to access the data that the BFP has placed at those addresses. In other implementation architectures, the
BSP will need to move all the data returned by the BFP to newly allocated memory blocks accessible to the framework,
and will call BioSFPI_Free after copying each memory block but before returning from the BioSPI_QueryUnits call. In the
former case, when the framework calls BioSPI_Free, the BSP will make a corresponding call to BioSFPI_Free. In the
© ISO/IEC 2011 – All rights reserved 9

latter case, the calls to BioSPI_Free will be handled internally by the BSP. However, such differences in the behaviour of
the BSP are not visible to the Framework.
The memory block containing the array shall be freed by the BSP via a call to BioSFPI_Free when it is no
longer needed by the BSP. The memory block pointed to by the UnitProperty member within each element of
the array shall also be freed by the BSP via a call to BioSFPI_Free when it is no longer needed by the BSP.
This function shall only be called after BioSFPI_Load has been called for the specified BFP.
There is no requirement that a unit ID, returned by this function for a given BioAPI unit, be made available with
the same unit ID value by the BSP to the framework. A BSP is free to translate any unit ID value (provided by
a BFP) into a different unit ID value before providing it to the framework. The purpose of such a translation
would be to avoid the existence of duplicate unit IDs within the scope of the BSP, which might happen when a
BSP is using two or more BFPs of the same category, or when a BSP is using a BSFP while also directly
managing biometric sensors.
Parameters
BsfpUuid (input) – The unique identifier for the BSFP for which the information is to be returned.
UnitSchemaArray (output) – A pointer to an address of the array of elements of type
BioAPI_UNIT_SCHEMA (allocated by the BSP - but see note above) containing the unit schema
information.
NumberOfElements (output) – A pointer to the number of elements in the array, which are managed
by the given BSFP and are currently in the inserted state.
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The value
BioAPI_OK indicates success. All other values represent an error condition.
Errors
BioAPIERR_INVALID_UUID
BioAPIERR_MEMORY_ERROR
8.2.5 BioSFPI_Free
BioAPI_RETURN BioAPI BioSFPI_Free
(void *Ptr);
Description
This function causes the space pointed to by Ptr to be de-allocated. If Ptr is NULL, no action occurs.
Otherwise, if Ptr does not match a pointer earlier
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...