Conformance

Status of this Appendix

In this regard, the content of this Appendix is advisory only, for guidance purposes as to the intentions of the HRS API designers.

Design Concepts for Conformance

• An HRS compliant application

• An HRS compliant service provider

HRS Compliant Application

All HRS function calls should be available. It is not intended that there should be a minimum set of functions that might be called.

HRS Compliant Service Providers

Service Providers are categorized as either Verification SPs or Identification SPs. In addition, an HRS-SP may be categorized as a monolithic or explicit client/server SP. A monolithic HRS-SP is fully loaded on a single platform. A client/server HRS-SP has components installed on two or more platforms. These components (client and server) may communicate with each other using the streaming callbacks provided by the client/server application.

HRS-SPs should accept all valid input parameters and return valid outputs. Optional capabilities and returns are not required to claim conformance. However, any optional functions or parameters that are implemented should be implemented in accordance with the specification requirements.

Additionally, all HRS-SPs should provide all required module registry entries. Entries to the module registry should be performed upon installation.

HRS-SPs should possess a valid and unique GUID, which may be self-generated.

Biometric data generated by the HRS-SP should conform to the data structures defined in Data Structures. HRS-SPs may only return CSSM_HRS_BIR data containing a registered FormatOwner with an associated valid FormatType.

All BSPs should support all Handle operations - see Handle Operations. Database operations - see HRS_SetPowerMode - are optional.

The following table is a summary of HRS-SP conformance requirements by type. Details are provided in the following sections.

HRS Compliant Verification SPs

Note:

1:few matching may be supported as a series of 1:1 calls.

An HRS compliant Verification SP should support the following biometric functions:

HRS_Enroll(

Only Purpose flags indicating Enroll for Verification should be accepted. If another purpose is set, an error condition should be set as a CSSM_RETURN. Acceptance of Payload is optional.

Client/server implementations of this function are optional.

HRS_Verify()

Client/server implementations of this function are optional.

Only the nearest, better supported RequestedFAR should be supported; however, the SP should return that supported value (ActualFAR).

Return of payload is required only if one is contained within the input StoredTemplate and if the score sufficiently exceeds the ActualFAR.

Return of AdaptedBIR is optional Return of raw data (AuditData) is optional.

As a default, all SPs should provide any GUI associated with the capture portion of the Verify operation. However, support for application control of the GUI is optional.

HRS Compliant Identification SPs

HRS_Enroll()

Purpose flags indicating either Enroll for Verification or Enroll for Identification should be accepted.

Acceptance of Payload is optional

Client/server implementations of this function are optional.

HRS_Verify()

Client/server implementations of this function are optional.

Only the nearest, better supported RequestedFAR should be supported; however, the BSP should return that supported value (ActualFAR).

Return of payload is required only if one is contained within the input StoredTemplate and if the score sufficiently exceeds the ActualFAR.

Return of AdaptedBIR is optional. Return of raw data (AuditData) is optional.

As a default, all SPs should provide any GUI associated with the capture portion of the Verify operation. However, support for application control of the GUI is optional.

HRS_Identify()

Client/server implementations of this function are optional.

Only the nearest, better supported RequestedFAR should be supported; however, the BSP should return that supported value (ActualFAR).

Support of binning is optional.

Return of matching Candidates is required; however, the SP may return values for the ActualFAR field as next nearest step/increment .

As a default, all SPs should provide any GUI associated with the capture portion of the Identify operation. However, support for application control of the GUI is optional.

HRS Compliant Client/Server SPs

If an HRS-SP is constructed such that it is installed and operates in a distributed fashion across a network or other communications channel, with direct communication between the distributed HRS components, it is considered to be a Distributed (Client/Server) HRS service provider. This does not include a Local service provider that can be installed in whole on both a client and a server platform, where communication between the client and the server is always at the application layer and the two instantiations of the service provider do not communicate with each other directly.

HRS-SPs should post to the module registry whether they support Local operation, Distributed operation, or both.

Local HRS-SPs should support all functions required by their category. These functions are both called locally (by an application running on the same platform) and executed locally (on the platform on which they are called and on which the service provider is installed). Streaming callbacks are not supported or used by local service providers.

In order to be HRS compliant, Client/Server service providers should support all functions for their category (Verification or Identification), defined above, when initiated from an application on either side. That is, all functions are supported by both the client and server components. However, although called locally, some functions may be executed remotely. These are identified below.

For functions that can be executed either locally or remotely, the application may dictate which mode the operation is to be performed in, via a parameter in the function call.

Additionally, Distributed HRS-SPs should support direct communication between partner components by "tunneling" through the application layer using the streaming callback capability (via the HRS_SetStreamCallback() and HRS_StreamInputOutput() functions).

Optional Capabilities

• If implemented, optional capabilities should conform to specification definitions.

• HRS-SPs are required to post to the module registry whether or not each option is supported.

• HRS-SP documentation should include a table that identifies which options are supported and which options are not supported.

Optional Functions

Primitive Functions

HRS-SPs are not required to implements the "primitive" functions:

HRS_Capture()
HRS_CreateTemplate()
HRS_Process()
HRS_VerifyMatch()
HRS_IdentifyMatch()

Database Operations

HRS-SPs are not required to provide an internal (or internally controlled) database. If one is provided, however, ALL database functions should be provided in order to access and maintain it. All provided database functions should conform to the definitions.

HRS_Import()

This function, as a whole, is optional. If it is provided, the module registry should so reflect, and it should be implemented as defined.

Verification BSPs are only required to process imported data if the Purpose flag includes Enroll for Verification. Identification-only SPs are only required to process imported data if the Purpose flag includes Enroll for Identification.

HRS_SetPowerMode()

This function, as a whole, is optional. If it is provided, the module registry should so reflect, and it should be implemented as defined.

Application Controlled GUI

All HRS compliant SPs should provide, as a default, the capability to display user interface information (assuming such a display is present and required by the autentication technology).

All SP supplied GUIs should include an operator abort/cancel mechanism.

Optionally, the HRS-SP may also support application controlled GUI. In this case, the SP should support the HRS_SetGUICallbacks() function.

If application controlled GUI is supported, the HRS-SP may additionally provide streaming data (for example, for voice and face recognition). If streaming data is provided, the SP should support the input parameters GuiStreamingCallback and GuiStreamingCallbackCtx.

All HRS-SPs should post to the module registry what GUI functions/options it supports.

Optional Sub-Functions

Return of Raw Data

Functions involving the capture of biometric data from a sensor may optionally support the return of this raw data for purposes of display or audit. If supported, the output parameter AuditData contains a pointer to this data. If not supported, the SP returns a value of -1.

Return of Quality

Upon the new capture of biometric data from a sensor, the SP may calculate a relative quality value associated with this data, which it will include in the header of the returned CapturedBIR (and the optional AuditData). If supported, this header field will be filled with a positive value between 1 and 100. If not supported, this field will be set to -2. This would occur during HRS_Capture() and HRS_Enroll().

Similarly, when a BIR is processed, another quality calculation may be performed and the quality value included in the header of the ProcessedBIR (and the optional ] AdaptedBIR). This would occur during

HRS_CreateTemplate()
HRS_Process()
HRS_Verify()
HRS_VerifyMatch()
HRS_Enroll()
HRS_Import()

ConstructedBIR operations.

The HRS-SP should post to the module registry whether or not it supports the calculation of quality measurements for each type of BIR - raw, intermediate, and processed.

Application-Controlled GUI

The HRS-SP supports the necessary callbacks to allow the application to control the "look-and-feel" of the GUI.

GUI Streaming Callbacks

The HRS-SP provides GUI streaming data, and supports the GUI streaming callback.

Detection of Source Presence

The HRS-SP can detect when there are samples available, and supports the source present event.

Payload Carry

Some HRS-SPs may optionally support the encapsulation of a Payload within a processed BIR, and the subsequent release of that payload upon successful verification. The content of the payload is unrestricted, but may include secrets such as PINs or private keys associated with the user whose biometric data is contained within the BIR. Payload data is encapsulated during a HRS_Enroll() or HRS_Process() operation, and is released as a result of a HRS_Verify() or HRS_VerifyMatch() operation. If supported, HRS-SPs should post to the module registry the maximum payload size it can accommodate. A maximum size of zero indicates payload carry is not supported. If input payloads exceed this size, an error should be generated. If payload carry is not supported, the output Payload is set to -1.

The HRS-SP should post to the module registry whether or not it provides the following:

• BIR encryption

• BIR signing

Return of FRR

During matching operations, the application may request a specific FAR threshold and the HRS-SP should return the nearest supported threshold. Optionally, the SP may also return the estimated FRR associated with this supported FAR. This Corresponding FRR value is an optional return from the HRS_Verify(), HRS_VerifyMatch(), HRS_Identify(), and HRS_IdentifyMatch() functions. If supported, the HRS-SP will return its best estimate of expected FRR. If not supported, the SP will return a value of -2.

Template/Model Adaptation

Some HRS-SPs may optionally provide the capability to utilize newly captured biometric data to update a stored BIR. This may only be performed as a result of a successful HRS_Verify() or HRS_VerifyMatch() (that is, one in which Result = CSSM_TRUE). This is performed in order to keep the enrolled BIR as fresh as possible, with the highest possible quality. The SP makes the decision as to when and if the adaptation should be performed (based on such factors as quality, elapsed time, and significant differences). If the SP does not support adaptation, the returned AdaptedBIR is set to -2. If the SP supports adaptation, but for some reason is not able or chooses not to perform the adaptation, then the return AdaptedBIR is set to -1. The SP should post to the module registry its support for adaptation.

Binning

Identification SPs may optionally support methods of limiting the population of a database to be searched in order to improve response time. This applies to Identification type SPs only and occurs only during HRS_Identify() and HRS_IdentifyMatch() operations. Identification SPs should post whether or not they support binning. Identification SPs that do not support binning may ignore the input Binning on/off parameter. Note that no explicit API support is provided for setting or modifying the binning strategy other than for turning it on or off.

Client/Server Communication

The SP supports the streaming callback to allow the client and server SPs to communicate.

Self-Contained Device

The supported device is self-contained. That is, at least the verification function is entirely contained within the device, and the device may contain a database.