|
|
|
| As information becomes the key to prosperity in the 21st century, biometric
data security will play a central role in providing a high level of security
to existing and future applications, networks, and information storage facilities.
The ability to verify an individual's identity through his or her unique
physical characteristics has come about due to an increase in speed and
a decrease in the cost of personal computers. When faced with the challenges
of integrating a new technology, it is only natural that different individuals
and companies will develop different approaches and so-called 'solutions.'
However, it is the next step in the evolution of a technology, standardization,
that will determine its success. |
| By the mid 1990, a number of companies who initially developed complex
matching algorithms for large isolated mainframe systems, had defined their
own biometric acquisition and processing interfaces for the PC. Some of
these proprietary approaches subsequently started to merge into standardized
interfaces such as HA-API, BioAPI or AIS API. However, to major proponents
within the industry it quickly became painfully evident that these loosely
organized associations and proprietary interfaces were not the ideal solution,
mainly because they remained proprietary in nature and they were incapable
in accommodating all aspects of biometrics appropriately. In order for the
biometric market to grow, it is necessary to quickly reach the highest possible
level of compatibility between applications and hardware developed by myriad
of different vendors. |
|
|
|
| When I/O Software approached the task of creating an interface that would
meet the necessary requirements for a standard in a highly diversified market,
it set the following overall operational goals: |
| |
Simplicity/Universality
To provide a simple and universal procedure for connecting compliant
applications with compliant devices
|
|
| |
Single Interface
To eliminate the need for software developers to waste time and
effort supporting multiple devices with different interfaces
|
|
| |
Minimize Software Burden
To minimize if not eliminate the software support burden on hardware
vendors. |
|
| |
User Interface
To create a consistent user experience. |
|
| |
Ease-of-Use
To increase the ease of use through standard user interfaces and controls.
|
|
| |
Interoperability
To facilitate market trials through technology interoperability |
|
| As a result of these goals, BAPI today enables biometric software applications
to work with any biometric authentication device developed by any hardware
vendor, leveraging device-specific capabilities, offering streamlined application
development with minimal need to understand biometrics and complete deployment
flexibility, while maintaining a consistent user interface throughout. |
| One of the main reasons for BAPI's unmatched flexibility is its multilevel
architecture. Level 3 defines the high level abstract layer that allows
application developers to rapidly develop prototype applications without
having to deal with the complexities of various biometric technologies,
and it is technology "blind". Level 2 deals more closely with
the specific technology and allows developers to utilize specific biometric
technologies. Level 1 is the lowest level and deals with device specific
issues. It distinctively allows developers to utilize device specific features.
|
|
|
|
| The following functions and features are
required for BAPI compliant DeviceSDKs: |
| |
No User Interface
All of the functionality of the device must be accessible by non-user-interactive
functions. |
|
| |
No internal dictionaries or static
data
All of the data structures must be accessible through the SDK.
|
|
| |
Portable data structures
All of the data structures must be portable from one machine to another.
|
|
| |
Non-interactive device detection
The SDK must be able to detect the presence of their device during
SDK initialization without interaction with the user. |
|
| |
Source detection sensor
The device must contain a method of determining whether a source is
present and the SDK must provide a function for querying the status
of the sensor. |
|
| |
Sampling, processing, and comparison
functions
The SDK may provide/require any number of functional steps to sample/acquire
raw data from a source, process the raw data into various templates,
and compare one or more templates for verification and/or identification.
The SDK must, however, export a function for sampling/acquiring, converting/processing
the raw data into one or more types of templates, and a function for
performing a one-to-one or one-to-many. |
|
| Recommended Features and Functions:
|
| |
Asynchronous source detection
The device should provide asynchronous callback notification for source
detection. |
|
| |
Template sizes
If dynamic templates are absolutely necessary for the device to function
properly, the maximum size for the dynamic templates should be kept
as small as possible.
|
|
| |
Source-free device initialization
Some devices require a source to be present for proper initialization.
If this type of initialization is absolutely necessary for the device
to function properly, then the time required to complete the initialization
should be kept as short as possible (<200ms).
|
|
| |
Displayable data
It is highly recommended that the SDK provide a function for displaying
the raw sample data and for displaying as many of the template types
as possible. If the raw data is processed on the physical device and
only some kind of template is transferred to the host system, the
SDK should also provide a function for displaying this template.
|
|
| |
Device-free authentication/identification
Functions provided for processing and comparison of templates should
operate normally in the absence of the corresponding device.
|
|
| |
Asynchronous device detection
The SDK should provide asynchronous callback notification for device
detection and removal.
|
|
Return to Top 
|
Standardization
