ISO/IEC 30106-1:2016
(Main)Information technology — Object oriented BioAPI — Part 1: Architecture
Information technology — Object oriented BioAPI — Part 1: Architecture
ISO/IEC 30106-1:2016 specifies an architecture for a set of interfaces which define the OO BioAPI. Components defined in this part of ISO/IEC 30106 include a framework, Biometric Service Providers (BSPs), Biometric Function Providers (BFPs) and a component registry. NOTE Each of these components have an equivalent component specified in ISO/IEC 19784‑1 as the OO BioAPI is intended to be an OO interpretation of this part of ISO/IEC 30106. For this reason, this part of ISO/IEC 30106 is conceptually equivalent to ISO/IEC 19784‑1. Concepts present in this part of ISO/IEC 30106 (for example, BioAPI_Unit and component registry) have the same meaning as in ISO/IEC 19784‑1. While the conceptual equivalence of this part of ISO/IEC 30106 will be maintained with ISO/IEC 19784‑1, there are differences in the parameters passed between functions and the sequence of function calls. These differences exist to take advantage of the features provided by Object Oriented Programming Languages.
Technologies de l'information — Objet orienté BioAPI — Partie 1: Architecture
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 30106-1
First edition
2016-03-15
Information technology — Object
oriented BioAPI —
Part 1:
Architecture
Technologies de l’information — Objet orienté BioAPI —
Partie 1: Architecture
Reference number
ISO/IEC 30106-1:2016(E)
©
ISO/IEC 2016
---------------------- Page: 1 ----------------------
ISO/IEC 30106-1:2016(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 30106-1:2016(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
5 Object Oriented BioAPI architecture . 2
5.1 Summary of BioAPI architecture . 2
5.2 BioAPI compatibility requirements . 4
5.3 Graphical User Interface (GUI) . 4
5.4 Implementation guidelines . 6
5.4.1 Basic concepts . 6
5.4.2 BioAPI_Unit development . 6
5.4.3 BFP development . 6
5.4.4 BSP development . 7
5.4.5 Framework and component registry . 8
5.4.6 Application development . 8
6 BioAPI CBEFF Patron Formats . 8
6.1 General . 8
6.2 Simple BIR . 8
6.3 Complex BIR .14
6.3.1 Structure .14
6.3.2 Child BIR .14
6.3.3 Parent BIR .14
7 Constants .17
7.1 General .17
7.2 Biometric types .17
7.3 Biometric subtypes .17
7.4 Error codes .18
8 OO BioAPI UML structure .21
8.1 General .21
8.2 Relationships among data structures .22
8.2.1 Class BIR .22
8.2.2 Class UnitSchema .23
8.2.3 Class BFPSchema .24
8.2.4 Class BSPSchema .24
8.2.5 Class FrameworkSchema .25
8.3 BioAPI_Unit structures .25
8.3.1 IArchive .25
8.3.2 IComparison .26
8.3.3 IProcessing .26
8.3.4 ISensor .27
8.4 BFP Structure .27
8.5 BSP Structure .28
8.6 Framework structure .28
8.7 Application related structure .29
© ISO/IEC 2016 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 30106-1:2016(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 37, Biometrics.
ISO/IEC 30106 consists of the following parts, under the general title Information technology — BioAPI
for object oriented programming languages:
— Part 1: Architecture
— Part 2: Java implementation
— Part 3: C# implementation
iv © ISO/IEC 2016 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 30106-1:2016(E)
Introduction
The existing versions of BioAPI (ANSI version-INCITS 358 and ISO/IEC 19784-1) specify an application
programming interface expressed in the C language. The use of a portable language like C ensures
the BioAPI is accessible across multiple computing platforms and application domains. BioAPI is an
appropriate fit for applications written in C and is adequate for applications written in C++.
Unfortunately, a function-based language like C does not map easily to the object oriented domain where
this issue may be answered with an object oriented (OO) version of BioAPI. As noted, the function-
based nature of a C API does not map easily to the object oriented paradigm (i.e. languages such as C#
and Java). In particular, the use of a C API from within an object oriented application is unnatural and
requires programming constructs which introduce complexity to the development of an application.
Development of a OO version of BioAPI aims to increase the productivity of software practitioners who
who wish to use the BioAPI whilst remaining in the object oriented domain.
A standard object oriented version of BioAPI allows, in case of Java, BSPs that are intended for loading
into a Java-based application server to perform verification and/or identification operations. In those
application servers, use of the OO BioAPI is more natural when developing a framework and BSPs than
the C version of BioAPI.
Another area in which a standard OO version of BioAPI would be useful is that of small computing
devices based on an object oriented language (OOL), where (as on the large application servers
mentioned above) an OO BioAPI framework and OO BSPs would fit better than their C counterparts.
This part of ISO/IEC 30106 is expected to have the following impact:
— enable creation of BioAPI applications by developers more comfortable with Object Oriented
Languages;
— create a market of standard OO BSP components which target OO environments such as Java
application servers, Java applets, small Java devices, .NET servers, .NET applications, web services;
— increase the level of adoption of BioAPI by decreasing the barrier of entry for OO developers. This
includes providing access to C based BSPs (as if they were OO BSPs) through special versions of the
BioAPI framework, bridging a standard OO BioAPI framework to a standard C BioAPI framework.
© ISO/IEC 2016 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 30106-1:2016(E)
Information technology — Object oriented BioAPI —
Part 1:
Architecture
1 Scope
This part of ISO/IEC 30106 specifies an architecture for a set of interfaces which define the OO BioAPI.
Components defined in this part of ISO/IEC 30106 include a framework, Biometric Service Providers
(BSPs), Biometric Function Providers (BFPs) and a component registry.
NOTE Each of these components have an equivalent component specified in ISO/IEC 19784-1 as the OO
BioAPI is intended to be an OO interpretation of this part of ISO/IEC 30106.
For this reason, this part of ISO/IEC 30106 is conceptually equivalent to ISO/IEC 19784-1. Concepts
present in this part of ISO/IEC 30106 (for example, BioAPI_Unit and component registry) have the same
meaning as in ISO/IEC 19784-1. While the conceptual equivalence of this part of ISO/IEC 30106 will be
maintained with ISO/IEC 19784-1, there are differences in the parameters passed between functions
and the sequence of function calls. These differences exist to take advantage of the features provided
by Object Oriented Programming Languages.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 2382-37, Information technology — Vocabulary — Part 37: Biometrics
ISO/IEC 19784-1:2006, Information technology — Biometric Application Programming Interface — Part
1: BioAPI Specification
ISO/IEC 19785-1:2015, Information technology — Common Biometric Exchange Formats Framework —
Part 1: Data Element Specification
ISO/IEC 19785-3:2015, Information technology — Common Biometric Exchange Formats Framework —
Part 3: Patron format specifications
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 2382-37, ISO/IEC 19784-1, and
ISO/IEC 19785 (all parts) apply.
4 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms defined in ISO/IEC 19784-1,
ISO/IEC 19785 (all parts) and the following apply.
API Application Programming Interface
BDB Biometric Data Block
BFP Biometric (OO) Function Provider
© ISO/IEC 2016 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 30106-1:2016(E)
BIR Biometric Information Record
BSP Biometric Service Provider
CBEFF Common Biometric Exchange Formats Framework
FMR False Match Rate
FPI Function Provider Interface
GUI Graphical User Interface
ID Identity/Identification/Identifier
MOC Match on Card
OOBioAPI Object Oriented BioAPI
PID Product ID
SB Security Block
NOTE This term and abbreviation is imported from ISO/IEC 19785-1.
SBH Standard Biometric Header
NOTE This term and abbreviation is imported from ISO/IEC 19785-1.
SPI Service Provider Interface
UUID Universally Unique Identifier
5 Object Oriented BioAPI architecture
5.1 Summary of BioAPI architecture
Object Oriented BioAPI shall be defined in a way that allows both structured development of applications
and services, as well as interoperability between application and BSPs, and among BSPs. Therefore, the
definition has to be done respecting the hierarchical structure of BioAPI (19784-1). In few words, an
application shall be developed using an OO BioAPI that allows the instantiation of a BSP, which is based
on the instantiation of one or several BioAPI_Units. The BSP can host more than one BioAPI_Unit of each
category, and several units of each type can be used at any time, no presenting any kind of limitation
on the units to be used in a BSP. This makes it necessary for all methods to provide the reference to the
unit to be used in each of the operations.
An application is not permitted to directly access BioAPI_Units. Therefore, this part of ISO/IEC 30106
does not define a BioAPI_Unit interface, but only an object oriented hierarchical interface/class
model that may ease the implementation of the BSP. The BSP shall inherit all public methods and data
structures for each BioAPI_Unit the BSP encapsulates. It is the responsibility of the BSP’s implementation
to determine which functions of the BioAPI_Unit are offered to clients of the BSP. Note, an exception
should be returned for any BSP interface method that is not implemented in the BSP. This is represented
in Figure 1.
Programming an application, which interacts directly with a BSP, introduces practical considerations
for the application designer. One such consideration is dealing with third-party suppliers who provide
biometric components for use in applications. For example, a supplier of sensors may desire to include
support for their entire family of sensors as a single entity (e.g. a library). To achieve this, the supplier
may consider implementing the library as a single BSP, but may choose to not implement monolithic
methods (i.e. aggregated functionality such as Enrol, which does in one single call the capture, the
processing of the sample, the creation of the biometric reference and even the archiving). Without
monolithic methods, the BSP forces the application to take responsibility for the implementation
of monolithic style functionality. This situation means the BSP may pass biometric data back to the
application so the application may perform processing. The application may then need to pass this data
on to another BSP for additional processing. In some contexts, the passing of data out to an application
may simply be inefficient, in other contexts this may be a security concern. A possible solution for this
inconvenience is to allow the hypothetical sensor BSP to interact directly with other BSPs, rather than
involving the application in the management of this communication. To achieve this, the biometric
2 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 30106-1:2016(E)
product provider may create an entity (e.g. a library) containing several BioAPI_Units of the same kind.
This is called a Biometric Function Provider (BFP) and exhibits the following characteristics.
— The BFP shall only host BioAPI_Units of the same category.
— The BFP is meant to allow that a BSP is linked to one of its BioAPI_Units, in order to complete or
adapt the functionality of the BSP.
— The BFP shall not provide functionality directly to the application, but only link to the BSP. The BSP
communicates with the BFP on behalf of the application. The BSP is responsible for providing the
BFP’s functionality to the application.
The above mentioned situation also solves a problem from developers’ point of view, which deals with
simplicity in developing applications. If an application may require to use BioAPI_Units from different
providers (e.g. a sensor from one provider and processing, comparison and archive BioAPI_Units from
other provider), then it will have to load two different BSPs, calling each of the methods independently.
As mentioned earlier, this has the inconvenience that it won’t be possible to call a monolithic method,
such as Verify(), which performs the data capture, the processing, extraction of the biometric reference
from the database, the comparison and taking the decision, all within the same single call. Then, the
application programmer will have to know which individual methods have to be called from each of
the BSPs, in order to get the same functionality. To summarize, a level of abstraction and efficiency is
achieved through the use of BFPs to segregate functionality into discrete sets. Each BFP aggregates a
set of functionality provided by a product supplier (through a BioAPI_Unit). These BFPs are used by
a BSP, where the BSP combines functionality from each BFP to offer monolithic methods for use by a
client. The client application may then call the monolithic methods in the BSP without concern for the
underlying implementation offered by a product supplier.
Another consideration for an application designer is the concern about security in regards to certain
operations. Biometric data is typically sensitive personal data and some implementations of OO BioAPI
may require the client application is not capable of directly accessing this data (ie: BIRs). By taking
advantage of BFPs, and the abstraction facilities they offer, the possibility of tampering by malware or
malicious users at the application level is removed. By using BFPs, all sensitive data will be handled at
a level no higher than the BSP level. This means no BIR will be accessible to the application, not only
simplifying application development, but eases concerns in relation to security.
The BFP shall not be accessed directly by the application. BioAPI calls are created to allow the
application to know the BioAPI_Units that are contained in the BFPs so that the application may later
request one BSP to include one of those BioAPI_Units of the BFP. This is done through a component
registry and the procedure is further described in 5.4.
All the above ideas shall be implemented to allow the dynamic selection of components to be used by
the application, but with no a-priori knowledge from the application developer. This is achieved by
the inclusion of a common framework, which shall be installed in the system where the application
is expected to be running. Then, the application shall request the framework for the list of the BSPs
and BFPs installed, select the BSPs (with the requested selection of BioAPI_Units from BFPs) to be
instantiated dynamically by the framework, and then accessing their methods and data structures
through the framework. The application shall never be allowed to access the BSPs directly. This is
summarized in Figure 1.
© ISO/IEC 2016 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 30106-1:2016(E)
Figure 1 — Generic structure of a framework-based application
BSPs may be accessed by several applications at the same time, and it may also happen that BioAPI_
Units in the BFPs are also accessed by several BSPs at the same time. It is up to the implementation
of the framework the way that this implemented (e.g. this may be done by queuing requests from the
different sources, or by responding to occurring events).
For those developers that are familiar with ISO/IEC 19784, it is important to provide a relationship
about the interfaces there defined and the different layers that compose these International Standards.
The correspondence between both International Standards is given in Table 1.
Table 1 — Correspondence between ISO/IEC 30106 and ISO/IEC 19784 interfaces
Interface in ISO/IEC 30106 Interface in ISO/IEC 19784
IFramework API
IBSP SPI
IBFP SFPI
Along the ISO/IEC 30106 series, the Unit level will be also specified, not as for specifying a different
interface, but for structuring in a hierarchical way the support for each of the categories of BioAPI_
Units at the IBSP or IBFP interfaces.
5.2 BioAPI compatibility requirements
This part of ISO/IEC 30106 is defined as compatible with BioAPI version 3.0 (ISO/IEC 19784-1.revision
1), but the framework may be developed as to allow the cross compatibility with previous versions
of BioAPI, as to allow BioAPI 2.x compliant BSPs and BFPs to be used in an ISO/IEC 30106 compliant
application.
There is no provision to allow Object Oriented BSPs to be used in an ISO/IEC 19784-compliant
framework and application.
5.3 Graphical User Interface (GUI)
A BSP may handle by itself, the interaction between the user and the system. For example, a BSP with
a sensor BioAPI_Unit may address all the interaction by the displaying messages, illuminating LEDs
4 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 30106-1:2016(E)
and/or activating sounds at the sensor itself. Such kind of interaction may include providing feedback
to the user on
— the finger to be placed at the sensor,
— how to improve the location of the sample in the sensor (e.g. alignment of the biometric characteristic
in relation to the sensor active area),
— whether the acquisition has been done in a correct way, or
— whether the biometric comparison has led to a positive or negative decision.
But in certain cases, it may be requested that such interaction is handled by the application using such
BSP, showing all messages and illustrations in the computer screen. This may also be handled by the
BSP itself, but this can lead to certain kinds of inconveniences such as the following:
— the BSP graphical user interface may not be adaptable to the different sizes and resolutions that the
application screen is using;
— the feedback provided has to follow the same look and feel as the main application, including the use
of service provider logos;
— the feedback has to be adaptable to the language of the user being identified, or where the system is
deployed.
In those cases, it is recommended in order to avoid re-programming the BSP or increasing the
complexity of the BSP, the interaction is handled by the application itself. As the feedback depends on
the specific step that the BSP is executing, and those steps are mostly controlled by the BSP (i.e. most
BSP functions are offered to the application as monolithic methods), then the way to solve this is by
using callback functions.
Callback functions shall be developed for each step where a BSP is required to either interact with, or
provide feedback to, a user. Naturally, the application shall provide a set of functions the BSP’s callbacks
will map to, which the BSP will call within the context of the original method call.
Therefore, if the BSP allows the use of callback functions for handling the GUI, the following development
actions shall be taken, for each of the processes requiring such interaction (e.g. Capture).
— The application shall implement all GUI related functions for such process. These functions are of
the following kinds:
— Select Function: to show the interaction with the user at the beginning or the end of the whole
process.
EXAMPLE At the beginning the process, the following message may be provided: “Capture process for
the index finger of the right hand”. And at the end of the process, the message to be given could be: “Acquisition
finished. Thank you!”. Therefore, the callback function shall know if it is being called at the beginning of the
process, or at the end. Also, the callback function can also provide the BSP with information about a user
action, such as cancelling the capture process. All this information flow is provided in parameters of the
callback function.
— State Function: Sometimes the BSP process may take several internal steps, which can be
designed a
...
DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 30106-1
ISO/IEC JTC 1/SC 37 Secretariat: ANSI
Voting begins on: Voting terminates on:
2014-12-04 2015-03-04
Information technology — BioAPI for object oriented
programming languages —
Part 1:
Architecture
Titre manque
ICS: 35.040
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 30106-1:2014(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2014
---------------------- Page: 1 ----------------------
ISO/IEC DIS 30106-1:2014(E)
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO’s
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2014 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC DIS 30106-1
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Conformance . 1
3 Normative references . 1
4 Terms and definitions . 1
5 Symbols and abbreviated terms . 1
6 Object Oriented BioAPI architecture . 2
6.1 Summary of BioAPI architecture . 2
6.2 BioAPI compatibility requirements . 4
6.3 Graphical User Interface (GUI) . 5
6.4 Implementation guidelines . 6
6.4.1 Basic concepts . 6
6.4.2 BioAPI_Unit development. 6
6.4.3 BFP development . 7
6.4.4 BSP development . 8
6.4.5 Framework and component registry . 8
6.4.6 Application development . 9
7 BioAPI C# CBEFF Patron Formats . 9
8 Constants . 9
8.1 General . 9
8.2 Biometric Types . 9
8.3 Biometric Subtypes . 10
8.4 Error Codes . 10
9 OO BioAPI UML Structure . 13
9.1 Introduction . 13
9.2 Relationships among data structures . 14
9.2.1 Class BIR . 14
9.2.2 Class UnitSchema . 15
9.2.3 Class BFPSchema . 16
9.2.4 Class BSPSchema . 17
9.2.5 Class FrameworkSchema . 18
9.3 BioAPI_Unit structures . 18
9.3.1 IArchive. 18
9.3.2 IComparison . 19
9.3.3 IProcessing . 19
9.3.4 ISensor. 20
9.4 BFP Structure . 20
9.5 BSP Structure . 21
9.6 Framework structure . 22
9.7 Application related structure . 22
Annex A (normative) Conformance statements . 23
A.1 General . 23
A.2 BioAPI OO Conformant Biometric Application . 23
A.3 BioAPI OO Conformant Framework . 23
A.4 BioAPI OO Conformant BSPs . 24
A.4.1 BioAPI OO Conformant Verification BSPs . 26
A.4.2 BioAPI OO Conformant Identification BSPs . 27
© ISO/IEC 2014 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC DIS 30106-1
A.4.3 BioAPI OO Conformant Capture BSPs . 28
A.4.4 BioAPI Conformant Verification Engines . 28
A.4.5 BioAPI OO Conformant Identification Engines . 29
A.4.6 Optional Capabilities . 29
Annex B (informative) Mapping between ISO/IEC 19784-1 and ISO/IEC 30106 . 35
B.1 Introduction . 35
B.2 Data Types . 35
B.3 Unit Classes . 46
B.3.1 Archive unit classes . 46
B.3.2 Comparison unit classes . 49
B.3.3 Processing unit classes . 52
B.3.4 Sensor unit classes . 54
B.4 BFPs . 55
B.5 BSPs . 57
B.6 Component Registry . 66
B.7 Framework . 67
iv © ISO/IEC 2014 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC DIS 30106-1
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 30106-1 was prepared by Technical Committee ISO/TC JTC1, Information Technology,
Subcommittee SC 37, Biometrics.
This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
ISO/IEC 30106 consists of the following parts, under the general title Information Technology — BioAPI for
Object Oriented Programming Languages:
Part 1: Architecture
Part 2: Java implementation
Part 3: C# implementation
© ISO/IEC 2014 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC DIS 30106-1
Introduction
The existing versions of BioAPI, the ANSI version-INCITS 358 and ISO/IEC 19784-1, specify an application
programming interface expressed in the C language. The use of this language ensures the wide applicability
and implementability of BioAPI across multiple computing platforms and application domains. This API is an
appropriate fit for applications written in the same language, and is adequate for applications written in C++.
Lack of portability of applications written in C is an issue that can be answered with an object oriented (OO)
version of BioAPI. A C API does not work well with applications written in Java, C#, and other programming
languages. In particular, the use of a C API from within an Object oriented (apart from C++) application is very
unnatural, and requires certain programming artifices that introduce complications in the application, thus
increasing the cost of application development and maintenance. If a standard OO version of BioAPI were
available, the development of Java, C#, etc. applications that use a standard biometric API would be easier
and cheaper than it is today.
A standard Object Oriented version of BioAPI would also allow, in case of Java, BSPs that are intended for
loading into a Java-based application server to perform verification and/or identification operations. In those
application servers, a Java BioAPI framework and Java BSPs would work better than their C counterparts.
Another area in which a standard OO version of BioAPI would be useful is that of small computing devices
based on object oriented language (OOL), where (as on the large application servers mentioned above) a OO
BioAPI framework and OO BSPs would fit better than their C counterparts.
This standard is expected to have the following impact:
Enable creation of many new BioAPI applications by developers more comfortable with Object
Oriented Languages.
Create a market of OO components that are standard OO BioAPI BSPs, and that can be used (along
with a OO BioAPI framework) in OO environments such as Java-based application servers, Java
applets, or small Java-based devices, .NET servers, .NET applications, Web Services;and
Increase the level of adoption of BioAPI by enabling OO application developers to access C BSPs
(as if they were OO BSPs) through special versions of the BioAPI framework that will bridge a
standard OO BioAPI framework to a standard C BioAPI framework.
vi © ISO/IEC 2014 – All rights reserved
---------------------- Page: 6 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/IEC DIS 30106-1
Information Technology — BioAPI for Object Oriented
Programming Languages — Part 1: Architecture
1 Scope
The proposed standard will specify a generic architecture for the interface of a BioAPI OO framework and
BioAPI OO BSP which will mirror the corresponding components specified in ISO/IEC 19784-1. Therefore, the
position occupied by the proposed standard within the general picture of biometrics standards will be the
same position that ISO/IEC 19784-1 occupies, the only difference being the programming language of the
interfaces. The concepts such as BioAPI_Unit, component registry, etc. are present in this standard and will
have the same meaning as in ISO/IEC 19784-1. The semantic equivalence of this standard will be maintained
with ISO/IEC 19784-1, but there are differences in actual parameters passed between functions and the
sequence of function calls. These differences exist to take advantage of the object oriented benefits of Object
Oriented Programming Languages.
2 Conformance
Annex A specifies the conformance requirements for systems/components claiming conformance to this
standard.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 19784-1:2006, Information Technology – Biometric Application Programming Interface – Part 1:
BioAPI Specification
ISO/IEC 19785-1:2006, Information Technology – Common Biometric Exchange Formats Framework – Part 1:
Data Element Specification
ISO/IEC 19785-2:2006, Information Technology – Common Biometric Exchange Formats Framework – Part 2:
Procedures for the Operation of the Biometric Registration Authority
4 Terms and definitions
For the purposes of this document, the terms defined in ISO/IEC 19784-1, ISO/IEC 19785 and ISO 2382-37
apply.
5 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms defined in ISO/IEC 19784-1, ISO/IEC
19785 and the following applies:
API – Application Programming Interface
BDB – Biometric Data Block
BFP – Biometric (OO) Function Provider
© ISO/IEC 2014 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC DIS 30106-1
BIR – Biometric Information Record
BSP – Biometric Service Provider
CBEFF – Common Biometric Exchange Formats Framework
FMR – False Match Rate
FPI – Function Provider Interface
GUI – Graphical User Interface
ID – Identity/Identification/Identifier
MOC – Match on Card
OOBioAPI – Object Oriented BioAPI
PID – Product ID
SB - Security Block
NOTE This term and abbreviation is imported from ISO/IEC 19785-1.
SBH – Standard Biometric Header
NOTE This term and abbreviation is imported from ISO/IEC 19785-1.
SPI – Service Provider Interface
UUID – Universally Unique Identifier
6 Object Oriented BioAPI architecture
6.1 Summary of BioAPI architecture
Object Oriented BioAPI shall be defined in a way that allows both, structured development of applications and
services, as well as interoperability between application and BSPs, and among BSPs. Therefore the definition
has to be done respecting the hierarchical structure of BioAPI (19784-1). In few words, this has to allow the
development of applications in a system based on a BioAPI Framework, as well as applications in a system
where no Framework is used (framework-free). Starting with the latter, and application in a framework-free
based system shall be developed using an OO BioAPI that allows the instantiation of a BSP, which is based
on the instantiation of one or several BioAPI_Units. The BSP can host more than one BioAPI_Unit of each
category, and when a session is attached, several units of each type can be selected, no presenting any kind
of limitation on the units to be used in a BSP. This makes it necessary for all methods to provide the reference
to the unit to be used in each of the operations.
It is not allowed that the application access BioAPI_Units directly. Therefore this International Standard does
not define a BioAPI_Unit interface, but only an object oriented hierarchical interface/class model that may
ease the implementation of the BSP. The BSP shall inherit all public methods and data structures of the
BioAPI_Units, and it is up to the implementation of the BSP implementation to decide which of them are
offered to the external world, and which of them are only returning the lack of support of such method. This is
represented in the following figure.
Programming an application using a direct connection with the BSPs, rises certain concerns in practical
situations. The first concern is dealing with industry providing elements to be used in applications. It may
happen that a provider is only providing sensors, and would like to include support to all its family of sensors
2 © ISO/IEC 2014 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC DIS 30106-1
as a single entity (e.g. a library). That provider may consider implementing that as a single BSP, but not being
interested in providing monolithic methods (i.e. aggregated functionality such as Enrol, which does in one
single call the capture, the processing of the sample, the creation of the biometric reference and even the
archiving). Therefore it will need to request these kind of functions to be done at the application level,
exchanging biometric information between the BSP and the application. Then, the application may forward
that biometric data to another BSP to complete the action. So a possible solution for this inconvenience is to
allow those sensors to directly interact with other BSPs, instead of using the application for that. To achieve
this, the biometric product provider may create an entity (e.g. a library) containing several BioAPI_Units of the
same kind. This is called a Biometric Function Provider (BFP), which has mainly the following characteristics:
The BFP shall only host BioAPI_Units of the same category.
The BFP is meant to allow that a BSP is linked to one of its BioAPI_Units, in order to complete or
adapt the functionality of the BSP.
The BFP shall not provide functionality to the application, but only the link to the BSP. It is the BSP
the one providing functionality to the application.
The above mentioned situation also solves a problem from developers' point of view, which deals with
simplicity in developing applications. If an application may require to use BioAPI_Units from different providers
(e.g. a sensor from one provider and processing, comparison and archive BioAPI_Units from other provider),
then it will have to load two different BSPs, calling each of the methods independently. As mentioned earlier,
this has the inconvenience that it won't be possible to call a monolithic method, such as Verify(), which
performs the data capture, the processing, extraction of the biometric reference from the database, the
comparison and taking the decision, all within the same single call. Then the application programmer will have
to know which individual methods have to be called from each of the BSPs, in order to get the same
functionality. So, by using a BSP that supports monolithic methods, and requesting that BSP to be linked to
those BioAPI_Units for the BFPs of other product providers, once that link is established, then the application
can call those monolithic methods without taking into account that the functionality is provided by different
vendors.
Last, but not least, there is a concern about security in certain operations. As biometric data is sensible
personal data, some clients may require that the biometric application will not be able to access directly the
user biometric data (i.e. the BIRs), avoiding the possibility of malware to tamper with such data. By using
BFPs, all sensible data will be handled at the BSP level, and no BIR may be accessible to the application, not
only simplifying the application development (by the use of monolithic methods), but also the security level
achieved.
The BFP shall not be accessed directly by the application. BioAPI calls are created to allow the application to
know the BioAPI_Units that are contained in the BFPs so that the application may later request one BSP to
attach one of those BioAPI_Units of the BFP. This is done through a component registry and the procedure is
further described in 6.4.
All the above ideas shall be implemented to allow the dynamic selection of components to be used by the
application, but with no a-priori knowledge from the application developer. This is achieved by the inclusion of
a common framework, which shall be installed in the system where the application is expected to be running.
Then the application shall request the framework for the list of the BSPs and BFPs installed, select the BSPs
(with the requested attachment of BioAPI_Units from BFPs) to be instantiated dynamically by the framework,
and then accessing their methods and data structures through the framework. The application shall never be
allowed to access the BSPs directly. This is summarized in the following figure.
© ISO/IEC 2014 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC DIS 30106-1
Application
Component Registry
Framework
BSP1 BSPm
Unit1 Unit2 UnitQ
BFP
Unit1 Unit2 UnitN Unit1 Unit2 UnitP
Figure 1: Generic structure of a framework-based application
BSPs may be accessed by several applications at the same time, and it may also happen that BioAPI_Units in
the BFPs are also accessed by several BSPs at the same time. It is up to the implementation of the
framework the way that this implemented (e.g. this may be done by queuing requests from the different
sources, or by responding to occurring events).
For those developers that are familiar with ISO/IEC 19784, it is important to provide a relationship about the
interfaces there defined, and the different layers that compose this International Standards. The
correspondence between both International Standards is given in the following table:
Table 1 — Correspondence between ISO/IEC 30106 and ISO/IEC 19784 interfaces
Interface in ISO/IEC 30106 Interface in ISO/IEC 19784
IFramework API
IBSP SPI
IBFP SFPI
Along all parts of this International Standard, the Unit level will be also specified, but not as for specifying a
different interface, but for structuring in a hierarchical way the support for each of the categories of
BioAPI_Units at the IBSP or IBFP interfaces.
6.2 BioAPI compatibility requirements
This International Standard is defined as compatible with BioAPI version 3.0 (ISO/IEC 19784-1.revision 1), but
the framework may be developed as to allow the cross compatibility with previous versions of BioAPI, as to
allow BioAPI 2.x compliante BSPs and BFPs to be used in an ISO/IEC 30106 compliant application.
There is no provision to allow Object Oriented BSPs to be used in an ISO/IEC 19784 compliant framework
and application.
4 © ISO/IEC 2014 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC DIS 30106-1
6.3 Graphical User Interface (GUI)
A BSP may handle by itself the interaction between the user and the system. For example, a BSP with a
sensor BioAPI_Unit may address all the interaction by the displaying messages, illuminating LEDs and/or
activating sounds at the sensor itself. Such kind of interaction may include providing feedback to the user on:
the finger to be placed at the sensor,
how to improve the location of the sample in the sensor (e.g. alignment of the biometric characteristic
in relation to the sensor active area),
whether the acquisition has been done in a correct way, or
whether the biometric comparison has led to a positive or negative decision.
But in certain cases, it may be requested that such interaction is handled by the application using such BSP,
showing all messages and illustrations in the computer screen. This may also be handled by the BSP itself,
but this can lead to certain kinds of inconveniences such as:
the BSP graphical user interface may not be adaptable to the different sizes and resolutions that the
application screen is using,
the feedback provided has to follow the same look & feel as the main application, including the use of
service provider logos,
the feedback has to be adaptable to the language of the user being identified, or where the system is
deployed.
In those cases, it is recommended that, in order to avoid the re-programming of the BSP or increasing the
complexity of the BSP, the interaction is handled by the application itself. As the feedback depends on the
specific step that the BSP is executing, and those steps are mostly controlled by the BSP (i.e. most BSP
functions are offered to the application as monolithic methods), then the way to solve this is by using callback
functions.
Callback functions shall be designed for each step where the BSP requires to interact with the user, and for
each of the processes to be called, the application provides the BSP with the selected functions, so that the
BSP can call them within the execution of the process.
Therefore, if the BSP allows the use of callback functions for handling the GUI, the following developm
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.