Creating Your Own Electronic Biometric Transmission Specification (EBTS)
There are many organizations globally and domestically that require the use of biometric identification services, internally and from third parties. Imagine this scenario: a company employing security guards for transportation of valuables needs to send information to the local, state, or federal agency in charge of prosecuting crime. This agency has a biometric identification service with information about all criminals processed over the past ten years. How can the company request the identification of a person applying for a guard position? How can an agency open its services to private companies without compromising security? This is where an EBTS comes into play.
The company in our example would send a “transaction” for processing which would need to comply with the receiving organization’s EBTS. This implies that the receiving organization would have to publish its EBTS. How can high security agencies, such as the FBI or Department of Defense (DOD), make public such strategic infrastructure? Actually, the question answers itself. Strategic infrastructure of this nature is required to provide services internally to highly complex organizations, but it is also required to have interoperability with other Automated Biometric Identification Systems (ABIS).
An ABIS is the next stage of what formerly was an AFIS (Automated Fingerprint Identification System). While an AFIS focused its biometric services on fingerprints, an ABIS performs a more complex operation because it is required to perform the identification of a person using multiple biometric modalities. The first step is the implementation of a platform that can identify a person using fingerprints, photographs, palm prints, iris, DNA, and other modalities, or any combination of these.
In a similar sense, many countries around the world have developed or adopted standards for the actual images. Such standards include ISO, NIST and ICAO standards; some countries have developed their own standards based on a combination of the former. These standards usually lack a description of the file containing the information or the mechanism to exchange biometric data. An EBTS precisely closes this gap since its main purpose is to specify a method in which an organization can submit a file containing biometric information and receive an answer.
There are two key components in creating your own EBTS: the description of the files and a way to operationally implement it.
In creating your own EBTS, you need to document the structure of the files. There are two examples that present a complete EBTS that an organization can use as a starting point: the FBI’s and DOD’s EBTS. We’ll use the FBI’s EBTS as a reference for our analysis and comments, but make sure to also review the DOD’s. Types of transactions are grouped into the following services: identification, information, investigation, notification, data management, and verification. You can find a complete description in the “Master EBTS FBI V10” that is available on the internet. You can adapt each of the services to your own scope and objectives, but ideally you should keep each type of transaction (TOT) as part of the same service. This will help you align with the FBI’s EBTS.
The TOT defines the process that will be followed for an EBTS file. The TOT is actually part of the EBTS file and is based on the services previously mentioned. For example, the FBI’s identification service includes a criminal ten-print submission with an answer required. This means that an EBTS file will have a criminal arrest record (CAR) TOT for the former and a criminal arrest no-retention (CAN) for the latter. This example is interesting because in the first case a response is required, which means the organization submitting the identification service request would be expecting the FBI to send a response regarding the identification process. In this case, the response will contain the positive identification or non-identification decision. It may also contain additional information regarding the person identified. In a similar way, an EBTS file may contain a TOT for the verification of an individual’s identity using fingerprints or photos.
The second component in creating your EBTS is going from paper to actual operation, which can be the tricky part. The implementation of your standard involves creating and sending an EBTS file with a TOT defined by you, receiving the EBTS file, and processing it accordingly to the TOT. On the submitting part, you need a client capable of creating an EBTS file with a defined TOT. On the server side, you first need the functions of receiving the EBTS file. In receiving the EBTS file, it needs to be validated that it comes from a secure client, and that the information required by the TOT is complete. Then the EBTS file needs to be managed and processed.
The benefit for an organization is not only the capability to exchange information with other organizations, but also a structured approach to a biometric solution. This approach presents clearly the mechanics behind a biometric identity management solution that can also include credentialing and access control (logical and physical). The description, of the services and TOTs, establishes clear expectations of the functionality a biometric solution should deliver. Finally, and more importantly, an organization can create a plan, using the EBTS, of the capabilities it should develop in the short, medium and long term.
ImageWare® Systems, Inc. is a proven, patented, multi-modal biometric company with over a decade of experience providing identity management solutions. Our innovative products, such as GoCloudID™, EBI Suite®, and GoMobile Interactive™, enable extraordinary modular, flexible and scalable identity solutions across a variety of markets including mobile, wireless, financial services, and healthcare.