If you require more complex information that is encoded differently between versions or is only present in a few versions, there is no way around handling the different cases for the different versions. Such information is collected in the “unified” field field, the idea being to allow quick access to commonly used information, without the hassle of having to check the specification version. Some of the common fields (name, date of birth, etc…) are encoded differently across different specification versions. Due to the large differences between the 2000 and later revisions of the specification, we will list them separately in the following. After 2003 only minor changes were made to the standard. The specification got a major overhaul between the 20 specifications and many data fields got reworked. If the AAMVAVersion is < 2, then the jurisdiction Version is always 0, as this information is not available in the code. IIN is the Issuer Identification Number which uniquely identifies the issuing jurisdiction. JurisdictionVersion is a jurisdiction specific version number of the implementation. Its parsed content is a dictionary with following key/value pairs:ĪAMVAVersion corresponds to the version of the specifications that is implemented in the code: 0=pre-specification, 1=2000, 2=2003, 3=2005, 4=2009, 5=2010, 6=2011, 7=2012, 8=2013, 9=2016. It is thus required to handle these versions differently.įurther information about the data elements can be found in the DL/ID specifications on the AAMVA Web page. Fields, including mandatory ones, vary between specification versions. Some data elements are mandatory (present on every code) while others are optional. A data element is uniquely identified by its data element ID. The data in DL/ID codes is encoded into data elements.

Texas drivers license barcode format