Interoperable ways to code biometric data: focus on ISO/IEC 19794 series

  • Home
  • Interoperable ways to code biometric data: focus on ISO/IEC 19794 series

Error message

User warning: The following module is missing from the file system: cascading_grants_services. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1184 of /var/www/html/web/includes/bootstrap.inc).
28 Oct

Interoperable ways to code biometric data: focus on ISO/IEC 19794 series

ISO/IEC 19794 series provide interoperable ways to code biometric data, depending on the modality. This multipart standard provides a framework to be applied to all parts, some data formats for captured sample data (e.g. sample images), and some others for processed sample data (e.g. fingerprint minutiae data). This family of standards have currently two different generations defined, that are both still accepted. Also there is a 3rd generation standardized under the series ISO/IEC 39794 for extensible interchange biometric data formats, which are expected to supersede ISO/IEC 19794 in a near future.

The first generation of standards is the one published in 2005–2007, and it has been requested to be kept available by ISO/IEC to keep compliance with the standards up to 2040 of some world-wide applications, such as the ePassport. But for state-of-the-art projects it is recommended that either the 2nd generation or the 3rd generation of these standards is followed. The second generation is composed of those editions being published in 2011 and beyond this date under the series ISO/IEC 19794. The third generation will be published under the ISO/IEC 39794 series.

The structure of ISO/IEC 19794 is the following, considering it as a multipart standard: 

  • Part 1 provides a general framework to be applied to all the other parts. It defines the general structure for the biometric data records and the common elements of such structure. It tells that each biometric data information record (BDIR) is to be composed of a general header that introduces the information to be followed, and one or more representations (i.e. biometric samples from the same user and the same modality), which are structured into a representation header and the representation data. Part 1 defines those common elements of each of the headers. In a more generic way, Part 1 specifies the following:
    • general aspects for the usage of biometric data records;
    • the processing levels and types of biometric data structures;
    • a naming convention for biometric data structures;
    • coding scheme for format types.
       
  • Part 2 and successive parts provide the information about those extra elements to be added to the different headers, plus the way the representation data are to be coded. This is done for each of the modalities defined. Up to date, the following parts are defined, each for one modality:
    • Part 2: finger minutiae data
    • Part 3: finger pattern spectral data (discontinued in 2nd generation)
    • Part 4: finger image data
    • Part 5: face image data
    • Part 6: iris image data
    • Part 7: handwritten signature time series data
    • Part 8: finger pattern skeletal data
    • Part 9: vascular image data
    • Part 10: hand geometry silhouette data (discontinued in 2nd generation)
    • Part 11: handwritten signature processed dynamic data
    • Part 12: face identity data (discontinued even in 1st generation; i.e. never published)
    • Part 13: voice data (not for 1st generation)
    • Part 14: DNA data (not for 1st generation)
    • Part 15: palm crease image data (not for 1st generation)
    • Part 16: full body image data (only for 3rd generation)
    • Part 17: gait image sequence data (only for 3rd generation)

For some of these modalities, more than one biometric data is defined. Main differences between these biometric data for one modality are amount of data and computational effort. For ICC’s limited resources, i.e. size of storage and computational power, consideration of selecting biometric data and its format should be required. Differences among the ISO/IEC 19794 generations are mainly on two aspects:

  • Elements to be included and whether they are mandatory or optional. In between generations, it was detected the need of adding/removing fields (typically adding), and making them either mandatory or optional. Sometimes the decision on making a field mandatory have changed several times among generations (e.g. some fields might be mandatory in 2nd generation and then changed to optional in 3rd generation).
  • How the information is coded into the BDIR:
    • 1st generation: The coding was made purely binary, with no tags indicating which field is being coded. Therefore, the order and length of fields was fixed, with no possible dynamic change. This way of coding forced to add some length fields and, in some cases, fields indicating presence or absence of further optional fields. Only for Part 2 compact format, a TLV coding is defined, following the specifications given in ISO/IEC 7816-11 and ISO/IEC 19785-3 clause 11.
    • 2nd generation: Two different kind of coding are considered in this generation. The first one is a binary one, similar to the one defined for the 1st generation. Unfortunately, as new fields were included, and also some others changed their specification (including length), this binary coding is incompatible with the one of the 1st generation. The second coding defined is a XML coding, were all specified fields are defined within the XML schema. XML formats are unlikely to be utilized within on-card comparison or other biometrics and ICCs related system due to common restrictions on memory consumption within such ICCs.
    • 3rd generation (specified in ISO/IEC 39794 instead of a new edition of ISO/IEC 19794): Noting the lack of compatibility between the 1st and the 2nd generation, this 3rd generation has been defined to allow future backward compatibility. This is the reason for calling this series of standard as "Extensible biometric data interchange formats". The definition is initially specified using ASN.1 formal language, allowing implementations in TLV and XML.