A mobile driver's license contains standardized data fields that identify the holder, describe their driving privileges, and enable verification across different systems and jurisdictions. The ISO/IEC 18013-5 standard defines these fields to ensure interoperability, so an mDL issued in California can be understood and verified in New York, at a TSA checkpoint, or by a bank conducting identity verification.
Why does standardized data matter?
Driver's licenses have long been physical cards, but to work in digital-first environments, they must be machine-readable and consistent. Without uniform data standards, verifiers could misinterpret or reject information, undermining trust in verifiable digital credentials.
The ISO/IEC 18013-5 standard establishes consistent naming conventions for every data field. If one state used "dob" and another used "date_of_birth," systems would fail to communicate effectively. Instead, the standard enforces uniform identifiers so any verifier, regardless of jurisdiction, can immediately recognize and process the data correctly.
What are the core mandatory fields?
The ISO/IEC 18013-5 specification defines a baseline set of mandatory identifiers that every mDL must include:
family_name: the holder's last name or surname
given_name: the holder's first name(s)
birth_date: full date of birth
issue_date: date when the mDL was issued
expiry_date: date when the mDL expires
issuing_country: alpha-2 code of the issuing country or territory
issuing_authority: name of the issuing authority (typically a state DMV)
document_number: the license number assigned by the issuing authority
portrait: an image of the holder
driving_privileges: the holder's licensed driving privileges (vehicle classes, endorsements, restrictions)
These fields represent the baseline information required for mDL functionality across all verifiers.
AAMVA expanded requirements
The American Association of Motor Vehicle Administrators (AAMVA) goes further by upgrading several fields from optional to mandatory for U.S. implementations. This ensures stronger consistency across jurisdictions:
height: the holder's height in centimeters
sex: the holder's sex, using ISO/IEC 5218 values
eye_colour: the holder's eye color, with values such as "blue," "green," or "hazel"
age_in_years: the holder's precise age in years
age_over_NN: a true/false statement verifying whether the holder is over a specific age (such as age_over_21)
These additions provide more complete data sets, helping verifiers confirm identity quickly and consistently across state lines.
Age verification fields
The age_over_NN fields deserve special attention because they enable privacy-preserving verification. Instead of revealing a full birthdate, the mDL can confirm that the holder is over a specific age threshold, 21 for alcohol purchases, 18 for tobacco, or any other legally relevant age.
A bartender checking ID doesn't need to know the customer's exact birthday, address, or license number. They only need confirmation that the person is legally old enough to purchase alcohol. The age_over_21 field provides exactly that, a cryptographically signed yes/no answer that the verifier can trust without accessing unnecessary personal information.
Additional optional fields
Beyond the mandatory fields, mDLs can include optional data elements based on jurisdictional requirements or specific use cases. These might include:
resident_address: the holder's residential address
nationality: the holder's nationality
birth_place: place of birth
signature_usual_mark: an image of the holder's signature
biometric_template_xx: biometric data for enhanced verification
Jurisdictions can decide which optional fields to include based on their legal requirements and the use cases they want to support.
How does data support selective disclosure?
The structured data format directly enables selective disclosure, allowing the sharing of only specific fields rather than the entire credential. Because each attribute is defined as a separate, signed element, the mDL holder has control over which fields to reveal in any given transaction.
When presenting an mDL at a bar, the holder can share only the age_over_21 field. When renting a car, they might share driving privileges and specify their age in years. When opening a bank account, they might share a fuller set of identity attributes. The holder controls what information flows to each verifier.
This selective disclosure is possible because the DMV creates digital signatures for specific attributes or grouped attributes. The holder can present a subset of the credential, and the verifier can still confirm the DMV's signature on those specific fields without needing to see the rest.
Machine-verifiable and human-readable
mDLs are designed primarily for machine-based verification, not visual inspection. The machine-readable format follows ISO/IEC 18013-5 standards and allows approved systems to verify information securely and automatically, such as at TSA checkpoints or other compliant verification environments.
Digital wallets may also show a human-readable display of the credential so the holder can see what information is being shared. However, this visual view is not intended to be relied on for acceptance. AAMVA discourages “flash pass” use of mDLs, emphasizing that trust comes from cryptographic verification by a reader, not from visually inspecting a screen.
Interoperability across use cases
The standardized data format ensures mDLs work across diverse verification scenarios, such as proving age at a bar, passing TSA airport screening, applying for a loan, or accessing online government services. A bartender checking age, a TSA officer validating travel documents, and a bank verifying identity for account opening all benefit from accessing consistent, standardized fields.
This interoperability is fundamental to the value of mobile driver's licenses. By mandating shared formats, the ISO and AAMVA frameworks ensure that verification is fast, reliable, and scalable across industries and jurisdictions.
Want to keep learning?
Subscribe to our blog.
