ISO/IEC 19794-2:2011/Cor.1:2012 Smartcard Summary

Fingerprint templates » ISO 19794-2:2011 » Smartcard

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:

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:

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:

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.

Repeats Delimiting Code Title
once TLV 7F61 GROUP Fingerprint group once TLV 02 FPCOUNT Number of fingerprints
FPCOUNT TLV 7F60 FINGERPRINT Fingerprint
optional TLV 7F2E FPSTRUCT Structured fingerprint data optional TLV 95 SAMPLETYPE Impression type optional TLV 5F2E NESTEDMIN Nested plain minutia data optional TLV A1 STDSTRUCT Standard structured data optional TLV A2 VENDORSTRUCT Proprietary structured data optional TLV 82 VENDORPLAIN Proprietary binary data
optional TLV 5F2E PLAINMIN Plain minutia data

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.

ContextEncoded tagClassP/CTag numberDefinition
 7F61applicationconstructed61GROUP
7F6102universalprimitive02 (integer)FPCOUNT
 7F60applicationconstructed60FINGERPRINT
7F60A1context-specificconstructed01FPHEADER
7F60/A181context-specificprimitive01MODALITY
7F60/A182context-specificprimitive02POSITION
7F60/A183context-specificprimitive03DATETIME
7F60/A187context-specificprimitive07OWNER
7F60/A188context-specificprimitive08SUBFORMAT
7F60/A1B1context-specificconstructed11PARAMS
7F60/A1/B181context-specificprimitive01MINRANGE
7F60/A1/B182context-specificprimitive02MINSORT
7F60/A1/B183context-specificprimitive03FEATUREBITS
 7F2Eapplicationconstructed2EFPSTRUCT
7F2E81context-specificprimitive01MINUTIAE
7F2E91context-specificprimitive11RCOUNTEXT
7F2E92context-specificprimitive12COREDATA
7F2E93context-specificprimitive13DELTADATA
7F2E94context-specificprimitive14ZONALEXT
7F2E95context-specificprimitive15SAMPLETYPE
7F2EA1context-specificconstructed01STDSTRUCT
7F2EA2context-specificconstructed02VENDORSTRUCT
7F2E82context-specificprimitive02VENDORPLAIN
 5F2Eapplicationprimitive2EPLAINMIN
Tags used in TLV fields and field groups

Fields and field groups

Fingerprint group (GROUP)

Encoded tagClassP/CTag number
7F61applicationconstructed61
Tag for GROUP field group

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)

ContextEncoded tagClassP/CTag number
7F6102universalprimitive02
Tag for FPCOUNT field

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 tagClassP/CTag number
7F60applicationconstructed60
Tag for FINGERPRINT field group

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)

ContextEncoded tagClassP/CTag number
7F60A1context-specificconstructed01
Tag for FPHEADER field group

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)

ContextEncoded tagClassP/CTag number
7F60/A181context-specificprimitive01
Tag for MODALITY field

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
01Multiple
02Face
04Voice
08Fingerprint
10Iris
20Retina
40Hand geometry
80Signature
0100Keystroke
0200Lip movement
0400Thermal face
0800Thermal hand
1000Gait
2000Body odor
4000DNA
8000Ear
010000Finger geometry
020000Palm geometry
040000Vein pattern
080000Footprint
Biometric modality types

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)

ContextEncoded tagClassP/CTag number
7F60/A182context-specificprimitive02
Tag for POSITION field

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.

BinaryHexHandFinger
0000000000UnknownUnknown
0010010125RightThumb
0010100129RightIndex
001011012DRightMiddle
0011000131RightRing
0011010135RightLittle
0010011026LeftThumb
001010102ALeftIndex
001011102ELeftMiddle
0011001032LeftRing
0011011036LeftLittle
Finger positions

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)

ContextEncoded tagClassP/CTag number
7F60/A183context-specificprimitive03
Tag for DATETIME field

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)

ContextEncoded tagClassP/CTag number
7F60/A187context-specificprimitive07
Tag for OWNER field

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)

ContextEncoded tagClassP/CTag number
7F60/A188context-specificprimitive08
Tag for SUBFORMAT field

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.

HexFormatMinutia sizeRidge ending
0005smartcard3 bytesvalley skeleton forking points
0006smartcard3 bytesridge skeleton endpoints
001Doff-card5/6 bytesconfigurable via ENDINGTYPE
Possible values of SUBFORMAT

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)

ContextEncoded tagClassP/CTag number
7F60/A1B1context-specificconstructed11
Tag for PARAMS field group

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)

ContextEncoded tagClassP/CTag number
7F60/A1/B181context-specificprimitive01
Tag for MINRANGE field group

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:

  1. lowest minutia quality (if available)
  2. largest distance from center of mass of all minutiae
  3. ridge endings before bifurcations
  4. 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)

ContextEncoded tagClassP/CTag number
7F60/A1/B182context-specificprimitive02
Tag for MINSORT field group

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.

Code (binary)Sort key
001MINX
010MINY
011MINANGLE
100polar distance (see below)
Minutia sort keys

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
01ascending
10descending
Minutia sort directions

This field is not part of ISO 19794-2:2011 off-card format.

Feature support (FEATUREBITS)

ContextEncoded tagClassP/CTag number
7F60/A1/B183context-specificprimitive03
Tag for FEATUREBITS field group

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 tagClassP/CTag number
7F2Eapplicationconstructed2E
Tag for FPSTRUCT field group

FPSTRUCT is a DER-TLV field group nested under FINGERPRINT with tag 7F2E (hex). It can contain several different representations of the fingerprint:

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)

ContextEncoded tagClassP/CTag number
7F2E81context-specificprimitive01
Tag for MINUTIAE field group

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:

BitsType
01Ridge ending / valley bifurcation
10Ridge bifurcation
00Other minutia type
Minutia types

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)

ContextEncoded tagClassP/CTag number
7F2E91context-specificprimitive11
Tag for RCOUNTEXT field group

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.

CodeMethod
0Custom
1Quadrants
2Octants
Edge picking methods

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)

ContextEncoded tagClassP/CTag number
7F2E92context-specificprimitive12
Tag for COREDATA field group

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)

Equivalent of MINY for cores. See notes under COREX.

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)

ContextEncoded tagClassP/CTag number
7F2E93context-specificprimitive13
Tag for DELTADATA field group

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)

Equivalent of MINY for deltas. See notes under DELTAX.

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)

ContextEncoded tagClassP/CTag number
7F2E94context-specificprimitive14
Tag for ZONALEXT field group

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)

ContextEncoded tagClassP/CTag number
7F2E95context-specificprimitive15
Tag for SAMPLETYPE field

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.

CodeImpression type
0Live / plain
1Live / rolled
2Non-live / plain
3Non-live / rolled
4Latent / impression
5Latent / tracing
6Latent / photo
7Latent / lift
8Live / swipe
9Vertical roll
24Live / contactless (plain)
28Other
29Unknown
Impression types

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 tagClassP/CTag number
5F2Eapplicationprimitive2E
Tag for NESTEDMIN field group

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)

ContextEncoded tagClassP/CTag number
7F2EA1context-specificconstructed01
Tag for STDSTRUCT field group

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)

ContextEncoded tagClassP/CTag number
7F2EA2context-specificconstructed02
Tag for VENDORSTRUCT field group

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)

ContextEncoded tagClassP/CTag number
7F2E82context-specificprimitive02
Tag for VENDORPLAIN field

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 tagClassP/CTag number
5F2Eapplicationprimitive2E
Tag for PLAINMIN field group

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.