text:
Biometric Specifications
for Personal Identity Verification
Patrick Grother
Wayne Salamon
Ramaswamy Chandramouli
NIST Special Publication 800-76-2
Biometric Specifications
for Personal Identity Verification
Patrick Grother
Wayne Salamon
Information Access Division
Information Technology Laboratory
Ramaswamy Chandramouli
Computer Security Division
Information Technology Laboratory
July 2013
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
There may be references in this publication to other publications currently under development by NIST in
accordance with its assigned statutory responsibilities. The information in this publication, including concepts and
methodologies, may be used by Federal agencies even before the completion of such companion publications.
Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist,
remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the
development of these new publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide
feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are
available at http://csrc.nist.gov/publications.
Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST)
promotes the U.S. economy and public welfare by providing technical leadership for the Nations measurement
and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations,
and technical analyses to advance the development and productive use of information technology. ITLs
responsibilities include the development of management, administrative, technical, and physical standards and
guidelines for the cost-effective security and privacy of other than national security-related information in
Federal information systems. The Special Publication 800-series reports on ITLs research, guidelines, and
outreach efforts in information system security, and its collaborative activities with industry, government, and
academic organizations.
Homeland Security Presidential Directive HSPD-12, Policy for a Common Identification Standard for Federal
Employees and Contractors [HSPD-12], called for Homeland Security Presidential Directive HSPD-12, Policy
for a Common Identification Standard for Federal Employees and Contractors [HSPD-12], called for new
standards to be adopted governing interoperable use of identity credentials to allow physical and logical access
to Federal government locations and systems. The Personal Identity Verification (PIV) standard for Federal
Employees and Contractors, Federal Information Processing Standard Personal Identity Verification (PIV) of
Federal Employees and Contractors (FIPS 201), was developed to define procedures and specifications for
issuance and use of an interoperable identity credential. This document, Special Publication 800-76 (SP 800-76),
is a companion document to FIPS 201. It describes technical acquisition and formatting specifications for the
PIV system, including the PIV Card itself. It also establishes minimum accuracy specifications for deployed
biometric authentication processes. The approach is to enumerate procedures and formats for collection and
preparation of fingerprint, iris and facial data, and to restrict values and practices included generically in
published biometric standards. The primary design objective behind these particular specifications is to enable
high performance and universal interoperability. The introduction of iris and face specifications into the current
edition adds alternative modalities for biometric authentication and extends coverage to persons for whom
fingerprinting is problematic. The addition of on-card comparison offers an alternative to PIN-mediated card
activation as well as an additional authentication method.
biometrics; credentials; identity management
The authors from the National Institute of Standards and Technology (NIST) wish to thank their colleagues who
reviewed drafts of this document and contributed to its development. Particular thanks go to the many external
commenters who produced detailed comments on the drafts, to Charles Wilson who directed the development of
the original SP 800-76 and its early update, SP 800-76-1, and to R. Michael McCabe for his extensive
knowledge of various fingerprint standards and the Federal Bureau of Investigation's procedures. The authors
also gratefully acknowledge and appreciate the many contributions from the public and private sectors for the
continued interest and involvement in the development of this publication.
Executive Summary
Scope: Homeland Security Presidential Directive 12, Policy for a Common Identification Standard for Federal Employees
and Contractors [HSPD-12], called for new standards to be adopted governing interoperable use of identity credentials
to allow physical and logical access to Federal government locations and systems. The Personal Identity Verification
(PIV) standard for Federal Employees and Contractors, Federal Information Processing Standard 201, Personal Identity
Verification (PIV) of Federal Employees and Contractors (FIPS 201), was developed to define procedures and
specifications for issuance and use of an interoperable identity credential. This document, Special Publication 800-76
(SP 800-76), is a companion document to FIPS 201. It describes technical acquisition and formatting specifications for
the PIV system, including the PIV Card itself. It also establishes minimum accuracy specifications for deployed
biometric authentication processes.
Approach: The approach is to enumerate procedures and formats for collection and preparation of fingerprint, iris
and facial data, and to restrict values and practices included generically in published biometric standards. The primary
design objective behind these particular specifications is to enable high performance and universal interoperability.
The introduction of iris and face specifications into the current edition adds additional modalities for biometric
authentication and extends coverage to persons for whom fingerprinting is problematic. The addition of on-card
biometric comparison offers an alternative to PIN-mediated card activation as well as an additional authentication
method. For the preparation of biometric data suitable for the Federal Bureau of Investigation (FBI) background
check, SP 800-76 references the ANSI/NIST Fingerprint Standard [AN2011] and the FBI's Electronic Biometric
Transmission Specification [EBTS].
Domain of use: Recognizing that PIV specifications are sometimes leveraged in other identity management
applications, it should be noted that derivative programs should adopt these PIV-specifications with appropriate
deliberative technical augmentation. The biometric data elements contained in this standard are suitable for one-to-
one verification of document holders when other application-specific factors are maintained. But, for example, if the
fingerprint templates mandated here are used in conjunction with fingerprints captured on non-PIV compliant
fingerprint sensors, there may be systematic degradations in recognition accuracy. Similarly, while it would be
appropriate to take the compressed iris specification defined here for use on a nation state's e-Passports , it would be
technically suboptimal to then copy those iris images to be the enrollment samples of an expedited traveler program
running in one-to-many single-factor mode (i.e., the mode of [NEXUS,UKIRIS]).
Biometric data used outside the PIV Data Model is not within the scope of this standard.
A physical artifact (e.g., identity card, smart card) issued to an individual that contains a PIV Card Application which stores
identity credentials (e.g., photograph, cryptographic keys, digitized fingerprint representations) so that the claimed identity of
the cardholder can be verified against the stored credentials by another person (human readable and verifiable) or an automated
process (computer readable and verifiable).
In the Data Group 4 container defined for iris data by [ICAO].
Table of Contents
1. Introduction .............................................................................................................................................. 1
1.1 Authority ....................................................................................................................................................... 1
1.2 Purpose and scope ....................................................................................................................................... 1
1.3 Audience and assumptions .......................................................................................................................... 1
1.4 Overview ....................................................................................................................................................... 2
1.4.1 Document structure ....................................................................................................................... 2
1.4.2 Inclusion of iris recognition ............................................................................................................ 3
1.4.3 Inclusion of fingerprint on-card comparison ................................................................................. 3
1.5 Relation to other biometric applications ..................................................................................................... 3
1.6 Second generation standards ...................................................................................................................... 4
2. Terms and acronyms................................................................................................................................ 5
2.1 Terms ............................................................................................................................................................. 5
2.2 Acronyms ...................................................................................................................................................... 5
2.3 Organizations ................................................................................................................................................ 5
3. Fingerprint enrollment ............................................................................................................................ 6
3.1 Scope .............................................................................................................................................................6
3.2 Fingerprint image acquisition.......................................................................................................................6
3.2.1 Fingerprint collection .....................................................................................................................6
3.2.2 Training of PIV fingerprint collection staff ....................................................................................8
3.2.3 Monitoring overall enrollment quality ..........................................................................................8
3.3 Fingerprint image format for images retained by agencies .......................................................................8
3.4 Fingerprint image specifications for background checks ......................................................................... 10
4. Fingerprint off-card authentication specifications .............................................................................. 12
4.1 Scope ............................................................................................................................................................12
4.2 Source images ..............................................................................................................................................12
4.3 Card issuance ...............................................................................................................................................12
4.4 Minutia record for off-card authentication ............................................................................................... 13
4.4.1 Use of a standard.......................................................................................................................... 13
4.4.2 General case .................................................................................................................................. 13
4.4.3 Special case for individuals who cannot be fingerprinted.......................................................... 15
4.5 Performance specifications for PIV compliance ........................................................................................ 16
4.5.1 Background and scope ................................................................................................................. 16
4.5.2 Minimum interoperability specification ...................................................................................... 16
4.5.3 Minimum accuracy specification...................................................................................................17
4.5.4 Test method ...................................................................................................................................17
4.6 Performance specifications for PIV operations ..........................................................................................17
4.7 Fingerprint capture ......................................................................................................................................17
4.7.1 Scope ..............................................................................................................................................17
4.7.2 Fingerprint acquisition specifications for flat capture sensors ...................................................17
5. Fingerprint on-card comparison specifications .................................................................................... 18
5.1 Scope ........................................................................................................................................................... 18
5.2 Background ................................................................................................................................................. 18
5.3 Approach to the use of standards ............................................................................................................. 18
5.4 Finger selection ........................................................................................................................................... 19
5.5 Data objects ................................................................................................................................................ 19
5.5.1 Biometric Information Template ................................................................................................. 19
5.5.2 Minutiae data for on-card comparison ........................................................................................ 20
5.6 Preparation of the minutia templates ........................................................................................................21
5.6.1 Conversion of INCITS 378 to ISO/IEC 19794-2 on-card comparison templates ...........................21
5.6.2 Effect of the BIT .............................................................................................................................21
5.7 Performance specifications for PIV compliance ........................................................................................ 22
5.7.1 Scope ............................................................................................................................................. 22
5.7.2 Background ................................................................................................................................... 22
5.7.3 Minimum interoperability specification ...................................................................................... 22
5.7.4 Minimum accuracy specification.................................................................................................. 23
5.7.5 Performance specifications for PIV operations .......................................................................... 23
5.8 Fingerprint capture ..................................................................................................................................... 23
5.9 On-card comparison interface.................................................................................................................... 23
6. Iris recognition specifications ............................................................................................................... 24
6.1 Scope ........................................................................................................................................................... 24
6.2 Background ................................................................................................................................................. 24
6.3 Iris image specification for PIV Cards ......................................................................................................... 25
6.3.1 General case .................................................................................................................................. 25
6.3.2 Special case for individuals whose eyes cannot be captured .................................................... 26
6.4 Iris image specification for iris images retained outside the PIV Card ..................................................... 27
6.5 Conformance of ISO/IEC 19794-6:2011 records .......................................................................................... 28
6.6 Iris image quality control ............................................................................................................................ 28
6.7 Performance specifications for PIV compliance ........................................................................................ 28
6.7.1 Properties of iris cameras............................................................................................................. 29
6.7.2 Specifications for iris record generators ..................................................................................... 29
6.7.3 Specifications for iris image matchers ......................................................................................... 30
6.7.4 Test methods ................................................................................................................................ 30
6.8 Performance specifications for PIV operations ......................................................................................... 30
7. Facial image specifications..................................................................................................................... 31
7.1 Scope ........................................................................................................................................................... 31
7.2 Acquisition and format ............................................................................................................................... 31
7.3 Performance specifications for PIV operations ......................................................................................... 33
8. Biometric sensor interface specifications ........................................................................................... 34
8.1 Scope ........................................................................................................................................................... 34
8.2 Available specifications and standards ...................................................................................................... 34
9. Common header for PIV biometric data .............................................................................................. 35
9.1 Scope ........................................................................................................................................................... 35
9.2 The CBEFF Header ....................................................................................................................................... 35
9.3 The CBEFF Signature Block ......................................................................................................................... 37
10. Minimum accuracy specifications......................................................................................................... 39
10.1 Scope ........................................................................................................................................................... 39
10.2 Approach ..................................................................................................................................................... 39
10.3 Operating threshold specification ............................................................................................................. 39
10.4 Conformance to accuracy specifications ...................................................................................................40
10.4.1 Use of multiple samples with fixed thresholds ...........................................................................40
10.5 Agency consideration of false rejection performance ..............................................................................40
11. Conformance to this specification........................................................................................................ 42
11.1 Conformance............................................................................................................................................... 42
11.2 Conformance to PIV registration fingerprint acquisition specifications .................................................. 42
11.3 Conformance of PIV Card fingerprint template records ........................................................................... 42
11.4 Conformance of PIV registration fingerprints retained by agencies........................................................ 42
11.5 Conformance of PIV background check records ....................................................................................... 42
11.6 Conformance to PIV authentication fingerprint acquisition specifications ............................................. 42
11.7 Conformance of PIV facial image records ................................................................................................. 42
11.8 Conformance of CBEFF wrappers .............................................................................................................. 42
12. References .............................................................................................................................................. 43
A.3.1 Template generator .....................................................................................................................48
A.3.2 Template matcher ........................................................................................................................49
List of Figures
List of Tables
Table 1 Summary of properties and roles of on- and off-card fingerprint comparison ............................................... 3
Table 2 Fingerprint acquisition protocols ......................................................................................................................6
Table 3 Quality control procedure for acquisition of a full set of fingerprint images.................................................. 7
Table 4 INCITS 381 profile for agency retention of fingerprint Images ........................................................................9
Table 5 Record types for background checks .............................................................................................................. 10
Table 6 INCITS 378 profile for PIV Card templates ...................................................................................................... 13
Table 7 BIT group template and profile ....................................................................................................................... 19
Table 8 ISO/IEC 19794-2 and ISO/IEC 19785-3 finger position codes ........................................................................... 20
Table 9 ISO/IEC 19794-6 profile for iris images stored on PIV Cards ........................................................................... 25
Table 10 ISO/IEC 19794-6 profile for a null iris image stored on PIV Cards ................................................................. 26
Table 11 ISO/IEC 19794-6 profile for iris images stored outside PIV Cards .................................................................. 27
Table 12 INCITS 385 profile for PIV facial images ......................................................................................................... 31
Table 13 CBEFF concatenation structure ...................................................................................................................... 35
Table 14 Patron format PIV specification ..................................................................................................................... 35
Table 15 CBEFF content for specific modalities ............................................................................................................ 36
Table 16 Maximum allowed false match rates by modality......................................................................................... 39
Table 17 Example performance test and threshold calibration programs .................................................................40
Table 18 INCITS 378 specification for PIV Card template generator and matcher certification ................................48
Table 19 Profile of ISO/IEC 19795-2 for iris camera testing .......................................................................................... 52
1. Introduction
1.1 Authority
This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its
statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-
NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate
information security for all agency operations and assets, but such standards and guidelines shall not apply to
national security systems. This recommendation is consistent with the requirements of the Office of Management
and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in A-130,
Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.
This recommendation, prepared for use by federal agencies, may be used by non-governmental organizations on a
voluntary basis and is not subject to copyright. Nothing in this document should be taken to contradict standards and
guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority.
Nor should this recommendation be interpreted as altering or superseding the existing authorities of the Secretary of
Commerce, Director of the Office of Management and Budget, or any other Federal official.
1.4 Overview
1.4.1 Document structure
This document defines:
In Section 2, acronyms and terms;
in Section 3, the fingerprint acquisition process, requirements for transmission of data to FBI, and a format for
agency-optional image retention;
in Section 4, the format of the PIV Card minutiae templates for off-card authentication, and specifications for
algorithms used in the generation and matching of such;
in Section 5, the formats and data structures for minutiae used in on-card comparison operations, and
specifications for algorithms used in the generation and matching of such;
in Section 6, the format for iris data stored on and off PIV Cards, and specifications for cameras and algorithms
used for the collection, preparations and matching of such;
in Section 7, the format and data structures for facial images on PIV Cards, and specifications for collection
in Section 8, interface specifications for biometric sensors;
in Section 9, the CBEFF header and footer supporting digital signatures on all PIV biometric data;
in Section 10, minimum accuracy specifications;
in Section 11, additional conformance information, beyond the specifications embedded in Sections 4 through 7;
in Section 12, references.
Figure 1 gives an approximate procedure for biometric data acquisition and disposition.
1.4.2 Inclusion of iris recognition
Iris specifications are included, in Section 6, to support biometric authentication of individuals. [FIPS] allows use of
iris for this purpose. The recommendation to agencies to install and operate iris equipment in its PIV issuance
processes allows agencies to additionally populate PIV Cards with iris as an alternative authentication modality. [FIPS]
requires the cardholder to enter a PIN number to release the templates. When the card is cryptographically
authenticated, this constitutes multi-factor authentication.
Table 1 Summary of properties and roles of on- and off-card fingerprint comparison
# Aspect Off-card comparison On-card comparison
1. [FIPS] requirement on Mandatory Optional
presence of biometric data
2. Use cases and pre-requisites
See [FIPS]
for access to the data
3. Interagency interoperable Yes No (As OCC is optional, it is only interoperable across
agencies if both agencies implement it).
4. Number of fingers required 2. But 0 or 1 are allowed in 1 or 2
to be stored on card exceptional cases see [FIPS]
5. Number of fingers to be used 1 or 2 1 or 2
in a biometric operation
6. Which fingers Members of the set A, which is a Members of the set B, which is a subset of the ten finger set
subset of the ten finger set T T, and |A B| 0, i.e., , fingers may be the same. See
Section 5.4.
7. Encoding of specific fingers INCITS 378:2004 [MINUSTD] ISO/IEC 7816-11:2004 [CARD-BIO]
8. Data format specifications This document, Section 4 This document, Section 5
9. Card interface specifications SP 800-73-4 [800-73] SP 800-73-4
10. Underlying data format INCITS 378:2004 [MINUSTD] ISO/IEC 19794-2:2011 [CARD-MIN] This template shall be
standard computed from the off-card INCITS 378:2004 template.
11. Fingerprint capture device Plain impression as specified in Section 4.7
for biometric operations
12. Accuracy testing MINEX III MINEX IV
NIST Special Publication 800-63-1 Electronic Authentication Guideline identifies three factors - things a person has, knows, and is.
PIV Card read times are replaced with network transmission times.
PIN entry times are eliminated but the something-you-know additional factor is lost.
The remote server is subject to physical or logical attack (e.g., a denial-of-service attack). Many kinds of
templates stored on a server can be reversed to produce a matchable-sample [REVFING, REVIRIS, REVFACE].
Formal template protection schemes, which mitigate the effect of compromise of a database, require further
If the PIV Card is not used to make an explicit claim to one of the N enrolled identities, the biometric-only one-to-
many authentication loses the something-you-have factor, and necessitates mitigation of a N-fold increase in false
match rates.
Such use cases are not addressed by this specification.
2. Terms and acronyms
2.1 Terms
Term Definition
Fingerprint Segmentation is the automated (and often manually reviewed) separation of an image of N fingers
segmentation into N images of individual fingers. N is usually four, for the index through little finger, and two for
a capture of two thumbs.
Iris segmentation Segmentation is the automated (and possibly manually reviewed) detection of the iris-sclera and
iris-pupil boundaries. This localizes the iris texture that is used for actual recognition.
One-to-many Of or relating to biometric identification in which submitted feature data is compared with that of
all enrolled identities.
One-to-one Of or relating to biometric verification in which submitted feature data is compared with that of
one, claimed, identity.
2.2 Acronyms
Acronym Definition
BIT Biometric Information Template a [CARD-BIO] data structure indicating Card capability
CBEFF Common Biometric Exchange Formats Framework
Detection Error Tradeoff (characteristic) A plot of FRR vs. FAR, or FNMR vs. FMR, used to
inform security-convenience tradeoffs in (biometric) authentication processes
FAR False Accept Rate (defined over an authentication transaction)
FIPS Federal Information Processing Standard
FMR False Match Rate (defined over single comparisons)
FNMR False Non-Match Rate (defined over single comparisons)
FRR False Reject Rate (defined over an authentication transaction)
FTE Failure to Enroll Rate
EBTS Electronic Biometric Transmission Specification (See References Section 12)
JPEG Joint Photographic Experts Group, standardized compression algorithm for face images
OCC On-card comparison
PNG Portable Network Graphics, standardized lossless compression algorithm for images
IREX Iris Exchange the NIST program supporting iris-based biometrics
MINEX Minutia Exchange the NIST program supporting minutia-based biometrics
NACI National Agency Check with Inquiries
NIST Fingerprint Image Quality an automated algorithm for quantifying good fingerprint
images; available as open-source.
SP Special Publication a designation for NIST documents, sometimes supporting FIPS.
WSQ Wavelet Scalar Quantization
2.3 Organizations
Acronym Definition
ANSI American National Standards Institute
FBI Federal Bureau of Investigation
IEC International Electrotechnical Commission
INCITS InterNational Committee for Information Technology Standards
ISO International Organization for Standardization
ITL Information Technology Laboratory (of NIST)
NIST National Institute of Standards and Technology
OMB Office of Management and Budget
OPM Office of Personnel Management
SC 37 The Biometrics standardization subcommittee under ISO/IEC Joint Technical Committee 1
3. Fingerprint enrollment
3.1 Scope
The specifications in this Section pertain to the production of the mandatory PIV biometric enrollment data. That is,
this Section provides specifications for acquisition, formatting, and storage of fingerprint images and templates. The
following is an overview of the material covered in this Section.
Sub-Section 3.2.1 gives specifications capture of fingerprints for PIV Registration and background checks;
Sub-Section 3.2.2 recommends training of enrollment station operators;
Sub-Section 3.2.3 recommends use of automated means to track fingerprint image quality over time;
Sub-Section 3.3 gives specifications for how fingerprint images are retained by agencies. [FIPS] gives
requirements and options for the retention of biometric data. Retention of data supports, for example,
detection of duplicate identities. When fingerprint images are retained they shall be stored in the format
specified in sub-Section 3.3. The format specification includes the [CBEFF] header of Section 9 to implement
the requirement to protect the integrity, and to allow for encryption, of the image records.
Sub-Section 3.4 specifies the transformation of fingerprints into records suitable for transmission to the FBI
for the background check.
Although FBI requirements drive the sensor specifications, the permanent electronic storage format specified in sub-
Section 3.3 is an INCITS standard record and is therefore specified independently.
If an agency retains fingerprint templates, in either proprietary or standardized formats, then they shall be embedded
in the [CBEFF] header of Section 9 which requires integrity protection and allows for encryption of the records.
1. There is no requirement that the order specified above is the order in which the images should be acquired.
2. The combined multi-finger plain-impression images are also referred to as slaps or flats. They are obtained by
simultaneous placement of multiple fingers on the imaging surface without specific rolling movement.
3. Options 2 and 3 represent existing agency practice. Although Option 1 is now acceptable to the FBI, agencies
may still need to implement Options 2 or 3 for transmission via the Office of Personnel Management.
For Options 1 and 2 the devices used for capture of the fingerprints shall have been certified by the FBI to conform to
Appendix F of the FBIs Electronic Biometric Transmission Specification [EBTS, Appendix F]. For Option 3, a scan of
the inked card shall be performed to effect conversion to electronic form. The scanner shall be certified by the FBI as
being compliant with [EBTS, Appendix F]. The scanning is needed to produce fingerprints in the digital formats of
Sub-sections 3.3 and 3.4. The FBI specifications include width and height specifications for the imaging surface. The
native scanning resolution of the device shall be 197 pixels per centimeter (500 pixels per inch) in both the horizontal
and vertical directions. These specifications comply with the FBI submission requirements and with the Image
Acquisition Setting Level 31 of the Finger Image-Based Data Interchange Format standard, INCITS 381 [FINGSTD].
For live-scan acquisition i.e., options 1 and 2, the enrollment client software should display the images to the attending
operator. The operator should repeat acquisition if the ridge structure is not clear, broken, or incomplete in the
displayed images.
The procedure for the collection of fingerprints, presented in Table 3, shall be followed. The procedure shall employ
the NIST Fingerprint Image Quality [NFIQ] algorithm to initiate any needed reacquisition of the images. An attending
official shall be present at the time of fingerprint capture. The agency shall employ measures to ensure the quality of
acquisition and guard against faulty presentation, whether malicious or unintentional. Quality assessment might be
an integral function of the acquisition device or might be implemented by the attending official. In any case, the
agency shall ensure that the applicant does not swap finger positions or hands, occlude fingers, or misalign or
misplace the fingers. Particularly, because it is common during collection of multi-finger plain impressions for little
fingers (i.e., positions 05 and 10) to not be long enough to reach the imaging platen, it is accepted practice for the
hand to be placed at an angle to the horizontal to ensure imaging of all four fingers. Although this is not needed with
newer large-platen devices the official shall in all cases take care to image all fingers completely. The procedure
requires segmentation of the multi-finger plain impressions; this operation may be assisted by the attending official.
Table 3 Quality control procedure for acquisition of a full set of fingerprint images
Step Action
1. Attending official should start by inspecting fingers and require absence of dirt, coatings, gels, and other foreign material.
2. Official should ensure imaging surface of the sensor or the paper card is clean.
Acquire fingerprints according to Option 1, 2, or 3 in Table 2. For Option 3, scan the inked card using [EBTS, Appendix F]
certified scanner.
Segment the multi-finger plain impression images into single-finger images. Automated segmentation is recommended.
4. Attending official should inspect the boundaries of the automatic segmentation and correct any failures, perhaps via an
interactive graphical user interface.
5. Compute NFIQ value for thumbs and index fingers. If all have NFIQ values 1, 2, or 3 (i.e., , good quality) then go to step 8.
6. Repeat steps 2-5 up to three more times.
If after four acquisitions the index fingers and thumbs do not all have NFIQ values of 1, 2 or 3 then select that set, acquired
in step 3 and segmented in step 4, for which the mean of the NFIQ values of the left index, right index, left thumb, and
7. right thumb is minimum (i.e., of best quality). If all of the index finger and thumb quality values are unavailable (perhaps
because of injury to one or more of those fingers) then use the last set from step 3 of those fingers that are available,
without any application of NFIQ.
8. Prepare and store the final records per Sub-sections 3.3 and 3.4
Ordinarily, all ten fingerprints shall be imaged in this process; however, if one or more fingers are not available (for
instance, because of amputation) then as many fingers as are available shall be imaged. When fewer than ten fingers
are collected, the FBI background transaction of Sub-section 3.4 requires field AMP 2.084 of the accompanying Type 2
record [see EBTS, Appendix C] to have labels indicating fingers that are amputated or otherwise not imaged.
A second version of the NFIQ algorithm is expected 9/13. This should a) produce quality values that better predict accuracy, b)
offer finer control of quality thresholds and c) offer additional capabilities. http://www.nist.gov/itl/iad/ig/development_nfiq_2.cfm
Given an input image, NFIQ (version 1) returns a value from 1 (excellent) to 5 (bad).
3.2.2 Training of PIV fingerprint collection staff
Quality of the biometric data is critical to the success of a biometric application. This is particularly true for enrollment
data that typically persists for years. As enrollment is an attended operation, the operator is important to the
collection of high quality data. Attending staff should be trained to maintain and clean the sensor, and to collect in
accordance with manufacturer's guidance and this document. Specifically Agencies shall apprise staff that:
Low humidity - typical in winter causes dry fingers from which good images are more difficult to collect. This risk
can be mitigated by measurement and appropriate use of supplemental humidification. Fingers may be lightly
Exposure of biometric equipment to bright light sources, such as direct sunlight, is generally adverse for
collection of fingerprints.
The background check can be defeated by mutilation of the fingerprints e.g.,either temporarily (e.g.,by burns or
abrasives) or permanently (e.g.,by surgical means). In addition certain medications can cause loss of fingerprint
ridge structure. It is recommended that collection of fingerprints from applicants with finger injuries be delayed
until the fingers heal.
To assist implementers, NIST has made [FINGSTD] sample data available .
34. Impression type (7.2.6) MF MV 0 or 2 See ANSI NIST ITL 1-2000
35. Horizontal line length (7.2.7) MF MV MIT
See Note 10
36. Vertical line length (7.2.8) MF MV MIT
37. Reserved (no clause) MF MV 0 See Note 11
38. Finger image data (7.2.9) MF MV MIT Uncompressed or compressed WSQ Data
39. CBEFF Signature Block MF MV See Section 9.3 of this document
Acronym Meaning
MF mandatory field [FINGSTD] mandates a field shall be present in the record
MV mandatory value [FINGSTD] mandates a meaningful value for this field
NC normative content [FINGSTD] gives normative practice for PIV. Such clauses do not define a field in the FIR.
A as required by standard For PIV, value or practice is as specified in [FINGSTD]
mandatory at time of For PIV, mandatory value that shall be determined at the time the record is instantiated and
instantiation shall follow the practice specified in [FINGSTD]
Fingerprint images conformant to this specification exist at http://www.itl.nist.gov/iad/894.03/nigos/piv_sample_data.html and
these were prepared using NIST software available from http://www.itl.nist.gov/iad/894.03/nigos/incits.html
1. The Capture Device ID should indicate the hardware model. The CBEFF PID [FINGSTD, 7.1.4] should indicate the
firmware or software version.
2. If certain fingers cannot be imaged, the value of this field shall be decremented accordingly.
3. The left and right four-finger images and two-thumb images may also be included. The value of this field shall be
incremented accordingly.
4. For PIV enrollment sets, the number of images will ordinarily be thirteen (that is, the ten segmented images from
the multi-finger plain impressions, and the three plain impressions themselves, 10+4+4+2) or fourteen (if the plain
thumb impressions were imaged sequentially, 10+4+4+1+1).
5. Images shall either be uncompressed or compressed using an implementation of the Wavelet Scalar Quantization
(WSQ) algorithm that has been certified by the FBI. As of February 2011, Version 3.1 of the WSQ algorithm shall be
used [WSQ31]. The FBI's requirement for a 15:1 nominal compression ratio shall apply.
6. Image compression should only be applied after the record content has been prepared, and the NFIQ quality
values have been computed.
7. The term view refers to the number of images of that particular finger (position). This value would exceed one if
imaging has been repeated. Inclusion of more than one image of a finger can afford some benefit in a matching
process. This document recommends that any additionally available images (say, from a PIV Card re-issuance
procedure) with quality value 1 to 3 should be included in the record. In all cases the images shall be stored in
order of capture date, with newest first.
8. Quality values shall be present. These shall be calculated from the NIST Fingerprint Image Quality (NFIQ) method
described in [NFIQ] using the formula Q = 20*(6 - NFIQ). This scale reversal ensures that high quality values
connote high predicted performance and consistency with the dictionary definition. The values are intended to
be predictive of the relative accuracy of a minutia based fingerprint matching system. It is recommended that a
user should be prompted to first attempt authentication using the finger with the highest quality, regardless of
whether this is the primary or secondary finger.
9. The quality value shall be set to 254 (the [FINGSTD] code for undefined) if this record is not a single finger print
(i.e., , it is a multi-finger image, or a palm print) or if the NFIQ implementation fails.
10. There is no restriction on the image size. However non-background pixels of the target finger shall be retained
(i.e., cropping of the image data is prohibited).
11. [FINGSTD, Table 4] refers to a single-byte field labeled "reserved", but there is no corresponding clause to
formally define it. The M1 committee has undertaken to resolve this by inserting a new sub-clause to require
inclusion of the "Reserved" field. This will appear in a revision of [FINGSTD]. In any case, PIV implementations
shall include the single byte field, setting the value to 0.
12. Line 27 indicates that the "Reserved" field shall have length 2 bytes. [FINGSTD, 7.1.15] indicates a length of 4
bytes which disagrees with the value in [FINGSTD, Table 2]. The INCITS M1 committee has indicated 2 bytes is the
correct value. PIV implementations shall include the 2 byte field, setting the value to 0.
1. All types of transactions with the FBI require both a Type 1 and Type 2 record to accompany the data; see
[AN2011, Table 2]. The Type 2 record supports labeling of missing fingers.
2. Fourteen records, one for each of 10 fingers, one for each four-finger plain, and one for each thumb
(segmented from a two-thumb image if necessary).
4. Fingerprint off-card authentication specifications
4.1 Scope
This Section specifies how the PIV mandatory biometric elements specified in [FIPS] are to be generated and stored.
This specification applies to templates stored within the PIV Card, and to [MINUSTD] templates otherwise retained by
agencies. The templates constitute the enrollment biometrics for PIV authentication and as such are supported by a
high quality image acquisition specification, and an FBI-certified compression format. The specification of a
standardized template here enables use of the PIV Card in a multi-vendor product environment.
4.4 Minutia record for off-card authentication
4.4.1 Use of a standard
PIV Card templates shall be a conformant instance of the INCITS 378-2004 [MINUSTD] minutiae template standard. A
standard record is used to satisfy global interoperability objectives. Second generation standards have been
published since the first PIV specification appeared in 2005; these standards are not cited in SP 800-76-2 for the
reasons given in Section 1.6. Implementations shall therefore respect the version number on Line 14 of Table 6.
Minutiae records conformant to the PIV specification are here http://www.itl.nist.gov/iad/894.03/nigos/piv_sample_data.html and these were
prepared using NIST software available from http://www.itl.nist.gov/iad/894.03/nigos/incits.html
Clause title and/or field name INCITS 378-2004 PIV Conformance
(Numbers in parentheses are [MINUSTD] Field or Value Informative Remarks
Values Allowed
clause numbers) content Required
23. Y (vertical) resolution (6.4.10) MF MV 197
24. Number of Finger Views (6.4.11) MF MV 2 Once each for primary and secondary
25. Reserved Byte (6.4.12) MF MV 0
26. Finger View Header (6.5.1) NC A
27. Finger Position (22.214.171.124) MF MV MIT
28. View Number (184.108.40.206) MF MV 0 See Note 10
View header
254, 255
M minutiae data records follow. If only M
31. Number of Minutiae (184.108.40.206) MF MV 0 M 128 10 minutiae are found re-enrollment
should be attempted.
32. Minutiae Type (220.127.116.11) MF MV 01b, 10b, or 00b See Note 1
M minutiae
Acronym Meaning
MF mandatory field [MINUSTD] requires a field shall be present in the FMR
MV mandatory value [MINUSTD] requires a meaningful value for a field
NC normative content [MINUSTD] gives normative practice for PIV. Such clauses do not define a field in the FMR.
A as required For PIV, value or practice is as normatively specified in [MINUSTD].
MIT mandatory at time of For PIV, mandatory value that shall be determined at the time the record is instantiated and
instantiation shall follow the practice specified in [MINUSTD]
1. [MINUSTD] requires that each stored minutia have a type associated with it. For PIV, the mandatory card
templates shall contain minutiae of type ridge ending or ridge bifurcation. These types are defined in [MINUSTD,
5.3.{2,3}]. Other types of minutiae, such as trifurcations and crossovers, shall not be included in PIV Card
templates. However, for those minutiae where it is not possible to reliably distinguish between a ridge ending
and a bifurcation, the category of "other" shall be assigned and encoded using bit values 00b. The angle and
location for a minutia of type "other" should be the angle and location that would have applied to the
corresponding ridge ending or bifurcation depending on which one the encoding algorithm determines to be the
most likely for that particular minutiae. This is a common characteristic of "inked" impressions that exhibit ridge
endings being converted to bifurcations and vice-versa due to over- or under-inking in the image.
2. The second paragraph of [MINUSTD, 6.4.2] refers both to an ASCII space and "three ASCII numerals" mentioned
in the first paragraph. The practice of using an ASCII space character as the first character of the version number
shall be followed: " 20\0" i.e., 0x20323000.
3. The length of the entire record shall fit within the container size limits specified in [800-73]. These limits apply to
the entire CBEFF wrapped and signed entity, not just the [MINUSTD] record.
4. Both fields ("Owner" and "Type") of the CBEFF Product Identifier of [MINUSTD, Clause 6.4.4] shall be non-zero.
The two most significant bytes shall identify the vendor, and the two least significant bytes shall identify the
version number of that supplier's minutiae detection algorithm.
5. The Capture Equipment ID shall be reported. Its use may improve interoperability.
6. The quality value shall be that computed for the parent image using [NFIQ] and reported here as Q = 20*(6 -
NFIQ). A value of "255" shall be assigned when fingerprints are temporarily unusable for matching. A value of
"254" shall be assigned when the fingerprints are permanently unusable.
7. All coordinates and angles for minutiae shall be recorded with respect to the original finger image. They shall not
be recorded with respect to any sub-image(s) created during the template creation process.
8. Determination of the minutia direction can be extracted from each skeleton bifurcation. The three legs of every
skeleton bifurcation must be examined and the endpoint of each leg determined. Figures 2A through 2C illustrate
the three methods used for determining the end of a leg. The ending is established according to the event that
occurs first:
o The 32nd pixel see Figures 2A and 2B or
o The end of skeleton leg if greater than 10 pixels (legs shorter are not used) see Figure 2B or
o A second bifurcation is encountered before the 32nd pixel see Figure 2C.
The angle of the minutiae is determined by constructing three virtual rays originating at the bifurcation point and
extending to the end of each leg. The smallest of the three angles formed by the rays is bisected to indicate the
minutiae direction.
10 < L 32 pixels
along ridge
second bifurcation
10 < L 32 pixels
C along ridge
If only one finger is available, the first view shall be populated and the second view shall be empty, as above.
Authentication systems encountering cards populated with empty minutia templates might use iris authentication, if
the data is present on card.
NOTE Minutia detection and matching algorithms continue to improve. Their accuracies have been measured on
reference data sets [MINEX04]. Some certified implementations are significantly more accurate than others,
affording lower false match rates for equal false rejection rates.
This specification applies to a commercial-off-the-shelf PC procured in 2005 and equipped with a 2GHz processor and 512 MB of
main memory. This specification shall be adjusted by the testing organization to reflect significant changes of the computational
3. it matches templates from all certified template generators, and the template generator accompanying the
matcher, with FNMR less than or equal to 0.01 at an FMR of 0.01 (where this is calculated from scores from the
sum of scores from two finger comparisons e.g., left and right index fingers).
The accuracy for interoperability criterion is that a matching algorithm recognizes all templates at a false match rate (FMR) less
than or equal to 0.01, the false non-match rate (FNMR) is at or below 0.01.
The MINEX III program replaces the original Ongoing MINEX procedure which ran 2007-2013. Implementations that were
deemed compliant in the older program are automatically compliant to Sections 184.108.40.206 and 220.127.116.11 as tested in MINEX III.
5. Fingerprint on-card comparison specifications
5.1 Scope
[FIPS] allows (but does not require) Agencies to use on-card comparison (OCC) of fingerprint minutiae. This Section
gives specifications for OCC for PIV. This specification includes enrollment data to be placed on the card,
authentication data to be sent to the card, and OCC certification information. This Section also specifies the data
structure for the storage of card parameters, and the procedure for preparation of OCC fingerprint minutiae
templates from those for off-card comparisons.
[800-73] indicates where OCC data is stored and that this data is separate and different from the mandatory off-card
comparison fingerprint templates. [800-73, Part 2] specifies the secure channel mechanisms to realize on-card
comparison over the [FIPS]-specified interfaces.
5.2 Background
NIST conducted two studies to support the use of on-card biometric comparison in identity management applications.
The Secure Biometric Match on Card activity engaged commercial providers to execute fingerprint
authentication over a contactless interface within a specific time limit. The study required privacy protection via
secured communication protocols and integrity protection using cryptographic signatures computed from the
biometric data. In addition, the card was authenticated to the reader. The activity has been published as NIST
Interagency Report 7452 [SBMOC].
The MINEX II evaluation was initiated to measure the core algorithmic speed and accuracy of fingerprint minutia
matchers running on ISO/IEC 7816 smartcards. Conducted in phases, the test required card- and fingerprint
matcher-provider teams to submit on-card comparison enabled cards. The latest results were reported in NIST
Interagency Report 7477 [MINEX II].
The main attraction of on-card comparison has been that someone who finds a card has only a small chance of
authenticating to it with fingerprints (related to the configured false match rate) the fact that template data never
leaves the card means that the attacker has no prior knowledge. See the related discussion in Section 5.4. In the off-
card comparison world, the PIN entry requirement is used to mitigate this risk.
FIPS 201-2 uses the term "on-card biometric comparison". It is standardized and preferred over the term "match-on-card".
This second edition of the minutia standard was completed on 2011-12-14.
5.4 Finger selection
This document recommends that different fingers should be imaged for off-card and on-card comparison. This
mitigates an attack where off-card templates are stolen (after PIN release) and used to prepare spoofs via [REVFING]
for use in on-card comparison (which is not preceded by PIN entry). This document nevertheless allows data from the
same fingers in on-card and off-card comparison operations for two reasons. First is to mitigate a usability issue,
namely that users might be confused as to which fingers should be presented. Second, there is always the possibility
that fingerprints are stolen from other sources (including latent acquisition) and used in a spoof attack.
1. The 0x0005 value indicates one of two definitions for reporting locations of minutiae defined in the ISO standard.
This one requires that the endings of ridges be reported at the point of the valley bifurcation (versus at the ridge tip
itself). These are the semantics required by INCITS 378:2004. The on-card comparison templates might reasonably be
produced from the parent INCITS 378 templates.
2. Which fingers are present is encoded using integers from Table 8. The finger position codes differ in the
fingerprint vs. smart-card standards. For on-card comparison data, ISO/IEC 19785-3:2007 finger position codes shall be
used (column B). For the PIV mandatory off-card comparison templates, [MINUSTD] finger positions shall be used
(column A). Card issuance processes shall transcode using the mapping of Table 8.
PIV readers involved in on-card and off-card authentication attempts shall heed Table 8 to correctly prompt users for
which finger to present.
Note that the penultimate (i.e., FDIS) draft of ISO/IEC 19785-3:2007 erroneously set bit six to 1. The final standard and
the PIV specification require that bits 6, 7 and 8 shall be 0.
Particularly the ISO/IEC 19794-2:2005 standard includes three encodings (record, card-normal, card-compact), has versions with
and without headers, has variants differing in their minutia placement semantics, has presence of standardized extended data
(zonal quality etc.) and of non-standard, proprietary, extended data.
5.6 Preparation of the minutia templates
5.6.1 Conversion of INCITS 378 to ISO/IEC 19794-2 on-card comparison templates
Existing PIV equipment produces (CBEFF-wrapped) [MINUSTD] instances of Table 6 for off-card comparison. An OCC
process may choose to use such equipment in which case [CARD-MIN] data would appropriately be prepared from
live [MINUSTD] templates via the non-trivial conversion of Figure 4. The conversion operation proceeds with a
pruning operation (Sec. 18.104.22.168 and 126.96.36.199), a re-encoding (conversion of 8 bit to 6 bit minutia angle, conversion from
14 bit to 8 bit position coordinates), and a sorting operation (Sec. 22.214.171.124). The order matters here due to arithmetic
Vendor X Remove excess minutiae by
Input Image 378:2004
generator Quality and Position
Vendor Y
Vendor supplied component PC based library
In the case K < N, the client should initially recapture fingerprints (by re-prompting the user to replace finger on the
sensor) and it that is unsuccessful should terminate the authentication.
yield minutiae outside the maximum possible spatial extent that can be encoded here (8 bit integers at 100 pixels cm-1
on card). The pruning mechanism of Sections 126.96.36.199 and 188.8.131.52 shall be used to remove such minutiae.
5.7.2 Background
NIST conducted tests of on-card comparison performance [MINEX-II]. Over four phases conducted between 2007 and
2010, the tests showed that four implementations would have attained the cross-provider interoperability
specifications of Section 4.5.2.
In parallel, NIST's Secure Biometrics Match-on-Card program demonstrated cryptographic protection of the template
data, and transactional durations below two seconds [SBMOC].
This requirement implies non-operational requirements, namely that a prototype card shall be submitted for testing and this
must allow multiple template comparisons without locking and must report similarity scores to a dedicated test laboratory
INFORMATIVE NOTE NIST's MINEX IV program implements this test [MINEX-IV] see Annex A.6.
184.108.40.206 Specification
To support operational authentication of PIV Card templates against live samples, a template generator and matcher-
pair shall be certified if
1. it meets all the interoperability criteria of sections 188.8.131.52 and 18.104.22.168, and
2. it matches single-finger native templates with FNMR less than or equal to 0.02 when the FMR is at or below
0.0001. The word native here means that all templates originate from one template generator and the provider
of the template generation algorithm is the same as that of the comparison algorithm. Native mode operation
will occur within an Agency that procures its template generation and matching equipment from the same
The MINEX IV program replaces the original MINEX II proof-of-concept evaluation which ran 2007-2011.
6. Iris recognition specifications
6.1 Scope
This Section standardizes specifications for use of iris images as allowed by [FIPS]. The Section includes specifications
for iris images stored on and off PIV Cards,
for iris capture devices, and
for components involved in automated recognition of PIV iris imagery.
The specifications extend the format requirements of ISO/IEC 19794-6:2011 with image quality related properties. The
capture device specifications concern imaging properties of the iris camera, and software interfaces around it. The
recognition component is specified in terms of minimum authentication accuracy and processing speed.
This document makes no mention of an iris template. In iris recognition, templates are proprietary non-standardized
mathematical encodings of information extracted from the formally standardized images that are defined in this
document. Templates are not interoperable. Interoperability is achieved with standardized images. Agencies electing
to retain only templates are vulnerable to supplier lock-in, and an inability to benefit from technology updates.
6.2 Background
Iris recognition affords highly accurate recognition of individuals. It has been used both for 1:1 verification and 1:N
identification [UKIRIS, IREX-III] and has proven stable [NEXUS, IREX-VI] for over a decade. Moreover, iris images can
be compressed to achieve small sizes [IREX-I, IREX-IV] affording rapid transmission across band-limited networks and
storage on identity credentials. This aspect is leveraged below.
Digital representations of rectilinear images of the human iris have been formally standardized as ISO/IEC 19794-6:2011
[IRISSTD]. This standard, which replaces earlier editions, is a necessary component in an interoperable marketplace
of iris cameras and iris recognition algorithms. The standard is used because it includes specialized image formats
that support compact storage on ISO/IEC 7816 Integrated Circuit cards. The PIV formats are shown in Figure 5.
Label A B
Some (commercial) template representations are actually larger than the specialized ISO/IEC 19794-6:2011 Image Type 7 PIV Card
images specified in this document.
First generation iris image standards included a polar-coordinate encoding. This supported compact sizes but was removed from
second generation standards because interoperability is sensitive to correct determination of the iris and pupil centers. A
replacement format (Figure 5B) has been shown to offer accurate recognition [IREX-IV] and broad industry support [IREX-I]. It
requires localization of the boundaries and the iris center. These tasks are non-trivial and are supported by quantitative tests.
6.3 Iris image specification for PIV Cards
6.3.1 General case
Iris images on PIV Cards shall conform to the requirements expressed in the Table 9 profile of the ISO/IEC 19794-6:2011
standard. Where required values and practice are not stated, the underlying requirements of the base standard shall
apply. The profile defines a standard record that contains one or two specialized iris images each of size around 3
kilobytes. These images shall follow the semantic requirements of Image Type 7 images defined in the standard. The
objective of these specifications is to afford maximum possible iris accuracy, low storage requirements, and
corresponding fast read times. These requirements include centering and masking of the eyelid and sclera regions (an
example is shown in Figure 5, column B). The masked regions can be very efficiently compressed. This affords small
record sizes and, vitally, preservation of the iris texture.
Table 9 ISO/IEC 19794-6 profile for iris images stored on PIV Cards
Clause or field of ISO/IEC ISO/IEC 19794-6
PIV Conformance Remarks
Field Value Values Allowed
1. CBEFF Header MF MV Patron format PIV Multi-field CBEFF Header. Sec. 9.2.
2. Format identifier MF MV 0x49495200 IIR\0 Four byte format identifier including null terminator.
3. Version number MF MV 0x30323000 020\0 Second 19794-6 version - not the 2005 standard
Iris General Header
4. Length of record MF MV See NOTE 1 The length (in bytes) of the entire iris image data.
5. Number of iris MF MV 1 or 2 Number of iris representations that follow. This value would
representations ordinarily be 1. See NOTE 4.
6. Certification flag MF MV 0x00
7. Number of eyes MF MV 1 or 2 2 if left and right are known present, else
represented 1 if left or right is known present.
If camera does not estimate eye label automatically, these
shall be manually assigned.
Representation 1: Data for the first eye image follows
8. Representation Length MF MV Bytes for this representation including the header + image
9. Capture date and time MF MV 2011 onwards. Capture start time in UTC
10. Capture device MF MV
technology identifier
11. Capture device vendor ID MF MV Manufacturer ID
12. Capture device type ID MF MV Vendor assigned make model product ID.
13. Quality block MF OIT
14. Representation number MF MIT 1 and then, optionally, 2 Representation sequence number
15. Eye label MF MIT 1 or 2 Left, right. If camera does not estimate eye label
automatically, these shall be manually assigned.
16. Image type MF MV 7 IMAGE_TYPE_CROPPED_AND_MASKED = 7 (07Hex) i.e., a
cropped and region-of-interest masked, centered, iris image
Representation Header + Image Data
and 6KB if two irises are by container defined in NIST Special Pub 800-73, and the size
stored. of its CBEFF header and digital signature.
Representation 2: Data for the second eye image follows
Analogous to Representation 1, above.
32. CBEFF Signature Block MF MV See Section 9.3 of this document
Acronym Meaning
MF mandatory field [IRISSTD] requires a field shall be present in the IIR
MV mandatory value [IRISSTD] requires a meaningful value for a field
OV optional value [IRISSTD] allows a meaningful value or allows 0 to be used to connote "unspecified"
mandatory at time of For PIV, mandatory value that shall be determined at the time the record is instantiated and shall
instantiation follow the practice specified in [IRISSTD]
OIT optional at time of instantiation For PIV, optional header value that may be determined at the time the record is instantiated
1. The entire record length plus the CBEFF header and CBEFF signature block length must be less than or equal to size
specified in NIST Special Publication 800-73-4. A single image of size 3K, or two images of each of size 3K, will fit in
this container. These sizes refer to the JPEG 2000 compressed iris image. JPEG 2000 implementations shall be
executed with a bit rate input value that corresponds to a 3Kilobyte target result. Higher bit rates and higher sizes are
2. The specification of a Type 7 image requires that the image captured from the camera has sufficient margin around
the iris to support the strict (0.6R, 0.2R) margin requirements of Image Type 7. During enrollment, client capture
software might usefully display the result with a prototypical overlay.
3. If any captured iris has diameter outside of the range [160,280] pixels, see Section 184.108.40.206.
4. The record should include a single iris. This recommendation exists because one iris can easily satisfy 1:1
comparison accuracy objectives [IREX-III] and, moreover, a single eye will be read faster and its digital signature can
be accessed and verified faster. Two eyes will be useful if one of the images is somehow of poor quality, or if one eye
is somehow occasionally unavailable for authentication. Quality control of the PIV Card imagery is imperative.
Table 10 ISO/IEC 19794-6 profile for a null iris image stored on PIV Cards
Clause or field of ISO/IEC ISO/IEC 19794-6
PIV Conformance Remarks
Field Value Values Allowed
1. CBEFF Header MF MV Patron format PIV Multi-field CBEFF Header. Sec. 9.2.
2. Format identifier MF MV 0x49495200 IIR\0 Four byte format identifier including null terminator.
Iris General Header
3. Version number MF MV 0x30323000 020\0 Second 19794-6 version - not the 2005 standard
4. Length of record MF MV See NOTE 1 The length (in bytes) of the entire iris image data.
5. Number of iris MF MV 1 Number of iris representations that follow.
6. Certification flag MF MV 0x00
7. Number of eyes MF MV 0 0 indicates laterality is unknown
Representation 1: Data for the only eye image follows
8. Representation Length MF MV Bytes for this representation including the header + image
9. Capture date and time MF MV 2011 onwards. Capture start time in UTC
10. Capture device MF MV
technology identifier
11. Capture device vendor ID MF MV Manufacturer ID
12. Capture device type ID MF MV Vendor assigned make model product ID.
13. Quality block MF MV 0 Zero indicates no quality blocks follow
14. Representation number MF MIT 1 Representation sequence number
15. Eye label MF MIT 0 Undefined which eye
16. Image type MF MV 7 IMAGE_TYPE_CROPPED_AND_MASKED = 7 (07Hex) i.e., a
cropped and region-of-interest masked, centered, iris image
with (0,6R 0,2R) margins. See NOTE 2
17. Image format MF MV 2 = 0x2 Encoding shall be RAW
18. Iris image properties bit MF MV 01010101 Bit field values.
19. Image width, W MF MIT 1 Dimensions ranges, in pixels, are implied by the exact
20. Image height, H MF MIT 1 [IRISSTD] margin requirements based on iris size.
21. Bit depth MF MV 8 Bit depth in bits per pixel. This shall not be used to indicate
compression level
22. Range MF OIT 0 Required field; optionally populated.
23. Roll angle of eye MF OIT 0 Camera or software should estimate roll angle. Rotation
24. Roll angle uncertainty MF OIT 0 should only be applied if angle is > 20 deg.
25. Iris centre, lowest X MF MV 0 These values are redundant for Image type = 7 for which
26. iris centre, highest X MF MV image shall be exactly centered. The iris center shall be
27. Iris centre, lowest Y MF MV 0 estimated by the iris localization code, or if necessary by a
28. Iris centre, highest Y MF MV human inspector.
29. Iris diameter, lowest MF MIT 0 These two fields are used to express a normative PIV
30. Iris diameter, highest MF MIT 0 requirement on iris size. See NOTE 3
31. Image length MF 1 1 byte
32. CBEFF Signature Block MF MV See Section 9.3 of this document
6.4 Iris image specification for iris images retained outside the PIV Card
This document neither requires nor precludes agencies from retaining iris images. [FIPS] recommends use of iris
imagery (and face in limited cases) in cases where fingerprints cannot be captured satisfactorily. In addition, [FIPS]
allows iris whenever fingerprints are used, and indicates that iris image data may be available outside the PIV Card for
authentication during PIV Card issuance, re-issuance, and verification data reset transactions. If agencies elect to
retain images, they shall be stored in the format specified in this clause. This clause establishes a profile of ISO/IEC
19794-6:2011 suited for retention of iris images outside the PIV Card. The format specification includes the [CBEFF]
header of Section 9, and this requires integrity protection and allows for encryption of the image records.
Retention of data supports, for example, detection of duplicate identities.
Table 11 ISO/IEC 19794-6 profile for iris images stored outside PIV Cards
Clause or field of ISO/IEC ISO/IEC 19794-6
PIV Conformance Remarks
Field Value Values Allowed
1. CBEFF Header (5.3) MF MV Patron format PIV Multi-field CBEFF Header. Sec. 8.
2. Format identifier MF MV 0x49495200 IIR\0 Four byte format identifier including null terminator.
3. Version number MF MV 0x30323000 020\0 Second 19794-6 version - not the 2005 standard
Iris General Header
4. Length of record MF MV The length (in bytes) of the entire iris image data.
5. Number of iris MF MV 1 or 2 Number of iris representations that follow. One iris is ample
representations for verification tasks.
6. Certification flag MF MV 0x00 Is certification information present in the representation
7. Number of eyes MF MV 1 or 2 2 if left and right are known present, else 1 if left or right is
represented known present.
Representation 1: Data for the first eye image follows
8. Representation Length MF MV Bytes for this representation including the header + image
Representation Header + Image
9. Capture date and time MF MV 2011 onwards. Capture start time in UTC
10. Capture device MF MV 0x00 Unknown or Unspecified
technology identifier 0x01 CMOS/CCD
11. Capture device vendor ID MF MV Manufacturer ID
12. Capture device type ID MF MV Vendor assigned make model product ID.
13. Quality block MF OIT
14. Representation number MF MIT 1 and then 2 Representation sequence number
15. Eye label MF MIT 1 or 2 Left, right. If camera does not estimate eye label automatically,
these shall be manually assigned.
16. Image type MF MV 2 IMAGE_TYPE_VGA = 0x02 i.e., 640 x 480 pixels. See [IRISSTD]
17. Image format MF MV 14 = 0x0E Compression and encoding shall be PNG or RAW.
2 = 0x02
18. Iris image properties bit MF MIT Bits 1-2: 01 or 10 Horizontal + vertical orientation shall not be undefined
field MIT Bits 3-4: 01 or 10
MV Bits 5-6: 01 Scan type shall be progressive.
MV Bits 7-8: 01 Compression history shall be none
Bit 1 is the least signif. bit.
Bit 8 is the most signif. bit.
19. Image width, W MF MIT 640 width in pixels, W
20. Image height, H MF MIT 480 height in pixels, H
21. Bit depth MF MV 8 Bit depth in bits per pixel. This shall not be used to indicate
compression level
22. Range MF OIT Required field; optionally populated.
23. Roll angle of eye MF OIT 20 Camera or software should estimate roll angle. Rotation
24. Roll angle uncertainty MF OIT 5 should only be applied if angle is > 20 deg.
25. Iris centre, lowest X MF MIT Iris need not be centered for Image type 2 but iris centre must
26. iris centre, highest X MF MIT be in a range such that margin requirements of [IRISSTD] are
27. Iris centre, lowest Y MF MIT met.
28. Iris centre, highest Y MF MIT
29. Iris diameter, lowest MF MIT 160 These two fields are used to express a normative PIV
30. Iris diameter, highest MF MIT 280 requirement that iris diameter shall be no smaller than 160
pixels, and no larger than 280 pixels. See NOTE 1
31. Image length MF MIT Size of the PNG encoded image data, in bytes, is unlimited
Representation 2: Data for the second eye image follows
Analogous to Representation 1, above.
32. CBEFF Signature Block MF MV See Section 9.3 of this document
1. If any captured iris has diameter outside of the range [160,280] pixels, see Section 22.214.171.124.
6.7.1 Properties of iris cameras
18.104.22.168 Scope
The following sub-sections support interoperable recognition by specifying iris camera and iris image properties.
Additionally, when selecting iris cameras, Agencies should consult informative Annex B.
188.8.131.52 Format
The camera shall produce, possibly in conjunction with client-side software, conformant Table 11 [IRISSTD, Image Type
2] instances (suitable for use in an authentication transaction).
These are 640x480 images conforming to Image Type 2 of [IRISSTD].
This specification applies to a commercial-off-the-shelf PC procured in 2010 and equipped with a 2GHz processor and 8GB of main memory. This
specification shall be adjusted by the testing organization to reflect significant changes of the computational platform.
6.7.3 Specifications for iris image matchers
A recognition algorithm is certified on the basis of its speed of computation, and on the error rates observed when it
matches single-eye records. Specifically, a recognition algorithm shall be certified if the following hold.
The median time taken to execute comparisons of genuine template pairs is below 0.05 seconds.
It matches both compressed Table 9 and Table 11 [IRISSTD] records from all certified record generators with
FNMR less than or equal to 0.01 at a FMR no larger than 0.0001.
7. Facial image specifications
7.1 Scope
[FIPS] establishes requirements and options for agency-collection, storage, and use of a facial image from PIV
applicants. The facial imagery shall be stored in the format specified here. The face specification has a very similar
format, and is functionally identical to, the ISO/IEC 19794-5:2005 face image adopted by the International Civil Aviation
Organization for e-Passports [ICAO]. However, note that two images are involved in one-to-one applications:
The enrollment image i.e., the PIV image as specified here.
The live authentication image for which additional capture specifications are typically necessary to address
subject height variations and the illumination environment (see [BSI-FACE], for example).
The image is suitable for automated face recognition and therefore fielded implementations shall conform to the
accuracy specifications given in this Section.
Clause title and/or field name INCITS 385-2004
(Numbers in parentheses are Informative Remarks
Field or Value
[FACESTD] clause numbers) Values Allowed
content Required
22. image-specific info. Width (5.7.3) MF MV MIT
See Note 7.
23. Height (5.7.4) MF MV MIT
24. Image Color Space (5.7.5) MF MV 1 sRGB. See Note 8.
25. Source Type (5.7.6) MF MV 2 or 6 Digital still or digital video
Device Type
(vendor supplied device ID) (5.7.7)
[FACESTD] requires 0 (unspecified) but
27. Quality (5.7.8) MF 0-100 A
allowed here.
28. Image Data Data Structure (5.8.1) MF MV MIT Compressed Data
29. Inheritance (6.1) NC A
Basic (Clause 6)
30. Image Data Encoding (6.2) NC A See Note 5
31. Image Data Compression (6.3) NC A See Notes 5+6
32. Facial Header (6.4.1) NC A Include 4 fields
33. Format Facial Information (6.4.2) NC A Include 9 fields
34. Image Information (6.4.3) NC A Include 8 fields
35. Inheritance Inheritance (7.1) NC A Inherits Basic
36. Purpose (7.2.1) NC A frontal Annex A
37. Pose (7.2.2) NC Frontal +/- 5 degrees
38. Expression (7.2.3) NC Neutral
39. Assistance in positioning face (7.2.4) NC A Only the subject appears
40. Shoulders (7.2.5) NC A Body + Face toward camera
41. Backgrounds (7.2.6) NC Annex A.4.3 Uniform
42. Subject and scene lighting (7.2.7) NC A Uniform
43. Shadows over the face (7.2.8) NC A None
44. Eye socket shadows (7.2.9) NC A None
45. Hot spots (7.2.10) NC A Should be absent. Diffuse light.
Frontal (Clause 7)
Acronym Meaning
FAC Face Information Record Facial header + facial info + repetition of (image info + image data)
MF mandatory field [FACESTD] requires a field shall be present in the FAC
OF optional field [FACESTD] allows a field to be present in record
MV mandatory value [FACESTD] requires a meaningful value for a field
OV optional value [FACESTD] allows a meaningful value or allows 0 to be used to connote "unspecified"
NC normative content [FACESTD] gives normative practice for PIV. Such clauses do not define a field in the FAC.
A as required For PIV, value or practice is as specified in [FACESTD]
mandatory at time of For PIV, mandatory value that shall be determined at the time the record is instantiated and shall
instantiation follow the practice specified in [FACESTD]
OIT optional at time of instantiation For PIV, optional header value that may be determined at the time the record is instantiated
1. The length of the entire record shall fit within the container size limits specified in [800-73]. These limits apply to
the entire CBEFF-wrapped and signed entity, not just the [FACESTD] record. Key lengths and signing algorithms
are specified in [800-78]. The size of the digital signature scales with the key length; it does not scale with the
size of the biometric record.
2. More than one image may be stored in the record. It may be appropriate to store several images if appearance
changes over time (beard, no beard, beard) and images are gathered at re-issuance. The most recent image shall
appear first and serve as the default provided to applications. PIV Card capacity, however, will limit the number
of images that can be stored (usually to one).
3. The recommendation is that only one image should be stored on the PIV Card.
4. PIV facial images shall conform to the Full Frontal Image Type defined in Clause 8 of [FACESTD].
5. Facial image data shall be formatted in either of the compression formats enumerated in Clause 6.2 of [FACESTD].
Both whole-image and single-region-of-interest (ROI) compression are permitted. This document ([800-76])
recommends that newly collected facial image should be compressed using ISO/IEC 15444 (i.e., JPEG 2000). This
applies when images will be input to automated face recognition products for authentication, and when images
are stored on PIV Cards. In this latter case, ROI compression should be used. The older ISO/IEC 10918 standard
(i.e., JPEG) should be used only for legacy images.
6. Facial images shall be compressed using a compression ratio no higher than 15:1. However, when facial images
are stored on PIV Cards JPEG 2000 should be used with ROI compression. The innermost region should be
centered on the face and compressed at no more than 24:1.
7. Face recognition performance is a function of the spatial resolution of the image. [FACESTD] does not specify a
minimum resolution for the Full Frontal Image Type. For PIV, faces shall be acquired such that a 20 centimeter
target placed on, and normal to, a camera's optical axis at a range of 1.5 meters shall be imaged with at least 240
pixels across it. This ensures that the width of the head (i.e., dimension CC in Figure 8 of [FACESTD]) shall have
sufficient resolution for the printed face element of the PIV Card. This specification and Clause 8.3.4 of
[FACESTD] implies that the image width shall exceed 420 pixels. This resolution specification shall be attained
optically without digital interpolation. The distance from the camera to the subject should be greater than or
equal to 1.5 meters (for distortion reasons discussed in [FACESTD, Annex A.8]). While the size specification is a
minimum, larger sizes might be used but this would require greater compression to achieve the size mandated by
8. Facial image data shall be converted to the sRGB color space. As stated in Clause 126.96.36.199 of [FACESTD] this
requires application of the color profile associated with the camera in use.
8. Biometric sensor interface specifications
8.1 Scope
This Section guides implementers of biometric enrollment and authentication applications that use biometric sensors.
9. Common header for PIV biometric data
9.1 Scope
All PIV biometric data shall be embedded in a data structure conforming to Common Biometric Exchange Formats
Framework [CBEFF]. This specifies that all biometric data shall be digitally signed and uniformly encapsulated. This
covers the following static data:
The PIV Card fingerprints mandated by [FIPS];
The PIV Card facial image mandated by [FIPS];
Any other biometric data that agencies elect to place on PIV Cards (e.g.,iris);
Any biometric records that agencies elect to retain (including purely proprietary, or derivative, elements);
Any biometric data retained by, or for, agencies or Registration Authorities.
There are three pieces of data that are exempt:
The [EBTS] data of Section 3.4 sent for background checks ;
The OCC data of Section 5.4 that is stored on the PIV Card ;
For the relevant data above, integrity shall be protected by pre-pending the data with a CBEFF header and appending
with a signature stored in the CBEFF signature block as depicted in the linear structure of Table 13.
The ANSI/NIST standard [AN2011] now provides for integrity protection with its own Type 98 record. This may be useful for
maintenance of PIV data. See http://biometrics.nist.gov/cs_links/standard/Type_98_Best_Practice_Guidance_v1.3.pdf.
For OCC, various pieces of CBEFF information are placed in the Biometric Information Template of Table 7 as standardized in
[CARD-BIO Annex C.2].
11. Biometric Data Quality (188.8.131.52) 1 SINT [-2,100]. A value of -2 shall denote that assignment was not supported by the
implementation; A value of -1 shall indicate that an attempt to compute a
quality value failed. Values from 0 to 100 shall indicate an increased
expectation that the sample will ultimately lead to a successful match.
12. Creator (220.127.116.11) 18 Note 6 See Note 6 for data type
13. FASC-N 25 Note 7 See Note 7 for data type
14. Reserved for future use 4 0x00000000
Some of the CBEFF Header fields in Table 14 take modality-specific values as detailed in Table 15.
When multiple samples (e.g., two single finger minutiae views) are included in one record (e.g., an INCITS 378
record) and the Creation Dates are different, the Creation Date shall be the earliest of the multiple views.
5. The Validity Period contains two dates each of which shall be coded according to Normative Note 4.
a. The validity period should start at the time when the biometric data is available for use (e.g., according to
policy or issuance considerations). It shall be no earlier than the Creation Date. Biometric applications (e.g.,
authentication) should respect this date.
b. [FIPS 201-2] limits the lifetime for biometric data. For facial images, agencies might reduce those limits to
eight years (Creation Date to closing date), but this might vary with technical or policy factors at agency
discretion. Biometric ageing is considered to be a slow continuous process. This field therefore serves as an
advisory that biometric data should be re-collected from the Cardholder at the next opportunity. This date is
not intended to invalidate any function of the card (see [FIPS] for that).
6. For PIV the Creator field has length 18 bytes of which the first K 17 bytes shall be printable ASCII characters, and
the first of the remaining 18-K shall be a null terminator (zero).
7. This field shall contain the 25 bytes of the FASC-N component of the CHUID identifier, per [800-73, 1.8.{3,4}]. The
FASC-N field may be filled with zeroes in the one exceptional case where PIV registration images are being stored
before a FASC-N has been assigned. In such instances, the digital signature shall be regenerated once the FASC-N
is known.
8. Iris quality may be set to [-2,100]. Note that formal standardization of iris image properties and quality metrics are
pending in the ISO/IEC 29794-6 standard [IRISQUAL] with publications expected in late 2013 or early 2014. The
value -2 indicates a failure to compute, and -1 indicates no attempt to compute quality.
The eight year duration comes from a study of the effect of face ageing on recognition accuracy [FACEPERF]. Because face-
based manual verification is common, this duration is adopted as a default. Iris seems to have longer-term stability [IREX-VI].
There are no published studies of long term fingerprint stability.
Use the issuerAndSerialNumber choice for SignerIdentifier
Specify a digestAlgorithm in accordance with [800-78]
Include, at a minimum, the following signed attributes:
A MessageDigest attribute containing the hash of the concatenated CBEFF_HEADER + Biometric
A pivFASC-N attribute containing the FASC-N of the PIV Card (to link the biometric data and PIV
An entryUUID attribute [RFC4530] containing the 16-byte representation of the UUID value that
appears in the GUID data element of the PIV Card's CHUID data element.
A pivSigner-DN attribute containing the subject name that appears in the PKI certificate for the
entity that signed the biometric data
Include the digital signature.
10. Minimum accuracy specifications
10.1 Scope
This Section establishes specifications for configuration of deployed biometric verification algorithms. In previous
sections , this document includes performance specifications for qualification of components that influence
recognition outcomes. This Section establishes minimum accuracy specifications and performance parameters for
components configured and used in operational PIV biometric authentication subsystems.
NOTE [FIPS] establishes options and requirements for all PIV functions including authentication. It allows only
certain modalities to be used in PIV contexts.
10.2 Approach
FIPS 140-2 establishes minimum requirements for authentication for activation of cryptographic-modules. This
Section defines analogous specifications for biometric person authentication. The specifications implement the
primary security objective of using biometrics as an authentication factor.
The approach is to require recognition algorithm operating thresholds to be set to achieve false match rates (FMR) no
higher than those advanced here. These false match rates apply to zero-effort authentication, i.e., the one-to-one
comparison of sample pairs from randomly selected different persons . The false match criteria implement the core
biometric security objectives. These are the primary interest of a security policy.
While any false match criterion can always be met by setting a stringent comparison threshold, the adoption of
stringent thresholds will imply elevated false rejection rates (FNMR or FRR) because of the error-rate tradeoff . High
false rejection rates will inconvenience legitimate users, and it is therefore imperative that biometric systems offering
sufficient performance are used see Section 10.5.
NOTE 1 Transactional false accept rates will be higher than these values if the transaction allows
presentation of more than one sample (e.g., a second finger) or biometrics (e.g., iris and face).
Those clauses, 4.5.3 and 4.5.4 for off-card fingerprint comparison, and 18.104.22.168 and 5.7.4 for on card comparison, qualify
components requiring core minutiae-based interoperable accuracy. They do this in laboratory tests. The accuracy criteria were
never intended to be adopted as operational verification criteria particularly the FMR = 0.01 threshold was instituted to bar non-
interoperable minutia detection algorithms and matchers but is not appropriate as an Agency security policy.
This represents the case where a lost card is found by someone who casually attempts a biometric authentication.
For fingerprints and face, industry convention is for recognition algorithms to produce similarity scores, for which higher
thresholds produce fewer false matches. For iris, the convention is to produce distance or dissimilarity scores, for which lower
thresholds produce fewer false matches.
As required by ISO/IEC 19795 biometric testing standards, test reports almost universally show this tradeoff using detection-error
tradeoff characteristics (DETs) or almost equivalently receiver operating characteristics (ROCs).
Threshold calibration information is available under NIST's MINEX and IREX programs.
NOTE 2 The iris false match rate is considerably lower because iris is readily capable of achieving this lower
more secure value without appreciable increases in false non-match rates [IREX-III]
The test measurements are typically obtained by running algorithms on commodity PC hardware.
Thereafter, the algorithm provider or integrator shall provide documented attestation that:
All components of the recognition software (including template generation and comparison algorithms) are
functionally identical to those submitted to the recognized test and calibration program. The use of recognition
algorithms on other platforms, such as wall mounted embedded processors, is allowed. The algorithm provider
shall submit the same software to the test program wherever it is ultimately installed.
All instances of the fielded comparison algorithms are configured with an operating decision threshold that is at
least as strong as that established in FMR vs. threshold calibration.
Agencies might require inspection of source code and institute appropriate controls to ensure that the source code is
indeed that installed in deployed equipment.
Additionally, Agencies could elect to conduct a biometric performance test to confirm the hypothesis that the FMR is
conformant to the specification of Section 10.3.
A transaction might include several comparisons from repeated presentations of multiple fingers or irises.
of users with the process. The use of two fingers or irises in all authentication transactions offers substantially
improved performance over single-instance authentication.
This document does not establish false rejection performance criteria how often genuine users are unable to
successfully authenticate because it does not represent a direct security objective. Agencies are cautioned that
false rejection performance is operationally vital in access control applications and is achieved by using high
performance cameras and algorithms, by ensuring good quality enrollment, by correct control of the environment, by
adherence to enrollment specifications, by subject and operator instruction, and by subject habituation. Agencies are
therefore strongly encouraged to consider:
Establishing a policy on how many times a subject can attempt to authenticate;
Establishing false rejection accuracy criteria against which tests and qualification procedures can be conducted;
Referring to false rejection performance measures reported for algorithms evaluated using the IREX test and
calibration procedure;
Referring to false rejection performance measures reported for algorithms conforming to the MINEX test and
calibration procedure;
Training staff to recognize poor quality images at time of enrollment;
Requiring the use of multiple samples (e.g., two fingers);
Conditions under which an alternative modality for authentication (e.g., iris instead of fingerprint) might be used;
Conditions under which an additional modality for authentication (e.g., iris and fingerprint) might be used;
Conducting their own supplementary tests. These might be performance tests of single products or
interoperability tests, and might be used to estimate application-specific performance. The execution of tests
conforming to one or more parts of the ISO/IEC 19795 standard is strongly recommended because biometric
testing is a specialized discipline. Particularly a number of subtleties and difficulties exist that can potentially
fatally undermine a test.
This specification does not:
Preclude agencies from establishing more stringent false match criteria. The false match criteria can always be
met by setting a high (i.e., stringent) comparison threshold. However, more stringent thresholds imply elevated
false rejection errors because of the error-rate tradeoff. One mitigation is to use two fingers or two eyes.
11. Conformance to this specification
11.1 Conformance
Conformance to this specification will be achieved if an implementation and its associated data records conform to
normative ("shall") Sections 3 through 10 but not Section 8. The following text summarizes these statements.
12. References
Citation Document
800-73 NIST Special Publication 800-73-4, Interfaces for Personal Identity Verification. There are currently three parts:
Pt. 1- PIV Card Application Namespace, Data Model & Representation
Pt. 2- PIV Card Application Card Command Interface
Pt. 3- PIV Client Application Programming Interface
800-78 NIST Special Publication 800-78-4, Cryptographic Algorithms and Key Sizes for Personal Identity Verification
800-85 NIST Special Publication 800-85 A-2, PIV Card Application and Middleware Interface Test Guidelines (SP800-73-3
Compliance), July 2010
NIST Special Publication 800-85 B, PIV Data Model Test Guidelines, Jul 2006
AN2011 ANSI/NIST-ITL 1-2011 Data Format for the Interchange of Fingerprint, Facial & Other Biometric Information,
NIST Special Publication 500-290, 2011. This supersedes SP 500-245.
APP/F See EBTS entry below.
BAZIN A. Bazin and T. Mansfield. An investigation of minutiae interoperability. In Proc. Fifth IEEE Workshop on
Automated Identification Advanced Technologies, June 2007. AUTO-ID 2007, Alghero Italy.
BIAS Biometric Identity Assurance Services (BIAS) SOAP Profile, Version 1.0, OASIS Standard, 24 May 2012,
NOTE: This normatively cites the INCITS 442:2010 standard for higher level requirements and architecture,
biometric operations, and data element for biometrics. INCITS 442 will be succeeded by ISO/IEC 30108 now
under development.
A reference implementation is available here: http://nist.gov/itl/iad/ig/upload/BIAS_20110608.zip
BIOAPI ISO/IEC 19784-1:2006[2007] BioAPI Biometric Application Programming Interface Part 1: BioAPI Specification
BIOAPI-ARCH ISO/IEC 19784-2:2007[2008] Biometric Application Programming Interface (BioAPI) Part 2: Biometric Archive
Function Provider Interface http://webstore.ansi.org/
BIOAPI-GUI ISO/IEC 19784- 1:2006/AM1 -2007 [2008 ], Information technology - BioAPI - Biometric Application Programming
Interface - Part 1: BioAPI Specification - Amendment 1: BioGUI specification
BIOAPI-FF ISO/IEC 19784-1, Amd. 2 19784-1:2006, Amd. 2:2009 [2009] - - Information technology - Biometric application
programming interface Part 1: BioAPI specification Amendment 2: Framework-free BioAPI
BIOAPI-SEC ISO/IEC 19784-1, Amd. 3 19784-1:2006, Amd. 3:2010 - Information technology -Biometric application
programming interface Part 1: BioAPI specification Amendment 3: Support for interchange of certificates
and security assertions, and other security aspects http://webstore.ansi.org/
BIOAPI-SENS BIOAPI-SFPI: ISO/IEC 19784-4:2011 Biometric Application Programming Interface (BioAPI) Part 4: Biometric
Sensor Function Provider Interface http://webstore.ansi.org/
BIOAPI-US ANSI INCITS 358-2002 (R2007) Information technology - BioAPI Specification (Version 1.1) and its amendment
ANSI INCITS 358-2002/AM1-2007 - Amendment 1: Support for Biometric Fusion.
BIOCTS F. Podio, D. Yaga, and C. J. McGinnis, NIST/ITL CSD Conformance Test Architectures (CTA) and Test Suites (CTS)
for Biometric Data Interchange Formats http://www.nist.gov/itl/csd/biometrics/biocta_download.cfm
BSI-FACE Markus Nuppeney, Marco Breitenstein and Matthias Niesing, EasyPASS - Evaluation of face recognition
performance in an operational automated border control system. BSI and Secunet, DE.
This presentation is accompanied by a supporting paper.
CARD-BIO ISO/IEC 7816-11:2004 Identification cards -- Integrated circuit cards -- Part 11: Personal verification through
Citation Document
biometric methods http://webstore.iec.ch/preview/info_isoiec7816-11%7Bed1.0%7Den.pdf
CARD-CMD ISO/IEC 7816-4:2005 Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands
for interchange http://webstore.iec.ch/preview/info_isoiec7816-4%7Bed2.0%7Den.pdf
CARD-MIN ISO/IEC 19794-2:2011 Information technology -- Biometric data interchange formats -- Part 2: Finger minutiae data.
This standard is not INCITS 378 nor ISO/IEC 19794-2:2005.
CBEFF INCITS 398-2005, American National Standard for Information Technology - Common Biometric Exchange
Formats Framework (CBEFF) http://webstore.ansi.org
EBTS AFIS-DOC-01078-9.1 CJIS-RS-0010 (V9.4) Electronic Biometric Transmission Specification, Criminal Justice
Information Services, Federal Bureau of Investigation, Department of Justice, May 25, 2010. Linked from here
Implementers should consult https://www.fbibiospecs.org/ or request the full EBTS documentation from the FBI.
Cited in this document are:
Appendix F - FBI/CJIS IMAGE QUALITY SPECIFICATIONS
Appendix N - DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-14 LOGICAL RECORDS
Appendix C - DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-2 LOGICAL RECORDS
Other USG agencies have their own EBTS variants. These are not relevant to PIV.
FACEPERF P. Grother, G.W. Quinn, and P. J. Phillips. Evaluation of 2D still-image face recognition algorithms. NIST
Interagency Report 7709, National Institute of Standards and Technology, August 2010. http://face.nist.gov/mbe.
Citation Document
Worldwide www.acgih.org (American Conference of Governmental Industrial Hygienists).
ANSI/IESNA RP-27.1-05 Recommended Practice for Photobiological Safety for Lamps and Lamp Systems,
IREX-I P. Grother, E. Tabassi, G. W. Quinn, and W. Salamon. IREX-I: Performance of Iris Recognition Algorithms on
Standard Images. Technical Report NIST Interagency Report 7629, http://iris.nist.gov/irex/, October 2009.
IREX-II E. Tabassi, P. Grother, and W. Salamon. IREX-II: Iris Quality Calibration and Evaluation (IQCE), Performance of Iris
Image Quality Assessment Algorithms, NIST Interagency Report 7820, September 30, 2011
IREX-III P. Grother, G.W. Quinn, J. Matey, M. Ngan, W. Salamon, G. Fiumara, C. Watson, Iris Exchange III, Performance of
Iris Identification Algorithms, NIST Interagency Report 7836, April 9, 2012. http://iris.nist.gov/irex
IREX-IV IREX IV Part 1: Evaluation of Iris Identification Algorithms, George W. Quinn and Patrick Grother, NIST
Interagency Report XXX. July 2013. http://iris.nist.gov/irex
IREX IV Part 2: Compression profiles for iris image recognition, George W. Quinn, Patrick Grother, Mei Ngan, and
Nick Rymer, NIST Interagency Report XXX, August 2013 http://iris.nist.gov/irex
IREX-V IREX V - Best Practices for Iris Image Collection, James Matey, Elham Tabassi, George W. Quinn, Patrick Grother
NIST Interagency Report XXX September 2013 http://iris.nist.gov/irex
IREX-VI IREX VI - Temporal Stability of Iris Recognition Accuracy, NIST Interagency Report XXXX
P. Grother J. R. Matey E. Tabassi G. W. Quinn and M. Chumakov http://iris.nist.gov/irex
IRISSTD ISO/IEC 19794-6:2011 Information technology -- Biometric data interchange formats -- Part 6: Iris image data
This document revises and replaces the 2005 iris standard. Published September 29, 2011.
This standard is being amended, with publication expected 2014. The amendment does two things: It
establishes conformance tests for 19794-6 iris records and, in support of that, clarifies the Image Type 7
appearance requirements. In particular it emphasizes that the sclera shall be masked. The title of the
amendment is: Information Technology Biometric data interchange formats Part 6: Iris image format -
Amendment 1: Conformance testing methodologies.
IRISQUAL ISO/IEC 29794-6:2014 (est. date) Information technology -- Biometric sample quality -- Part 6: Iris image quality
This standard is currently nearing completion, at the Draft IS level.
MANSFIELD T. Mansfield et al. Research report on minutiae interoperability tests. Technical report, Minutiae Template
Interoperability Testing, 2007. http://www.mtitproject.com/DeliverableD62.pdf
MINEX04 P. Grother et al., Minutiae Interoperability Exchange Test, Evaluation Report: NISTIR 7296. The report is archived
here: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=150619
The ongoing assessment of minutiae algorithms is housed here: http://www.nist.gov/itl/iad/ig/ominex.cfm
MINEX II P. Grother, W. Salamon, C. Watson, M. Indovina, and P. Flanagan, MINEX II Performance of Fingerprint Match-on-
Card Algorithms Phase II / III / IV Report NIST Interagency Report 7477 (Revision I+II)
MINUSTD INCITS 378-2004, American National Standard for Information Technology - Finger Minutiae Format for Data
Interchange http://webstore.ansi.org
NFACS IAFIS-DOC-07054-1.0, Criminal Justice Information Services, Federal Bureau of Investigation, Department of
Justice, April 2004.
NEXUS Canada Border Services Agency. Nexus. Expedited border clearance for pre-approved travelers into Canada and
United States. 20032013. http://www.cbsa-asfc.gc.ca/prog/nexus/menu-eng.html.
NFIQ E. Tabassi and C. Wilson - NISTIR 7151 - Fingerprint Image Quality, NIST Interagency Report, August 2004
NFIQ E. Tabassi and P. Grother - NISTIR 7422 Quality Summarization - Recommendations on Biometric Quality
SUMMARY Summarization across the Application Domain
PERFSCEN ISO/IEC 19795-2:2007 Information technology -- Biometric performance testing and reporting -- Part 2: Testing
methodologies for technology and scenario evaluation http://webstore.ansi.org
PERFSWAP ISO/IEC 19795-4:2008 Information Technology -- Biometric Performance Testing and Reporting -- Part 4:
Interoperability Performance Testing http://webstore.ansi.org
REVFACE A. Adler, Sample images can be independently restored from face recognition templates, Proc. Canadian
Citation Document
Conference Electronic and Computer Engineering, 11631166 (2003)
REVFING Jianjiang Feng, A. K. Jain, A.K. Fingerprint Reconstruction: From Minutiae to Phase, IEEE Transactions on Pattern
Analysis and Machine Intelligence, Volume: 33 , Issue: 2, pp. 209 223. Feb. 2011
Annex A. Fingerprint minutiae performance testing and certification procedures
A.1 Scope
This Annex gives normative specifications for tests used to certify implementations that generate and/or match the
mandatory minutia-based biometric elements specified by [FIPS], i.e., the two fingerprint minutiae templates placed
on the PIV Card for either off-card comparison, or on-card. That is, this annex regulates the test itself, and the testing
laboratory, not the products under test, and the data specifications here should not be confused with those given in
Section 2.3 for fielded PIV implementations.
This test design conforms to the provisions of the ISO/IEC 19795-4 [PERFSWAP] standard, as profiled by this
document. One Section of that standard deals with blind testing. For PIV testing the template matcher shall not be
able to discern the source of the enrollment templates.
A.3.1 Template generator
A template generator shall be certified as a software library. For PIV, a template generator is a library function that
shall convert an image into a minutiae record. The input image represents a PIV enrollment plain impression. The
output template represents one of the PIV Card templates. A supplier's implementation, submitted for certification,
shall satisfy the requirements of an application programming interface (API) specification to be published by the test
organizer. The API specification will require the template generator to accept image data and produce [MINUSTD]
templates conformant to Table 18. Where values or practices are not explicitly stated in Table 18, the specifications of
Section 4.3 and Table 6 apply (e.g., on minutiae type). The CBEFF header and CBEFF signature shall not be included.
The testing laboratory shall input images to the generator. The template generator shall produce a conformant
template regardless of the input. Such a template may contain zero minutiae. This provision transparently and
correctly accounts for failures to enroll. In a deployed system, if quality assessment or image analysis algorithms
made some determination that the input was unmatchable a failure to enroll might be declared. In an offline test
such a determination shall result in at least a template containing zero minutiae. However, because in PIV other
suppliers' matchers may be capable of handling even poor templates, it is recommended that a template generator
submitted for testing should deprecate any internal quality acceptance mechanism, and attempt production of a
viable template.
Table 18 INCITS 378 specification for PIV Card template generator and matcher certification
# Clause title and/or field name PIV Conformance Informative Remarks
(Numbers in parentheses are [MINUSTD] Values Allowed
clause numbers)
1. Format Identifier (6.4.1) 0x464D5200 i.e., ASCII "FMR\0"
2. Version Number (6.4.2) 0x20323000 i.e., ASCII " 20\0".
3. Record Length (6.4.3) 26 L 800 26 byte header, max of 128 minutiae. See row 18.
4. CBEFF Product Identifier Owner (6.4.4) 0
5. CBEFF Product Identifier Type (6.4.4) 0
6. Capture Equipment Compliance (6.4.5) 0
7. Capture Equipment ID (6.4.6) 0
8. Size of Scanned Image in x direction (6.4.7) MIT
9. Size of Scanned Image in y direction (6.4.8) MIT
Inherited directly from input data
10. X (horizontal) resolution (6.4.9) 197
11. Y (vertical) resolution (6.4.10) 197
12. Number of Finger Views (6.4.11) 1
13. Reserved Byte (6.4.12) 0
14. Finger Position (22.214.171.124) MIT Inherited directly from input data
15. View Number (184.108.40.206) 0
16. Impression Type (22.214.171.124) 0 or 2 Inherited directly from input data
17. Finger Quality (22.214.171.124) MIT Inherited directly from input data
18. Number of Minutiae (18.104.22.168) 0 M 128 M minutiae data records follow
19. Minutiae Type (220.127.116.11) 01b, 10b, or 00b See Note 1 below Table 6
20. Minutiae Position (184.108.40.206) MIT See Note 7 below Table 6
21. Minutiae Angle (220.127.116.11) MIT See Note 8 below Table 6
This test specification previously required minutia quality values to
22. Minutiae Quality (126.96.36.199) MIT be zero. This requirement no longer applies. It did not and does
not apply to the PIV operational specification.
23. Extended Data Block Length (18.104.22.168) 0 No bytes shall be included following this field.
Acronym Meaning
mandatory at time of For PIV Certification, a mandatory value that shall be determined at the time the record
instantiation is instantiated and shall follow the practice specified in [FINGSTD]
A.3.2 Template matcher
A template matcher shall be certified as a software library. For PIV, a matcher is a software function that compares
enrollment templates with authentication templates to produce a similarity score. The similarity score shall be an
integer or real value quantity. The enrollment templates represent the PIV Card templates. The authentication
templates represent those extracted from fingerprints collected in an authentication attempt. A supplier's
implementation, submitted for certification, shall satisfy the API specification published by the test organizer.
The API specification will support at a minimum the comparison of one authentication template (from an individual's
primary or secondary fingers) with one enrollment template (from the same finger of either the same person or
another individual). Both templates shall conform to the Table 6 profile of [MINUSTD].
The test shall require that all invocations of the matching function shall yield a similarity score regardless of the input
templates. Larger scores shall be construed as indicating higher likelihood that the input data originated from the
same person. A failure or refusal to compare the inputs shall in all cases result in the reporting of a score. This
document recommends implementers report a low score in this case.
The input [MINUSTD] enrollment templates shall be prepared by the test agent using software from a supplier. The
input [MINUSTD] authentication templates shall be the output of the template generation software provided by the
supplier of the matcher under test. This means that a matcher cannot be certified as a standalone item.
A.5 Determination of an interoperable group
The testing laboratory shall compute the detection error tradeoff characteristic (DET) for all pair wise combinations of
the template generators and template matchers. The testing laboratory shall generate a rectangular interoperability
matrix (see [PERFSWAP]). The matrix has rows corresponding to the generators and columns corresponding to the
matchers. Each element of the interoperability matrix shall be the false reject rate at a fixed false accept rate. This
value corresponds to one operating point on the DET. As described in Annex A.3, the DET automatically includes the
effect of failure to enroll and acquire.
An interoperable group of template generators and matchers shall be established as the largest subgroup of products
submitted in an initial certification round for which all elements of the interoperability sub-matrix (i.e., FRR values)
are less than or equal to 0.01 at a fixed 0.01 FAR operating point. The condition that all pair wise product
combinations should be below this threshold is instituted because the PIV application is intolerant of non-
interoperable pairs.
Annex B. Selection of iris camera
This document does not establish certification criteria for iris cameras used in PIV. The motivation for this is that a
formal certification procedure is not yet ready (see below) and, that as an Agency-optional biometric, iris certification
costs are not warranted given the wide availability of high-performing cameras. Instead, Agencies might reasonably
consider evidence of deployed track record, prior test or operational results, standards-compliance, and the guidance
of the following Sub-sections.
The [APP/F] certification originates in the need to ensure images are suitable from criminal forensic examination.
This approach measures accuracy and this necessarily involves using an iris recognition algorithm. Agencies might
allow each tested camera to be associated with an algorithm, or might instead select a separate reference algorithm
against which all cameras will be compared. The decision on which of these options to take will depend on the
operational context and on availability of algorithms.
Agencies might choose to select cameras that demonstrate adequate accuracy and speed in a scenario test of the
sort defined below. A test laboratory should execute such a test in formal conformance to the scenario testing
requirements in Section 7 of the ISO/IEC 19795-2:2007 Testing Methodologies for Technology and Scenario Evaluation
standard [PERFSCEN]. The test laboratory should additionally execute the test given the design and reporting
constraints given in Table 19 - the specifications define the scenario under test, and restrict the parameters of the test
design to ensure production of actionable performance data while mitigating the cost of the test.
The test laboratory should deliver a test report to the requesting Agency. The test report should conform to the
reporting requirements of [PERFSCEN] and should report all accuracy and speed data mentioned in Section 6.7 of this
20 7.1.7 Image and subject The test laboratory shall retain all collected images. The camera or its ancillary software shall
identity collection export one image per enrollment per eye in ISO/IEC 19794-6:2011 format.
21 7.2.2 Test crew habituation The test crew should be habituated or pre-trained to mimic habituation. The test crew may
have prior use of the iris camera and system.
22 7.2.3 Test crew composition The test crew shall be comprised of at least 250 individuals who appear on two or more
The test crew shall include at least 40% males.
The test crew shall include at least 40% subjects with age above 40.
23 7.2.4 Test subject Each subject shall be assigned an identity token.
24 7.3.1 Performance Specifications appear in Section 6.7.
25 7.3.2 Enrollment performance Failure to enroll rate (FTE) shall be calculated as the fraction of persons for which at least
one eye cannot be enrolled.
26 7.3.3 Failure-to-acquire Failure to acquire events, if detected, shall be counted and reported.
27 7.3.4 Verification performance False rejection rates shall be computed as the fraction of genuine subject-transactions that
result in verification failure.
If false acceptance occurs, testing should be stopped because false matches are unlikely to
occur in a test of with this population size and the occurrence of a false match would be an
indication of inappropriately weak threshold or a faulty implementation.
28 7.3.5 Identification metrics None.
29 7.3.6 Generalized error rates Failure to acquire events encountered during genuine subject transactions shall be combined
including failure to with false rejects to produce an effective or generalized false rejection rate.
30 7.3.7 Interim analyses A test may be terminated early if the observed measurements support, at a statistically
supported 99% confidence level, the hypothesis that the PIV requirements on FRR and
capture time are violated.
Given this test report, the agency should elect to certify a camera against a set of performance requirements an
example of such follows.
EXAMPLE The camera shall support accurate recognition. An iris camera shall be certified if it completes the
performance test defined in Annex B with all of the following results:
The proportion of subjects, executing up to three enrollment attempts, for which zero eyes can be captured
i.e., failure-to-enroll rate (FTE) is at or below 0.01;
The proportion of genuine verification transactions, each embedding up to three verification attempts, that
are falsely rejected (FRR) is at or below 0.01 given a configuration consistent with false acceptance rate
(FAR) at or below 0.0003 using only a PIV compliant [IRISSTD] generator and matcher;
Retains all [IRISSTD] images to be used in offline comparisons and confirmation of the online results for
which false match rate (FMR) shall be at or below 0.0001.
These performance specifications apply to one-to-one authentication .
These performance specifications should also be suitable for one-to-many identification, which is outside of the PIV scope.
However, identification requires proportionally much lower false match rates which are attainable using more stringent
thresholds. These may be estimated via a calibration procedure [IREX-III].

subset: commoncrawl