MINEX II 

Performance of Fingerprint Match-on-Card Algorithms

Evaluation Plan 

NIST Interagency Report 7485 

P. Grother and W. Salamon

Information Access Division 

National Institute of Standards and Technology 

August 15, 2007 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 2 of 49

Release Note 

February 29, 2008 

This document was developed in 2007 as the binding concept-of-operations and evaluation plan for the 

conduct of the MINEX II evaluation of Match-on-Card (see http://fingerprint.nist.gov/minexII). 

It is being released as formal NIST Interagency Report as a definitive documentation of a method of testing 

fingerprint minutia matching algorithms running on ISO/IEC 7816 smart cards. 

A report on the MINEX II Phase I and II trials has been published as NIST IR 7477. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 3 of 49

MINEX 

An Evaluation-based Program for the Improvement of Minutiae 

Interoperability 

MINEX II 

An Assessment of ISO/IEC 7816 Card-Based 

 Match-on-Card Capabilities 

Patrick Grother and Wayne Salamon 

NIST 

August 15, 2007 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 4 of 49

Version History 

Nov 2, 2007 

― Changed Phase I to Phase II in the participation agreement, Annex H. 

― Inserted the already announced schedule into this document on page 3. 

Oct 23, 2007 

― In 10.4.1, changed 60 to 83, i.e. corrected the max number of minutia before command chaining is needed.

Oct 19, 2007 

― In 10.4.1, state that we will attempt Command Chaining for large templates. 

― In 10.5.2, add hyperlink to NIST's minutia template handling open-source code 

― In 10.5.2, add hyperlink to NIST's MOC test application open-source code 

― In A.3 replaced incorrect ref to NIST template conversion program "fmrisocompact" → "fmr2fmr" 

The changes below applied to Phase I which was open until Sep 10, 2007. 

Aug 15, 2007: 

― Modified Table 19 and Table 21 to show our minimum acceptable response for card and matcher IDs. 

Aug 14, 2007: 

― Modified 10.3 and Figure 1: Minutia sorting should be the final step in the I378 to ISO-CC conversion. 

― Fixed typos 

Aug 3, 2007: 

― In H.3.4, made inline explicit link to NIST's encryption key for submission of all material to NIST. 

― Deleted redundant "7F 2E xx" from Table 14's data field, which erroneously repeated Table 6 content. 

― In H.3.2, added explicit HTML link to the password-protected area - Registered participants are required to 

download and process a small validation set of images. 

July 25, 2007: Clarified section H.2.1 on how to participate. 

July 12, 2007: Schedule deleted here, and moved to newly establish MINEX II homepage: 

http://fingerprint.nist.gov/minexII

July 11, 2007. The final set of changes are: 

― Clarification that the BIT structure is a read-only entity in MINEX II. NIST does not intend to update the 

BIT, nor require card to support updating of the BIT. This means that the finger position information in the 

BIT will often be incorrect. 

― Fix datatype for PC-based similarity score with that specified for card i.e. use two byte unsigned Integer 

similarity scores both on-card and off-card. 

― Fix match_templates() function – template sizes input values were missing. 

― Only one BIT required, if the two would otherwise be identical. 

― Tag '83' is now optional in BIT. 

― Typos, clarifications. 

June 29, 2007. This MOC test specification is a heavily revised version of the May 24 draft. It has been 

produced in response to the many comments received, and the decisions made at a NIST workshop. A short 

final comment period will close on July 5, 2007, and a final plan released on July 9. Please note the main 

changes: 

― Corrected card APDUs (sec. 7). 

― PC/SC card reader named (sec 5.3). 

― Adoption of modified Ongoing MINEX API (sec. 8). 

― Use of INCITS 378 templates with quality values as progenitors of ISO-CC templates (secs. 5.4 and 6.2). 

Abandon ISO-CC generation because ISO-CC doesn't have quality values. 

― Clarified intent of minutia quality values (sec. 6.2.2) 

― Refined text on how pruning proceeds (sec 9.4). 

― Allow template generator to return a center for pruning (sec. 9.4.4) 

May 24, 2007. This interim version is available for comment until May 31, 2007. The changes from May 8 are 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 5 of 49

shown in blue.

May 8, 2007. NIST is pleased to announce the availability of this draft evaluation plan. The entire content of this 

document is subject to revision. 

NIST specifically requests reviewers of the document to submit comments to the authors. These may include 

suggestions to add, subtract, or change its content. 

March 12, 2007. NIST requested comments on the feasibility of MOC. NIST is most appreciative of the 

numerous, enthusiastic and helpful responses. 

Provisional Timeline

December 17 Release of MINEX II Report Tentative

November 15 Submissions must be operating correctly at NIST

November 5 Initial submission to Phase II must be received.

October 22 Phase 2 submission period

Sept 14 Return of Phase 1 results to suppliers

Sept 11-13 Biometrics Consortium, Baltimore MD

July 11 - Sep 10 NIST will accept applications to participate in Phase 1. This phase will include 

acceptance testing and execution of Phase 1 trials. 

July 11 Establishment of MINEX II website, http://fingerprint.nist.gov/minexII

July 9 Final test plan

July 5 End of comment period

June 28 Release of draft test plan. NIST invites comments from interested parties. 

May 31 Comment period closes Past

May 24 sBMOC Workshop at NIST

May 9 First draft MINEX II, ISO-CC + MOC Test Plan

March 29 Comment period closed

March 12 MOC Concept document + RFP
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 6 of 49

Table of Contents

1. Overview .................................................................................................................. 9

2. Scope ...................................................................................................................... 9

3. Normative References ................................................................................................ 10

4. Caution .................................................................................................................. 11

4.1. Relationship between MINEX II and other issues .............................................................. 11

4.2. Relationship between MINEX II and Ongoing MINEX .......................................................... 11

5. Abbreviations ........................................................................................................... 11

6. Aspects of the test .................................................................................................... 12

6.1. Match-on-card vs. match-off-card .............................................................................. 12

6.2. Fundamental concept of the test ............................................................................... 12

6.3. Generic interface hardware and software ..................................................................... 12

6.4. INCITS 378:2004 vs. ISO/IEC 19794-2:2005 Compact Card .................................................. 13

6.5. BIT Processing ....................................................................................................... 13

6.6. Card-matcher combinations ...................................................................................... 13

6.7. Two phase testing .................................................................................................. 13

6.8. Options for participation .......................................................................................... 14

6.9. Three-way interoperability ....................................................................................... 14

6.10. Metrics ............................................................................................................... 14

6.11. Participation ........................................................................................................ 14

7. Profile of MINEX II templates ........................................................................................ 15

7.1. Overview ............................................................................................................. 15

7.2. INCITS 378:2004 profile ........................................................................................... 15

7.3. ISO/IEC 19794-2:2005 compact card structure................................................................ 16

7.4. Non-presence of a header ........................................................................................ 17

7.5. Minutia uniqueness ................................................................................................. 17

7.6. Failure to acquire .................................................................................................. 17

8. MOC interface specification ......................................................................................... 17

8.1. Overview ............................................................................................................. 17

8.2. Approach to the use of ISO/IEC 7816 ........................................................................... 17

8.3. Establish Communications ........................................................................................ 17

8.4. Selection of the test application ................................................................................ 17

8.5. Store enrollment template on the card ........................................................................ 18

8.6. NIST read of the BIT ............................................................................................... 18

8.7. Verification .......................................................................................................... 20

8.8. Reading card identifier ............................................................................................ 22

8.9. Reading matcher identifier ....................................................................................... 22

9. PC-based API specification ........................................................................................... 23

9.1. Overview ............................................................................................................. 23

9.2. INCITS 378:2004 compliant templates .......................................................................... 23

9.3. Submission ........................................................................................................... 23

9.4. Testing interface ................................................................................................... 23

9.5. Software and Documentation .................................................................................... 25

9.6. Runtime behavior .................................................................................................. 26

10. NIST conversion of I378 to ISO-CC templates ..................................................................... 27

10.1. Background .......................................................................................................... 27

10.2. Presence of BITs on card .......................................................................................... 27

10.3. Use of BITs ........................................................................................................... 27

10.4. Number of minutiae ............................................................................................... 28

10.5. Sort order of minutiae ............................................................................................. 30

10.6. Ridge count, core and delta and zonal quality information ................................................ 30

11. References .............................................................................................................. 30

Annex A Comparison of the INCITS 378 and ISO/IEC 19794-2 standards ............................................... 31

A.1 Syntactic differences .............................................................................................. 31

A.2 Semantic differences .............................................................................................. 31
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 7 of 49

A.3 Simulation protocol ................................................................................................ 32

A.4 Results after re-quantization of angle and position ......................................................... 33

A.5 Results after reduction in number of minutiae ............................................................... 33

A.6 Conclusions .......................................................................................................... 34

Annex B Three-way interoperability ......................................................................................... 36

Annex C Input fingerprint image specifications ............................................................................ 38

C.1 Format ............................................................................................................... 38

C.2 Resolution and dimensions ....................................................................................... 38

C.3 Sensor and impression types ..................................................................................... 38

Annex D Error Codes and Handling ........................................................................................... 39

Annex E Predefined SDK Constants ........................................................................................... 40

E.1 Pre-defined values ................................................................................................. 40

Annex F Ambiguities in the standards........................................................................................ 41

F.1 Compact card sorting .............................................................................................. 41

F.2 Unique minutia ..................................................................................................... 41

F.3 No support for placing reference data on the card .......................................................... 41

Annex G ISO/IEC 19794-2:2005 record profile .............................................................................. 42

Annex H Application to participate in MINEX II ............................................................................. 44

H.1 Who should participate............................................................................................ 44

H.2 How to participate ................................................................................................. 44

H.3 NIST activity ......................................................................................................... 44

H.4 Points of contact ................................................................................................... 45

H.5 Access to MINEX II validation data .............................................................................. 45

H.6 Access to MINEX II test data ...................................................................................... 46

H.7 Reporting of results ................................................................................................ 46

H.8 Return of the supplied materials ................................................................................ 46

H.9 Agreement to participate ......................................................................................... 47

Annex I NIST mailing address .................................................................................................. 49

List of Figures 

Figure 1 – Conversion of INCITS 378 to ISO-CC ............................................................................. 27

Figure 2 - Use of INCITS 378 for simulation of ISO-CC accuracy ......................................................... 32

Figure 3 – Effect of minutia pruning on FNMR (above) and FMR (below) .............................................. 35

Figure 4 – Native vs. Two-way vs. Three-way Interoperability .......................................................... 36

Figure 5 – Fingerprint image raster scan order ............................................................................. 38

List of Tables 

Table 1 – Family of MINEX evaluations ......................................................................................... 9

Table 2 – Abbreviations ......................................................................................................... 11

Table 3 – MINEX II classes of participation .................................................................................. 14

Table 4 – MINEX II profile of INCITS 378:2004 standard ................................................................... 15

Table 5 – MINEX II profile of ISO/IEC 19794-2:2005 standard ............................................................ 16

Table 6 – ISO/IEC 19794-2 minutiae template DO ......................................................................... 16

Table 7 – Command APDU for selection of MOC application ............................................................. 17

Table 8 – Response APDU from selection of MOC application ........................................................... 18

Table 9 – Command APDU for storage of reference template ........................................................... 18

Table 10 – Response APDU from storage of reference template ........................................................ 18

Table 11 – Command APDU for retrieval of biometric information template ......................................... 18

Table 12 – Response APDU from retrieval of biometric information template ....................................... 19

Table 13 - ISO/IEC 19794-2 Biometric Information Template ........................................................... 19

Table 14 – Command APDU for comparison of biometric templates ................................................... 20

Table 15 – Response APDU from comparison of biometric templates .................................................. 20

Table 16 – Command APDU for retrieval of verification similarity score .............................................. 21

Table 17 – Response APDU for retrieval of verification similarity score ............................................... 21
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 8 of 49

Table 18 – Command APDU for retrieval of Card identifier .............................................................. 22

Table 19 – Response APDU for retrieval of Card identifier ............................................................... 22

Table 20 – Command APDU for retrieval of Matcher identifier .......................................................... 22

Table 21 – Response APDU for retrieval of Matcher identifier ........................................................... 22

Table 22 – NFIQ Mappings ...................................................................................................... 23

Table 23 – MINEX create_template API Function ........................................................................... 23

Table 24 – MINEX API match_templates function .......................................................................... 24

Table 25 – MINEX API get_pids function ..................................................................................... 25

Table 26 – Minutia encodings of the ISO-CC and INCITS 378 ............................................................. 31

Table 27 – Minutia location quantization of ISO-CC and INCITS 378 templates ....................................... 31

Table 28 – Minutia angle quantization of ISO-CC and INCITS 378 templates .......................................... 31

Table 29 – Source code for conversion of INCITS 378 to ISO-CC ......................................................... 32

Table 30 – Relative accuracy of ISO-CC and INCITS 378 templates (Fixed FMR) ...................................... 33

Table 31 – Relative accuracy of ISO-CC and INCITS 378 templates (fixed t) .......................................... 33

Table 32 – MINEX API return codes ........................................................................................... 39

Table 33 – MINEX API predefined values ..................................................................................... 40

Table 34 - ISO/IEC 19794-2 and ISO/IEC 7816-11 finger position codes ............................................... 40

Table 35 – MINEX II profile of ISO/IEC 19794-2:2005 standard ........................................................... 42

Table 36 – ISO/IEC 19794-2 minutiae template DO ........................................................................ 42

Table 37 – Zonal quality data .................................................................................................. 43

Acknowledgements 

The authors are grateful to the following contributors, and other anonymous individuals, without whose input 

this document would not have been concluded. 

Staff Cogent Inc. 

Rick Lazarick CSC Identity Labs 

Dirk Scheuermann, 

Ulrich Waldmann Fraunhofer Institute for Secure Information Technology 

Olaf Henniger 

Claude Barral Gemalto 

Christophe Candela id3 Semiconductors 

Gilles Lisimaque Identification technology Partners, Inc. 

Christophe J. Goyet Oberthur Technologies 

Jean-Christophe Fondeur Sagem Morpho Inc 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 9 of 49

Overview 

The MINEX program is intended to improve template-based interoperability from the state reported in MINEX 

041 and MTIT2 toward that achievable with image-based implementations. The approach is to conduct several 

trials, MINEX II, III, IV etc, each of which will embed development, evaluation, targeted feedback and

consultation activities between NIST, industry and other interested parties. Within scope is anything to do 

with fingerprint minutiae as an interoperable biometric for identity management. Typical outcomes will be 

measurements of accuracy, processing time, template size, and proposals to revise the relevant standards, 

studies of utility of quality measures, calibration information, and new metrics. 

Table 1 gives an overview of the various MINEX activities at NIST, and a context for future work, starting with 

MINEX II. 

Table 1 – Family of MINEX evaluations 

MINEX I 

(MINEX 041) 

This test was conducted as an initial comparison of image vs. minutia-based interoperability. It 

assessed the core algorithmic ability of fingerprint matcher Z to compare minutiae templates 

from sources X and Y. It compared that case with fully proprietary templates on the same sets 

of archival data. The test adopted the INCITS 378 template as a base standard. 

The test is now closed. http://fingeprint.nist.gov/minex04

Ongoing 

MINEX3

Ongoing MINEX is a continuing program of interoperability assessment intended to measure 

conformance and interoperability of INCITS 378:2004 samples. The test uses one expanded 

partition of the MINEX 04 data to formulate interoperable groups of matchers and template 

generators. One client of Ongoing MINEX is the US Government's PIV program which has its own 

set of criteria against which the interoperable group is formed. 

The test results are available to other applications or programs which may elect to set their 

own criteria for interoperable performance. 

The test remains open. 

MINEX II 

MINEX II will consider Match-on-Card capabilities using ISO/IEC 19794-2 compact card 

templates. These will be produced from parent INCITS 378:2004 records. 

In addition, because NIST considers the compact-card template small enough to be rapidly read 

from a card, the study may be useful for organizations considering Match-off-Card applications.

The test design is complete - This document is intended to be the definitive MINEX II test plan. 

Errata will be posted on http://fingerprint.nist.gov/minexII

MINEX III 

A future program, to be announced in the summer 2007, will return to the issue of core minutia 

interoperability. The scope is yet to be finalized, but it is likely to focus on development and 

exploitation of the minutia quality value. 

1. Scope 

MINEX II is intended to measure the core algorithmic capabilities of fingerprint matching algorithms running 

on standardized ISO/IEC 7816 smart cards. Specifically the test will 

― instantiate a mechanism for MOC testing, 

― measure the accuracy of match-on-card (MOC) implementations using ISO/IEC 19794-2:2005 compact card 

minutiae templates, 

― time the various operations, 

― test the viability of INCITS 378 to ISO/IEC 19794-2 compact card transcoding, 

― formulate comments toward possible revision of the relevant standards, and 

 

1

 Minutiae Interoperability Exchange Test, MINEX, NIST Interagency Report 7296, March 21, 2006. 

2

 Minutiae Template Interoperability Testing, http://www.mtitproject.com

3

 See the Ongoing MINEX Homepage at http://fingerprint.nist.gov/minex
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 10 of 49

― test conformance to the INCITS 378:2004 record format, as profiled herein. 

The primary outputs of the test will be statements of performance using the following metrics. 

― False non-match and false match error rates, 

― Off-card template generation times, 

― On-card matching times. 

In so doing, this evaluation 

― requires production of INCITS 378:2004 templates, and 

― uses NIST's open-source transcoder to convert INCITS 378:2004 templates to ISO/IEC 19794-2 compact 

card format for matching, 

Not in the scope of this evaluation, but the subject of a separate activity4

 at NIST is: 

― securing the communications channel, including cryptographic protection of the biometric templates; 

― template integrity protection using digital signatures; 

― authentication of the card to the reader; 

― contactless communications; 

The following are specifically not within the current scope of this evaluation: 

― The ISO/IEC 19794-2 "record" and "card normal" templates, 

― Ridge count, core and delta, and zonal quality extensions, 

― Non-standard extensions to any standardized minutia format, 

― Evaluation of readers, including performance, conformance and interoperability, 

― Evaluation of ruggedness or durability of the card,

― On-card template generation (i.e. extraction of minutiae from images), 

― Template update or adaptation, 

― Although the test will use ISO/IEC 7816 parts 4 and 11, and conformance to this subset will be a 

requirement, this study does not constitute a formal test of conformance to any part of ISO/IEC 7816, and 

― Devices not conforming to ISO/IEC 7816, including all sense-on-card devices that embed proprietary 

template formats. 

2. Normative References 

The following referenced documents are indispensable for the application of this document. For dated 

references, only the edition cited applies. For undated references, the latest edition of the referenced 

document (including any amendments) applies. 

― INCITS 378:2004 — American National Standard for Information Technology — Finger Minutiae Format for 

Data Interchange 

― ISO/IEC 7816-4:2005 — Identification cards — Integrated circuit cards — Part 4: Organization, security and 

commands for interchange 

― ISO/IEC 7816-6:2005 — Identification cards — Integrated circuit cards — Part 6: Interindustry data 

elements for interchange 

― ISO/IEC 7816-11:2004 — Identification cards — Integrated circuit cards — Part 11: Personal verification 

through biometric methods 

― ISO/IEC 19794-2:2005 — Information technology — Biometric data interchange formats — Part 2: Finger 

minutiae data 

 

4

 See documents linked from here: http://csrc.nist.gov/piv-program/ 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 11 of 49

― ISO/IEC 19794-2:2005/Cor.1:2007 — Information technology — Biometric data interchange formats — Part 

2: Finger minutiae data – Technical Corrigendum 1 (first draft, JTC001-SC37-N-2119, circulated May 2007) 

― ISO/IEC 19785-3:2005 — Common biometric exchange formats framework — Part 3: Patron format 

specifications (FDIS draft, JTC001-SC37-N-2163, circulated June 6, 2007) 

― ISO/IEC FCD 19795-4 — Biometric Performance Testing and Reporting — Part 4: Interoperability 

Performance Testing. 

3. Caution 

3.1. Relationship between MINEX II and other issues 

Neither this document, nor any future execution of MINEX or MOC evaluations by NIST, should be construed as 

an indication that NIST, nor any other agency of the United States government, has decided for or against the 

inclusion or exclusion of the items listed below in any current or future government specification or program. 

― Contactless biometric interfaces, 

― MOC implementations, 

― ISO/IEC 19794-2 formats, and 

― Definitive formats for standardized templates to be stored on, or transmitted to, cards. 

This document is strictly a special notice that is being published to reach a wider audience. It is not a federal 

procurement action, and no RFQ or RFP is available.

In addition, the identification of any commercial product or trade name does not imply endorsement or 

recommendation by the National Institute of Standards and Technology. 

3.2. Relationship between MINEX II and Ongoing MINEX 

MINEX II will use samples drawn from the same population as is used in the Ongoing MINEX process. MINEX II 

will be conducted in two phases. For reasons of timeliness, Phase I is likely to consider only a subset of those 

images, and will only examine native or limited cross-vendor template interoperability. Phase II will extend 

the operation toward full interoperability testing, including the kind examined in Ongoing MINEX. Phase II 

may also employ an expanded set of images or comparison counts. 

4. Abbreviations 

The abbreviations and acronyms of Table 2 are used in many parts of this document. 

Table 2 – Abbreviations 

APDU Application Protocol Data Unit as used in ISO/IEC 7816-4

BIT Biometric Information Template as defined in ISO/IEC 7816-11 

DET Detection error tradeoff characteristic – a plot of FNMR vs. FMR (sometimes as normal 

deviates, sometimes on log-scales) 

FMR False match rate

FNMR False non-match rate

IDMS Identity management system

INCITS InterNational Committee on Information Technology Standards

ISO/IEC 7816 Multipart standard for "Identification cards - Integrated circuit(s) cards with contacts"

ISO/IEC 19794 Multipart standard of "Biometric data interchange formats"

I378 INCITS 378:2004 as profiled in this standard

ISO-CC The compact card minutia format of clause 8 in ISO/IEC 19794-2:2005

MINEX Generic name for the series of NIST's Minutia Interoperability Exchange Tests

MOC Match on card

MXC Match off card

NIST National Institute of Standards and Technology
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 12 of 49

PC/SC Generic interface specification for PC to smart card connectivity 

SC 17 Subcommittee 37 of Joint Technical Committee 1 – developer of smart card standards

SC 37 Subcommittee 37 of Joint Technical Committee 1 – developer of biometric standards

SDK The term Software Development Kit refers to any library software submitted to NIST

5. Aspects of the test 

5.1. Match-on-card vs. match-off-card 

The MINEX II test is specifically aimed at testing the efficacy of match-on-card (MOC) implementations that 

compare instances of ISO/IEC 19794-2:2005 compact card (ISO-CC) templates. Thus, one use of MINEX II 

would be to confirm that performance achieved by a MOC submission to Ongoing MINEX (an off-card process) 

is actually achievable on at least one ISO/IEC 7816 card. 

The MINEX II study is initiated in response to near-term imperatives to evaluate the technology. 

The test is likely to require somewhat customized cards (i.e. not production cards), at least because of the 

requirement to be able to read similarity scores from the card. 

5.2. Fundamental concept of the test 

The MOC capability shall be tested in three stages:

― In stage 1, NIST will measure the accuracy of the matching algorithm executing on a PC class machine. 

The test requires submission of a Pentium-class implementation of the same MOC algorithm5. This stage 

is likely to embed hundreds of thousands of genuine and impostor comparisons to support the accuracy 

measurement goals of the MINEX tests. 

― In stage 2, NIST will repeat a small subset of the stage 1 template comparisons on the card. Selected

genuine and impostor comparisons will be repeated on the card by successively storing reference 

templates on the card and sending verification templates to the card for comparison. 

― In stage 3, NIST will compare similarity scores retrieved from the card in stage 1 with those generated in 

stage 3. For any given pair of reference and verification templates, they must be identical. 

This three-stage strategy assures NIST that the accuracy of the MOC implementation is identical to that of the 

PC-based version of the algorithm, and that the card itself is truly capable of running at the measured 

accuracy. 

5.3. Generic interface hardware and software 

NIST intends to access all cards via third party PC/SC hardware owned by NIST. NIST will use the SCR SCM3356

reader7, and the M.U.S.C.L.E open-source drivers8 under Linux. 

NIST does not currently intend to use other card readers, but reserves the right to do so for any purpose. 

As in previous tests, NIST intends to run the PC-based portions of the test using software components 

implementing a simple "C" API. 

 

5

 While NIST understands that the PC-based matcher submission may need to use only fixed-point arithmetic, or run 

underneath an emulator, we do not address means of assuring equivalence of on and off card implementations. 

6

 Specific hardware and software products identified in this plan will used in order to perform the evaluations described 

in this document. In no case does identification of any commercial product, trade name, or vendor, imply 

recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the 

products and equipment identified are necessarily the best available for the purpose. 

7

 The reader is documented at http://www.scmmicro.com/security/view_product_en.php?PID=11. 

8

 See driver software homepage is http://www.linuxnet.com/middle.html
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 13 of 49

5.4. INCITS 378:2004 vs. ISO/IEC 19794-2:2005 Compact Card 

In MINEX II, NIST requires submitted template generators to produce INCITS 378:2004 templates, as profiled in 

section 6.2 of this document. NIST will convert such templates to ISO/IEC 19794-2:2005 compact card 

instances before passing them to PC-based and card-based matching algorithms. Conversion will be done onthe-fly and will be parameterized per the BIT(s) read from the target smart card. 

NIST is not requiring production of ISO-CC templates because the following points hold. 

― Three-byte ISO-CC minutia points are strict "semantic children" of six-byte INCITS 378:2004 or ISO/IEC

19794-2:2005 record format minutia points. 

― The process of conversion of INCITS 378:2004 to ISO-CC is trivial and mostly standardized, and that there 

is no additional intellectual property needed to compute an ISO-CC template vs. an I378 template. 

― Minutia quality values are required entries in INCITS 378:2004 minutiae records. 

― Minutia quality values are required when preparing ISO-CC templates for MOC. 

― The quality field of I378 is considered an essential mechanism for improving minutia-based 

interoperability from the state measured in MINEX and MTIT. 

― ISO-CC templates can exist only as terminal objects, i.e. they cannot be used in the preparation of other 

standardized minutia records. 

With regard to issues of minutia selection and placement, NIST draws the attention of template generator 

developers to the German national body contribution, N2135, submitted to SC 37 Working Group 3 on May 29, 

2007. 

5.5. BIT Processing 

NIST will read one or two ISO/IEC 7816-11 BITs from each submitted card as a group (see the card APDU in 

section 7.6). These parameterize the conversion of I378 templates to ISO-CC templates before they are sent 

to 

― card based MOC matcher implementations, and 

― PC-based MOC match implementations. 

5.6. Card-matcher combinations 

The primary objective of MINEX II is to ascertain MOC capability by measuring fingerprint algorithm accuracy 

in the intended environment (i.e. the card). NIST considers that card vendors may elect to team with several 

fingerprint algorithm vendors, and vice versa. NIST further expects that a fingerprint supplier's technology 

may demonstrate improved accuracy when implemented on a more capable card. 

NIST seeks to identify the most capable components and combinations of components and therefore the 

participation agreement, Annex H, requires identification of all card and fingerprint technology suppliers, 

with responsible signatories from all collaborating organizations. 

5.7. Two phase testing 

NIST is likely to conduct the test in two phases. The first is intended to be a smaller and faster evaluation of 

submitted software and cards that 

― will use a reduced number of images, 

― or only a subset of all interoperability paradigms (see section 5.9), 

― will give feedback and results to the suppliers, and 

― is not intended to include release of results to the sponsors or the public. 

― Suppliers should submit new software and hardware for the second phase. The second phase will include

the full size test and will result in a final public report. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 14 of 49

NIST is particularly interested in facilitating improved performance between Phase 1 and Phase 2. It intends 

to provide feedback to suppliers and to allow submission of improved software and hardware. NIST remains 

open to comment on what feedback (metrics, data, or calibration information) would be most useful. 

5.8. Options for participation 

For phase 1, participants shall provide the components identified in one or more rows of Table 3. All

components in a row shall be supplied. Up to four submissions (e.g. 3 Class A + 1 Class B) are permitted to 

allow 

― card suppliers to team with several suppliers of fingerprint template generators, and vice versa, and 

― suppliers to submit, say, fast-but-inaccurate and slow-but-accurate versions. 

Table 3 – MINEX II classes of participation 

Class of 

Participation 

Annex H

Participation 

agreement 

ISO/IEC 7816

Card + Matcher 

PC-based ISOCC Template 

Matcher 

PC-based INCITS 

378:2004 

Template 

Generator 

Class A + + +

Class B + + + +

These classes of participation may be revised for Phase II. 

5.9. Three-way interoperability 

NIST anticipates that some cards embed fingerprint matchers that are not accompanied by an associated 

template generator (i.e. Class A), and may well be used with enrollment and verification templates coming 

from two different sources. That is card-based matcher, M, will compare a reference template produced by 

X with a verification template from Y. NIST intends to evaluate three-way interoperability in Phase 2 of this 

test, but may in addition do so in Phase 1. The possible implications for accuracy are discussed in Annex B. 

Both Class A and Class B submissions may be tested in all combinations of M, X and Y. 

5.10. Metrics 

NIST intends to report full detection error tradeoff (DET) characteristics for all implementations tested. The 

DET is primary mechanism for transferring the accuracy results of evaluations into the technology policy 

arena (e.g. in order to establish security requirements). 

In addition, in the full-size Phase 2 trial, NIST intends to report performance interoperability matrices9. Such 

tables will report false non-match rates at fixed false match rates of 0.0001 as the primary figure of merit. 

NIST may report other metrics also. 

NIST will measure and report estimates of the elapsed times of at least the 

― template generation process, 

― on-card and off-card template comparisons, and 

― the storage of the reference template on the card. 

5.11. Participation 

Prospective participants should read this document then complete the application form, Annex H. 

 

9

 Like Table 8 of NIST Interagency Report 7296 Performance and Interoperability of the INCITS 378 Template. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 15 of 49

6. Profile of MINEX II templates 

6.1. Overview 

All template generators submitted under the MINEX II program shall produce an INCITS 378:2004 template, as 

defined in section 6.2. This is specified because a valid minutia quality is required in the preparation of the 

section 6.3 ISO-CC templates sent to the matchers. 

6.2. INCITS 378:2004 profile 

6.2.1. Record structure 

Template generators shall produce records conformant to Table 4. This is identical to the Ongoing MINEX 

profile10 except that 

― the minutia quality field shall be meaningfully populated11, 

― the IBIA vendor code field shall be populated, 

― the version number IDs shall be populated. 

Table 4 – MINEX II profile of INCITS 378:2004 standard 

Section title and/or field name 

(I378 clause numbers in parentheses) 

Values Allowed Informative Remarks

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) 32 ≤ L ≤ 800 26 record header + 4 view header +2

extended data length + 6K. Max K is 128 

4. CBEFF Product Identifier Owner (6.4.4) > 0 Two byte, IBIA registered, vendor ID.

5. CBEFF Product Identifier Type (6.4.4) > 0 Two byte, vendor assigned, version number.

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 Inherited directly from input data

9. Size of Scanned Image in y direction (6.4.8) MIT

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 (6.5.1.1) MIT Inherited directly from input data (see 8.4.2)

15. View Number (6.5.1.2) 0

16. Impression Type (6.5.1.3) 0 or 2 Inherited directly from input data

17. Finger Quality (6.5.1.4) MIT Inherited directly from input data

18. Number of Minutiae (6.5.1.5) 0 ≤ K ≤ 128 K minutiae data blocks

19. Minutiae Type (6.5.2.1) 01b, 10b, or 00b

20. Minutiae Position (6.5.2.2) MIT

21. Minutiae Angle (6.5.2.3) MIT

22. Minutiae Quality (6.5.2.4) 0, 1 ≤ Q ≤ 100 0 = unsupported

23. Extended Data Block Length (6.6.1.1) 0 No bytes shall follow this field.

MIT = mandatory at time of instantiation

 

10 The Ongoing MINEX profile is that given in Table 11 of NIST Special Publication 800-76-1. 

11 The operational PIV profile given Table 3 of NIST Special Publication 800-76-1 requires the minutia quality field to be 

supplied per I378. However all existing minutia standards gives poor guidance on what quality means. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 16 of 49

6.2.2. Minutia quality values 

The use of a minutia quality value is normatively required by clause 8.3.1 of ISO/IEC 19794-2:2005 for the 

preparation of ISO-CC templates, as described later in section 9.4.3. 

For MINEX II, the template generator shall generate quality values that are indicative that a minutia is a true 

minutia. That is, larger values shall indicate decreased likelihood that the minutia is a false minutia. This 

requirement is specifically distinct from one in which the quality value would be indicative of, for example, 

the local noise in the original image. 

MINEX III will be a cooperative project to develop minutia quality implementations. 

6.2.3. ID values 

The ID values will be used for internal NIST logging. The version numbers should be distinct between any 

versions which offer different algorithmical functionality. 

6.3. ISO/IEC 19794-2:2005 compact card structure 

This section defines precisely what constitutes the data to be sent to PC-based and card-based MOC 

implementations. It is included here because ISO/IEC 19794-2:2005 and its draft corrigenda and revisions 

define multiple templates combining 

― three encodings (record, card-normal, card-compact), 

― versions with and without headers12, 

― variants differing in their minutia placement semantics, 

― presence of standardized extended data (zonal quality etc), and 

― presence of non-standard, proprietary, extended data. 

The MINEX II evaluation will use ISO-CC templates for which 

― the record and view headers shall be absent, 

― standardized extended data shall be absent, and 

― proprietary extended data shall be absent. 

NIST will convert the I378 instances of Table 4 to produce Table 5 instances of ISO-CC. This process is 

described in section 9. 

Table 5 – MINEX II profile of ISO/IEC 19794-2:2005 standard 

1. X coordinate 8 [0,255] Expressed in units of 0.1 mm View data

S instances of the 

minutiae data on 

lines 17-20 shall be 

present

2. Y coordinate 8 [0,255] Expressed in units of 0.1 mm

3. Minutiae type 2

4. Minutiae angle 6 [0,63] Resolution is 5.625 degrees

MOC implementations shall accept templates in the TLV format of Table 6. 

Table 6 – ISO/IEC 19794-2 minutiae template DO 

Tag L Value

‘7F2E’ L1 Biometric data template

Tag L Value

‘81’ L2 Finger minutiae data

Field Size (bits) Valid Values

X coordinate 8 [0,255] S 

Y coordinate 8 instances [0,255]

Minutiae type 2

 

12 Working Group 3 of SC 37 discussed this issue in its January 2007 meeting in New Zealand. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 17 of 49

Minutiae angle 6 [0,63]

6.4. Non-presence of a header 

NIST has abandoned plans to require the minutiae data to be preceded by a four byte view header. These 

plans were advanced in versions of this document circulated before May 26 2007. However, see also section 

F.3 for a comment regarding standardization. 

6.5. Minutia uniqueness 

A non-ISO requirement is for the minutia points to be unique. Template generators submitted in MINEX II 

shall output unique (x, y, and theta) tuples and NIST will implement checks to detect deviations from such 

behavior. This requirement is instituted because non-uniqueness impedes some matching algorithms. 

6.6. Failure to acquire 

Template generators in MINEX evaluations must always produce a Table 4 template, even if no minutiae are 

found. Such a template will have length 26 bytes, and the value in the "number of minutiae" field shall be 0. 

NIST considers this a valid template. It is useful for correct accounting of template generator failure (see 

MINEX NIST IR 7296 http://fingerprint.nist.gov/minex04/minex_report.pdf section 5.3). 

7. MOC interface specification 

7.1. Overview 

The following subsections define the mechanism by which all cards shall be accessed for this test. This 

includes selection of the application, reading and use of the Biometric Information Template (BIT), 

installation of a reference template, verification, recovery of similarity scores, and retrieval of identifiers. 

The template generation function, including use of the BIT(s), shall be conducted on PC-class computers. 

7.2. Approach to the use of ISO/IEC 7816 

The following subsections detail the MINEX II MOC interface. It was designed with the following criteria in 

mind. 

― Adherence to the provisions of ISO/IEC 7816-4:2005, 7816-11:2004 and 19794-2:2005. 

― When the base standards provide for optional content this specification follows NIST Special Publication 

800-73-1 Interfaces for Personal Identity Verification. 

― To only define new elements when extant standards are silent on a necessary functionality. 

The impact of the second provision is to select odd byte INS values, indicating the command data field

contains BER-TLV objects. 

7.3. Establish Communications 

An Answer-to-Reset shall be performed to determine (T=0, T=1 or T=CL). 

7.4. Selection of the test application 

This card shall be supplied with a dedicated NIST MOC testing application. It shall be invoked once by using 

the SELECT command in Table 7. The response shall be as in Table 8. 

 Table 7 – Command APDU for selection of MOC application 

Command 

Parameter 

Required Value Meaning

CLA

INS 

‘00’

‘A4’ SELECT 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 18 of 49

P1-P2 ‘04 0C’ AID follows, 1100b 

Lc field 16 Length of AID

Data field 'F0 4E 49 53 54 20 4D 4F 43 20 54 53 54 20 50 31' AID

In ASCII, "≡NIST MOC TST P1" 

where P1 connotes Phase 1 

Le field Absent

Table 8 – Response APDU from selection of MOC application 

Response Parameter Meaning

Data field Empty

SW1-SW2 See ISO/IEC 7816-4:2005

7.5. Store enrollment template on the card 

The APDU for replacing the template on the card is shown in Table 9. It uses the PUT DATA instruction to 

overwrite the existing reference template. 

Table 9 – Command APDU for storage of reference template 

Command 

Parameter 

Required Value Meaning

CLA

INS 

P1-P2 

‘00’

‘DB’ 

'3F FF' 

PUT DATA 

Store anywhere in the current Dedicated File (Application DF) 

Lc field Length of command data field

Data field Table 6 Data Object in BER-TLV format to be stored (tag '7F 2E')

Le field Empty

Table 10 – Response APDU from storage of reference template 

Response Parameter Meaning

Data field Empty

SW1-SW2 See ISO/IEC 7816-4:2005

Note that finger position data is not included, because no standard regulates its transmission. In any case, 

NIST will only conduct comparisons of same-finger templates. NIST will not write, nor require support for 

writing, new BIT(s) to reflect any changes in the finger position value. 

NIST considers that the lack of a standard here impedes at least testing, and probably operational issuance 

systems - see Annex F. 

7.6. NIST read of the BIT 

NIST will use the command of Table 11 to retrieve the BIT group template of Table 13 per the response of 

Table 12. 

Table 11 – Command APDU for retrieval of biometric information template 

Command 

Parameter 

Required 

Value 

Meaning

CLA

INS 

P1-P2 

‘00’

‘CB’ 

'3F FF' 

GET DATA 

Retrieve from anywhere in the current Dedicated File (Application DF) 

Lc field '04'

Data field '5C'

'02' 

'7F 61' Data Object identifier to be retrieved (group of BIT) 

Le field ‘00’
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 19 of 49

Table 12 – Response APDU from retrieval of biometric information template 

Response Parameter Meaning

Data field Biometric Information Template (see Table 13)

SW1-SW2 See ISO/IEC 7816-4:2005

Table 13 contains two BITs13. NIST shall apply the first BIT to enrollment templates. NIST shall apply the 

second BIT to the verification templates. If only one bit is present, NIST shall apply it to both the enrollment 

and verification templates. Whether there are one or two BITs, they shall be grouped together as a BIT group 

template. NIST will read the group of two BITs from each submitted card, and store it. NIST is likely to 

conduct this read operation only once, but will use the BITs to parameterize all template conversion 

operations prior to sending templates to the card or to the PC-based software matcher. 

All instances of a submitted card must have the same BIT group. The BIT(s) shall contain the data as 

described in Table 13. The BIT(s) may also contain other information (e.g. as allowed by the standards), 

which NIST shall ignore. 

Table 13 - ISO/IEC 19794-2 Biometric Information Template 

Tag Len. Value NIST

‘7F61’ Var. BIT group template Requirements

Tag Len. Value

'02' 1 Number of BITs in the group 2

‘7F60’ Var. Biometric Information Template (BIT) For enrollment

Tag Len. Value

‘A1’ Var. Biometric Header Template (BHT) conforming to ISO/IEC 

19785-3:2005 

Tag Len. Value

'81' 1 08 biometric type (08 = fingerprint)

'82' 1 XX biometric subtype (finger position)

These values shall be from 7816-11 table (and 

19785) and NOT from 19794-2 

See NOTE 1 below

‘87’ 2 CBEFF BDB format owner 0101 i.e. 

JTC1/SC37 

‘88’ 2 CBEFF BDB format type 0005 see sec. 

7.6.1 

'B1' Var. Biometric matching algorithm parameters 

ISO/IEC 19794-2 Table 14 

Tag Len. Value

'81' 2 Min. and max. numbers of 

minutiae, see ISO/IEC 19794-2 

(subclause 8.3.3, Table 10) 

See sec. 0

'82' 1 Minutiae order, see ISO/IEC 19794-

2 (subclause 8.3.4 and Tables 11 

and 12)14

Native, see sec. 

9.5 

'83' 1 Feature handling indicator, see 

ISO/IEC 19794-2 (Table 15) 

See NOTE 2 below 

and sec. 9.6 

‘7F60’ Var. Biometric Information Template (BIT) For verification

Tag Len. Value

‘A1’ Var. Biometric Header Template (BHT)

Tag Len. Value

 

13 In accordance with the suggestion in Annex D of ISO/IEC 19794-2:2005, NIST seeks to support asymmetric enrollment 

and verification templates. This allows, for example, higher maximum numbers of minutiae in the reference template 

than in the verification template. However, NIST will not pass these parameters to the template generator so the PCbased API still only contains a generic create_template() function call which does not differentiate between enrollment 

and verification (see sec. 8.4.2). Instead, this will occur during a pre-match post-processing of the template. 

14 The text in this line is a corrected version of that in ISO/IEC 19794-2:2005 Table 14 second-to-last line which should 

reference subclause "8.3.4" not "8.33". 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 20 of 49

'81' 1 08 biometric type (08 = fingerprint)

'82' 1 XX biometric subtype (finger position)

These values shall be from 7816-11 table (and 

19785) and NOT from 19794-2 

See NOTE 1 below

‘87’ 2 CBEFF BDB format owner 0101 i.e. 

JTC1/SC37 

‘88’ 2 CBEFF BDB format type 0005 see sec. 

7.6.1 

'B1' Var. Biometric matching algorithm parameters 

ISO/IEC 19794-2 Table 14 

Tag Len. Value

'81' 2 Min. and max. numbers of 

minutiae, see ISO/IEC 19794-2 

(subclause 8.3.3, Table 10) 

See sec. 0

'82' 1 Minutiae order, see ISO/IEC 19794-

2 (subclause 8.3.4 and Tables 11 

and 12) 

Native, see sec. 

9.5 

'83' 1 Feature handling indicator, see 

ISO/IEC 19794-2 (Table 15) 

See NOTE 2 below 

and sec. 9.6 

NOTE 1 NIST does not intend to pass finger position information to the card. Therefore, NIST cannot 

expect correct data in the '82' tag. NIST requires the tag to be present, per ISO/IEC 19785-3:2007, but will 

not test its value. NIST will never update the BIT, for example when the reference data is changed. 

NOTE 2 The tag '83' is optional. If present, the value shall be 00000000b. It is included in the table 

above, to formally indicate that extended data is out of scope of this test. 

7.6.1. Variants of the ISO/IEC 19794-2 standard 

Clause 9 of the ISO/IEC 19794-2:2005 standard gives the "format type" codes for six variants which differ in 

the encoding (as in Table 26) and placement requirements on minutiae. Placement variation, such as 

whether a ridge ending is encoded as the ridge skeleton end-point or as the valley bifurcation, remains an 

open issue in minutiae interoperability. For the current test, NIST will maintain its MINEX requirement of the 

latter definition. Thus, 

― cards must return a value of 0005 for the "format type" in the BIT tag '88', and 

― encoders should follow the ISO/IEC 19794-2:2005 clause 6 guidance on placement. 

7.7. Verification 

7.7.1. APDU specifications 

The verification data is sent using the VERIFY command of Table 14. 

Table 14 – Command APDU for comparison of biometric templates 

Command Parameter Meaning

CLA

INS 

P1-P2 

‘00’

‘21’ = VERIFY 

‘00 00’ 

Lc field Length of command data field

Data field Value Field of the template, identical to Table 6.

Le field absent

The odd INS value allows the use of P1-P2 parameters with a value of 00-00 as the indication of what is to be 

verified is given by the tag of the data object presented in the data field of the command. 

Table 15 – Response APDU from comparison of biometric templates 

Response Parameter Meaning
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 21 of 49

Data field Empty

SW1-SW2 '90 00' (yes) or

'63 CX' (register 0) or 

'63 00' 

NOTE that this only returns the status code. The required similarity score is returned in a separate GET DATA 

command, see section 7.7.2. 

7.7.2. Locking of the card 

NIST seeks to conduct arbitrary comparisons on the card. However NIST will respect '63 CX' counter values 

and will also attempt to execute high-scoring comparisons with sufficient frequency to ensure that low

scoring verification comparisons are infrequent enough to prevent card locking. NIST will discontinue testing 

of cards for which these mechanisms are insufficient to prevent locking. 

PC-based implementations of MOC algorithms shall never lock. 

7.7.3. Similarity scores 

NIST must be able to read a similarity score from the card. NIST will not evaluate cards that produce only a 

verification decision. These requirements support computation of a full DET characteristic, the primary 

output of this test. NIST considers matching algorithms that produce only a small number of possible 

similarity values (naturally or otherwise) to be operationally less useful. 

Table 17 specifies return of a two-byte similarity score. Native matching scores outside the range [0,65535] 

should be internally remapped by the implementation. 

Table 16 – Command APDU for retrieval of verification similarity score 

Command Parameter Meaning

CLA

INS 

P1-P2 

‘00’

‘CB’ = GET DATA 

'3F FF' = Retrieve from anywhere in the current Dedicated File (Application DF) 

Lc field '03'

Data field '5C'

'01' 

'C0' Data Object identifier to be retrieved (two byte similarity score) 

Le field '04' (2+2) length of BER-TLV encoded data object to be retrieved

Table 17 – Response APDU for retrieval of verification similarity score 

Response Parameter NIST required values Meaning

Data field 'C0' Tag of the score data

'02' Length of the score value 

xx xx Score value 

Big-endian score from the 

last comparison on 

[0-65535] 

SW1-SW2 See ISO/IEC 7816-4

NOTE Using a proprietary tag ('C0') to retrieve the verification similarity score is a guarantee this information 

will not be available for card applications in operational mode because the information uses a tag which has a 

meaning for the test application only.

7.7.4. Prohibition of stateful behavior 

Although NIST is interested in template update as a potential means of improving operational performance, it 

is beyond the scope of this test. Any card that attempts update is likely to give answers different from those 

on produced in the Stage 2 PC testing, where template update is prohibited by 8.6.4. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 22 of 49

7.8. Reading card identifier 

Table 10 of ISO/IEC 7816-6:2004 provides a structure for card data under constructed data element tag '66'. 

This structure must be readable using the GET DATA APDU of Table 18. 

Table 18 – Command APDU for retrieval of Card identifier 

Command Parameter Meaning

CLA

INS 

P1-P2 

'00'

'CB' = GET DATA 

'3F FF' = Retrieve from anywhere in the current Dedicated File (Application DF) 

Lc field '03' length of command data field

Data field '5C'

'01' 

'66' Data Object identifier to be retrieved (Card Data) 

Le field '00'

For administration purposes and to identify the card under test, for example in MINEX II test reports, NIST will 

use the information contained in the response field of Table 19 which should contain a discretionary field, tag 

'73', containing the card version information in tag '88'. 

Table 19 – Response APDU for retrieval of Card identifier 

Response Parameter Meaning Minimal response value

Data field 73 06

 88 04 <4 byte CBEFF ID> 

SW1-SW2 See ISO/IEC 7816-4

7.9. Reading matcher identifier 

Table 12 of ISO/IEC 7816-6:2004 provides a structure for application related data under constructed data 

element tag '6E'. This structure must be readable using the APDU of Table 20 and Table 21. NIST shall 

include the result of this GET DATA whenever it identifies the algorithm, for example in MINEX II test reports. 

Table 20 – Command APDU for retrieval of Matcher identifier 

Command Parameter Meaning

CLA

INS 

P1-P2 

'00'

'CB' = GET DATA 

'3F FF' = Retrieve from anywhere in the current Dedicated File (Application DF) 

Lc field '03' length of command data field

Data field '5C'

'01' 

'6E' Data Object identifier to be retrieved (Application related data) 

Le field '00'

The response field should contain a discretionary field, tag '73', containing the matcher identifier in tag '99'. 

Table 21 – Response APDU for retrieval of Matcher identifier 

Response Parameter Meaning Minimal response value

Data field 73 06

 99 04 <4 byte CBEFF ID> 

SW1-SW2 See ISO/IEC 7816-4
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 23 of 49

8. PC-based API specification 

8.1. Overview 

This section describes the MINEX II API. It applies to the PC-based Stage 2 accuracy test outlined in section 

5.2. The material differences between the MINEX II API and that specified in Ongoing MINEX are as follows. 

― The INCITS 378 template shall conform to section 6.2. 

― The template generator is required to return the coordinates of a logical center, about which minutiae

pruning will be conducted. 

― The matchers must accept ISO-CC instances (not I378 instances). 

8.2. INCITS 378:2004 compliant templates 

All templates created shall conform to the specification of 6.2. NIST will test conformance of all generated 

templates using our own open-source code15. 

These shall contain the image quality value (line 17 of Table 4) that was input to the SDK by NIST, i.e. the 

SDK is not to generate this value. This value may be of use to template generators. The value shall be the remapped NIST NFIQ value given in Table 22. 

Table 22 – NFIQ Mappings 

Encoded NFIQ values to be passed as inputs to the template generator

NFIQ MINEX 04 800-76-1 MINEX II

1 100 100 100

2 75 80 80

3 50 60 60

4 25 40 40

5 1 20 20

"C" macros for finger quality are given in Annex E.

8.3. Submission 

Those wishing to participate in MINEX II testing shall provide NIST with those components identified in the 

Participation Classes given in section 5.8. Software shall be submitted as an SDK (Software Development Kit) 

library which complies with the API (Application Programmer Interface) specified in this document. Cards 

submitted to NIST shall be conformant to ISO/IEC 7816 and support the biometric functionality described in 

section 7. 

8.4. Testing interface 

8.4.1. Requirement 

MINEX participants shall submit an SDK which presents the "C" prototyped interface given in the following 

subsections. In MINEX II, Phase 1, the template generation function is optional. 

8.4.2. Minutiae extraction 

NIST will create templates using the SDK function call defined in Table 23. The function shall be capable of 

processing the image data specified in Annex C. 

Table 23 – MINEX create_template API Function 

Prototype INT32 create_template(

const BYTE *raw_image, 

const BYTE finger_quality, 

 

15 See http://www.itl.nist.gov/iad/894.03/nigos/biomdi.html
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 24 of 49

const BYTE finger_position,

const BYTE impression_type, 

const UINT16 height, 

const UINT16 width, 

UINT16 *xcenter, 

UINT16 *ycenter, 

BYTE *INCITS_378_template); 

Description This function takes a raw input image and outputs the corresponding I378 conformant template. The 

memory for the template is allocated before the call i.e. create_template() does not allocate memory for 

the result. The function returns either success (0) or failure (non-zero). Failure indicates a failure to enroll 

the image and will nevertheless result in the output of a I378 template with zero minutia. This will be used 

in subsequent comparisons. 

An error shall result in a template containing only the record and finger view headers. This number of

minutiae shall be set to 0, and no minutia data shall be present. The resulting template shall have length 

of 32 bytes (26-byte Record Header + 4-byte Finger View header + 2 bytes for the Extended Data Block 

length which shall be set 0x0000). All other fields in the Record and Finger View headers shall be set to 

their regular and accurate values. 

Input

Parameters 

raw_image The uncompressed raw image used for template creation.

finger_quality The quality of the fingerprint image (e.g. QUAL_GOOD).

finger_position The finger position code (e.g. FINGPOS_RI).

impression_type The impression type code (e.g. IMPTYPE_LP).

height The number of pixels indicating the height of the image.

width The number of pixels indicating the width of the image.

Output

Parameters 

xcenter Horizontal and vertical locations of a center point suitable for pruning to be 

used per section 9.4.3. If this functionality is not supported, the xcenter 

shall be set to the input width (i.e. outside the bounds of the image). 

ycenter

INCITS_378_template The output template, per Table 4

Return 

Value 

This function returns zero on success or a documented non-zero error code otherwise.

8.4.3. Minutiae matching 

One-to-one comparisons representative of single-finger verification attempts will be made using the function 

defined in Table 24. 

Table 24 – MINEX API match_templates function 

Prototype INT32 match_templates(

const BYTE *verification_template, 

const UINT16 verification_template_size, 

const BYTE *enrollment_template, 

const UINT16 enrollment_template_size, 

UINT16 *score); 

Description This function compares two Table 5 ISO-CC compliant templates and outputs a match score. The 

verification_template shall be compared to the enrollment_template (in that order where the 

underlying matcher is order dependent). 

The returned score is an integer representing the similarity of the parent fingerprint images. It should 

not be artificially quantized. NIST will allocate memory for this parameter before the call. When the 

function is called with either or both templates containing zero minutiae (see 6.6) the function shall

assign the value 0 to the score, then return a documented error code (see 8.6.3 below). 

Input 

Parameters 

verification_template A Table 5 template from create_template() as processed by NIST 

according to the verification BIT. 

verification_template_size The size, in bytes, of the input verification template 0 ≤ N ≤ 384

enrollment_template A Table 5 template from create_template() as processed by NIST 

according to the enrollment BIT. 

enrollment_template_size The size, in bytes, of the input enrollment template 0 ≤ N ≤ 384

Output

Parameters 

score A similarity score resulting from comparison of the templates, on the 

range [0,65535]. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 25 of 49

Return Value This function returns zero on success (i.e. a valid score is produced) or a documented non-zero error 

code on failure. 

8.4.4. Implementation identifiers 

The implementation shall support the function of Table 25 to identify itself. 

Table 25 – MINEX API get_pids function 

Prototype INT32 get_pids(

UINT32 *template_generator, 

UINT32 *template_matcher); 

Description This function retrieves CBEFF PIDs which identify the SDK’s supported core template generator and 

template matcher. Both PIDs shall be four-byte fields conforming to the CBEFF Product Identifier (PID) 

requirements of clause 6.4.4 of INCITS 378:2004. These state that 

― The two most significant bytes of the field indicate the (corporate) owner. It is a hexadecimal 

integer assigned by the IBIA (per the requirement of clause 6.5.12.1 of ISO/IEC 19785-1:2006). 

― The least two significant bytes are an owner-assigned version number. 

The memory for the template generator and matcher parameters will be allocated by NIST before the 

call. 

If the SDK does not include a template_generator, the returned value shall be zero. 

Output

Parameters 

template_generator

template_matcher 

A PID which identifies the SDK’s minutiae extractor

A PID which identifies the SDK’s matcher. 

Return Value This function returns zero on success or a documented non-zero error code on failure. In the latter 

case, both output parameters shall be set to 0. 

8.5. Software and Documentation 

8.5.1. SDK Library and Platform Requirements 

Participants shall provide NIST with binary code only (i.e. no source code) − supporting files such as header 

(“.h”) files notwithstanding. Such files shall not contain intellectual property of the company nor any 

material that is otherwise proprietary. It is preferred that the SDK be submitted in the form of a single static 

library file (ie. “.LIB” for Windows or “.a” for Linux). However, dynamic/shared library files are permitted. 

If dynamic/shared library files are submitted, it is preferred that the API interface specified by this document 

be implemented in a single “core” library file with the base filename ‘libminex’ (for example, ‘libminex.dll’ 

for Windows or ‘libminex.so’ for Linux). Additional dynamic/shared library files may be submitted that 

support this “core” library file (i.e. the “core” library file may have dependencies implemented in these 

other libraries). 

8.5.2. Linking 

NIST will link the provided library file(s) to a C language test driver application (developed by NIST) using 

― For windows, version 3.3.3 of the GCC compiler will be used under Cygwin; 

― For RedHat Linux 7.3 platforms, version 2.96 of GCC will be used. 

All GCC compilers use libc. The link command might be "gcc –o mintest mintest.c -L. –lminex" 

Participants are required to provide their library in a format that is linkable using GCC with the NIST test 

driver, which is compiled with GCC. All compilation and testing will be performed on x86 platforms running 

either Windows 2000 or Red Hat Linux 7.3 (dependent upon the operating system requirements of the SDK). 

Thus, participants are strongly advised to verify library-level compatibility with GCC (on an equivalent 

platform) prior to submitting their software to NIST to avoid linkage problems later on (e.g. symbol name and 

calling convention mismatches, incorrect binary file formats, etc.). 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 26 of 49

NOTE Dependencies on external dynamic/shared libraries such as compiler-specific development 

environment libraries are discouraged. If absolutely necessary, external libraries must be provided to NIST 

upon prior approval by the Test Liaison. 

8.5.3. Installation and Usage 

The SDK must install easily (i.e. one installation step with no participant interaction required) to be tested, 

and shall be executable on any number of machines without requiring additional machine-specific license 

control procedures or activation. 

The SDK’s usage shall be unlimited. The SDK shall neither implement nor enforce any usage controls or limits 

based on licenses, execution date/time, number of executions, presence of temporary files, etc. 

It is recommended that the SDK be installable using simple file copy methods, and not require the use of a 

separate installation program. Contact the Test Liaison for prior approval if an installation program is 

absolutely necessary. 

8.5.4. Documentation 

Participants shall provide complete documentation of the SDK and detail any additional functionality or 

behavior beyond that specified here. The documentation must define all error and warning codes (see 8.6.3). 

8.5.5. Modes of operation 

Individual SDKs provided shall not include multiple “modes” of operation, or algorithm variations. No switches 

or options will be tolerated within one library. For example, the use of two different “coders” by a minutiae 

extractor must be split across two separate SDK libraries, and two separate submissions. 

8.6. Runtime behavior 

8.6.1. Speed 

The following limits are instituted to constrain NIST's total MINEX II computational workload. 

― The mean template match operation shall not exceed 10 milliseconds. 

― The mean template creation operation shall not exceed 1.2 seconds (using a 2GHz Pentium IV). 

8.6.2. Interactive behavior 

The SDK will be tested in non-interactive “batch” mode (i.e. without terminal support). Thus, the submitted 

library shall not use any interactive functions such as graphical user interface (GUI) calls, or any other calls 

which require terminal interaction e.g. reads from “standard input”. 

8.6.3. Error codes and status messages 

The SDK will be tested in non-interactive “batch” mode (i.e. without terminal support). Thus, the submitted 

library shall run quietly, i.e. it should not write messages to "standard error" and shall not write to “standard 

output”. Instead, the SDK shall conform to the error notification procedures of Annex D. 

8.6.4. External communication 

Processes running on NIST hosts shall not write any data to external resource (e.g. server, file, connection, or 

other process) other than those explicitly allowed in this document. 

8.6.5. Stateful behavior 

All components in this test shall be stateless and idempotent. No component of the test is permitted to 

maintain state information. This applies to template generation and matching, and to on-card and off-card 

activity. NIST will institute appropriate tests to detect stateful behavior in the activities mentioned in the 

following subsections. If detected, NIST will cease evaluation and inform the provider. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 27 of 49

NOTE NIST is prohibiting template adaptation, and will accordingly implement checks to detect any stateful 

behavior and side-effects. However NIST is interested in template update as a potential means of improving 

operational performance, but it is beyond the scope of this and foreseeable testing efforts. 

9. NIST conversion of I378 to ISO-CC templates 

9.1. Background 

NIST intends to maintain its use of the I378 standard as a primary format for off-card storage of minutia 

templates. NIST recognizes the advantages of ISO-CC for on-card storage or matching. Although the two 

kinds of templates differ, the accuracy implications seem to be limited - see the Annex A simulation of the 

impact on matching accuracy. 

9.2. Presence of BITs on card 

Each submitted card shall be populated with one or two BITs per section 7.6. These shall be treated as readonly data. These shall be supplied in the structure given in Table 13 which leverage the BIT and BIT grouping 

structures of ISO/IEC 7816-11:2004 (Tables 1 and 2). 

The BITs parameterize the production of templates that a reader, or other system, should send to the 

requesting card: For a reference template TR, a verification template TV, and a PC or card-based matcher, 

M, the test will compare BIT-processed versions of the templates to produce a similarity score 

s = M(BR(TR), BV(TV)) 

where BR and BV denote the functions representing the BIT parameterization. 

Operationally the BIT parameters (e.g. maximum number of minutiae) might be sent as inputs to a template 

generator. NIST does not intend to do this because such specialization would be computationally prohibitive 

in the context of an interoperability test16. Instead, NIST proposes to standardize the minutiae template 

reduction process as follows. 

9.3. Use of BITs 

NIST will treat on-card and off-card matcher implementations identically. This means that the BITs read from 

the card will be used to parameterize BOTH the conversion of templates sent to the card and to the PC-based 

match operation. 

The conversion operation proceeds with a pruning operation (sec. 9.4.3), a sorting operation (sec. 9.5), and a 

re-encoding (sec. Annex A.1). NIST will conduct this operation using its own software which 

― exists within a larger standard biometric data interchange software distribution named BioMDI, 

― is entirely open source17 ISO/IEC 9899:1999 "C" code, 

― is available for download and cooperative development18 in the open-source model, and 

― is under formal version control19. 

Figure 1 – Conversion of INCITS 378 to ISO-CC 

 

16 For example, if a test used T templates, N template generators and C cards, imposes the requirement to execute 

O(TNC) image-to-template generations. 

17 See the license at http://www.itl.nist.gov/iad/894.03/nigos/NIGOS_licdis_061906.pdf 

18 The software is available at http://www.itl.nist.gov/iad/894.03/nigos and maintained using a Perforce version control 

system, at http://www.perforce.com/, for which clients are freely available. While a nightly zip/tar-archive is 

produced, users should subscribe to NIST's open-source server because it automatically sends email notifications of any 

changes to the software. 

19 Users need to register http://www.itl.nist.gov/iad/894.03/nigos/NIGOS_User_Registration.pdf and may then access the 

code branches using a client such as P4V at http://www.perforce.com/perforce/products/p4v.html. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 28 of 49

The items in parentheses are the names of executables present in NIST's BioMDI distribution. 

9.4. Number of minutiae 

9.4.1. Limits on number 

NIST's considers that its role is not to impose algorithmic constraints. However the minimum and maximum 

numbers of minutia a card may accept are regulated as follows 

― The one-byte value implies a range of [0,255], 

― Because some templates will naturally contain 0 minutia (see FTA in section 6.6), minimum values will be 

ignored, 

― NIST imposed a 128 minutia maximum in all prior MINEX trials. This is arguably too high given that MINEX 

04, which used four large operational single index finger flat-impression datasets, found that the leading 

systems produced a median of 41 minutiae from each image with the 5% and 95% quantiles being 24 and 

61 respectively. 

― A T=0 APDU command constrains the maximum number of three-byte minutia to 83. Note that T = 0 is 

not required by NIST. 7816 command chaining will be attempted for larger templates, as necessary. 

― Informative Annex D.1.1 of ISO/IEC 19794-2 recommends the minimum number of minutiae for enrollment 

to be 16, and for verification, 12. It also recommends the maximum number of minutiae for enrollment 

and verification is 60. NIST notes that these are recommendations only, but otherwise takes no 

immediate position on the appropriateness of these numbers beyond the information presented in 

Annex A. 

9.4.2. Effect of the BIT 

NIST will send single-view templates to the PC-based and card-based matching implementations. The 

reference and verification templates shall be parameterized by their respective BITs, as follows. If,

― the value indicated in the BIT for the minimum number of minutiae is 0 ≤ N ≤ 255, 

― the value indicated in the BIT for the maximum number of minutiae is 0 ≤ M ≤ 255, 

― the number of minutia present in a (generally third-party) verification template is K, then 

― the number of minutia NIST will send to the card is denoted by S where 

S = {

M if K ≥ M 

K if K < M 

K if K < N 

Input

Image 

INCITS 378 

template 

Vendor X 

generator

Angle Quantization 8 → 6 bits

(fmr2fmr) 

(x,y) 197 → 100 pix cm-1

(fmr2fmr) 

ISO-CC 

template 

Prune on Q and Position 

(fmrprune) 

Sort 

(fmrsort) 

NIST supplied component

BIT Parameters 

Vendor supplied component

Vendor Y card 

Vendor Y

 PC based .so or .dll 

BER-TLV 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 29 of 49

Note that the BIT parameter N is ignored. This is necessary because some input templates will inevitably 

have zero minutiae. The matcher shall execute successfully when either or both of the input templates

contains fewer than N minutiae20. 

NIST will reject cards for which N > M. 

9.4.3. Pruning mechanism 

When a MOC implementation indicates the capability to take no more than M minutiae, NIST proposes to 

follow a refined version of the guidance given in the last paragraph of clause 8.3.1 of ISO/IEC 19794-2:2005: 

Specifically NIST intends to replace the requirement to use the convex hull, with a method based on the 

distance of a minutia from a center. This is based on the ISO/IEC 19794-2 subclause 8.3.4 guidance for polar 

ordering. 

Thus given a I378 template containing K minutiae and a BIT request for no more than M minutiae our software 

will remove K - M minutiae as follows. 

Minutiae with the lowest quality value are removed first. If two or more minutia have an equal quality value, 

then the one with the largest value of the integer quantity 

r

2

 = (x – xc)

2

 + (y – yc)

2

is removed. Finally if those values are tied, then the ISO/IEC 19794-2:2005 polar ordering instruction to 

prioritize small angle minutiae is applied. 

NIST understands that the ISO/IEC 19794-2:2005 material on polar coordinates is intended for sorting, not 

pruning, but considers the convex hull approach to be complex, and potentially harmful effects. 

9.4.4. Pruning center 

In MINEX II, all I378 template generators may additionally report the coordinates of an appropriate center 

about which pruning should be conducted. Earlier versions of this test specification established the minutia 

means (center-of-mass) for (xc, yc), per the ISO/IEC 19794-2:2005 sorting guidance. However, this may be 

particularly inappropriate when large numbers of minutia are reported in a noisy part of the image. 

NIST will conduct pruning about 

― the center coordinates from the template generator, if supplied, otherwise 

― the center of mass, per the ISO standard. 

9.4.5. Pruning priority 

It is clear that a quality algorithm producing many levels of quality will cause the pruning operation to prune 

on r2 only occasionally. Conversely, a quality algorithm producing few levels of quality will cause r2 pruning 

to be more dominant. An implementer should not supply quality values that are dependent solely of r2

because this contradicts the true-minutia requirement of section 6.2.2. 

 

20 An unappealing alternative would be to fill with N-K randomly generated minutiae. 

If the number of minutiae exceeds the maximum number processible by a card, 

truncation is necessary. The truncation is a 2 step process. At first, finger minutiae 

of poor quality are eliminated. If still too many minutiae are there, then truncation 

shall be made by peeling off minutiae from the convex hull of the minutiae set and 

before sorting into the order required by the card.
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 30 of 49

9.5. Sort order of minutiae 

9.5.1. Support for ordering 

Although template generators are likely to produce templates whose minutiae have an arbitrary order, the 

ISO-CC standard defines several geometric orderings of the minutia. The x-y and y-x sorting methods support 

extension of the spatial range of a fingerprint (e.g. for rolled prints) in one dimension. The polar method 

supports a center-first sort. 

Currently NIST intends to support at least the unsorted, Cartesian y-x, Cartesian x-y and polar sorting 

methods, because the standard defines these as options. NIST published open-source "C" code which is 

maintained here http://www.itl.nist.gov/iad/894.03/nigos/biomdi.html and is called by our MOC application 

here http://www.itl.nist.gov/iad/894.03/nigos/biomapp.html. NIST does not intend to accept commercial 

code for this purpose, although we may institute a conformance test for implementations that do. 

However, NIST is aware that commercial readers will need to include such software in addition to the pruning 

software. This adds complexity and a "degree of freedom" that would better be handled as a natural property 

of the matching algorithm. Although NIST notes the European Citizen Card specification, CEN/TS 15480-2, 

requires implementations to accept arbitrarily sorted data, NIST prefers not to ignore the SC37/WG3 intent to 

allow sorting. NIST does consider that the exact requirements of ISO/IEC 19794-2 clause 8 are unclear. 

9.5.2. Modulo sorting for large images 

Note that archival imagery used in all planned MINEX evaluations is at most 500 pixels in width and height, 

and is scanned at 19.7 pixels mm-1, and therefore all possible minutiae coordinates can be encoded in 8 bits 

without modulo sorting (or removal). 

The ISO/IEC 19794-2:2005 standard needs modification, see Annex F.1. 

9.6. Ridge count, core and delta and zonal quality information 

The ISO/IEC 19794-2:2005 standard allows the BIT to indicate the "extended data" defined in clause 7.5 of 

that standard. However in Table 13, the binary value 00000000b indicates that ridge count, core and delta 

and zonal quality information are out of the scope of this test. Suppliers must adhere to the zero 

specification here. 

NIST is interested in possible performance improvement associated with the use of richer templates, but past 

experience with INCITS 378 extensions (MINEX 04) has not suggested large improvements are available. 

However NIST will, on request from any interested party, consider conducting tests of templates that include 

extended data. Particularly, what benefits would zonal quality allow beyond that associated with a 

(calibrated) minutia quality value. 

10. References 

[1] C. Wilson et al., “Biometric Data Specification for Personal Identity Verification,” NIST Special Publication 

800-76-1 http://csrc.nist.gov/publications/nistpubs/800-76-1/SP800-76-1_012407.pdf 

[2] P. Grother et al., “Performance and Interoperability of the INCITS 378 Template,” NIST IR 7296 

http://fingerprint.nist.gov/minex04/minex_report.pdf

[3] E. Tabassi et al. “Finger Print Image Quality,” NISTIR 7151 2004 (Gaithersburg, MD: National Institute of 

Standards and Technology, August 2004) http://www.itl.nist.gov/iad/894.03/quality/reports/ir_7151.pdf

[4] American National Standard for Information Technology – Finger Minutiae Format for Data Interchange, 

ANSI/INCITS 378-2004, www.incits.org
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 31 of 49

Annex A 

Comparison of the INCITS 378 and ISO/IEC 19794-2 standards 

CBEFF Format Owner = 0101 for ISO/IEC JTC 1/SC 37. 

CBEFF Format Type = 0005 for ridge endings encoded as valley bifurcation points, as in INCITS 378. 

The INCITS 378 standard's record format and the ISO/IEC 19794-2 compact card format differ syntactically 

and semantically. These differences are presented in the next two subsections. Thereafter we address the 

implications for transcoding between the standards, and the MINEX requirements. 

A.1 Syntactic differences 

The INCITS 378:2004 and ISO-CC templates differ as follows. In ISO-CC 

― the (x,y) coordinates are encoded in 8 bits as opposed to 14 bits, 

― the spatial resolution is fixed at 10 pixels per millimeter as opposed to variable resolution, 

― the angle is encoded in 6 bits as opposed to 8 bits, and 

― the minutia quality value is absent. 

These differences are depicted in Table 26. Note that ridge count and core and delta information is not 

being evaluated in this test, and therefore the BIT entry defined in ISO/IEC 19794-2 Table 14, shall be set to 

0, and ignored. 

Table 26 – Minutia encodings of the ISO-CC and INCITS 378 

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6

ISO/IEC 19794-2 Compact Card Format x coord. y coord. t angle

8 8 2 6

ISO/IEC 19794-2 Record Format and 

INCITS 378 

t x coord. r y coord angle quality

2 14 2 14 8 8

t = type r = reserved 

A.2 Semantic differences 

The abbreviated 8 bit (x,y) encodings in the ISO-CC standard support "typical" single-finger images by

specifying a hard-wired resolution of 10 pixels per millimeter (ISO/IEC 19794-2, subclause 8.2). This is 

approximately half of typical enrollment data gathered on 500 ppi (19.7 pixels per millimeter) optical

scanners. This is summarized in Table 27. The effect would be that minutia can not extend over a region 

larger than 255 / 10 = 25.5 mm. However the ISO-CC standard provides for coordinate wraparound wherein 

the minutia coordinates are sorted such that the actual value may extend beyond the range by encoding it as 

x mod 256. Reconstruction of the actual value is possible because sorting is applied. 

Table 27 – Minutia location quantization of ISO-CC and INCITS 378 templates 

Standard Allowed values 

(units) 

Allowed values (mm) Allowed values (mm), 

at 500 ppi 

INCITS 378:2004 record format [0,16383] Depends on the 

encoding resolution 

[0, 0.051, 0.1015, 

0.1523, ..., 831.6] ISO/IEC 19794-2 record format

ISO/IEC 19794-2 compact card [0,255] [0, 0.1, 0.2 ... 25.5] N/A

As shown in Table 28, the three different angular encodings support minutia encodings of varying precision. 

Whether this difference materially affects performance is dependent on the sensitivity of the matching

algorithm, and on how accurately template generators measure the angle. 

Table 28 – Minutia angle quantization of ISO-CC and INCITS 378 templates 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 32 of 49

Standard Allowed values 

(units) 

Quantization 

Degrees per unit Radians per unit

INCITS 378:2004 record [0,179] 360 / 180 = 2 2pi / 180 = 0.0349

ISO/IEC 19794-2 record [0,255] 360 / 256 = 1.4063 2pi / 256 = 0.0245

ISO/IEC 19794-2 compact card [0,63] 360 / 64 = 5.625 2pi / 64 = 0.0982

A.3 Simulation protocol 

To quantify the effects of the ISO-CC encoding vs. the INCITS 378 record format, NIST simulated the 

production of ISO-CC templates by quantizing the coordinates and angles in sets of INCITS 378 templates 

produced in NIST's existing MINEX testing. 

Figure 2 - Use of INCITS 378 for simulation of ISO-CC accuracy 

The C code fragments to effect these transformations are shown in Table 29. This code is part of the 

"fmr2fmr" program distributed21 by NIST as part of a suite of libraries and applications that support various 

INCITS and ISO biometric data interchange standards. 

Table 29 – Source code for conversion of INCITS 378 to ISO-CC 

Angular re-quantization

// The ISO minutia record has 6 bits for the angle, so 

// we have 64 possible values to represent 360 degrees. 

for (m = 0; m < mcount; m++) // for all minutiae 

{ 

 const int theta = 2 * (int)fmds[m]->angle; // 378 has 2 degrees 

 const double isotheta = round((64.0 / 360.0) * (double)theta); // CC has 5.625 deg 

 fmds[m]->angle = (unsigned char)round(((360.0 / 64.0) * isotheta) / 2.0); // Put back in 378 

} 

Spatial re-quantization

for (m = 0; m < mcount; m++) // for all minutiae

{ 

 const double x = (double)fmds[m]->x_coord; // cast from unsigned short 

 const double y = (double)fmds[m]->y_coord; // cast from unsigned short 

 const double xmm = 10.0 * x / (double)xres; // millimeters, because INCITS 378 resolution 

 const double ymm = 10.0 * y / (double)yres; // values are in pixels per centimeter 

 const double xunits = xmm / 0.1; // units of 0.1 pix per mm which is the CC 

 const double yunits = ymm / 0.1; // card format's hardwired sampling freq 

 const unsigned short xcc = 

 (unsigned short)(0.5 + xunits); // round the value - this is what would be 

 const unsigned short ycc = // stored in "typical" say 500 dpi operation 

 (unsigned short)(0.5 + yunits); 

 fmds[m]->x_coord = (unsigned short)((double)xcc * (double)xres * 0.01); // Now put back 

 fmds[m]->y_coord = (unsigned short)((double)ycc * (double)yres * 0.01); // in 378 format 

} 

 

21 This is available for download; see http://www.itl.nist.gov/iad/894.03/nigos/biomdi.html

Enrollment 

Image 

INCITS 378 

template 

Vendor X 

generator

Angle

8 → 6 bits

(x,y)

197 → 100 

pix cm-1

INCITS 378 

template 

Vendor X 

matcher

Verification

Image 

INCITS 378 

template 

Vendor X 

generator

Angle

8 → 6 bits

(x,y)

197 → 100 

pix cm-1

INCITS 378 

template 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 33 of 49

We took five vendors and applied their matchers to INCITS 378 templates derived from the outputs of that 

vendor's template generator. They are applied natively, that is to enrollment and verification templates 

from the same supplier's INCITS 378 generator. The five matching algorithms, identified in the first columns, 

are some of the more accurate ones assessed in the Ongoing MINEX evaluation. 

All results apply to single finger matching using the POEBVA collection of left and right index fingers, as used

in the Ongoing MINEX evaluation. The FNMR computation is conducted over 15 disjoint sets each containing 

16000 genuine scores. The FMR computation is likewise conducted over 15 disjoint sets each containing

16000 impostor scores. 

A.4 Results after re-quantization of angle and position 

Table 30 gives the change in FNMR when the matcher operating threshold is set to achieve FMR values of 0.01 

on INCITS 378 templates and then reset to achieve those FMRs on ISO-CC templates. This thresholding 

strategy is representative of the situation where thresholds can be set for the ISO-CC template independently 

of any INCITS 378 matcher trial or calibration. 

Table 30 – Relative accuracy of ISO-CC and INCITS 378 templates (Fixed FMR) 

Base FMR Base FNMR Change in FNMR

A1 0.01 0.0140 0.0005 +/- 0.0006 p 2e-03

A2 0.01 0.0158 0.0018 +/- 0.0007 p 3e-08

A3 0.01 0.0133 0.0007 +/- 0.0007 p 2e-03

A4 0.01 0.0183 0.0006 +/- 0.0005 p 6e-05

A5 0.01 0.0159 0.0008 +/- 0.0005 p 9e-05

Table 31 gives changes in FMR and FNMR when the matcher operating threshold is set to achieve FMR values 

of 0.01, on the unaltered INCITS 378 templates. This thresholding strategy is representative of the situation 

where a ISO-CC template is sent, with transcoding, to an INCITS 378 matcher. 

Table 31 – Relative accuracy of ISO-CC and INCITS 378 templates (fixed t) 

Change in FMR and FNMR when ISO-CC encoding is synthesized from instances of the INCITS 378 record format 

"MIN:A" templates. 

Base FMR Change in FMR Base FNMR Change in FNMR

A1 0.01 -0.0013 +/- 0.0008 p 7e-06 0.0140 0.0008 +/- 0.0008 p 5e-04

A2 0.01 -0.0008 +/- 0.0011 p 1e-02 0.0158 0.0020 +/- 0.0007 p 4e-09

A3 0.01 -0.0006 +/- 0.0008 p 6e-03 0.0133 0.0007 +/- 0.0006 p 5e-04

A4 0.01 -0.0004 +/- 0.0006 p 1e-02 0.0183 0.0007 +/- 0.0007 p 7e-04

A5 0.01 -0.0008 +/- 0.0009 p 1e-03 0.0159 0.0010 +/- 0.0008 p 1e-04

Thus when going from INCITS 378 to ISO-CC 

― Table 30 shows small but statistically significant increases in FNMR. The worst case is A2 whose FNMR

goes from 0.0158 to 0.0176 at a FMR of 0.01 corresponding to about 11% more missed matches. 

― At a fixed threshold for both kinds of template, Table 31 shows small that FMR is slightly but significantly 

lower for ISO-CC than for INCITS 378, but that FNMR is again higher. 

The presence of an algorithm-effect (some implementations are more sensitive than others, viz. A2 over A3, 

means that vendors should consider this issue for their implementations. 

NOTE The change in performance for less accurate matchers and template generators has not been studied. 

A.5 Results after reduction in number of minutiae 

The plots of Figure 3 show the effect of apply the pruning operation of section 9.4.3 to raw INCITS 378 (not 

ISO-CC) templates. The effect on accuracy is shown for the same five leading matcher providers as used 

above. The matchers are applied natively i.e. the matcher from provider X is applied to compare templates 

from X's generator. For each matcher, the threshold is set to the value that gives a FMR of 0.001 on the 

entire unpruned corpus. The error rates are then recomputed after removing zero or more minutia to 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 34 of 49

achieve a maximum of N in each template. The top graph shows the effect of retaining all minutiae in the 

enrollment template and minutiae in the verification template. The lower graph shows the effect of pruning 

both. 

The conclusions are 

― FNMR increases for all matchers algorithms, with approximately 60 minutia being a reasonably "lossless" 

value. Note that the 95% percentiles for number of minutiae are 60, 65, 60, 64, and 63. 

― FNMR has increased by an order of magnitude (from ~2% to ~20%) when fewer than 20 minutia are used. 

― FMR values also change significantly, beginning at the same 60 minutiae breakpoint, and substantially 

below about 20 minutiae. Some systems improve (decline in FMR) and some degrade (increase in FMR). 

NIST is concerned that any increase in FMR associated with transactions involving small numbers of 

minutiae is a security hazard. 

Not shown here is distributional information on the numbers of minutiae produced by template generators. 

NIST has observed variation in the numbers found from a single image. Also not shown are interoperable 

results (cross-vendor) and NIST suggests that an incorrect conclusion from the graphs would be that template 

generators finding more minutiae are better performing. 

A.6 Conclusions 

The ISO-CC template can offer performance approaching that of the INCITS 378 template. However, some 

implementations exhibit degraded performance. This study, however, only approximates actual ISO-CC 

performance because providers may be able to improve algorithmic functionality if they specifically know the 

target result is ISO-CC. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 35 of 49

Figure 3 – Effect of minutia pruning on FNMR (above) and FMR (below) 

Maximum number of minutiae after polar pruning of just the verification template

FNMR

0.1

0.05

0.01

0.005

0.001

0.0005

FMR

 10 20 50 100

FNMR

0.1

0.05

0.01

0.005

0.001

0.0005

FMR

Maximum number of minutiae after polar pruning both verification and reference templates
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 36 of 49

Annex B 

Three-way interoperability 

NIST anticipates that some cards embed fingerprint matchers that are not accompanied by an associated 

template generator, and may well be used with enrollment and verification templates coming from two 

different sources. That is card-based matcher, M, will compare a reference template produced by X with a 

verification template from Y. NIST will evaluate three-way interoperability in this test. MINEX participants 

should be aware that the MINEX 04 measurements of Figure 4, show three-way interoperability (green) will 

generally offer poorer performance 

― than in two-way (cyan) or native (horizontal bar) cases, and 

― in situations (matchers 1 and 4) in which the provider of a matcher supplies a template generator that is 

less effective than its peers. 

Figure 4 – Native vs. Two-way vs. Three-way Interoperability 

Matcher 1 Matcher 2 Matcher 3 Matcher 4 Matcher 5

The notation here, MXY, denotes use of matcher supplier M, with template generator suppliers X and Y. The 

values plotted are FNMR values at FMR = 0.01 for five leading matcher providers executing left and right 

single-finger matches of INCITS 378 templates. The matchers are paired with the best seven different 

template generators found in MINEX 04. 

NIST acknowledges that not requiring a card/matcher provider to team with a template generator provider is 

inconsistent with the requirement in section 5.6 to require pairing of card and matcher combinations. 

However this seeming inconsistency is undertaken in light of the following: 

― Cards and matching algorithms may well be bound at time of manufacture; 

Native MMM Two way 

MMX or MXM 

Same TG 

MXX 

Three way 

MXY 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 37 of 49

― Cards and reference templates are bound at time the card issuance or IDMS software was shipped by an 

integrator; 

― Although software matcher implementations (e.g. Java applets) exist (and are eligible for testing) and

these could be selected during integration or even issuance, they are reported to run significantly more 

slowly. 

Further NIST is motivated by a desire to improve performance, both in this evaluation and in fielded 

operation. Given that NIST has demonstrated that some template generators are better than others, NIST 

seeks to measure card-matcher-template generator compatibility. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 38 of 49

Annex C 

Input fingerprint image specifications 

C.1 Format 

The SDK must be capable of processing fingerprint images supplied to the SDK in uncompressed raw 8-bit (one 

byte per pixel) grayscale format. Each image shall appear to have been captured in an upright position and 

approximately centered horizontally in the field of view. The image data shall appear to be the result of a 

scanning of a conventional inked impression of a fingerprint. Figure 1 illustrates the recording order for the 

scanned image. The origin is the upper left corner of the image. The x-coordinate (horizontal) position shall 

increase positively from the origin to the right side of the image. The y-coordinate (vertical) position shall 

increase positively from the origin to the bottom of the image. 

Figure 5 – Fingerprint image raster scan order 

Raw 8-bit grayscale images are canonically encoded. The minimum value that will be assigned to a "black" 

pixel is zero. The maximum value that will be assigned to a "white" pixel is 255. Intermediate gray levels will 

have assigned values of 1- 254. The pixels are stored left to right, top to bottom, with one 8-bit byte per 

pixel. The number of bytes in an image is equal to its height multiplied by its width as measured in pixels; 

there is no header. The image height and width in pixels will be supplied to the SDK as supplemental 

information. 

C.2 Resolution and dimensions 

All images for this test will employ 500 PPI resolution (horizontal and vertical). 

The dimensions of the fingerprint images will vary from 150 to 812 pixels in width, and 166 to 1000 pixels in 

height. 

Note – the SDK must be capable of processing images with any dimensions in these specified ranges without 

the use of separately invoked cropping or padding facilities. For example, SDKs which require cropping of 

large images must do so internal to the operation of the create_template (see below) API call. 

C.3 Sensor and impression types 

All images used for testing in MINEX come from the POEBVA data set described in NISTIR 7296 [2] (see 

Appendix B, Table 23 page 47) and thus have been obtained from live-scan sensors (Smiths-Heimann ACCO 

1394 and Cross Match 300A). All images tested in MINEX are plain impression type images. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 39 of 49

Annex D 

Error Codes and Handling 

Each participant shall provide their SDK with text documentation of all (non-zero) error or warning return 

codes (see section 8.5.4, Documentation). 

The application should include error/exception handling so that in the case of a fatal error, the return code is 

still provided to the calling application. 

At minimum the return codes of Table 32 shall be used. 

Table 32 – MINEX API return codes 

Return 

code 

Explanation

0 Success

1 Image size not supported

2 Failed to extract minutiae – unspecified error

3 Failed to extract minutiae – impression type not supported

4 Failed to match templates – null probe or gallery template

5 Failed to match templates – unable to parse probe template

6 Failed to match templates – unable to parse gallery template

All messages which convey errors, warnings or other information shall be suppressed. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 40 of 49

Annex E 

Predefined SDK Constants 

E.1 Pre-defined values 

The pre-defined values (constants) of Table 33 are for use in specifying parameters to the MINEX testing 

interface: 

Table 33 – MINEX API predefined values 

// Finger quality values

#define QUAL_POOR 20 // NFIQ value 5 

#define QUAL_FAIR 40 // NFIQ value 4 

#define QUAL_GOOD 60 // NFIQ value 3 

#define QUAL_VGOOD 80 // NFIQ value 2 

#define QUAL_EXCELLENT 100 // NFIQ value 1 

// Finger position codes

#define FINGPOS_UK 0x00 // Unknown finger 

#define FINGPOS_RT 0x01 // Right thumb 

#define FINGPOS_RI 0x02 // Right index finger 

#define FINGPOS_RM 0x03 // Right middle finger 

#define FINGPOS_RR 0x04 // Right ring finger 

#define FINGPOS_RL 0x05 // Right little finger 

#define FINGPOS_LT 0x06 // Left thumb 

#define FINGPOS_LI 0x07 // Left index finger 

#define FINGPOS_LM 0x08 // Left middle finger 

#define FINGPOS_LR 0x09 // Left ring finger 

#define FINGPOS_LL 0x0A // Left little finger 

// Impression type codes

#define IMPTYPE_LP 0x00 // Live-scan plain 

#define IMPTYPE_NP 0x02 // Nonlive-scan plain 

Note that the finger position codes differ in the fingerprint standards, and the smart-card standards.

For all interactions with the card ISO/IEC 7816-11:2004 finger position codes shall be used. For all 

interactions with PC-based implementations ISO/IEC 17994-2:2005 finger positions shall be used. NIST will 

transcode any values using the Table 34 associations whenever needed. The table summarizes the two base 

standards and is included here for informative purposes only. 

Table 34 - ISO/IEC 19794-2 and ISO/IEC 7816-11 finger position codes 

Finger ID

Biometric subtype 

ISO/IEC 19794-2:2005 ISO/IEC 7816-11:2004

Binary value Hex Value Binary value Hex Value

No information given 00000b 00 00000b 00

right thumb 00001b 01 00101b 05

right index 00010b 02 01001b 09

right middle 00011b 03 01101b 0D

right ring 00100b 04 10001b 11

right little 00101b 05 10101b 15

left thumb 00110b 06 00110b 06

left index 00111b 07 01010b 0A

left middle 01000b 08 01110b 0E

left ring 01001b 09 10010b 12

left little 01010b 0A 10110b 16
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 41 of 49

Annex F 

Ambiguities in the standards 

F.1 Compact card sorting 

The last line of ISO/IEC 19794-2:2005 clause 8.3.4 "The same construction principle may be applied also for 

the Y coordinate" should be changed to "The same construction principle may alternatively be applied to the 

Y coordinate. Using this construction on X and Y together is not possible." 

Clause 8.3.4 is very long. To enable easy citation of the standard, it needs to be broken up into named (or 

even umnamed) subparagraphs. 

The text in ISO/IEC 19794-2:2005 Table 14 second-to-last line references subclause "8.33" which should be 

"8.3.4". 

F.2 Unique minutia 

There should be a normative requirement for minutia (x,y,theta) triples to be unique. The issue of requiring 

unique (x,y) values seems to be in conflict with the reporting of trifurcations which would have same (x,y). 

F.3 No support for placing reference data on the card 

ISO/IEC FDIS 19785-3:2007(E) establishes the CBEFF TLV-encoded CEBFF patron format for the tag associated 

with biometric subtype data (in this case finger position). This value is '82'. Neither ISO/IEC 7816-11:2004, 

nor ISO/IEC 19794-2:2005 include normative specifications for this location. However, there is no 

standardized mechanism for finger position information to be sent to the card when storing a reference

template. Indeed, none of the relevant standards advance a normative prescription for a ISO/IEC 7816-

4:2005 command for this purpose. Yes, ISO/IEC 7816-11:2004 includes the use of a CHANGE REFERENCE DATA 

command as an example in informative Annex B, but that text does not advance a method for passing the 

biometric subtype to the card. 

NIST sees the lack of a standardized command as an impediment to MINEX II (see discussion in section 7.5). 

NIST sees the lack of a standardized mechanism for transmission of biometric subtype data to the card as an 

inhibitor toward (future) multi-finger applications. 

NIST is interested in standardization of the transmission of reference data to the card. 

A revision of ISO/IEC 19794-2 might usefully include definitive procedures for enrolling fingerprint minutiae 

templates on the card. It should recommend CHANGE REFERENCE DATA or PUT DATA and particularly should 

establish tags for finger position (biometric subtype). NIST notes that there is no support for unsegmented 

fingerprints. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 42 of 49

Annex G 

ISO/IEC 19794-2:2005 record profile 

Table 35 – MINEX II profile of ISO/IEC 19794-2:2005 standard 

Field name and ISO/IEC 19794-2:2005

clause numbers in parentheses 

Values Allowed Informative Remarks

5. Format Identifier (7.3.1) 0x464D5200 i.e. ASCII "FMR\0"

6. Version Number (7.3.2) 0x20323000 i.e. ASCII " 20\0".

7. Record Length (7.3.3) 32 ≤ L ≤ 800 26 record header + 4 view header +2 

extended data length + 6K. Max K is 128 

8. Capture Equipment Certifications (7.3.4) 0

9. Capture Device Type ID (7.3.5) 0

10. Size of Scanned Image in x direction (7.3.6) MIT Inherited directly from input data

11. Size of Scanned Image in y direction (7.3.7) MIT

12. X (horizontal) resolution (7.3.8) 197

13. Y (vertical) resolution (7.3.9) 197

14. Number of Finger Views (7.3.10) 1

15. Reserved Byte (7.3.11) 0

16. Finger Position (7.4.1.1) MIT Inherited directly from input data

17. View Number (7.4.1.2) 0

18. Impression Type (7.4.1.3) 0 or 2 Inherited directly from input data

19. Finger Quality (7.4.1.4) MIT Inherited directly from input data

20. Number of Minutiae (7.4.1.5) 0 ≤ K ≤ 128 K minutiae data blocks

21. Minutiae Type (7.4.2.1) 01b, 10b, or 00b

22. Minutiae Position (7.4.2.2) MIT

23. Minutiae Angle (7.4.2.3) MIT

24. Minutiae Quality (7.4.2.4) 0, 1 ≤ Q ≤ 100 0 = unsupported

25. Extended Data Block Length (7.5.1.1) >= 0 Either 0 for no extended data, or the length 

of a zonal quality block 

26. Extended Data Area Type Code (7.5.1.2) 0x0003 Optional, only present if (7.5.1.1) is > 0.

27. Zonal Q. Cell Width and Height (7.5.4.1) 1 ≤ NPIX ≤ W Optional, only present if (7.5.1.1) is > 0.

Zonal Q. Cell Width and Height (7.5.4.1) 1 ≤ NPIX ≤ H Optional, only present if (7.5.1.1) is > 0.

28. Zonal Q. Cell Quality Info. Depth (7.5.4.2) 1, 2, 4, 8 Optional, only present if (7.5.1.1) is > 0.

This value shall not be 0. 

29. Zonal Q. Cell Quality Data (7.5.4.3) Optional, only present if (7.5.1.1) is > 0.

MIT = mandatory at time of instantiation

Table 36 – ISO/IEC 19794-2 minutiae template DO 

Tag L Value

‘7F2E’ L1 Biometric data template

Tag L Value

‘81’ L2 Finger minutiae data

Field Size (bits) Valid Values

X coordinate 8 [0,255] S 

Y coordinate 8 instances [0,255]

Minutiae type 2

Minutiae angle 6 [0,63]

'94' L3 Zonal Quality 

Data 

5+var See Table 37 1 

instance 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 43 of 49

where the zonal quality block shall conform to Table 37. This data is a modified version of that inserted into 

ISO/IEC 19794-2:2005 by the draft Technical Corrigendum 1, SC 37 N2119. 

Table 37 – Zonal quality data 

FIeld Length 

(bytes) 

Values

Allowed 

Informative Remarks

1 Horizontal Resolution of the Quality Map (8.4.1.1.2) 1 See Note 1 and Example 1

2 Vertical Resolution of the Quality Map (8.4.1.1.2) 1

3 Quality Map Width (8.4.1.1.3) 1 # cells in x horizontal direction

4 Quality Map Height (8.4.1.1.3) 1 # cells in y vertical direction

5 Cell Quality Information Depth (8.4.1.1.4) 1 1, 2, 4, 8 Not 0.

6 Cell Quality Data (8.4.1.1.5) L Packed bits

NOTE 1 The first draft Technical Corrigendum 1, SC37N2119 has one field for cell quality resolution, 

i.e. it assumes the x-y resolutions are equal. However, the ISO-REC standard allows different cell resolutions 

in x and y. Therefore, if the ISO-REC to ISO-CC transcoding process is to become viable operationally, then 

card zonal quality data needs to support anisotropic resolutions. NIST will comment on the update of N2119 

(to be circulated for ballot in the latter half of 2007). 

EXAMPLE 1 If the horizontal cell dimension in a ISO-REC zonal quality block (clause 7.5.4.1 of ISO/IEC

19794-2:2005) is 20 pixels, and the corresponding horizontal resolution is 197 pixels per centimeter (clause 

7.3.8 of ISO/IEC 19794-2:2005), then the value of the entry on line 1 of this table (i.e. the number of cells 

per decimeter) will be round(10 * 197 / 20) = 99, where the rounding operator is nowhere standardized.
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 44 of 49

Annex H 

Application to participate in MINEX II 

H.1 Who should participate 

Providers of ISO/IEC 7816 card-based MOC implementations using ISO/IEC 19794-2:2005 minutia-based 

templates are invited to participate in MINEX II. In addition, companies, research organizations, or 

universities that have developed mature prototypes or who research fingerprint matching of interoperable 

templates are invited to participate. 

The fingerprint template generation and matching software need not be “operational,” nor a production 

system, nor commercially available. However, the system must, at a minimum, be a stable implementation 

capable of being “wrapped” (formatted) in the API specification that NIST has specified in section 8 for this 

evaluation. 

Anonymous participation will not be permitted. This means that signatories to this Agreement acknowledge 

that they understand that the results (see sections 5.8 and Annex H.7) of the evaluation of the software 

and/or hardware will be published with attribution to their organization(s). 

H.2 How to participate 

H.2.1 Application package 

In order to request participation in MINEX II, prospective participants must assemble ALL of the following 

items and send the entire package to NIST at the address given in Annex I. 

― Physical 7816 cards for each submission (see section 5.8 and H.3.3). 

― A signed and fully completed copy of this entire Annex H, including the Agreement Application to 

Participate in MINEX II, form below. This must identify, and include signatures from, the Responsible 

Parties. 

The package may also include: 

― Software for each submission (see section 5.8 and H.3.4). 

H.2.2 Parties 

The Responsible Party is an individual with the authority to commit the organization to the terms in this 

document. 

The Point of Contact is an individual with detailed knowledge of the system applying for participation. 

H.3 NIST activity 

H.3.1 Initiation 

Upon receipt of the signed Annex H form by NIST, the organization or organizations, if teaming, shall be 

classified as a “Participant”. NIST must receive the form during the submission period described in the MINEX 

II Calendar. 

H.3.2 Supplier validation 

Registered Participants will be provided a username and password to allow access to a small Validation

Dataset available on the website http://fingerprint.nist.gov/minex/registered/. Prior to submission of their 

SDK, the Participant must to verify that their software executes on the validation data, and produces correct 

similarity scores and templates. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 45 of 49

H.3.3 Submission of hardware to NIST 

Suppliers shall send five identical instances of the smart card to NIST at the address given in Annex I. 

Suppliers commit to assisting NIST in resolving deviations from the specifications of this document, errors, 

defects or inconsistencies. 

H.3.4 Submission of software to NIST 

After the Participant has executed his software on the validation imagery, the participants shall send the 

software and its validation output to NIST. All submitted material shall be encrypted using GnuPG (gpg) by 

downloading the MINEX Test Liaison's public key: http://fingerprint.nist.gov/minex/minex_pk.asc whose 

fingerprint is 448F 3828 719D B6B0 FDC5 3DE6 715B 6C72 062A 520A. 

― Importing it into your keyring using: gpg --import minex_pk.asc 

― Using it to encrypt your SDK (with ASCII armor if submitting via email): gpg -r minex -ae mysdk.zip 

The result shall either be 

― emailed to minex@nist.gov or 

― sent to NIST on CD media to the address given in Annex I. 

H.3.5 Acceptance testing 

Cards submitted shall implement the APDU specifications of section 7. 

Software submitted shall implement the MINEX II API Specification of section 8. 

Upon receipt of the SDK and validation output, NIST will attempt to reproduce the output by executing the 

SDK on the validation imagery, using a NIST computer. In the event of disagreement in the output, or other 

difficulties, the Participant will be notified. 

In the event cards or software is found to be non-functional or non-compliant with this document's 

specifications, or where the validation dataset results cannot be replicated by NIST, Participants will be 

notified with a detailed description of the problem(s) and given a reasonable opportunity to resubmit (as time 

allows) according to the discretion of the MINEX II Liaison. 

H.3.6 Limits of testing 

NIST will use the Participant's cards and SDK software only for the testing described in this document. The 

provided hardware and software will also be used to resolve any errors identified subsequent to the test or 

publication of results. 

NIST agrees not to use the Participants software for purposes other than indicated herein, without express 

permission by the Participant. 

H.4 Points of contact 

The MINEX II Liaison is the government point of contact for MINEX II. All correspondence should be directed 

to minex@nist.gov, which will be received by the MINEX II Liaison and other MINEX II personnel. 

These correspondences may be posted on the FAQ (Frequently Asked Questions) area of the MINEX II website

at the discretion of the MINEX II Liaison. The identity of those persons or organizations whose 

correspondences lead to FAQ postings will not be made public in the FAQ. 

H.5 Access to MINEX II validation data 

The MINEX II Validation Data is supplied to Participants to assist in preparing for MINEX II. 

The fingerprints in the MINEX II Validation Data are representative of the MINEX II Test Data only in their 

format. Image quality, collection device and other characteristics are likely to vary between the Validation 

and Test Datasets. 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 46 of 49

H.6 Access to MINEX II test data 

The MINEX II Test Datasets are protected under the Privacy Act (5 U.S.C. 552a), and will be treated as

Sensitive but Unclassified and/or Law Enforcement Sensitive. 

MINEX II Participants shall have no access to MINEX II Test Data, either before, during or after the test. 

Information about the images data has been previously published in MINEX 04 report, NIST IR 729622

. 

H.7 Reporting of results 

H.7.1 Reports 

The Government will combine appropriate results into one or more MINEX II Reports. Together these will 

contain, at a minimum, descriptive information concerning MINEX II, descriptions of each experiment, and 

aggregate test results. NIST will include 

― DET performance metrics as the primary indicators of one-to-one verification accuracy, 

― ISO/IEC 19795-4 interoperability matrices as the primary measures of interoperability, and 

― enrollment and verification timing statistics. 

NIST may compute and report other aggregate statistics. 

NIST intends to release Phase 1 results to the participant only. 

NIST intends to publish Phase 2 results in one or more NIST Interagency Reports. 

The Phase 2 reports will: 

― contain the names of Phase 1 participants, 

― not contain the results from Phase 1 participants' implementations, 

― contain the names of Phase 2 participants, and 

― contain the results of all Phase 2 participants' implementations which will associated with the 

participants names. 

H.7.2 Pre-publication review 

Participants will have an opportunity to review and comment on the reports. Participants’ comments will be 

either incorporated into the main body of the report (if it is decided NIST reported in error) or published as 

an addendum. Comments will be attributed to the participant. 

H.7.3 Citation of the report 

After the release of the Phase II Final Report, Participants may decide to use the results for their own 

purposes. Such results shall be accompanied by the following phrase: “Results shown from the Minutiae

Interoperability Exchange Test (MINEX II) do not constitute endorsement of any particular system by the U. S. 

Government.” Such results shall also be accompanied by the URL of the MINEX II Report on the MINEX II

website, http://fingerprint.nist.gov/minexII. 

H.7.4 Rights and ownership of the data 

Any data obtained during MINEX (excepting the submitted SDK itself), as well as any documentation required 

by the Government from the participants, becomes the property of the Government. Participants will not 

possess a proprietary interest in the data and/or submitted documentation. 

H.8 Return of the supplied materials 

H.8.1 Returning software to vendors 

NIST will not return any supplied software, documentation, or other material to vendors. 

 

22 MINEX Report NIST IR 7296 PDF is here: http://fingerprint.nist.gov/minex04/minex_report.pdf 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 47 of 49

H.8.2 Returning cards to vendors 

NIST will not return cards to the provider. NIST will destroy the cards within ninety days of publication of the 

results for that card or notification to the vendor that the card is inoperable. This requirement is needed 

because template data on the card is protected and because NIST has no mechanism to assure deletion of

templates from the card. However, NIST to support debugging NIST may, at its sole discretion, return cards 

during the initial acceptance testing phase. 

H.9 Agreement to participate 

With the signing of this form, Participants attest that they will not file any MINEX II-related claim against 

MINEX II Sponsors, Supporters, staff, contractors, or agency of the U.S. Government, or otherwise seek

compensation for any equipment, materials, supplies, information, travel, labor and/or other participant 

provided services. 

The Government is not bound or obligated to follow any recommendations that may be submitted by the 

Participant. The United States Government, or any individual agency, is not bound, nor is it obligated, in any 

way to give any special consideration to MINEX II Participants on future contracts, grants or other activities. 

With the signing of this form, Participants realize that any test details and/or modifications that are provided 

in the MINEX II website supersede the information on this form. 

With the signing of this form, Participants realize that they can withdraw from the MINEX II Phase II at any 

time prior to the end of the Phase II submission window, without their participation and withdrawal being 

documented in the MINEX II Final Report. 

This form shall be completed by all suppliers of ISO/IEC 7816 cards and providers of fingerprint technology electing to 

participate in the MINEX II trials. When more than one supplier is part of a team to provide an implementation, a 

Responsible Party from each party shall complete an executed copy of this agreement. 

Card identifier (identical to value 

returned in sec. 7.8). Required for 

Class A + B (sec. 5.8) submissions. 

Fingerprint matcher identifier (identical 

to value returned in sections 7.9 and 

8.4.4). Required for Class A + B (sec. 

5.8) submissions. 

Fingerprint template generator 

identifier (identical to that return in 

sec. 8.4.4). Required only for Class B 

(sec. 5.8) submissions. 

Hex Vendor ID Hex Vendor ID (IBIA assigned) Hex Vendor ID (IBIA assigned)

Hex vendor assigned version no. Hex vendor assigned version no. Hex vendor assigned version no.

Responsible Party for supplier of smart card

Company / Organization Name

Title First Name MI Last Name Suffix

Street Address

City State Zip Country

Phone Fax Email

Technical point of contact Phone Email

Responsible Party for supplier of fingerprint matcher technology (i.e. any algorithms present on the card or in the SDK 

library). 

Company / Organization Name

Title First Name MI Last Name Suffix
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 48 of 49

Street Address

City State Zip Country

Phone Fax Email

Technical point of contact Phone Email

Responsible Party for supplier of fingerprint minutiae template generator technology (i.e. any algorithms present in the 

SDK library). 

Company / Organization Name

Title First Name MI Last Name Suffix

Street Address

City State Zip Country

Phone Fax Email

Technical point of contact Phone Email

With my signature, I agree that this document is a sufficient description of the test to be conducted.

With my signature, I hereby request consideration as a Participant in the Minutia Interoperability Exchange 

Test II (MINEX II), and I am authorizing my company or organization to participate in MINEX II according to the 

rules and limitations listed in this document. 

With my signature, I also state that I have the authority to accept the terms stated in this document 

________________________________________________________________________________ 

SIGNATURE OF CARD SUPPLIER RESPONSIBLE PARTY DATE 

________________________________________________________________________________ 

SIGNATURE OF FIRST FINGERPRINT SOFTWARE SUPPLIER RESPONSIBLE PARTY DATE 

________________________________________________________________________________ 

SIGNATURE OF SECOND FINGERPRINT SOFTWARE SUPPLIER RESPONSIBLE PARTY DATE 
NIST MINEX Match-on-card Test Plan. 

NIST Grother and Salamon Page 49 of 49

Annex I 

NIST mailing address 

The address given below shall be used for all mail or courier delivery to NIST. This includes delivery of MINEX 

II participation agreements and all MINEX II cards and software. 

MINEX II Test Liaison 

National Institute of Standards and Technology 

Information Access Division (894) 

100 Bureau Drive, Stop 8940 

Gaithersburg, MD 20899-8940 

USA 

In cases where the courier needs a phone number please use NIST S+H 301 nine seven five six two nine six.