AAMVA Card Design Specifications: FAQs

1. On page 48 in paragraph D.12.3 the specification says that variable length fields should be padded when they do not use the maximum field length.  On the next page, in paragraph d.12.3.1, the specification states that the use of padding for variable length fields is optional.  Which statement is correct?
    
   Answer: The use of padding for variable length fields is optional.  If padding is used, it should be done as described in paragraph D.12.3 on page 48.
    
2. Paragraph D.12.3 states as follows:
    
   “Mandatory data elements for which no data exists for a given cardholder are to be encoded with the word "NONE." In the event data is not available for a mandatory data element, "unavail" is to be encoded.”
   
   What do you do when the maximum length of the data field is less than the four (“NONE”) or seven (“unavail”) characters required?
   
   Answer: We are currently researching this problem and have not found a simple solution.  The obvious solution of using as many of the letters as will fit in the particular field may create problems if the resulting truncation results in filling the blank with something that could be misinterpreted as codes for some other meaning.  However, other solutions that have been suggested may also create problems.  We will continue to research this issue and will address it in the next revision of the specification.
    
3. Should the “Document Discriminator” be unique to each card issued?
    
   Answer: The purpose of the Document Discriminator is to differentiate between an original and one or more duplicate DL/ID cards that have been issued to same person.  Theoretically, only the last card issued to that person is valid, even if all the other information on the card remains unchanged.  Depending on how a jurisdiction implements its system, the Document Discriminator could be the same as another data element, e.g. the Audit Information or an Inventory Control Number.  For example, if a jurisdiction uses pre-printed card bodies with a unique Inventory Control Number pre-printed on the card body that is still visible after the card is personalized, then that Inventory Control Number could be recorded in the driver’s record and used as the Document Discriminator.  In this case, each card issued to the card holder would have a unique Inventory Control Number.  Similarly, if a jurisdiction uses a unique Audit Information data element on each card it produces, that Audit Information can also serve as the Document Discriminator since it could be used to differentiate between two cards issued to the same person.  The simplest version of the Document Discriminator would be a one-up number for each card issued to the same Customer ID Number.
    
4. What information should go into the Federal Commercial Vehicle Code (DCH) field used in the bar code?
    
   Answer: As yet, the Federal government has not established codes for this purpose.  Therefore, AAMVA recommends a solution that differs for a commercial license (CDL) and a non-commercial license.  For a CDL, fill the Federal Commercial Vehicle Code field using the same data as in the Jurisdiction-Specific Vehicle Class (DCA) field.  For a non-commercial license, fill the Federal Commercial Vehicle Code field with “NONE”.
    
5. The Address – Postal Code (DAK) field in the bar code is defined as 11 characters.  How should this field be filled when using a five digit or a nine digit US ZIP code?
    
   Answer: Regardless of the number of characters known for the ZIP code, the field should be left justified and no hyphen should be used.  If only the first five characters of the ZIP code are available, then add four zeroes at the end to make the total length nine characters and then add two blanks at the end.  An example of what this might look like is “54321000bb ”.  For a nine digit ZIP code, use the ZIP code and then add two blanks at end.  An example of this would look like “987654321bb”. (In these examples the lower case “b” represents a blank.)
    
6. Can you provide a sample of what the data encoded for a standard bar code should look like?
    
   Answer: The following shows what the encoded data in a standard bar what look like:
   
   

   @^L_F^R_S^C_RANSI 636034030002DL00410229ZV02700031DLDAQ123456789^L_F
   DCAC^L_F
   DCBBEK^L_F
   DCDNONE^L_F
   DCSSAMPLE^L_F
   DCTDRIVER LICENSE^L_F
   DCUNONE^L_F
   DAG123 S MAIN STREET^L_F
   DAHAPT 2A^L_F
   DAIANYTOWN^L_F
   DAJVA^L_F
   DAK123450000 ^L_F
   DBC1^L_F
   DAU069 in^L_F
   DCE4^L_F
   DAYBRO^L_F
   DBA11082010^L_F
   DBB01011980^L_F
   DBD05082006^L_F
   DCGUSA^L_F
   DCF1234567891^L_F
   DCHNONE^L_F^C_R
    
   ZVZVAJURISDICTION^L_F
   ZVBSPECIFIC^L_F^C_R

1. What is the minimum number of security features required?
      
   Answer: The specifications require a minimum of six security features, as follows:
      - The common security feature (The AAMVA OVD)
      - A Level 3 (or forensic) feature
      - At least four additional devices to protect at Levels 1 and 2
    
   Keep in mind that the 2-d bar code and the additional security features included in the design of the AAMVA OVD may not be counted as meeting requirements for the second and third bullets.
    
2. The definition of “ghost image” on page 33 of ANNEX C in paragraph C.4.f uses the term “half tone”, which seems to preclude the use of color printing for a ghost image. Is this intended? (Feb. 15, 2007)
    
   Answer: First, remember that the “informative” label on ANNEX C means that it does not establish requirements. The information in ANNEX C helps establish common terms of reference, but does not preclude the use of any security device that the jurisdiction determines to provide good protection. A jurisdiction should not exclude the use of a security device solely because it fails to appear in ANNEX C or it does not meet the exact definition provided in Annex C. That said, the definition provided for “ghost image” needs improvement.
    
   When the Card Design Specifications is next revised, we should rewrite the definition of “ghost image” In the meantime, AAMVA suggests substituting the following definition:
    
   

   Ghost image: A lighter reproduction of the original image that appears in the same area as the personal data such that the image appears to be in the background and the personal data can still be read without interference.

Magnetic Stripe Format