FREQUENTLY ASKED QUESTIONS — DEVELOPMENT

1. We would like to automatically fill in forms using data that you read from the IDs, but it seems that sometimes last names and first names don't come out properly?
2. What are all the possible images that can be returned by a document scan? It seems that most documents return an Infrared image, a White image, and an UltravioletA image. However, a few documents also return an UntravioletB image (and they don't do it consistently)?
3. Is there any way to get my arms around exactly what Regions/Fields/Authentications will be done for the various document types?
4. Is there any known maximum in the system, in terms of all the data fields that may be captured and/or the lengths of those fields? We are trying to get our arms around the maximum number of fields that could be returned, as well as maximum lengths of those fields. We are trying to figure out exactly what our database will need to handle.
5. Here is what we're seeing. With an invalid Nebraska card, the AssureTec Tutorial is showing what appear to be failures in 2 Near-Infrared Pattern tests, 2 Ultraviolet Pattern tests and 1 Visible Pattern test. In our code in we handle the AssureTec.AssureID.SDK.AssureIDSession.DocumentComplete event handler. In that handler we walk through the AssureTec.AssureID.SDK.Events.DocumentEventArgs.Document.Alerts collection that is passed in. Each and every element in that collection has a Result of AuthenticationResult.Passed. This differs from the results the Tutorial is showing, unless it is getting information from a different source. We need clarification from AssureTec as to whether we are doing something wrong or there is a problem in the SDK.
6. Is there a Java-based SDK for the AssureTec platform?
7. I have a software development question. Who should I contact? (OR) How do I use your SDK?
8. We've developed an application using your SDK. Do you have any sample IDs that we could use to demo our application?
9. Is there a way to turn on and off the writing of biographic data to the log file?

1. We would like to automatically fill in forms using data that you read from the IDs, but it seems that sometimes last names and first names don't come out properly?

   
   Whenever possible the AssureID software attempts to normalize the document bearer's name into parsed surname and given name fields, in addition to returning the full name as a separate field. However, this is not always possible due to how the information is laid out in the document. In most cases, when information is read from the magstripe and/or 2D barcode of a driver's license or ID or the machine-readable zone (MRZ) of a passport or visa, the name is delimited such that it can be reliably parsed into these components.

   However, when a magstripe or 2D barcode is not available (such as when using an ID-300 device), or when this information cannot be read (such as on a Georgia driver's license due to encryption), this information must be extracted from the document image itself using OCR. In some cases (such as a New York driver's license), this information is laid out in a delimited "Last, First" format, and the software is able to parse the surname and given name using the delimiter (i.e. the comma). In many cases though, the name is laid out in a "First Last" format, and there are no delimiters available to assist the software in determining surname and given name. In these cases, the software generally only returns a full name field.

   Parsing a non-delimited name is not something that can be done reliably due to a large number of conventions and naming styles and customs, especially true when looking at international documents. When a multi-word name is presented with no delimiter(s), it is impossible to reliably parse it into surname/given name or first/middle/last. Below are some examples that illustrate this difficulty:

   Mary Ellen Beth Smith: First name is two words, middle is a single word, and last name is a single word

   George Herbert Walker Bush: First name is a single word, middle is two, and last name is a single word

   Malcom Arthur Von Klauss : First name is a single word, middle is a single word, and last name is two words

   This is further complicated when ethnic names are encountered:

   Alonso de Montoya y Perez de las Altas Cumbres: ???

   Our recommendation to integrators is that if they have a requirement to fully parse names, that they work with their customer to develop a set of business rules to deal with the non-parsed full names that may be returned by the AssureID software. The integrator can then perform this custom parsing in their application whenever they receive a full name field from a document with no corresponding parsed surname/given name fields. Based on our experience, this approach will not be 100% reliable, but will deal with a majority of cases where the name is not parsed. In the few exception cases where the business rules are insufficient, a mechanism should exist in the application to allow the user to correct the information manually before continuing with the transaction.

2. What are all the possible images that can be returned by a document scan? It seems that most documents return an Infrared image, a White image, and an UltravioletA image. However, a few documents also return an UntravioletB image (and they don't do it consistently)?

   
   The Document Authentication Library encodes tests for each document based on its security characteristics. Most documents have security characteristics to be checked under White and Near-Infrared light. Some documents need to be checked under UltravioletA and UltravioletB light as well. AssureID captures images in different lighting conditions as required by the encoded tests as well as the capture device's capabilities.

3. Is there any way to get my arms around exactly what Regions/Fields/Authentications will be done for the various document types?

   
   There is a list of standard fields that all documents should support provided that the information is present on the document (see the DocumentFieldCollection in the AssureID SDK reference manual). That is, all documents should have an MRZ field unless there is no MRZ on the particular type of document. Therefore, this list will vary greatly, depending on the types of documents you are using. If you are using just passports, this list is a bit more consistent, but if you are using passports, driver licenses, identification cards, and social security cards, the fields present will vary significantly between these various forms of identification.

   Regions are mainly image regions of interest that were extracted from the document. The regions present on a particular document are not standardized. Regions can be better used by how they are referenced. All fields and authentications have a References property that allows you to determine the related regions, images, etc. This enables an application to display the region image clip of a field by looking at the field’s references. It also allows the application to display the image clip related to a particular authentication.

   And lastly, there is a set of “standard” authentications, but there is no definition of what authentications will appear in which document type. For instance, there are three different versions of USA Passport in the library, all three of which will contain different authentications that are used to authenticate the specific security features for each issue of the USA Passport.

4. Is there any known maximum in the system, in terms of all the data fields that may be captured and/or the lengths of those fields? We are trying to get our arms around the maximum number of fields that could be returned, as well as maximum lengths of those fields. We are trying to figure out exactly what our database will need to handle.

   
   There are no limitations within the AssureID software on field length. However, there are realistic limitations based on where the data is coming from. The MRZ field on a passport is 88 characters, and the address field on drivers licenses will be no more than 100-200 characters (generally). These will most likely be the longest fields you will encounter. Since the data is being extracted from identification documents that aren't very large, there is a practical limit to how many characters each field can have by virtue of the width and height of the document.

   As for number of fields, this can vary depending on how many discrete data fields exist on the physical document. There is a standard set of fields defined in the SDK, which can be found in the reference guide in the DocumentFieldCollection class. In general, these fields will only be present if they exist on the physical document. In addition, auxiliary non-standard fields may also be present on the document, but I do not expect this number to exceed the number of standard fields present. So, worst case example may be twice the number of standard fields, which I don't expect you'd ever encounter.

5. Here is what we're seeing. With an invalid Nebraska card, the AssureTec Tutorial is showing what appear to be failures in 2 Near-Infrared Pattern tests, 2 Ultraviolet Pattern tests and 1 Visible Pattern test. In our code in we handle the AssureTec.AssureID.SDK.AssureIDSession.DocumentComplete event handler. In that handler we walk through the AssureTec.AssureID.SDK.Events.DocumentEventArgs.Document.Alerts collection that is passed in. Each and every element in that collection has a Result of AuthenticationResult.Passed. This differs from the results the Tutorial is showing, unless it is getting information from a different source. We need clarification from AssureTec as to whether we are doing something wrong or there is a problem in the SDK.

   
   The reason you are seeing this discrepancy is how risk factors and the Pass/Fail result interact.

   Each authentication test (alert) has a risk factor result, which a floating point value from 0.0 (pass) to 1.0 (fail). The Pass/Fail result for each authentication test is arrived at by thresholding the value (e.g. < 0.5 = pass, >= 0.5 = fail). The entire document also has a risk factor, which is arrived at by combining the risk factor results from the individual authentications.

   The problem you are seeing is that several authentication tests are returning non-zero risk scores that are not high enough to result in the individual test failing, but are causing the risk factor for the entire document to exceed the threshold for the document and fail the entire document. As we had discussed yesterday, the real result of each authentication test is the risk factor, so by using just the pass/fail status for each test, all the information on the results is not being displayed.

   The Tutorial interprets the results a bit differently, performing a thresholding of its own. Values from 0.0 to 0.3 will result in a Pass, 0.3 to 0.7 will result in a Caution, and 0.7 or higher will result in a failure.

   How do document counts relate to the rows in the library contents list?

   You cannot “count” the columns. Some documents are base types that never classify. The actual counting is done by counting the number of DL or DL-ID or ID or TP, etc in a column to the right of the Issue Type.

   What ePassport authentication (chip) or validation functionality does the AssureTec platform support?

   When a document is inserted, the chip will be detected and reading will start in parallel with the imaging of the document. This optimizes the entire process such that reading the ePassport will not take substantially longer than reading a normal document. (Certain older documents, which incorporate older Basic Access Control (BAC) chips may take significantly longer due to the amount of time required to read these chips.) Once the document imaging has completed AND the chip has been read, the document may be removed from the reader. Thus, the product retains its single-step functionality (i.e. insert document, wait, remove document).

   The information read from the chip is returned to client applications via the SDK as fields in the same manner that OCRed information is returned to the client. The client application has access to both the OCR and Smartcard data when it exists from both sources (e.g. name, birth date, portrait photo, etc.). Authentication tests performed simply generate additional authentication results, accessible via the SDK. Most of these additional tests are data consistency tests verifying the Smartcard data against the OCRed data, but there are also additional tests that verify the presence, integrity, and format of the Smartcard data.

   The only significant client application change that is required to fully support ePassports is functionality to handle manual BAC key correction. This is necessary if the MRZ cannot be read correctly and it requires manual correction in order to unlock the chip for reading on BAC encoded documents. A new event has been added to the SDK that indicates that the BAC key requires correction. The application can display this value for correction along with an image clip of the field (for data entry convenience). Once the corrected key has been entered, a method is called in the SDK to set the BAC key and the document may be reinserted. Note that the document does not need to be held in place during this data entry process, as it is likely that the user will want to remove it and view the actual document during data entry, and they need both hands for data entry. After correcting the key, the document will be reinserted as a new transaction.

6. Is there a Java-based SDK for the AssureTec platform?

   
   Currently, there is no Java SDK for the product, nor are there any immediate plans to implement one. You could easily implement a Java-based wrapper around the COM SDK, which some of our customers have done.

7. I have a software development question. Who should I contact? (OR) How do I use your SDK?

   
   Please read through the AssureID Professional SDK Programmer's Guide, which would be at C:\Program Files\AssureTec\AssureID\sdk if you have installed the AssureID Professional SDK. If you still have questions, please contact support@assuretec.com.

8. We've developed an application using your SDK. Do you have any sample IDs that we could use to demo our application?

   
   Sorry, AssureTec cannot provide sample ID documents.

9. Is there a way to turn on and off the writing of biographic data to the log file?

   
   You can do so by modifying the DAPServiceConfig.xml configuration file found in our "config" directory, by changing the <logFilter> setting replacing "All" with "Error, Warning, Info".

   (optionally "Exception" and/or "Debug" could be added, but currently they only need "Error, Warning, Info").

   Note: <logDebugLevel> only applies if "Debug" is added to the <logFilter>.

   <...snip....>
    <service>
     <log>
      <logFilename>C:DAPService {1} {0:Dyyyy-MM-ddTHH-mm-ss}.log</logFilename>
      <logFilter>Error, Warning, Info</logFilter>
      <logDebugLevel>Fine</logDebugLevel>
      <logRetentionDays>2</logRetentionDays>
     </log>
     <resourceFile>....AssureTec.AssureID.Platform.Service</resourceFile>
     <resourceCulture>en</resourceCulture>
     <balloonMessages>true</balloonMessages>
     <balloonErrors>true</balloonErrors>
    </service>
   <...snip...>