ISO/IEC 19794-2:2011/Cor.1:2012 Smartcard Summary
This is a complete description of fingerprint template format for smartcards defined in ISO/IEC 19794-2:2011 spec (often abbreviated ISO 19794-2:2011 or ambiguously ISO 19794-2), including minor fixes described in Technical Corrigendum 1 (Cor.1:2012), except for the following changes:
- Only smartcard variation is described here. Off-card format is described separately.
- Essential content from related ISO publications (ISO 19794-1:2011, 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:2011. There is no guarantee though and you should consult the original ISO/IEC 19794-2:2011 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:2011, ISO/IEC 19794-1:2011, 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:2011 is one of several fingerprint template formats that can be used for this purpose.
ISO 19794-2:2011 defines main off-card format and an additional smartcard format described here. Smartcard format is intended for use in smartcards, specifically those implementing ISO 7816-11.
ISO 19794-2:2011 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:2011 off-card format defined in the same spec, because it is substantially different.
This template format is a new version of older ISO 19794-2:2005. 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:2011 does not fully define the smartcard template format. It refers to ISO 19794-1:2011, 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 version of the smartcard format introduces several changes relative to ISO 19794-2:2005:
- Removed reduced minutia size format.
- SUBFORMAT has different set of values.
- MINUTIAE has DER-TLV tag 81 instead of 90. STDMIN, which previously had tag 81 and served as an alternative for MINUTIAE, is no longer part of the format.
- NMINUTIA was abandoned. CMINUTIA was kept as MINUTIA.
- Meaning of MINTYPE value 00 "other" was clarified.
- There's a recommended algorithm for calculating MINANGLE. Handling of trifurcations is defined.
- In ridge count extension, quadrant and octant alignment to minutia direction is now specified (see STARTYPE).
- Presence and ordering requirements for EDGEDEF records have changed.
- In ridge count extension, placeholder records set EDGETO and RIDGECOUNT fields to 255 rather than zero.
- Value of the RIDGECOUNT field is higher by one and algorithm to compute it is defined.
- COREANGLE and DELTAANGLE calculation is implementation-defined.
- MINHIGH pruning algorithm has changed.
- SAMPLETYPE field was added.
This smartcard format is a variation of ISO 19794-2:2011 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.
- 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 has different length and structure.
- FINGERPRINT has a variety of alternative representations. It can contain either PLAINMIN or FPSTRUCT. FPSTRUCT can then contain NESTEDMIN, STDSTRUCT, VENDORSTRUCT, and VENDORPLAIN as alternatives to preferred contents of MINUTIAE and extensions.
- 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, FPBYTES, DEVTECH, DEVVENDOR, DEVID, WIDTH, HEIGHT, RESOLUTIONX, RESOLUTIONY, VIEWOFFSET, HASCERTS, CERTCOUNT, CERTIFICATE (CERTIFIEDBY, CERTTYPE), FPQUALITY, QCOUNT, QRECORD, QALGO, MINBYTES, ENDINGTYPE, MINQUALITY, ZONEVENDOR, and ZONEALGO 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.
- SUBFORMAT is used to differentiate between ridge ending types instead of ENDINGTYPE.
- POSITION uses different codes and fewer values.
- Card can have limits on minutia count (MINRANGE) and require minutia sorting (MINSORT).
- Since there is no RESOLUTIONX/RESOLUTIONY, fields MINX and MINY are encoded at fixed resolution. The same applies to COREX/COREY and DELTAX/DELTAY.
- DATETIME has different structure.
- 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.
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 | 81 | context-specific | primitive | 01 | 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 | 95 | context-specific | primitive | 15 | SAMPLETYPE |
| 7F2E | A1 | context-specific | constructed | 01 | STDSTRUCT |
| 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:2011 off-card format, but it represents multi-fingerprint template just like the entire ISO 19794-2:2011 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:2011 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:2011 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:2011 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:2011 off-card format, which uses MAGIC field for similar purposes. It is not mentioned in the ISO 19794-2:2011 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:2011 off-card format with different codes and more positions. This field is not mentioned in the smartcard subformat description in ISO 19794-2:2011 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 has different structure in ISO 19794-2:2011 off-card format. It is not mentioned in the ISO 19794-2:2011 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:2011 off-card format, but it may be present with the same value in higher level data structures that wrap the 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). It is used to identify this fingerprint template format and additionally to indicate meaning of MINTYPE 01. It contains unsigned big-endian 16-bit number with possible values listed in the table below.
| Hex | Format | Minutia size | Ridge ending |
|---|---|---|---|
| 0005 | smartcard | 3 bytes | valley skeleton forking points |
| 0006 | smartcard | 3 bytes | ridge skeleton endpoints |
| 001D | off-card | 5/6 bytes | configurable via ENDINGTYPE |
Value 001D identifies ISO 19794-2:2011 off-card format, which is normally not embedded in DER-TLV framing used in this smartcard format.
Values 0005 and 0006 identify this smartcard format with following variations:
- 0006: MINTYPE value 01 means ridge skeleton endpoint.
- 0005: MINTYPE value 01 means valley skeleton forking point.
This field is not part of ISO 19794-2:2011 off-card format, but it may be present with value 001D (hex) in higher level data structures that wrap the off-card template. ISO 19794-2:2011 off-card format differentiates ridge ending type using ENDINGTYPE field. Set of allowed values has changed since ISO 19794-2:2005.
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:2011 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:2011 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:2011 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 according to the following priorities:
- lowest minutia quality (if available)
- largest distance from center of mass of all minutiae
- ridge endings before bifurcations
- largest minutia angle
Lower priority criteria are used only for minutiae that are equal according to all higher priority criteria. Center of mass is computed from minutia list before pruning starts.
This field is not part of ISO 19794-2:2011 off-card format. Pruning algorithm has changed since ISO 19794-2:2005.
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:2011 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:2011 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:2011 does not make it clear how to choose between X and Y sorting.
This field is not part of ISO 19794-2:2011 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.
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 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:2011 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:2011 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:2011 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:2011 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:2011 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:2011 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:2011 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 together with RCOUNTEXT, COREDATA, DELTADATA, and ZONALEXT
- STDSTRUCT or MINUTIAE alone with optional VENDORSTRUCT/VENDORPLAIN
- NESTEDMIN
If there is no VENDORSTRUCT/VENDORPLAIN, then MINUTIAE and extensions can be placed directly under FPSTRUCT. If VENDORSTRUCT/VENDORPLAIN is present, then all other field groups must be wrapped in STDSTRUCT. The only exception is that when there are no extensions, MINUTIAE can be placed directly under FPSTRUCT even when VENDORSTRUCT/VENDORPLAIN is present. NESTEDMIN is a special case defined only in underlying specififications (ISO 7816-11:2017).
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 interpretation of MINTYPE is defined by SUBFORMAT field, which is not part of FPSTRUCT.
This field group is not part of ISO 19794-2:2011 off-card format, which has only one representation for the fingerprint. NESTEDMIN is not mentioned in the ISO 19794-2:2011 spec, but it is described in underlying specifications (ISO 7816-11:2017). In ISO 19794-2:2005, MINUTIAE had tag 90. Tag 81 was assigned to STDMIN, which is not present in this version of the format.
Minutia list (MINUTIAE)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 81 | context-specific | primitive | 01 |
MINUTIAE is a DER-TLV field group nested under FPSTRUCT with tag 81 (hex). It contains MINUTIA records.
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.
If VENDORSTRUCT/VENDORPLAIN is present and there are extension field groups alongside MINUTIAE under FPSTRUCT, then MINUTIAE and other field groups must be wrapped in STDSTRUCT. MINUTIAE is not used (under FPSTRUCT) if NESTEDMIN or STDSTRUCT is present.
Minutiae are encoded differently from ISO 19794-2:2011 off-card format, which has explicit MINCOUNT field, different restrictions on minutia count, and somewhat different structure of its MINUTIA record. In ISO 19794-2:2005, this field group had tag 90 (hex) and it could also contain NMINUTIA records and reduced minutia size format.
Minutia record (MINUTIA)
MINUTIA records span 3 bytes each and carry minutia position (MINX, MINY), angle (MINANGLE), and type (MINTYPE).
ISO 19794-2:2011 off-card format has different order and sizes of fields and an extra MINQUALITY field.
Minutia X position (MINX)
MINX is an 8-bit unsigned number encoding location of the minutia on the fingerprint along X axis in units of 10-1mm. Higher values of MINX 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.
In ISO 19794-2:2011 off-card format, this field is in pixel units and it is larger. Since smartcard format has no RESOLUTIONX field, minutia position is encoded at fixed resolution of 10-1mm. Smartcard format has no WIDTH field either, which means there is no constraint on MINX other than that it is non-negative.
Minutia Y position (MINY)
Like MINX above but for Y axis. Higher values of MINY place the minutia further down. MINY is stored in an 8-bit unsigned field.
Minutia type (MINTYPE)
Minutia type is stored in the top two bits of the byte it shares with MINANGLE. 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.
Minutiae of type "other" can represent exotic minutiae that are neither ridge endings nor bifurcations. They can also represent ambiguous minutiae that cannot be reliably classified as either ridge endings or bifurcations. It follows that minutiae of type "other" should match all three minutia types. This is a clarification of wording from ISO 19794-2:2005.
Minutia angle (MINANGLE)
A 6-bit unsigned number holding quantized minutia angle in range 0-63. It occupies lower 6 bits of the byte it shares with MINTYPE.
Zero angle points to the right and angle increases counterclockwise. Dequantization to floating-point degrees is performed by multiplying MINANGLE 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.
If ridge ending is located at endpoint of ridge skeleton (see SUBFORMAT), ridge ending angle is the tangent of the ridge skeleton leg that terminates in the minutia. If ridge ending is located at forking point of valley skeleton (per SUBFORMAT), 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. Ridge bifurcation angle is similarly derived from legs of ridge skeleton. Minutiae of type "other" must have an implementation-defined angle.
Skeleton leg tangent is ambiguous, because skeleton legs curve a lot around skeleton forking point. The spec however defines recommended (but not required) method for calculating this tangent. Imagine a circle centered at the minutia with radius of 1.63mm (32px at 500dpi). This circle intersects with skeleton leg if the leg is long enough. Tangent of skeleton leg is then defined as the angle of a ray originating at minutia position and passing through this intersection. If the skeleton leg is not long enough, its end is taken instead of the intersection. If the endpoint is not at least 0.5mm away from minutia position, skeleton leg has no angle and the minutia must be discarded. This recommended procedure is a new addition since ISO 19794-2:2005.
Trifurcations, minutiae with four outgoing ridge skeleton legs, are represented by two minutiae that share the same position (MINX/MINY) and differ in MINANGLE. Handling of trifurcations is a new addition since ISO 19794-2:2005.
In ISO 19794-2:2011 off-card format, this field has higher resolution of 8 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:2011 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. Quadrants and octants are aligned to minutia's direction (MINANGLE) differently. For quadrants, minutia's direction lies between two quadrants. For octants, minutia's direction bisects some octant. 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.
Quadrant and octant alignment to minutia direction was added in this version of the format. ISO 19794-2:2005 didn't specify it.
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. If STARTYPE is custom (code 0), implementation is free to choose which edges to include. If STARTYPE is quadrants (code 1) or octants (code 2), ridge counts must be recorded for every quadrant/octant, but implementation can choose to completely omit some central minutiae with all their quadrants/octants.
EDGEDEF record ordering depends on STARTYPE. If STARTYPE is custom (code 0), EDGEDEF record ordering is implementation-defined. If STARTYPE is set to quadrants (code 1) or octants (code 2), EDGEDEF records for single central minutia are listed together ordered by octant/quadrant number. Both octants and quadrants are numbered counterclockwise. First octant is the one where minutia points. First quadrant is the "north-east" one if minutia points "south". See STARTYPE for description of quadrant and octant alignment.
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 set to 255.
ISO 19794-2:2005 was ambiguous as to whether every minutia should be considered as central minutia when STARTYPE is set to quadrants (code 1) or octants (code 2). This version of the format clarifies that it is not necessary to provide ridge count data for all minutiae. Edge ordering rules are different and less ambiguous. Format of placeholder edge record has changed.
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 255.
In ISO 19794-2:2005, placeholder record had EDGETO set to zero while this format sets it to 255.
Number of crossed ridges (RIDGECOUNT)
An 8-bit unsigned number containing the number of ridges crossed by the edge plus one. Ridges connected to either EDGEFROM or EDGETO minutiae are not considered crossed.
Ridge is crossed when it is crossed in ridge skeleton (single pixel wide representation of ridges). Ridge may be crossed more than once as long as valley skeleton is crossed at least once inbetween.
If the current EDGEDEF record is a placeholder for quadrant or octant devoid of minutiae, RIDGECOUNT is set to 255.
Value of RIDGECOUNT is higher by one compared to ISO 19794-2:2005. Placeholder record has RIDGECOUNT set to 255 instead of zero. Counting of ridge crossings is more precisely defined, including repeated crossings.
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:2011 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 MINUTIA 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 MINX for cores. The spec is ambiguous about resolution of COREX, but it is probably safe to assume it has the same resolution as MINX, i.e. 10-1mm.
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:2011 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 MINANGLE.
ISO 19794-2:2005 defined how core angle should be determined. This version of the format leaves it to the implementation arguing that core angle cannot be reliably determined.
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:2011 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 MINUTIA 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 MINX for deltas. The spec is ambiguous about resolution of DELTAX, but it is probably safe to assume it has the same resolution as MINX, i.e. 10-1mm.
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:2011 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. Every repeat of this field contains one of the three delta angles encoded in the same way as MINANGLE.
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.
ISO 19794-2:2005 defined how delta angles should be determined. This version of the format leaves it to the implementation arguing that delta angles cannot be reliably determined.
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:2011 off-card format, this field group is encoded as an extension block. ZONEWIDTH and ZONEHEIGHT from ISO 19794-2:2011 off-card format were replaced with ZONESX, ZONESY, and ZONERES in order to deal with absence of WIDTH and HEIGHT fields. Fields ZONEVENDOR and ZONEALGO are not part of smartcard format.
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:2011 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:2011 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:2011 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:2011 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:2011 off-card format except that its size is calculated differently and it can be empty when ZONEBITS is zero.
Impression type (SAMPLETYPE)
| Context | Encoded tag | Class | P/C | Tag number |
|---|---|---|---|---|
| 7F2E | 95 | context-specific | primitive | 15 |
SAMPLETYPE is an optional DER-TLV field nested under FPSTRUCT with tag 95 (hex). It contains 8-bit unsigned number indicating how the fingerprint was captured. Contrary to the vendor-defined DEVID, this field is actually useful, because its values are specified. Matching algorithms can use this information to adjust error tolerances and other parameters. Allowed values in range 0-9, 24, and 28-29 are described in the table below. Code 29 "Unknown" should be used as default.
| Code | Impression type |
|---|---|
| 0 | Live / plain |
| 1 | Live / rolled |
| 2 | Non-live / plain |
| 3 | Non-live / rolled |
| 4 | Latent / impression |
| 5 | Latent / tracing |
| 6 | Latent / photo |
| 7 | Latent / lift |
| 8 | Live / swipe |
| 9 | Vertical roll |
| 24 | Live / contactless (plain) |
| 28 | Other |
| 29 | Unknown |
This field is a new addition since ISO 19794-2:2005. This field is a fixed-size field in ISO 19794-2:2011 off-card format.
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 is present.
This field group is not part of ISO 19794-2:2011 off-card format. It is not mentioned in the ISO 19794-2:2011 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. If STDSTRUCT is present, then the field groups it can wrap cannot be also under FPSTRUCT.
This field group is not part of ISO 19794-2:2011 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 MINUTIAE must be also present.
This field group is not part of ISO 19794-2:2011 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 MINUTIAE must be also present.
This field group is not part of ISO 19794-2:2011 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. 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:2011 off-card format. It is not mentioned in the ISO 19794-2:2011 spec, but it is described in underlying specifications (ISO 7816-11:2017, ISO 19785-3:2015). In ISO 19794-2:2005, this field could also contain reduced minutia size format.