ISO/IEC 19794-2:2005/Cor.1:2009 Smartcard Summary
This is a complete description of fingerprint template format for smartcards defined in ISO/IEC 19794-2:2005 spec (often abbreviated ISO 19794-2:2005 or ambiguously ISO 19794-2), including minor fixes described in Technical Corrigendum 1 (Cor.1:2009), except for the following changes:
- Only smartcard variation is described here. Off-card format is described separately.
- Essential content from related ISO publications (ISO 19785-3:2015, ISO 7816-11:2017) was incorporated to keep this format summary self-contained.
- All content is distributed under permissive CC BY 4.0 license.
- Normative content was completely rewritten from scratch to avoid infringing copyrights.
- Non-normative commentary was dropped. Author added his own non-normative comments.
- Special notes were added for opensource and in-house software developers.
- Differences from other formats and other versions of this format were documented.
This format summary is complete in the sense that implementations written according to this document are also fully conforming implementations of ISO/IEC 19794-2:2005. There is no guarantee though and you should consult the original ISO/IEC 19794-2:2005 spec if in doubt.
This document was written by Robert Važan as part of his work on SourceAFIS fingerprint matcher using his legally obtained copies of ISO/IEC 19794-2:2005, ISO/IEC 19785-3:2015, and ISO/IEC 7816-11:2017. Author has no affiliation with ISO. This format summary is distributed free of charge under Creative Commons Attribution 4.0 International License to enable truly open implementation of the format in opensource software. Nevertheless, author discourages use of ISO 19794-2 and other so-called "standard" templates in favor of plain fingerprint images.
Introduction
Human fingerprint recognition is usually performed in two separate steps: feature extraction and matching. Feature extraction takes fingerprint image (also called fingerprint sample), usually obtained from fingerprint reader (or fingerprint sensor) hardware, and produces so-called fingerprint template filled with fingerprint features useful for matching. Matching takes two fingerprint templates on input, compares fingerprint features contained in them, and produces similarity score on output, which is then compared to a threshold to produce match or non-match decision. There are many kinds of fingerprint features: minutiae (especially ridge endings and bifurcations), core and delta points, ridge shapes or patterns, orientation and ridge frequency fields, edges between minutiae, and many others.
Most fingerprint recognition systems have their own native fingerprint template format. Some people however insist on exchange of fingerprint templates between fingerprint recognition systems even though it is almost always a bad idea. ISO 19794-2:2005 is one of several fingerprint template formats that can be used for this purpose.
ISO 19794-2:2005 defines main off-card format and an additional smartcard format described here. This document also describes reduced minutia size format, which is a variation of the off-card format. Smartcard format is intended for use in smartcards, specifically those implementing ISO 7816-11.
ISO 19794-2:2005 smartcard format mainly encodes minutiae, including their position, angle, and type (ending, bifurcation, or other). It can optionally encode ridge counts on edges between minutiae, information about cores and deltas, and zonal image quality. It carries some fingerprint metadata, notably finger position (thumb, index, ...). It can be used to communicate smartcard parameters (see PARAMS). It permits encoding several fingerprints in a single template.
Related formats
Smartcard format is described separately from ISO 19794-2:2005 off-card format defined in the same spec, because it is substantially different. This document also describes reduced minutia size format, which is a variation of the off-card format.
This template format has a new version: ISO 19794-2:2011. The two versions can be differentiated by looking at the SUBFORMAT field. Some values of this field are shared by both versions though and in those cases there is no way to tell the formats apart.
ISO 19794-2:2005 does not fully define the smartcard template format. It refers to ISO 7816-11 and ISO 19785-3 for overall structure of the template. This overall structure has been inlined in this document to keep this format summary self-contained. Underlying DER-TLV encoding is already publicly documented.
Commands used to communicate with the smartcard are out of scope for this document. They can be found in relevant ISO 7816-* specifications.
Changes
This smartcard format is a variation of ISO 19794-2:2005 off-card format. Smartcard format differs from the off-card format in several ways:
- DER-TLV is used to encode some fields and field groups in addition to fixed-size encoding.
- There is an explicit top-level field group GROUP.
- Several field groups can be used as the top-level field group: GROUP, FINGERPRINT, and FPSTRUCT, although the last one has interpretation issues when used alone. Additionally reduced minutia size format can be embedded in any of these field groups or used separately.
- There is no HEADER. Of its fields, only FPCOUNT is preserved under GROUP
- Added FPHEADER field group, of which only POSITION field exists in the off-card format.
- MINUTIA was replaced with two alternatives: NMINUTIA and CMINUTIA. The new minutia types can be used in smartcard format or in reduced minutia size format.
- FINGERPRINT has a variety of alternative representations. It can contain either PLAINMIN or FPSTRUCT. FPSTRUCT can then contain NESTEDMIN, STDSTRUCT, STDMIN, VENDORSTRUCT, and VENDORPLAIN as alternatives to preferred contents of MINUTIAE and extensions. Several field groups can contain reduced minutia size format instead of plain NMINUTIA/CMINUTIA list.
- Messages originating from the card may contain FINGERPRINT field group with no minutia data (no PLAINMIN or FPSTRUCT), only FPHEADER with PARAMS to communicate card parameters.
- Extensions are represented as optional DER-TLV field groups and there is consequently no EXTBYTES field and no EXTENSION field group.
- COREDATA and DELTADATA are two separate extensions. There is no COREDELTA field group.
- Off-card format fields MAGIC, VERSION, TOTALBYTES, DEVSTAMP, DEVID, WIDTH, HEIGHT, RESOLUTIONX, RESOLUTIONY, VIEWOFFSET, SAMPLETYPE, FPQUALITY, and MINQUALITY were omitted.
- Fields and field groups FPCOUNT, FINGERPRINT, POSITION, RCOUNTEXT, COREDATA, DELTADATA, and ZONALEXT are encoded in DER-TLV.
- MINCOUNT is implicit in MINUTIAE size.
- POSITION uses different codes.
- Card can have limits on minutia count (MINRANGE) and require minutia sorting (MINSORT).
- NMINTYPE/CMINTYPE value 01 can also mean valley skeleton bifurcation depending on SUBFORMAT.
- Since there is no RESOLUTIONX/RESOLUTIONY, fields NMINX/NMINY and CMINX/CMINY are encoded at fixed resolution. The same applies to COREX/COREY and DELTAX/DELTAY.
- ZONALEXT has different structure. Allowed values in ZONEBITS are different.
Layout
The template is a tree of DER-TLV fields and field groups. Several field groups can be used as the top-level field group: GROUP, FINGERPRINT, and FPSTRUCT, although the last one has interpretation issues when used alone. Some DER-TLV field groups contain fixed-length fields. Numbers are in big-endian byte order. Alternative representation is provided by reduced minutia size format.
Reduced minutia size format
In addition to the above DER-TLV based format, ISO 19794-2:2005 spec also defines "format with record header for use in card-based systems", which is just ISO 19794-2:2005 off-card format with NMINUTIA/CMINUTIA instead of MINUTIA and with additional interpretation of minutia type 01 (see NMINTYPE).
The only way to distinguish reduced minutia size format and its variations from ISO 19794-2:2005 off-card format is by examining SUBFORMAT field. But since this field is not part of the ISO 19794-2:2005 off-card format and thus not part of the reduced minutia size format, SUBFORMAT must be stored in higher level data structures. If DER-TLV encoding as defined in ISO 19785-3:2015 is used for the higher level data structures, then the reduced minutia size format is stored in field PLAINMIN, NESTEDMIN, or STDMIN (or perhaps even MINUTIAE) of the above DER-TLV based format.
Tag index
Tags of DER-TLV fields and field groups are always listed as fully encoded hexadecimal numbers. Their decoded form is provided in the table below as well as in individual field descriptions.
| Context | Encoded tag | Class | P/C | Tag number | Definition |
|---|---|---|---|---|---|
| 7F61 | application | constructed | 61 | GROUP | |
| 7F61 | 02 | universal | primitive | 02 (integer) | FPCOUNT |
| 7F60 | application | constructed | 60 | FINGERPRINT | |
| 7F60 | A1 | context-specific | constructed | 01 | FPHEADER |
| 7F60/A1 | 81 | context-specific | primitive | 01 | MODALITY |
| 7F60/A1 | 82 | context-specific | primitive | 02 | POSITION |
| 7F60/A1 | 83 | context-specific | primitive | 03 | DATETIME |
| 7F60/A1 | 87 | context-specific | primitive | 07 | OWNER |
| 7F60/A1 | 88 | context-specific | primitive | 08 | SUBFORMAT |
| 7F60/A1 | B1 | context-specific | constructed | 11 | PARAMS |
| 7F60/A1/B1 | 81 | context-specific | primitive | 01 | MINRANGE |
| 7F60/A1/B1 | 82 | context-specific | primitive | 02 | MINSORT |
| 7F60/A1/B1 | 83 | context-specific | primitive | 03 | FEATUREBITS |
| 7F2E | application | constructed | 2E | FPSTRUCT | |
| 7F2E | 90 | context-specific | primitive | 10 | MINUTIAE |
| 7F2E | 91 | context-specific | primitive | 11 | RCOUNTEXT |
| 7F2E | 92 | context-specific | primitive | 12 | COREDATA |
| 7F2E | 93 | context-specific | primitive | 13 | DELTADATA |
| 7F2E | 94 | context-specific | primitive | 14 | ZONALEXT |
| 7F2E | A1 | context-specific | constructed | 01 | STDSTRUCT |
| 7F2E | 81 | context-specific | primitive | 01 | STDMIN |
| 7F2E | A2 | context-specific | constructed | 02 | VENDORSTRUCT |
| 7F2E | 82 | context-specific | primitive | 02 | VENDORPLAIN |
| 5F2E | application | primitive | 2E | PLAINMIN |
Fields and field groups
Fingerprint group (GROUP)
| Encoded tag | Class | P/C | Tag number |
|---|---|---|---|
| 7F61 | application | constructed | 61 |
GROUP is a DER-TLV field group with tag 7F61 (hex) that represents a set of fingerprints. It is used as the top-level field group when several FINGERPRINT blocks must be present in the template.
This field group is not explicitly present in ISO 19794-2:2005 off-card format, but it represents multi-fingerprint template just like the entire ISO 19794-2:2005 off-card format.
Number of fingerprints (FPCOUNT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F61 | 02 | universal | primitive | 02 |
FPCOUNT is a required DER-TLV field nested under GROUP with tag 02 (hex). It is an unsigned 8-bit number that indicates the number of FINGERPRINT blocks in this GROUP.
In ISO 19794-2:2005 off-card format, this field is a fixed-size field included in HEADER.
Fingerprint (FINGERPRINT)
| Encoded tag | Class | P/C | Tag number |
|---|---|---|---|
| 7F60 | application | constructed | 60 |
FINGERPRINT is a DER-TLV field group with tag 7F60 (hex) that represents single fingerprint. It can be used as the top-level field group when only one fingerprint is needed. It can be also nested under GROUP when multiple fingerprints must be sent together.
Structure of FINGERPRINT has several variations. FPHEADER, which is always present, indicates which parts of FINGERPRINT are present and also carries additional metadata. Biometric data is in nested FPSTRUCT. Alternatively, simpler encoding of biometric data can be in PLAINMIN. Biometric data can be completely omitted when FINGERPRINT is used to carry PARAMS (nested under FPHEADER) from the card.
This field group is length-delimited and very differently structured in ISO 19794-2:2005 off-card format.
Fingerprint header (FPHEADER)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60 | A1 | context-specific | constructed | 01 |
FPHEADER is a required DER-TLV field group nested under FINGERPRINT with tag A1 (hex). It has two requires fields, OWNER and SUBFORMAT, that determine structure of the rest of the FINGERPRINT. It is also a container for other metadata. Optional PARAMS can be retrieved from the card wrapped in FPHEADER.
This field group is not part of ISO 19794-2:2005 off-card format.
Biometric modality (MODALITY)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | 81 | context-specific | primitive | 01 |
MODALITY is an optional DER-TLV field nested under FPHEADER with tag 81 (hex). Biometric modality codes are listed in the table below. Fingerprints have code 08 (hex). Shortest possible encoding is used, so this field has length 1 for fingerprints. When this field is omitted, fingerprint modality is inferred from OWNER and SUBFORMAT.
| Code (hex) | Modality |
|---|---|
| 01 | Multiple |
| 02 | Face |
| 04 | Voice |
| 08 | Fingerprint |
| 10 | Iris |
| 20 | Retina |
| 40 | Hand geometry |
| 80 | Signature |
| 0100 | Keystroke |
| 0200 | Lip movement |
| 0400 | Thermal face |
| 0800 | Thermal hand |
| 1000 | Gait |
| 2000 | Body odor |
| 4000 | DNA |
| 8000 | Ear |
| 010000 | Finger geometry |
| 020000 | Palm geometry |
| 040000 | Vein pattern |
| 080000 | Footprint |
This field is not part of ISO 19794-2:2005 off-card format, which uses MAGIC field for similar purposes. It is not mentioned in the ISO 19794-2:2005 spec, but it is described in underlying specifications (ISO 19785-3:2015).
Finger position (POSITION)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | 82 | context-specific | primitive | 02 |
POSITION is an optional DER-TLV field nested under FPHEADER with tag 82 (hex). It contains unsigned 8-bit number encoding hand position of the finger. It must be one of the codes listed in the table below. If omitted, unknown finger position is assumed.
| Binary | Hex | Hand | Finger |
|---|---|---|---|
| 00000000 | 00 | Unknown | Unknown |
| 00100101 | 25 | Right | Thumb |
| 00101001 | 29 | Right | Index |
| 00101101 | 2D | Right | Middle |
| 00110001 | 31 | Right | Ring |
| 00110101 | 35 | Right | Little |
| 00100110 | 26 | Left | Thumb |
| 00101010 | 2A | Left | Index |
| 00101110 | 2E | Left | Middle |
| 00110010 | 32 | Left | Ring |
| 00110110 | 36 | Left | Little |
This field is a fixed-length field in ISO 19794-2:2005 off-card format with different codes of finger positions. This field is not mentioned in the smartcard subformat description in ISO 19794-2:2005 spec, but it is defined in underlying specifications (ISO 19785-3:2015).
Capture date and time (DATETIME)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | 83 | context-specific | primitive | 03 |
DATETIME is an optional DER-TLV field nested under FPHEADER with tag 83 (hex). It contains BCD-encoded timestamp digits YYYYMMDDHHMMSS (7 bytes). This is the time when the sample was captured by scanning device.
This field is not part of ISO 19794-2:2005 off-card format. It is not mentioned in the ISO 19794-2:2005 spec, but it is described in underlying specifications (ISO 19785-3:2015).
Format owner (OWNER)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | 87 | context-specific | primitive | 07 |
OWNER is a required DER-TLV field nested under FPHEADER with tag 87 (hex). It contains an unsigned big-endian 16-bit number 0101 (hex), which is registered to ISO/IEC JTC 1/SC 37 Biometrics, the publisher of this format. SUBFORMAT makes sense only in context of particular OWNER.
This field is not part of ISO 19794-2:2005 off-card format, but it may be present with the same value in higher level data structures that wrap the off-card template.
Subformat type (SUBFORMAT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | 88 | context-specific | primitive | 08 |
SUBFORMAT is a required DER-TLV field nested under FPHEADER with tag 88 (hex). Since this format has a number of variations, SUBFORMAT field is needed to disambiguate them. It contains unsigned big-endian 16-bit number with possible values listed in the table below.
| Hex | Format | Extensions | Minutia size | Ridge ending |
|---|---|---|---|---|
| 0001 | off-card | none | 6 bytes | valley skeleton forking points |
| 0002 | off-card | allowed | 6 bytes | valley skeleton forking points |
| 0003 | modified off-card | allowed | 5 bytes | valley skeleton forking points |
| 0004 | modified off-card | allowed | 5 bytes | ridge skeleton endpoints |
| 0005 | smartcard | allowed | 3 bytes | valley skeleton forking points |
| 0006 | smartcard | allowed | 3 bytes | ridge skeleton endpoints |
| 0019 | modified off-card | allowed | 3 bytes | valley skeleton forking points |
| 001A | modified off-card | allowed | 3 bytes | ridge skeleton endpoints |
| 001B | smartcard | allowed | 5 bytes | valley skeleton forking points |
| 001C | smartcard | allowed | 5 bytes | ridge skeleton endpoints |
Values 0001 and 0002 are only relevant for ISO 19794-2:2005 off-card format.
Values 0005, 0006, 001B, and 001C identify this smartcard format with following variations:
- 0005, 0006: MINUTIAE contains CMINUTIA records.
- 001B, 001C: MINUTIAE contains NMINUTIA records.
- 0006, 001C: NMINTYPE/CMINTYPE value 01 means ridge skeleton endpoint.
- 0005, 001B: NMINTYPE/CMINTYPE value 01 means valley skeleton forking point.
Values 0003, 0004, 0019, and 001A identify reduced minutia size format with the following variations:
- 0003, 0004: NMINUTIA is used instead of MINUTIA.
- 0019, 001A: CMINUTIA is used instead of MINUTIA.
- 0004, 001A: NMINTYPE/CMINTYPE value 01 means ridge skeleton endpoint.
- 0003, 0019: NMINTYPE/CMINTYPE value 01 means valley skeleton forking point.
Since reduced minutia size format does not include this field, SUBFORMAT must be part of higher level data structures. If this DER-TLV smartcard format is used as the higher level data structure, then this field is used to identify variation of reduced minutia size format embedded in other fields of this format.
This field is not part of ISO 19794-2:2005 off-card format, but it may be present with values 0001 and 0002 (hex) in higher level data structures that wrap the template. ISO 19794-2:2005 off-card format has VERSION field that sometimes serves similar purpose.
Algorithm parameters (PARAMS)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1 | B1 | context-specific | constructed | 11 |
PARAMS is an optional DER-TLV field group nested under FPHEADER with tag B1 (hex). It is only present in messages received from the smartcard. If PARAMS is present, then FINGERPRINT may be devoid of fingerprint data and contain only FPHEADER. PARAMS contains information about card capabilities and requirements in field groups MINRANGE, MINSORT, and FEATUREBITS.
This field group is not part of ISO 19794-2:2005 off-card format.
Minutia count range (MINRANGE)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1/B1 | 81 | context-specific | primitive | 01 |
MINRANGE is an optional DER-TLV field group nested under PARAMS with tag 81 (hex). It is only present in messages received from the smartcard. It indicates minimum and maximum number of minutiae accepted by the card. This information is in nested fields MINLOW and MINHIGH.
This field group is not part of ISO 19794-2:2005 off-card format.
Minimum minutia count (MINLOW)
An unsigned 8-bit number specifying minimum number of minutiae expected by the card in MINUTIAE. If MINRANGE is not present, default is 16 for enrollment and 12 for verification.
This field is not part of ISO 19794-2:2005 off-card format.
Maximum minutia count (MINHIGH)
An unsigned 8-bit number specifying maximum number of minutiae expected by the card in MINUTIAE. If MINRANGE is not present, default is 60.
Excess minutiae are pruned by removing low quality minutiae and then outermost minutiae.
This field is not part of ISO 19794-2:2005 off-card format.
Minutia sorting (MINSORT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1/B1 | 82 | context-specific | primitive | 02 |
MINSORT is an optional DER-TLV field group nested under PARAMS with tag 82 (hex). It is only present in messages received from the smartcard. When present, smartcard expects minutiae to be sorted according to fields SORTKEY, SORTDIR, and SORTWRAP. Special value zero means no sorting is needed.
This field group is not part of ISO 19794-2:2005 off-card format.
Sorted minutia wraparound (SORTWRAP)
Bit 5 of MINSORT indicates the card expects special "wraparound" minutia format. Wraparound sort mode is poorly documented in ISO 19794-2:2005 and consequently hard to implement correctly. When SORTWRAP is enabled, SORTKEY and SORTDIR are zero.
The idea is to encode 16-bit X or Y coordinates by sorting minutiae by X or Y respectively and then storing only the lower 8 bits of the X or Y coordinates. Card can reconstruct 16-bit X or Y coordinates by assuming that every break of sort order means wraparound. For example, X coordinates 100, 200, and 300 would be stored as 100, 200, and 44. Since minutiae can be sorted either by X or by Y, wraparound mode cannot be applied to both at the same time. What's worse, ISO 19794-2:2005 does not make it clear how to choose between X and Y sorting.
This field is not part of ISO 19794-2:2005 off-card format.
Minutia sort key (SORTKEY)
This 3-bit field (spanning bits 2 through 4 in MINSORT) specifies minutia attribute used for sorting. Together with SORTDIR, this field determines minutia ordering. Possible values are in the table below. This field is zero when SORTWRAP is enabled or when no sorting is needed.
| Code (binary) | Sort key |
|---|---|
| 001 | NMINX/CMINX |
| 010 | NMINY/CMINY |
| 011 | NMINANGLE/CMINANGLE |
| 100 | polar distance (see below) |
When sorting by X, minutiae with the same X position are sorted by Y. Conversely when sorting by Y, minutiae with the same Y position are sorted by X. When sorting by minutia angle, minutiae with the same angle can be sorted in any way.
Polar sorting is performed relative to the center of mass of all minutiae. Polar distance and polar angle is calculated relative to this center. Minutiae are sorted by polar distance. Minutiae with the same polar distance are sorted by polar angle.
This field is not part of ISO 19794-2:2005 off-card format.
Minutia sort direction (SORTDIR)
This 2-bit field (occupying bits 0 and 1 in MINSORT) specifies minutia sort direction (ascending or descending). Together with SORTKEY, this field determines minutia ordering. Possible values are in the table below. This field is zero when SORTWRAP is enabled or when no sorting is needed.
| Code (binary) | Sort direction |
|---|---|
| 01 | ascending |
| 10 | descending |
This field is not part of ISO 19794-2:2005 off-card format.
Feature support (FEATUREBITS)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F60/A1/B1 | 83 | context-specific | primitive | 03 |
FEATUREBITS is an optional DER-TLV field group nested under PARAMS with tag 83 (hex). It is only present in messages received from the smartcard. Card can use it to indicate which extensions it can process. FEATUREBITS value is 1 byte long. Only lowest 4 bits are used. Highest 4 bits are zero.
This field group is not part of ISO 19794-2:2005 off-card format.
Zonal quality supported (ZONESOK)
Bit 3 of FEATUREBITS indicates the smartcard can process ZONALEXT.
This field is not part of ISO 19794-2:2005 off-card format.
Deltas supported (DELTAOK)
Bit 2 of FEATUREBITS indicates the smartcard can process DELTADATA extension.
This field is not part of ISO 19794-2:2005 off-card format.
Cores supported (COREOK)
Bit 1 of FEATUREBITS indicates the smartcard can process COREDATA extension.
This field is not part of ISO 19794-2:2005 off-card format.
Ridge counts supported (COUNTOK)
Bit 0 of FEATUREBITS indicates the smartcard can process RCOUNTEXT.
This field is not part of ISO 19794-2:2005 off-card format.
Structured fingerprint data (FPSTRUCT)
| Encoded tag | Class | P/C | Tag number |
|---|---|---|---|
| 7F2E | application | constructed | 2E |
FPSTRUCT is a DER-TLV field group nested under FINGERPRINT with tag 7F2E (hex). It can contain several different representations of the fingerprint:
- MINUTIAE and optionally also RCOUNTEXT, COREDATA, DELTADATA, and ZONALEXT
- NESTEDMIN
- STDSTRUCT/STDMIN and optionally also VENDORSTRUCT/VENDORPLAIN
This field group is not used when the simpler PLAINMIN is present. It is also omitted when FINGERPRINT is just a container for FPHEADER/PARAMS reported by the card.
Per ISO 7816-11:2017, FPSTRUCT can be used as the top-level field group in some card operations, but doing so would cause ambiguity, because structure of MINUTIAE is defined by SUBFORMAT field, which is not part of FPSTRUCT.
This field group is not part of ISO 19794-2:2005 off-card format, which has only one representation for the fingerprint. NESTEDMIN is not mentioned in the ISO 19794-2:2005 spec, but it is described in underlying specifications (ISO 7816-11:2017).
Minutia list (MINUTIAE)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 90 | context-specific | primitive | 10 |
MINUTIAE is a DER-TLV field group nested under FPSTRUCT with tag 90 (hex). It contains either NMINUTIA or CMINUTIA records depending on the value of SUBFORMAT.
Number of minutiae is implicit in the length of MINUTIAE. It should be in range MINLOW to MINHIGH. Excess minutiae must be pruned according to rules described under MINHIGH.
ISO 19794-2:2005 is ambiguous as to whether this field can contain reduced minutia size format. It should be therefore tolerated when decoding. To avoid ambiguity, STDMIN is preferred over this field when encoding reduced minutia size format.
Minutiae are encoded differently from ISO 19794-2:2005 off-card format, which has explicit MINCOUNT field, different restrictions on minutia count, and somewhat different structure of its MINUTIA record.
Normal minutia record (NMINUTIA)
NMINUTIA records span 5 bytes each and carry minutia position (NMINX, NMINY), angle (NMINANGLE), and type (NMINTYPE). Presence of NMINUTIA records in MINUTIAE depends on the value of SUBFORMAT.
ISO 19794-2:2005 off-card format has similar field group MINUTIA, which has an extra MINQUALITY field. Minutia position (NMINX, NMINY) is encoded differently in smartcard format. Interpretation of NMINTYPE is slightly different.
Normal minutia type (NMINTYPE)
Minutia type is packed in the top two bits of the first byte occupied by the NMINX field. Three minutia types are supported:
| Bits | Type |
|---|---|
| 01 | Ridge ending / valley bifurcation |
| 10 | Ridge bifurcation |
| 00 | Other minutia type |
Minutia type 01 represents either ridge skeleton ending or valley skeleton forking point depending on value of SUBFORMAT.
The original spec says that the third minutia type "other" (code 00), should not be used for endings and bifurcation, but then it says that it should match not only itself but also endings and bifurcations, which means that it can be used as "either" minutia type, which is generated by feature extractors when they cannot clearly classify the minutia as ending or bifurcation. This interpetation was confirmed by ISO 19794-2:2011.
ISO 19794-2:2005 off-card format only supports ridge skeleton endpoint interpretation of type 01 in its MINTYPE field. Valley skeleton bifurcation interpretation is specific to the smartcard format. This is fixed in ISO 19794-2:2011.
Normal minutia X position (NMINX)
NMINX is a 14-bit unsigned number that is stored in the lower 14 bits of the big-endian 16-bit number that also contains NMINTYPE. It encodes location of the minutia on the fingerprint along X axis in units of 10-2mm. Higher values of NMINX place the minutia further to the right.
In order to determine minutia position, feature extractor first constructs ridge skeleton by thinning ridges down to one pixel wide lines. Valley skeleton is constructed similarly by thinning valleys. Ridge endings lie at forking points of the valley skeleton. Similarly, ridge bifurcations lie at forking points of the ridge skeleton. Location of minutiae other than ending and bifurcation is implementation-specific, but it should be always present.
Implementation may calculate position differently as long as it approximates the above skeleton-based method.
Position of minutiae of type "other" is implementation-defined, but it should be done in such a way that these minutiae can match endings and bifurcations in case of ambiguous minutia type.
ISO 19794-2:2005 off-card format has similar field MINX, which is in pixel units. Since smartcard format has no RESOLUTIONX field, minutia position is encoded at fixed resolution of 10-2mm. Smartcard format has no WIDTH field either, which means there is no constraint on NMINX other than that it is non-negative.
Normal minutia Y position (NMINY)
Like NMINX above but for Y axis. Higher values of NMINY place the minutia further down. NMINY is stored in a 16-bit unsigned big-endian field, but only the lower 14 bits of this field are used for NMINY. Upper 2 bits are zero.
Normal minutia angle (NMINANGLE)
An 8-bit unsigned number holding quantized minutia angle in range 0-255. Zero angle points to the right and angle increases counterclockwise. Dequantization to floating-point degrees is performed by multiplying NMINANGLE by (360/256). Quantization is performed by dividing the floating-point angle by (360/256), rounding to nearest integer, and taking the lowest 8 bits.
Ridge ending angle is defined as mean angle of two of the three valley skeleton legs that run around the ridge terminated by the ending. Skeleton leg angle is defined as the angle of its tangent, but this is highly ambiguous, because legs curve a lot around skeleton forking points. Ridge bifurcation angle is similarly derived from legs of ridge skeleton. Minutiae of type "other" must have an implementation-defined angle.
Compact minutia record (CMINUTIA)
This is a 3-byte variation of NMINUTIA. Presence of CMINUTIA records in MINUTIAE depends on the value of SUBFORMAT. Size of fields CMINX/CMINY and CMINANGLE is smaller compared to corresponding fields in NMINUTIA.
Compact minutia X position (CMINX)
An 8-bit unsigned number encoding minutia position along X axis. This field is the same as NMINX except it is smaller and it has resolution 10-1mm.
Compact minutia Y position (CMINY)
An 8-bit unsigned number encoding minutia position along Y axis. This field is the same as NMINY except it is smaller and it has resolution 10-1mm.
Compact minutia type (CMINTYPE)
Minutia type is packed in the top two bits of the byte it shares with CMINANGLE. It contains the same values as NMINTYPE.
Compact minutia angle (CMINANGLE)
A 6-bit unsigned number holding quantized minutia angle in range 0-63. It occupies lower 6 bits of the byte it shares with CMINTYPE.
Zero angle points to the right and angle increases counterclockwise. Dequantization to floating-point degrees is performed by multiplying CMINANGLE by (360/64). Quantization is performed by dividing the floating-point angle by (360/64), rounding to nearest integer, and taking the lowest 6 bits.
Ridge ending angle is defined as mean angle of two of the three valley skeleton legs that run around the ridge terminated by the ending. Skeleton leg angle is defined as the angle of its tangent, but this is highly ambiguous, because legs curve a lot around skeleton forking points. Ridge bifurcation angle is similarly derived from legs of ridge skeleton. Minutiae of type "other" must have an implementation-defined angle.
This field is identical to NMINANGLE except that precision is lowered to 6 bits.
Ridge count extension (RCOUNTEXT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 91 | context-specific | primitive | 11 |
RCOUNTEXT is an optional DER-TLV field group nested under FPSTRUCT with tag 91 (hex).
Minutia set defined in MINUTIAE can be annotated with ridge counts. Ridges are counted on a line (or edge) connecting two minutiae. Edge's ridge count is the number of ridges crossed by the edge as precisely defined in RIDGECOUNT field. RCOUNTEXT extension encodes this ridge count data.
Not all edges in the template need to have ridge count data. Edge picking method is specified in STARTYPE field. Information about every picked edge is then stored in EDGEDEF records that follow. The number of EDGEDEF records is derived from length of RCOUNTEXT. Ordering of EDGEDEF records depends on STARTYPE.
In ISO 19794-2:2005 off-card format, the same field group is encoded as an extension block.
Edge picking method (STARTYPE)
This template format recognizes three edge picking methods: quadrants, octants, and custom. STARTYPE field contains an 8-bit unsigned code according to the table below.
| Code | Method |
|---|---|
| 0 | Custom |
| 1 | Quadrants |
| 2 | Octants |
Custom edge picking (code 0) simply means the implementation is free to choose edges however it wants. It can also choose how to order EDGEDEF records.
Quadrant (code 1) and octant (code 2) edge picking involves splitting the area around central minutia into four or eight sectors respectively. There are no restrictions on how the sectors are rotated relatively to the minutia. For every sector, ridge count is recorded for the edge to the nearest minutia in that sector. Quadrant and octant picking places strict requirements on presence, ordering, and contents of EDGEDEF records as explained below.
Edge between minutiae (EDGEDEF)
The 3-byte EDGEDEF record contains ridge count (stored in RIDGECOUNT field) for a single edge between minutiae identified by EDGEFROM and EDGETO fields. The number of EDGEDEF records is derived from length of RCOUNTEXT. Field STARTYPE determines which edges are present.
EDGEDEF record ordering depends on STARTYPE:
- If STARTYPE is custom (code 0), EDGEDEF records are ordered first by EDGEFROM and then by EDGETO.
- If STARTYPE is set to quadrants (code 1) or octants (code 2), EDGEDEF records for single central minutia are listed together. There are no other ordering constraints for neither central nor neighbor minutiae.
If STARTYPE is set to quadrants (code 1) or octants (code 2), the structure of EDGEDEF records is defined in more detail. EDGEFROM identifies the central minutia while EDGETO identifies the neighbor minutia. If some quadrant or octant does not have any minutiae, implementation must emit a placeholder record with EDGETO and RIDGECOUNT fields zeroed, thus padding edge list for every central minutia to four or eight records respectively.
Note that the original spec is unclear about the ordering of edges in ridge count extension. For maximum compatibility, template encoders should sort everything by EDGEFROM and then by EDGETO while decoders should accept arbitrary ordering. The original spec is also ambiguous as to whether quadrant and octant ridge picking (see STARTYPE) requires implementations to consider all minutiae as central minutiae or whether central minutiae can be picked arbitrarily. To be safe, encoders should include edges for all minutiae while decoders should accept edge information for a subset of all minutiae.
Starting minutia of the edge (EDGEFROM)
An 8-bit unsigned offset into MINUTIAE field group. It identifies minutia that is on one end of the edge leading to EDGETO. If STARTYPE is quadrants (code 1) or octants (code 2), EDGEFROM is the central minutia.
Ending minutia of the edge (EDGETO)
An 8-bit unsigned offset into MINUTIAE field group. It identifies minutia that is on the other end of the edge starting in EDGEFROM. If STARTYPE is quadrants (code 1) or octants (code 2), EDGETO is the neighbor minutia. If the current EDGEDEF record is a placeholder for quadrant or octant devoid of minutiae, EDGETO is zero.
Number of crossed ridges (RIDGECOUNT)
An 8-bit unsigned number containing the number of ridges crossed by the edge. Ridge count does not include ridges connected to either EDGEFROM or EDGETO minutiae.
Curved ridges may be crossed more than once. The original spec doesn't say how to handle such cases, but it is reasonable to count every ridge only once.
If the current EDGEDEF record is a placeholder for quadrant or octant devoid of minutiae, RIDGECOUNT is zero. Note that zero is a valid value for very short edges. Zeroed RIDGECOUNT is ambiguous if EDGETO is also zero. Since very short edges are rare, implementations can assume that zero RIDGECOUNT means placeholder EDGEDEF record.
Core data extension (COREDATA)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 92 | context-specific | primitive | 12 |
COREDATA is an optional DER-TLV field group nested under FPSTRUCT with tag 92 (hex). It contains a list of cores found on the fingerprint. Core is loosely defined as a point that is partially or completely encircled by ridges.
Every core is defined in a COREDEF record. Number of cores is specified by CORENUM field. Presence or absence of COREANGLE field is indicated by CHASANGLE flag.
In ISO 19794-2:2005 off-card format, this field group is part of COREDELTA extension.
Number of cores (CORENUM)
Number of COREDEF records in the COREDATA extension encoded as an unsigned 8-bit number. Valid values are in range 0-15.
Core point (COREDEF)
COREDEF describes one core found on the fingerprint. COREDEF record repeats CORENUM times. Its structure is somewhat similar to NMINUTIA record. Every core has position (COREX, COREY). If CHASANGLE is set, every COREDEF also contains COREANGLE.
Core angle presence flag (CHASANGLE)
This 1-bit field occupies bit 14 (counting from zero) of the 16-bit big-endian unsigned number that also contains COREX. If it is set, COREANGLE field is present. If it is zero, COREANGLE is not recorded.
Core X position (COREX)
Equivalent of NMINX for cores. The spec is ambiguous about resolution of COREX, but it is probably safe to assume it has the same resolution as NMINX, i.e. 10-2mm.
This field occupies lower 14 bits of the 16-bit big-endian unsigned number that also contains CHASANGLE field.
If there are ridge endings enclosed in the core, position of the innermost ridge ending defines position of the core. Innermost ridge ending is defined only as "nearest to maximal curvature" of the enclosing ridge, which is not clear at all. It is probably safe to pick ending closest to extreme (farthest) point of the enclosing ridge.
If there are no enclosed ridge endings, then the end of the enclosed valley defines position of the core.
ISO 19794-2:2005 off-card format encodes the same field at configurable resolution (RESOLUTIONX).
Core Y position (COREY)
Core angle (COREANGLE)
This field is present only if the CHASANGLE flag is set. It contains an angle encoded in the same way as NMINANGLE, but its meaning is different.
Core angle is derived from direction of ridges closest to the core position, but the original spec is not clear whether core direction should point out or inside the core. It says that it "points towards the open side of the concave ridge", but it's not clear what is "open side". We can only guess this means the core angle points out of the core.
Whorl cores have no angle. CHASANGLE must be zero in this case.
Delta data extension (DELTADATA)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 93 | context-specific | primitive | 13 |
DELTADATA is an optional DER-TLV field group nested under FPSTRUCT with tag 93 (hex). It contains a list of deltas found on the fingerprint. Delta is loosely defined as the point where three distinct ridge flows meet.
Every delta is defined in a DELTADEF record. Number of deltas is specified by DELTANUM field. Presence or absence of DELTAANGLE fields is indicated by DHASANGLE flag.
In ISO 19794-2:2005 off-card format, this field group is part of COREDELTA extension.
Number of deltas (DELTANUM)
Number of DELTADEF records in the DELTADATA extension encoded as an unsigned 8-bit number. Valid values are in range 0-15.
Delta point (DELTADEF)
DELTADEF describes one delta found on the fingerprint. DELTADEF record repeats DELTANUM times. Its structure is somewhat similar to NMINUTIA record. Every delta has position (DELTAX, DELTAY). If DHASANGLE is set, every DELTADEF also contains three repeats of the DELTAANGLE field.
Delta angle presence flag (DHASANGLE)
This 1-bit field occupies bit 14 (counting from zero) of the 16-bit big-endian unsigned number that also contains DELTAX. If it is set, three repeats of the DELTAANGLE field are present. If it is zero, no DELTAANGLE is recorded.
Delta X position (DELTAX)
Equivalent of NMINX for deltas. The spec is ambiguous about resolution of DELTAX, but it is probably safe to assume it has the same resolution as NMINX, i.e. 10-2mm.
This field occupies lower 14 bits of the 16-bit big-endian unsigned number that also contains DHASANGLE field.
Delta position is defined as the center of weight of three points, each of which lies where two ridges approaching the delta diverge. Such definition doesn't cover all types of deltas though.
ISO 19794-2:2005 off-card format encodes the same field at configurable resolution (RESOLUTIONX).
Delta Y position (DELTAY)
Delta angle (DELTAANGLE)
This field is present three times if DHASANGLE flag is set and zero times otherwise. The field contains an angle encoded in the same way as NMINANGLE, but its meaning is different.
Delta angle is defined by direction of ridges before they diverge as they approach the delta. Delta angle points away from the delta.
If any of the three angles cannot be determined, the unused angle field should be filled with a copy of another angle. When the template is decoded, duplicate delta angles should be discarded.
Zonal quality extension (ZONALEXT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 94 | context-specific | primitive | 14 |
ZONALEXT is an optional DER-TLV field group nested under FPSTRUCT with tag 94 (hex).
ZONALEXT assigns quality scores to areas of the fingerprint. There are ZONESX times ZONESY zones. Each zone is is a square with size derived from ZONERES. Every zone has quality score with precision of ZONEBITS.
Meaning of zone quality scores is implementation-defined, which renders zonal quality data nearly useless.
In ISO 19794-2:2005 off-card format, this field group is encoded as an extension block. ZONEWIDTH and ZONEHEIGHT from ISO 19794-2:2005 off-card format were replaced with ZONESX, ZONESY, and ZONERES in order to deal with absence of WIDTH and HEIGHT fields.
Zone resolution (ZONERES)
Unsigned 8-bit number encoding resolution of zonal quality data in zones per decimeter (100mm). Resolution is the same along X and Y axis. Values are in range 20 to 255, which allows for zones that are 7.7px to 98px wide at 500dpi. Recommended value is 125.
This field is not part of ISO 19794-2:2005 off-card format, which has ZONEWIDTH and ZONEHEIGHT fields instead.
Horizontal zone count (ZONESX)
Number of zones in ZONALQUALITY data along X axis encoded as a non-zero unsigned 8-bit number.
This field is not part of ISO 19794-2:2005 off-card format, which infers zone count from WIDTH instead.
Vertical zone count (ZONESY)
Number of zones in ZONALQUALITY data along Y axis encoded as a non-zero unsigned 8-bit number.
This field is not part of ISO 19794-2:2005 off-card format, which infers zone count from HEIGHT instead.
Bits per zone (ZONEBITS)
Number of bits allocated for each zone in ZONALQUALITY data. This field is encoded as an unsigned 8-bit number. Allowed values include 1, 2, 4, 8, and the special value 0.
When ZONEBITS is zero, all zones specified by ZONESX, ZONESY, and ZONERES are considered to have sufficient quality. ZONALQUALITY is empty in this case.
Allowed values are different from ISO 19794-2:2005 off-card format.
Zonal quality data (ZONALQUALITY)
This field encodes a two-dimensional array of unsigned zonal quality values. Higher values mean higher image quality in the zone.
Number of zones is specified in ZONESX and ZONESY. Zones are encoded row by row top-down and left-to-right. Each zone takes up ZONEBITS bits. Zones are aligned to bits rather than bytes. Zones in one byte are laid out starting from the most significant bits and ending with the least significant bits. Unused least significant bits in the last byte of ZONALQUALITY are filled with zeroes.
When ZONEBITS is zero, this field is empty.
This field is the same as in ISO 19794-2:2005 off-card format except that its size is calculated differently and it can be empty when ZONEBITS is zero.
Nested plain minutia data (NESTEDMIN)
| Encoded tag | Class | P/C | Tag number |
|---|---|---|---|
| 5F2E | application | primitive | 2E |
NESTEDMIN is a DER-TLV field group nested under FPSTRUCT with tag 5F2E (hex). It is just an alternative location for PLAINMIN with identical contents. NESTEDMIN is not used when MINUTIAE or STDSTRUCT/STDMIN is present.
This field group is not part of ISO 19794-2:2005 off-card format. It is not mentioned in the ISO 19794-2:2005 spec, but it is described in underlying specifications (ISO 7816-11:2017).
Standard structured data (STDSTRUCT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | A1 | context-specific | constructed | 01 |
STDSTRUCT is a DER-TLV field group nested under FPSTRUCT with tag A1 (hex). When present, it contains MINUTIAE and optionally also RCOUNTEXT, COREDATA, DELTADATA, and ZONALEXT. It is used to encapsulate mentioned field groups when VENDORSTRUCT or VENDORPLAIN is also present in FPSTRUCT. It is not used when STDMIN is present.
This field group is not part of ISO 19794-2:2005 off-card format.
Standard minutia data (STDMIN)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 81 | context-specific | primitive | 01 |
STDMIN is a DER-TLV field group nested under FPSTRUCT with tag 81 (hex). It is a simpler alternative to STDSTRUCT. It is used instead of MINUTIAE when VENDORSTRUCT or VENDORPLAIN is also present in FPSTRUCT. When present, it has the same contents as MINUTIAE would have under FPSTRUCT. It is also a better choice for storing reduced minutia size format than MINUTIAE. STDMIN is not used when STDSTRUCT is present.
This field group is not part of ISO 19794-2:2005 off-card format.
Proprietary structured data (VENDORSTRUCT)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | A2 | context-specific | constructed | 02 |
VENDORSTRUCT is a DER-TLV field group nested under FPSTRUCT with tag A2 (hex). It contains implementation-defined structured (in DER-TLV sense) representation of the fingerprint. When present, STDSTRUCT or STDMIN must be also present.
This field group is not part of ISO 19794-2:2005 off-card format.
Proprietary binary data (VENDORPLAIN)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 82 | context-specific | primitive | 02 |
VENDORPLAIN is a DER-TLV field group nested under FPSTRUCT with tag 82 (hex). It contains implementation-defined primitive (in DER-TLV sense) representation of the fingerprint. When present, STDSTRUCT or STDMIN must be also present.
This field group is not part of ISO 19794-2:2005 off-card format.
Plain minutia data (PLAINMIN)
| Encoded tag | Class | P/C | Tag number |
|---|---|---|---|
| 5F2E | application | primitive | 2E |
PLAINMIN is a DER-TLV field group nested under FINGERPRINT with tag 5F2E (hex). It is a simpler alternative to FPSTRUCT. When present, it has the same contents as MINUTIAE would have under FPSTRUCT. It can also contain reduced minutia size format. PLAINMIN is not used when FPSTRUCT is present or when FINGERPRINT is just a container for FPHEADER/PARAMS reported by the card. It can be also nested under FPSTRUCT as NESTEDMIN.
This field group is not part of ISO 19794-2:2005 off-card format. It is not mentioned in the ISO 19794-2:2005 spec, but it is described in underlying specifications (ISO 7816-11:2017, ISO 19785-3:2015).