NIST/ITL Conformance Test Suite 

for Patron Format A Data Structures 

Specified in ANSI INCITS 398-2008, 

Common Biometric Exchange Formats Framework (CBEFF) 

Beta Implementation V1.1 

Overview 

August 2008 

Fernando Podio, NIST/ITL, CTS Development Project Manager 

Mark Jerde, ID Technology Partners (NIST Contractor) 

Yooyoung Lee, Department of Computer Engineering, 

University of Chung-Ang, Korea (NIST Guest Researcher) 

Fred Herr, ID Technology Partners (NIST Contractor) 

Dylan Yaga, NIST STEP Student 

National Institute of Standards and Technology (NIST) 

Information Technology Laboratory (ITL) 

Computer Security Division (CSD)

CBEFF CTS 

Beta 1.1
2

DISCLAIMER FOR 

NIST/ITL CONFORMANCE TEST SUITE (CTS) FOR 

PATRON FORMAT A DATA STRUCTURES SPECIFIED IN ANSI INCITS 

398-2008, COMMON BIOMETRIC EXCHANGE FORMATS FRAMEWORK (CBEFF) 

BETA IMPLEMENTATION V1.1 

August 21, 2008 

The software was developed by the National Institute of Standards and Technology (NIST), an 

agency of the Federal Government. Pursuant to Title 15 United States Code Section 105, works 

of NIST are not subject to copyright protection in the United States and are considered to be in 

the public domain. Thus, the software may be freely reproduced and used. Please explicitly acknowledge the National Institute of Standards and Technology as the source of the software. 

This software is released by NIST as a service and is expressly provided "AS IS." NIST MAKES 

NO WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, 

WITHOUT LIMITATION, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT AND DATA ACCURACY. 

NIST DOES NOT REPRESENT OR WARRANT THAT THE OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT ANY DEFECTS WILL 

BE CORRECTED. 

NIST does not warrant or make any representations regarding the use of the software or the results thereof, including but not limited to the correctness, accuracy, reliability or usefulness of 

the software. By using this software or by incorporating this software into another product, you 

agree to hold harmless the United Sates Government for any and all damages or liabilities that 

arise out of such use. 

Certain trade names and company products are mentioned in the text or identified. In no case 

does such identification imply recommendation or endorsement by the National Institute of 

Standards and Technology, nor does it imply that the products are necessarily the best available 

for the purpose. With the exception of material marked as copyrighted, information presented in 

this document is considered public information and may be distributed or copied. Use of appropriate byline/photo/image credits is requested. 

This work was funded by NIST/ITL CSD and the NIST/ITL Identity Management Systems Program. It was funded in part by the National Institute of Justice.
3

Contents 

1. Introduction ........................................................................................................................... 4 

2. Background ............................................................................................................................ 4 

3. CBEFF data structures and conformance testing .............................................................. 5 

4. Conformance Testing Process and the PFA CTS Implementation................................... 6 

4.1 CBEFF conformance testing process .......................................................................... 6 

4.2 Conformance Test Suite Implementation................................................................... 7 

4.2.1 The GUI ................................................................................................................. 7

4.2.2 CTS Modules ......................................................................................................... 8 

5. Conclusion and ongoing / future work ................................................................................ 9 
4

NIST/ITL Conformance Test Suite for Data Structures Conforming to Patron 

Format A Specified in ANSI INCITS 398-2008, Common Biometric Exchange 

Formats Framework (CBEFF) 

Beta Implementation V1.1 

August 21, 2008 

Test Suite Overview 

1. Introduction 

This document describes a conformance testing process and a conformance test suite implementation developed by NIST/ITL for testing Biometric Information Records for conformance to the 

Patron Format A specified in Annex A of ANSI INCITS 398-2008, Common Biometric Exchange Formats Framework (CBEFF) [1]. 

The CBEFF group of standards – developed by national and international standards development 

bodies (InterNational Committee for Information Technology Standards (INCITS) Technical 

Committee M1 – Biometrics[2] and ISO/IEC Joint Technical Committee 1 (JTC 1) Subcommittee SC 37) – Biometrics[3]) define basic data structures and sets of abstract data elements and 

values that support the straightforward interchange of biometric data when used in conforming 

Biometric Information Records (BIRs). These values are designed to reveal the format and other 

attributes of the biometric data in the BIR without exposing the biometric data itself to applications. The CBEFF descriptive data in such BIRs provide a means for applications to efficiently 

determine whether a particular biometric data record is of interest, and if so, which biometric 

services to call to process the biometric-specific data. 

CBEFF promotes interoperability of biometric-based application programs and systems by specifying BIR headers – called Standard Biometric Headers (SBHs) – via specifications called “Patron Formats” that support the description of specific physical and logical attributes of the biometric data. Successful interoperability requires that the BIRs conform to a particular Patron 

Format specification. This in turn creates a need for conformance testing for the CBEFF Patron 

Formats. In addition to supporting the exchange of biometric data and metadata in an open systems environment, CBEFF data structures support security of biometric data. 

2. Background 

The success of biometric applications is particularly dependent on the interoperability of biometric systems. Standard-based solutions are required by many government and commercial applications. A number of biometric standards that will aid these users exist. The existence of standards alone is not enough to demonstrate that products meet the technical requirements specified 

in the standards. Conformance testing captures the technical description of a standard and measures whether an implementation faithfully implements the standard. 

NIST/ITL/CSD supports the development of national and international biometric standards and 

has promoted conformity assessment through active technical participation in the development of 

these standards, sponsorship of specific biometric standard projects (e.g., conformance testing 

methodologies for biometric technical interfaces), and the development of associated confor-
5

mance testing architectures and testing suites designed to test for conformance to a number of 

biometric interface and data interchange standards [4]. 

These efforts support US government agencies that are implementing or planning to implement 

biometric-based personal recognition systems as well as commercial applications of biometrics. 

This project is also well aligned with the goals of the National Science and Technology Council’s National Biometrics Challenge released in August 2006 [5], as well as key principles and 

goals of NSTC’s Policy for Enabling the Development, Adoption, and Use of Biometric Standards [6]. The Registry of USG Recommended Biometric Standards [7] developed by NSTC’s 

Subcommittee on Biometrics and Identity Management supplements the NSTC Policy for Enabling the Development, Adoption and Use of Biometric Standards. This Registry is based upon 

interagency consensus on biometric standards required to enable the interoperability of various 

Federal biometric applications, and to guide Federal agencies as they develop and implement related biometric programs. 

The biometric technical interface standards listed in the Registry are recommended for USG applications for biometric systems that include “plug and play” capability and easily support the 

seamless integration of system components into functioning systems and the swapping of components as needed without losing functionality, such as the ability to achieve data interchange 

and to protect the biometric data during transmission and storage. One of the standards included 

in the Registry is ANSI INCITS 398-2008. One of the CBEFF data structures specified in this 

standard is Patron Format A (PFA). This Patron Format is a general purposed, flexible and convenient format that is considered easy to decode. 

The session below discusses CBEFF data structures and concepts of conformance testing and the 

following session describes a conformance testing process and the Conformance Test Suite 

(CTS) implementation. This CTS can be applied against an implementation to determine whether 

the standard or specification requirements of the patron format are met. 

3. CBEFF data structures and conformance testing 

CBEFF describes a set of data elements and values to support biometric data records in a common way. These data elements can be encoded in a record header that facilitates exchange of 

biometric data between different system components or between systems. The CBEFF standards 

provide forward compatibility for technology improvements and allow creation of new patron 

formats. The BIR structure defined by CBEFF supports security (digital signatures and data encryption), processing information and descriptive attributes of the biometric data. 

As shown in Figure 1, the CBEFF record defines three components in a single structure. 

Standard Biometric 

Header (SBH) 

Biometric Data 

Block (BDB) 

Security Block 

(SB) 

Figure 1 - CBEFF Biometric Information Record (BIR) Structure 
6

- The SBH (Standard Biometric Header) includes the data elements (required and optional) 

that describe the biometric data's structure and selected attributes of its content. These include 

the appropriate standardized data elements and values defined by CBEFF, and may also include 

data elements and values defined by a patron format specification to satisfy unique requirements. 

- The BDB (Biometric Data Block) contains the biometric data. It can contain processed or unprocessed data. A BDB typically conforms to a standardized data interchange format such as the 

formats developed by INCITS M1 or JTC 1/SC 37, but could – alternatively – contain a proprietary data structure. Fields in the SBH specifically identify the BDB format and other metadata so 

the biometric application can pass the BIR or the BDB content to the correct biometric processing module. 

- The SB (Security Block) can contain a digital signature, message authentication code (MAC), 

or algorithm identifier information and parameters required for applying integrity and encryption 

processes to the BDB. CBEFF requires that the SBH not be encrypted, although it can be covered by integrity algorithms. As with the BDB format, the SB format is defined by an SB "owner" and can be adapted to the specific requirements of an application or system. Fields in the 

SBH identify the SB format to guide integrity checking of the entire BIR and to support appropriate decryption of the BDB. 

The CTS described by this overview was designed to test the conformance of BIRs to CBEFF 

Patron Format A specified in ANSI INCITS 398-2008. As stated in the previous section, Patron 

Format A is a flexible and convenient format and considered easy to decode. The SBH defined 

by this Patron Format includes mandatory, conditional and optional CBEFF data elements. The 

CBEFF Patron Format A specification uses an Optional Fields Present Mask to indicate which 

optional fields are present in the SBH of each BIR. The Patron Format A specification requires 

that the CBEFF fields in the SBH be in the same order as specified in the format. 

The CTS implementation tests conformance of the SBH components of a BIR to instantiations of 

Patron Format A (e.g., mandatory fields-only implementation, mandatory and some optional 

field implementations) and the consistency of the BIR (it validates the lengths of the BIR, BDB 

and SB). As stated below, other CTS modules are being developed to test BDB conformance to 

biometric data interchange standards as well as BIRs for other Patron Formats. 

4. Conformance Testing Process and the PFA CTS Implementation 

Conformance testing establishes whether or not the Implementation Under Test (IUT) meets all 

of the requirements specified by a standard. It is normally used by implementers during the 

product development process. It is also meant to provide the users of these products some assurance that the product conforms to a standard or specification as expected. 

4.1 CBEFF conformance testing process 

A conformance testing process is the complete range of testing activities necessary to assess the 

conformity of an IUT. For the purposes of this document, only the biometric information record 

(the BIR) claiming conformance to Patron Format A of ANSI INCITS 398-2008, is considered 

an IUT. The overall process includes: 
7

a) Analysis of the specification or standard: 

i) Identification of data elements to be tested and other requirements (e.g., internal consistency of the data structure) 

b) Development of a conformance testing methodology including: 

i) Scope of the tests and development of test objectives, test assertions and test cases1

c) CTS implementation including: 

i) Development of a testing plan 

ii) Design of a detailed architecture 

iii) Development of the CTS 

iv) Generation of required data (e.g., Test Cases, Manifests) to test the CTS implementation (see below) 

d) Execution of the tests and generation of test logs and test reports 

 

This CTS implementation performs Level 1 and 2 testing based on assertions developed to perform these tests. Some test assertions that are not required by the base standard were implemented in the CTS for operator’s convenience. Level 1 checks field by field and byte by byte 

conformance with the specification of Patron Format A as specified in ANSI INCITS 398-2008, 

both in terms of fields included and the ranges of the values in those fields. Level 2 testing confirms the internal consistency of the BIR under test, relating values from one part or field of the 

BIR to values from other parts or fields of the BIR (typically internal length fields). 

4.2 Conformance Test Suite Implementation 

The CTS architecture consists of a Graphical User Interface (GUI) and a CTS Module both developed in C#. The architecture is designed to support SBH, BDB and SB testing modules. 

4.2.1 The GUI 

The GUI is responsible for handling the tests, tracking and logging test results, test suite parameterization and selection as well as interfacing with the appropriate testing modules and presenting 

results to the user. 

The current CTS implementation allows the user to perform the following tasks and tests: 

1) Edit – This function generates and edits Manifests and Test Cases and can also edit a 

binary file. A Manifest is a file that defines the format to which a Binary File must conform. 

2) Test Binary Files – A Binary file is an instantiation of BIR data. This data is tested 

against a Manifest. A Binary file doesn’t contain any information beyond the test data 

values. 

 

1

 NIST/ITL/CSD sponsored an INCITS M1 project for the development of a conformance testing methodology 

standard for CBEFF data structures specified in ANSI INCITS 398-2008. NIST/ITL/CSD submitted to INCITS M1 

the test assertions for PFA developed for this projects as well as assertions for the other Patron Formats. 
8

3) Test Cases Tester – A Test Case can be thought of as a self-contained combination of a 

Manifest and a specific Binary File. Test Cases are primarily used by module developers 

to ensure the modules perform as expected. There are two types of Test Cases, Valid 

Test Cases and Invalid Test Cases. Valid or Invalid, a Test Case should always “Pass.” 

It can “Pass” for either of two reasons. 

• First, testing of the Test Case passes. This is a Valid Test Case. 

• Second, testing fails, but the reason it failed was expected. This is an Invalid Test 

Case. Invalid Test Cases can be difficult to understand so the following is a simplified illustration. For example, suppose a standard states “The value in field one 

shall be 3.” The developers could construct a Test Case with the value 4 in field 

one, expecting the test to fail. If the test fails because the value in field one is 

wrong the Test Case passes – it has shown the module does not accept this incorrect value in field one. The Invalid Test Case has proved the module correctly rejects the field one value 4. 

A broad set of Test Cases gives a high degree of confidence that the module functions as 

it should. Over 1,000 Test Cases were created for the CTS and they all pass (only a few 

are included in the distribution for illustration). 

Figure 2 - Conformance Testing Architecture 

4.2.2 CTS Modules 

CTS modules implement the actual test logic for testing a particular IUT. CTS modules are designed according to the standard or specification to which the IUT claims conformance. As 

shown in Figure 2, the GUI can interface with modules that test a variety of data structures. In 

IUT (Binary BIR) 

Test Cases (XML) GUI (C#) 

BDB 

Modules 

SB 

398-2008 PF-A Modules 

module 

(C#)

... ...

SBH Modules 

Test Logs (XML) Manifest (XML) Parameterization and Test Reports (HTML) 

Selection of Expected 

State 
9

this system, modules can be developed and executed not just for the substructures of CBEFF 

BIRs, but also for BDB content that claims conformance to a standardized data interchange format, or indeed for any well specified data structure. 

Since the CBEFF Patron Format A CTS tests whether IUTs satisfy both Level 1 and 2 testing 

requirements, the CTS module implementation is intended to test the following: 

- All CBEFF SBH mandatory, conditional and optional fields included in a PFA instantiation 

- All required interrelationships between the header fields 

- The lengths of the BIR substructures (SBH, BDB and SB) as recorded in the respective 

length fields 

If errors are found, one can deduce that the implementation does not conform to the specification. 

5. Conclusion and ongoing / future work 

The document discussed a Conformance Test Suite architecture and CTS implementation to test 

ITUs for conformance to CBEFF PFA as specified in ANSI INCITS 398-2008. The CTS allows 

for the generation/editing of Manifests and Test Cases and tests binary files for conformance to 

the patron format. It generates two types of results: test logs (in XML) for automated analysis of 

a large number of tests and test reports (in HTML) to facilitate operator’s analysis of test results. 

The CTS implementation has been successfully tested using a large set of Valid and Invalid Test 

Cases and binary files (conforming and not conforming to the standard). 

An advanced conformance testing architecture integrating the “Lessons Learned” from the CTS, 

is currently being implemented. CTSs to test implementations of selected biometric data interchange format standards are under development. Some of the key improvements being researched and /or implemented in Beta 2 include: 

• Module Dynamic Discovery – Similar to Adobe® PhotoShop® and other well-known 

programs that support “add-ins” or “plug-ins”, Beta 2 loads SBH, BDB and SB modules 

at runtime. There are two main benefits of this architecture. First, modules can be developed without modifying the GUI source code. (A “Module Developers’ Kit” is in 

consideration.) Second, new or updated modules are easily distributed and installed. 

• Web Services – Modules can be called either on the local computer or on a web services 

computer anywhere on the internet or an intranet. 

• Test Case Enhancement – Test Cases are greatly improved, allowing far fewer Test Cases 

to test more success and failure conditions. 

• Testing flexibility – Any module can be tested all by itself (e.g., conformance testing to a 

standard biometric data interchange format). 

Conformance testing is expected to contribute to enhanced biometric data interchange and interoperability. Conformance testing tools are expected to help both developers and end-users by 

verifying conformance claims, leading to greatly increased levels of confidence in products. 
10

References 

[1] ANSI INCITS 398-2008, Common Biometric Exchange Formats Framework (CBEFF) can 

be obtained (for a fee) at: http://www.techstreet.com/incitsgate.tmpl or 

http://webstore.ansi.org/ 

[2] InterNational Committee for Information Technology Standards (INCITS) Technical Committee M1 – Biometrics (http://m1.incits.org/) 

[3] International Standards Organization/ International Electrotechnical Commission (ISO/IEC) 

Joint technical Committee 1 (JTC 1) Subcommittee 37 (SC 37 ) – Biometrics (www.jtc1.org

– select SC 37 “Biometrics”. 

[4] NIST/ITL Computer Security Division 2007 Annual Report 

(http://csrc.nist.gov/publications/nistir/ir7442/NIST-IR-7442_2007CSDAnnualReport.pdf) 

[5] “The National Biometrics Challenge”, National Science and Technology Council, Subcommittee on Biometrics (now Subcommittee on Biometrics and Identity Management), August 

2006 (http://www.biometrics.gov/nstc/publications.aspx)

[6] “NSTC Policy for Enabling the Development, Adoption and Use of Biometric Standards”, 

NSTC Subcommittee on Biometrics and Identity Management, September 7, 2007 - 

http://www.biometrics.gov/Standards/Default.aspx

[7] “Registry of USG Recommended Biometric Standards”, V1.0, National Science and Technology Council, Subcommittee on Biometrics and Identity Management, June 5 2008 - 

http://www.biometrics.gov/Standards/Default.aspx