My company wants to submit a product for MINEX compliance testing, how do we initiate the procedure?
Follow the application procedure here.
I understand MINEX is an interoperability test, which products must my product interoperate with?
A product submitted for MINEX testing must interoperate with all products that have been listed as compliant under MINEX on the day before the product was formally accepted for testing.
What are the criteria for a product to even be accepted for testing?
The product must be tested to satisfy the INCITS 378 and MINEX API conformance criteria given in the MINEX API document. Acceptance also requires that all templates generated using the product must all be conformant.
Which products have been listed so far?
The list of products may be found here.
I see NIST has published many results for fingerprint products based on proprietary templates, does NIST require submission of such an implementation for MINEX?
No, suppliers must submit only products that generate and match INCITS 378 template handling products, as specified in the MINEX API.
The MINEX homepage says that template generators are tested separately from template matchers. Why is this?
The production of fingerprint minutia templates is a logically and physically distinct activity from matching them. The two processes embed different kinds of algorithmic intellectual property. The MINEX 04 Evaluation Report showed that the most accurately matched templates are not always supplied by the vendors of the best matching products.
So can I submit only a template generator for evaluation?
Well can I submit only a template matcher for evaluation?
No. This is because the MINEX evaluation targets an interoperable paradigm in which an enrollment template, from product X, is compared with a live authentication fingerprint processed by supplier Y's product which embeds a template generator and matcher.
What data will be used for compliance testing?
The data used by NIST for this process is referred to as POEBVA and its origin and properties are described in both the MINEX04 Evaluation Report, in Annex B, as well as Appendix A of NIST IR 7151 . The images have been sequestered at NIST for compliance testing.
What is the criteria for passing the MINEX compliance test and being listed on the MINEX Compliant List page of the website?
The MINEX 04 Evaluation established an interoperable group of products. Eight template generators produced templates that were matched by six template matchers with, in all cases, a false non-match rate less than 0.01 at a fixed false match rate of 0.01. From April 2006 onwards: 1. A template generator passes the MINEX compliance test if its outputs can be matched by all previously listed matchers with a false non-match rate less than 0.01 at the fixed false match rate of 0.01. 2. A template matcher passes the MINEX compliance test if it matches templates from all previously listed template generators with a false non-match rate less 0.01 at the fixed false match rate of 0.01. This is referred to as Baseline Compliance. The result of this process should then be a group of products for which all pairs of products give a baseline level of performance. Note that SP 800-76, section 7.4, imposes some timing requirements on products.
Will the interoperable error rates be made public or will NIST just update the interoperable products list?
All error rates will be published, in addition to the list of interoperable products.
So if a product fails to meet the MINEX criteria will that outcome be reported by NIST?
Yes, and the error rates for all product pairs will be reported here.
If a product fails to meet the MINEX criteria, can we later submit an improved product? If so, on what schedule?
New products may be submitted after 90 days have elapsed from the acceptance date of the last submitted product.
MINEX compliant products, as listed on the MINEX Compliant List page of the website, are accompanied by a Product ID. Where does this come from?
The Product ID (described in INCITS 378, clause 6.4.4) has two parts. The first two bytes identify the supplier of the product. This is registered with the IBIA who list it here. The second two bytes identify the version number of the product, in this case the template generator. This value is assigned by the vendor.
So can a product be submitted for MINEX testing without seeking PIV compliance?
Yes. A supplier seeking PIV compliance must explicitly request this on the application form.
So can other programs, organizations or applications, perhaps in other countries, require MINEX testing?
Yes, at their option.
And what fees must be paid for MINEX testing?
There are no fees.
Why does the MINEX process not include three-way testing (vendor Z matches templates from suppliers X and Y), as conducted in the MINEX 2004 report?
This scenario is not usually the most operationally relevant case. Ongoing MINEX targets the most common case where vendor X matches templates from X and Y. The full three-way test is expensive to compute.
Why do the error rates reported in Ongoing MINEX differ from those (for the same products) used in MINEX 2004?
Ongoing MINEX employs a larger sample of the POEBVA fingerprint population than that used in MINEX 2004.
The MINEX API specification puts limits on the average time need to make templates and, separately, to match them. NIST SP 800-76 specifies different limits? So which ones apply?
The MINEX API specifications are instituted to constrain the resources needed by NIST in executing the MINEX tests. The looser SP 800-76 specification, on the other hand, is instituted only to ensure that template encoding and matching tasks are insignificant components of a typical operational verification attempt. The SP 800-76 specification will be strictly enforced for products submitted for PIV compliance testing.
Can we submit an SDK before obtaining valid Product ID?
Product IDs (PIDS) are not checked as part of MINEX testing, however if PIV compliance is being sought, then the PIDs returned by the SDK must comply with the format specified in the Ongoing MINEX API section 3.2.4 before being accepted for testing. All tested SDKs seeking PIV compliance which pass the MINEX compliance test will be listed along with the PIDs returned by the SDK.
INCITS 378 provides for an encoding for the quality of each minutiae and SP 800-76 allows this throughout the PIV program. However the MINEX API requires a template generator to set this field to zero. Why?
The INCITS 378 standard specifies a range for quality of [1,100], but it does not establish a standard interpretation of what that value means. Without a precise definition interoperability is not possible. For MINEX testing the zero value was required to ensure that the interoperability of the core (x,y,theta) minutiae data is being evaluated. SP 800-76, however, allows the quality value to be present because in PIV, when the template generator PID is also present, a matcher may use this information without any risk to interoperability (for example, when it sees a template from the same supplier). Zero minutiae quality values were used in the original MINEX Evaluation.
The MINEX API requires production of a template for ALL input images, even poor or empty ones. Why?
Ordinarily when a product is given a poor input image, if may fail to produce a template. This is often referred to as a failure to enroll. In MINEX such cases must produce a template, referred to as a NULL template. The MINEX test requires a template in ALL cases in order to correctly account for such failures. A matcher that encounters a NULL template in a genuine comparison should produce a low score (and this will increase the false non-match rate). Similarly, in an impostor comparison a null template will produce a low score (and this will decrease the false match rate).
The MINEX Test Results webpage lists in the Notes section: "Tables created using 2-finger POEBVA data." What is meant by "2-finger"?
The matcher function in MINEX takes two single templates and returns a similarity score. This function is applied to a pair of left index fingers and, seperately, to a pair of right index fingers. The resulting scores are added together. This implements sum-rule fusion. This process is used to estimate recognition error rates for a verification process in which two fingers are used in each attempt.