Previous section.

CDSA/CSSM Authenticaton: Human Recognition Service (HRS) API
Copyright © 2000 The Open Group



CDSA/HRS (Common Data Security Architecture/Human Recognition Service) is a CSSM (Common Security Services Manager) EMM (Elective Module Manager). It is intended to provide a high-level generic authentication model, suited to use for any form of human authentication. Particular emphasis has been made in the design on its suitability for authentication using biometric technology.

It covers the basic functions of Enrollment, Verification, and Identification, 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 "layered" manner.

Biometric Technology

The basic model is the same for all types of biometric technology. First, the initial "template" of the user has to be constructed. This is done by collecting a number of samples through whatever device is being used. Salient features are extracted from the samples, and the results combined into the template. The construction of this initial template is called Enrollment. The algorithms used to construct a template are usually proprietary. This initial template is then stored by the application, and essentially takes the place of a password.

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 Verification, 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 Identification. 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.

Possible Implementation Strategies shows some possible implementation strategies. The various steps in the verification and identification operations are shown in the box labeled Biometric Service Provider. The stages identified above the box refer to the primitive functions of the H-level interface.

and it shows that a BSP has degrees of freedom in the placement of function in these primitives. There is a degree of freedom not shown in Possible Implementation Strategies; the manufacturer is free to put most, if not all of the BSP functionality in the sensing device itself. In fact, if the device contains a Biometric Identification Record (BIR) database, all functions may be performed in the device.
Figure: Possible Implementation Strategies

BIRs and Templates

This standard uses the term template to refer to the biometric enrollment data for a user. The template must be matched (within a specified tolerance) by sample(s) taken from the user, in order for the user to be authenticated.

The term biometric identification record (BIR) refers to any biometric data that is returned to the application, including raw data, intermediate data, processed sample(s) ready for verification or identification, as well as enrollment data. Typically, the only data stored persistently by the application is the BIR generated for enrollment (that is, the template). The structure of a BIR is shown in Biometric Identification Record (BIR).

Figure: Biometric Identification Record (BIR)
The format of the Opaque Biometric Data is indicated by the Format field of the Header. This may be a standard or proprietary format. The Opaque Data may be encrypted.

Values of Format Owner are assigned and registered by the International Biometric Industry Association (IBIA), which ensures uniqueness of these values. Registered format owners then create one or more FormatIDs (either published or proprietary), corresponding to a defined format for the subsequent opaque biometric data, which may optionally also be registered with the IBIA. Organizations wishing to register as a biometric data format owner can do so for a nominal fee by contacting the IBIA:

Web site:
Telephone: +1 202-783-7272
Fax: +1 202-783-4345
Post: 601 Thirteenth Street, NW, Suite 370 South, Washington DC. 20005, USA
Email: for general information

Table: IBIA Contact 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:

API Model

There are three principal high-level abstraction functions in the API:

However, as Possible Implementation Strategies shows, the processing of the biometric data from the capture of raw samples to the matching against a template may be accomplished in many stages, with much CPU-intensive processing. The API has been defined to allow the biometric developer the maximum freedom in the placement of the processing involved, and allows the processing to be shared between the client machine (which has the biometric device attached), and a server machine. It also allows for self-contained devices, in which all the biometric processing can be done. Client/server support by BSPs is optional.

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.

  1. Using Primitive Functions

    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 Payloads.

    Figure: Client/Server Processing using Primitive Functions

  2. Using a Streaming Callback

    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.

    A client BSP that is servicing a self-contained device may ignore the Streaming Callback interface, and perform the requested function locally. A server BSP that is servicing a self-contained device will use the Streaming Callback to request that the client BSP proceeds to perform the requested function.
    Figure: Client/Server Operations Driven from Server

    Figure: Client/Server Operations Driven from Client


Raw biometric samples are the complex analog data streams produced by sensing devices. No two samples from a user are likely to be identical. Templates are the digital result of processing and compressing these samples; they are not precise representations of the user. Therefore, the results of any matching of samples against a stored template can only be expressed in terms of probability.

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.


No two biometric samples from a user are likely to be identical. For this reason, it is not possible to directly use biometric samples as cryptographic keys. The HRS, however, allows a template to be closely bound to a cryptographic key, which could be released upon successful verification.

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.

BIR Databases

The HRS does not manage user databases; only applications do that. In most cases, the user database may already exist (for example, a database of bank accounts, the user registry of people who belong to a network domain, or those authorized to access a web server), and the biometric application is simply associating a biometric template with each user in the database, in addition to (or as a substitute for) a password. It is important that the application does maintain control over who can access this database.

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.

User Interface Considerations

The user interface for passwords and PINs is quite straightforward, but for biometric technology it can be quite complex and very much technology dependent, requiring multiple implementation-dependent interactions with the user. Some biometric technologies present streams of data to the user (face and voice, for example), while some require the user to validate each sample taken (face, voice, and signature, for example). During enrollment, some technologies verify each sample taken against the previous samples. The number of samples taken for a particular purpose may vary from technology to technology, and finally, the user interface is generally different for enrollment than for verification and identification.

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.


"Processed" BIRs are always smaller than "intermediate" BIRs; by how much is technology dependent, and also dependent on how much processing has already been done by Capture.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index