It covers the basic functions of
and includes a database interface to allow a
biometric service provider (BSP) to manage the identification population for optimum performance.
It also provides primitives which allow the application to manage the capture of samples on a client, and the Enrollment, Verification, and Identification, on a server.
The HRS is designed for use by both application developers and biometric technology developers. To make the integration of the technology as straight-forward and simple as possible (thus enhancing its commercial viability), the approach taken is to hide or encapsulate to the extent possible the complexities of the biometric technology. This approach also serves to extend the generality of the interface to address a larger set of potential biometric technologies and applications.
This specification is designed to support multiple authentication methods, both singularly and when used in a combined or
Thereafter, whenever the user needs to be authenticated, samples are captured from the device, processed into a usable
form, and matched against the template that was enrolled earlier. This form of biometric authentication is called
since it verifies that a user is who they say they are (that is, verifies a particular asserted identity).
Biometric Technology, however, allows a new form of authentication called
In this form, a user does not have to assert
an identity. Instead, the biometric service provider compares the processed samples of the user against a specified population of
templates, and decides which ones match most closely. Depending on the match probabilities, the user's identity could be
concluded to be that corresponding to the template with the closest match.
biometric identification record
are assigned and registered by the International Biometric Industry Association (IBIA), which
|Post:||601 Thirteenth Street, NW, Suite 370 South, Washington DC. 20005, USA|
|Email:||firstname.lastname@example.org for general information|
The Signature is optional. For standardized BIR formats, the signature will take a standard form (to be determined when the format is standardized). For proprietary BIR formats (all that exists at the present time), the signature can take any form that suits the BSP. For this reason, there is no C-program structure definition of the signature.
The BIR Data Type indicates whether the BIR is signed and/or encrypted.
When a service provider creates a new BIR, it returns a handle to it. Most local operations can be performed without moving the BIR out of the service provider. [BIRs can be quite large, so this is a performance advantage.] However, if the application needs to manage the BIR (either store it in an application database, or send it to a server for verification/identification), it can acquire the BIR using the handle.
Whenever an application needs to provide a BIR as input, it can be done in one of three ways:
There are several good reasons why processing and matching
may take place on a server, including:
Two methods are provided to support client/server processing.
There are four primitive functions in the API which, when used in sequence on client and server, can accomplish the same as the high-level abstractions:
Capture is always execute on the client machine; attempting to execute Capture on a machine without a biometric device will return function not supported. One or more samples are acquired (either for Enrollment, Verification or Identification). The Capture function is allowed to do as much processing on the sample(s) as it sees fit, and may, in fact, for verification or identification complete the construction of the BIR. If processing is incomplete, Capture returns an "intermediate" BIR; indicating that the Process function needs to be called. If processing is complete, Capture returns a "processed" BIR; indicating that the Process function does not need to be called. The application specifies the purpose for which the samples are intended, giving the BSP the opportunity to do special processing. This purpose is recorded in the constructed BIR.
The "processing algorithms" must be available on the server, but may also be available on the client. The Process function is intended to provide the processing of samples necessary for the purpose of verification or identification (not enrollment). It always takes an "intermediate" BIR as input, and may complete the processing of the biometric data into "final" form suitable for its intended purpose. On the client, if it completes the processing, it returns a "processed" BIR; otherwise it returns an "intermediate" BIR; indicating that Process needs to be called on the server. On the server, it will always complete processing, and always return a "processed" BIR. The application can always choose to defer processing to the server machine, but may try to save bandwidth (and server horsepower) by calling Process on the client.1
Performs the actual comparison between the "processed" BIR and one template (VerifyMatch), or between the "processed" BIR and a set of templates (IdentifyMatch). The support for IdentifyMatch is optional, but the supported Match functions are always available on the server, and may be available on the client.
CreateTemplate is provided to perform the processing of samples for the construction of an enrollment template. CreateTemplate always takes an "intermediate" BIR as input, and constructs a template (that is, a "processed" BIR with the recorded purpose of either enroll_verify and/or enroll_identify). Optionally, CreateTemplate can take an old template and create a new template which is the adaptation of the old template using the new biometric samples in the "intermediate" BIR. The BSP may optionally allow the application to provide a "payload" to wrap inside the new template - see
The application (on both the client and the server) is responsible for providing a streaming interface for the BSP to use to communicate the samples and return the results. In this case, the application does not need to use the Capture, Process and Match primitives. The Verify, Identify, and Enroll, functions use the streaming interface to split the BSP function between client and server. These functions may be driven from either the client or the server. In either the case, if there are Graphical User Interface (GUI) callbacks set, the client BSP will call them at the appropriate times to allow the client application to control the look and feel of the user interface.
There are two possible measures for the results of a match:
FAR is the probability that samples falsely match the presented template, whereas FRR is the probability that the samples are falsely rejected (that is, should match, but do not). Depending on the circumstances, the application may be more interested in one than the other.
The HRS functions allow the application to request a maximum FAR value (that is, a limit on the probability of a false match,) and an optional maximum FRR value. If both are provided, the application must tell the BSP which one should take precedence.
The principal result returned is the actual FAR value achieved by the match. A BSP may optionally return the actual FRR value achieved. For Identify and IdentifyMatch, these results are contained in the Candidate array.
The returning of scores to an application can be a security weakness if appropriate steps are not taken.. This is because a "rogue" application can mount a "hillclimbing" attack by sequentially randomly modifying a sample and retaining only the changes that produce an increase in the returned score. In this way a synthetic image can be created to fool the biometric system. However, allowing only discrete increments of score (FAR) to be returned to the application eliminates this method of attack. The level of quantization required to neutralize this attack is dependent on the type of biometric and the algorithms used.
In the Enroll, Process, and Update functions, the application may present a "payload" to be carried in the opaque data of the BIR that is being constructed. This payload is essentially wrapped inside the biometric data by the BSP. It is released to the application on successful verification of the template. The BSP may have a policy of only releasing the "payload" if the Actual FAR achieved is below a certain threshold (this threshold being recorded in the BSP's registry entry).
The "payload" can be any data that is useful to the application; it does not have to be cryptographic; and even in a cryptographic application it could be either a key label or a wrapped key.
The HRS allows a BSP to manage a database of BIRs for two reasons:
It is the responsibility of the application to make any necessary association between the BSP's database(s) and the user database(s). To assist in this, each entry in a BSP database has a GUID associated with it. For security reasons, entries in a BSP database cannot be modified; only created and deleted. New entries get new GUIDs.
Not all service providers support identification, and not all those need to support a database interface. If the identification population is sufficiently small, it can be handled by passing an array of BIRs across the interface.
Databases can be created by name, and a service provider may have a default database. If a service provider supports a device that can store BIRs, then that device should be the default database. The default database is always open when the BSP is attached, and the handle to the open default database is always -1.
Most biometric service providers come with a built-in user interface, and this may often be sufficient for most purposes. The
API, however, allows the application to control the "look-and-feel" of this user interface, by allowing the application to
provide callbacks for the service provider to use to present and gather samples.
One of the callbacks is used to present and gather samples and to indicate state changes to the application. All service providers must support this callback, though the state machines may vary considerably. The other GUI callback is used to present streaming data to the user, in the form of a series of bitmaps. This callback is optional, and the service provider indicates in its registry entry whether one is required. This entry also indicates whether the user must validate samples, and whether samples are verified.
The service provider is in control of the user interface state machine, and calls the state callback whenever there is a state change event. These state changes may be the completion of a sample, progress on a sample, or the need to present the user with a message. On return, the application can present the service provider with a response from the user; cancel, continue, valid sample, invalid sample, etc.
If the service provider needs to present a sample stream to the user, it calls the streaming callback in parallel to the state change events. This callback will require multi-threading in both the service provider and the application.