| Question ID # |
Date |
Posted by | Category |
| 266 |
2006-02-16 11:38:52 |
Ramaswamy Chandramouli |
editorial |
| Question: |
Regarding JPEG2000 compression, ROI:
A previous draft stated that for use of JPEG2000 ROI, 24:1 was the maximum compression for the inner region, with 120:1 permitted for outer region if ROI is used. Now it says that 15:1 is the maximum overall compression for an image, but 24:1 for inner region when using ROI.
Is this saying that 15:1 is required for applications other than card storage? That more compression is permitted when using ROI for card storage? Is there no longer an outer-region limit?
Are there guidelines for ROI for non-card storage apps, or is this not recommended?
Are there guidelines for defining the ROI location, dimensions?
Is there a maximum allowable compression for card storage, with or without ROI? |
|
| Answer: |
For storage not on PIV Cards the compression ratio shall not exceed 15:1.
For storage on PIV Cards the following recommendations apply:
ROI compression should be used.
The compression ratio of the inner region should not exceed 24:1.
The compression ratio of the outer regions are not limited. |
|
| 284 |
2007-01-25 11:54:57 |
Hildegard Ferraiolo |
editorial |
| Question: |
| On page 17, section 4.1.4.1 of FIPS 201, it refers to SP 800-76 regarding the photo background. I am unable to locate this information. Could you please tell me what the mandatory requirement is and where to find it? |
|
| Answer: |
| Line 41 of Table 6 specifies the normative content of INCITS 385 for the PIV background. See clause 7.2.6 and Annex A.4.3 of INCITS 385. |
|
| 315 |
2007-12-27 09:27:19 |
Hildegard Ferraiolo |
editorial |
| Question: |
| Section 8 in SP 800-76 describes the performance testing and certification procedures. I wonder when the next certification test will be available and where I can find the latest API specification for the test. Thanks. |
|
| Answer: |
| http://fingerprint.nist.gov/MINEX |
|
| 338 |
2006-07-26 09:05:54 |
Patrick Grother |
corrections |
| Question: |
NIST PIV Project,
We have reviewed the MINEX website and all material on the website. The MINEX page still leaves a number of questions unanswered. The APIs for MINEX and SP 800-76 are different.
For example,
o The MINEX create_template receives a raw image along with finger quality, finger position, impression type, height, and width. According to SP 800-76, the input for the template generator is a [FINGSTD] record, which includes these values as part of its structure.
o The MINEX match_templates receives two templates. According to SP 800-76, the input for the template matcher is four templates.
o None of the Supplier Name, Version Number, Timestamp, or Contact Point functions are defined in MINEX, but are required for SP 800-76.
How can we obtain clarification, which API standard do we code to MINEX or SP800-76?
|
|
| Answer: |
800-76 does not establish an API for minutiae generators and matchers. It puts constraints on tests of such implementations. The MINEX documentation specification does establish an API and should be adhered to. The get_pids() function in the MINEX API implements the 800-76 need for vendor name and number. The contact point and timestamp functions are not implemented in MINEX.
|
|
| 344 |
2006-08-14 14:17:50 |
Patrick Grother |
editorial |
| Question: |
| I recognize that the fingerprint templates on the PIV card must use the interoperable tempalte format - this helps for credential reissuance and interagency compatibility. However, for internal authentication, is it permissible to use a proprietary fingerprint template - not one stored on the card, but perhaps on the server. In other words, for physical access one could swipe the contactless portion of the card and place their finger - whereby the finger is matched off a central database. And then for logical access, the user could place their PIV card in the reader and use the same centrally stored fingerprint. Is this up to the agency, or does the HSDP-12 standard mandate that any use of the card in conjuction with fingerprint authentication use only the fingerprint template stored on board the card? (I understand it is ok to the use the card with other biometrics, such as hand geometry, so why not other fingerprint solutions too which may provide better usability and management capabilities?) |
|
| Answer: |
| SP 800-76 mandates INCITS 378 templates as the interoperable biometric elements. It does not prohibit agencies from adopting proprietary (or standards-based) authentication mechanisms based on fingerprints or any other biometrics. However SP 800-76 does specify that all biometric data, on the card or off, shall be wrapped in the header defined in section 6. |
|
