The New Mobile Driver Licenses — How to Use ISO 18013–5
The new Mobile Driver License (mDL) can be used to make customer interactions more efficient and accurate. Understand how mDL interactions work using the ISO/IEC 18013–5 Standard…
Read this article sequentially so that definitions of New Terms build. Some content attributable to members of the ISO/IEC 18013–5 group.
What is an mDL?
We use Driver’s Licenses every day in a myriad of situations/ways. Although the card primarily represents our privilege to drive vehicles, we seldom present it for that purpose. It also represents a confirmation of our legal age, name, and our contact information in the physical world. Far more often, we show our Driver’s License (DL) to verify age at a club, prove our name to a hotel, share our address to cash a check, or access secure airport gates.
So, let’s put a DL on a mobile phone. Simple, right?
A simple image of a license on a phone or in a wallet app is not on its own trustworthy. Boarding passes in a wallet are a pointer to the actual boarding pass in trusted airlines systems. Since each phone on its’ own is not fully trusted, the industry needs a common, trusted approach. The approach in the forthcoming ISO/IEC 18013–5 mDL Standard (draft is here) provides mechanisms to obtain and trust the data from a Mobile Driver’s License (mDL). These are not just a digital representation of your card.
Obtaining the Data. Multiple methods of standardized interaction with an mDL will unlock the power of mobility for identity and driving use cases. The standard specifies ways, under the control of the mDL Holder, that a Verifier (aka Relying Party) can obtain and trust the data.
Trusting the Data. The Verifier needs to know that the data is unchanged and matches the official record. When an official Issuing Authority of Driver’s Licenses securely places the DL onto the phone according to ISO/IEC 18013–5 standard, a trustworthy mDL is possible. The Issuer electronically signs the data and ensures it is provisioned to the proper device of the proper user. Everything from the name to the portrait image to the driving privileges is signed and can be verified by any capable device, called an mDL Reader.
Standardized Interactions
Attended Use Cases
The first version of ISO/IEC 18013–5 is targeted to support only attended use cases — those where a person is present to verify the identity of the mDL Holder against a portrait obtained from the mDL.
In-Person (Disconnected Devices)
When the mDL and Reader are not connected to the Internet, they must exchange information over nearby communication channels.
Certificates from a Trust List. Issuers use their private key to e-sign mDL data. Readers must obtain the corresponding signed public keys, called Signer Certificates, in order to verify the signature on any data obtained from mDLs. Signer Certificates are distributed in a list structure. It is envisioned that associations of Issuing Authorities or vendors of Reader devices will assemble Signer Certificates they trust and distribute them in Trust Lists.
Standardized Exchange and Validation of Data. The mDL Holder must initiate the exchange. The mDL Holder allows a QR code to be scanned or taps their phone on an NFC-enabled Reader. This action exchanges enough information, Device Engagement Parameters, for the two devices to securely connect. The Reader asks for only the data it needs, and the two devices exchange the signed driver license data over the local connection. Local connection can be NFC, Bluetooth, or Wi-Fi Aware, and the number of seconds to obtain the data varies by connection. The portrait — photo of the mDL Holder — is the largest data element and will take the longest to transfer. Still, it should always be requested for attended use cases. Once the data is obtained, the Reader verifies the signature on the individual data elements using the Signer Certificates. This ensures the data is genuine and unchanged, and is called Passive Authentication. The standardized data exchange also can provide cryptographic proof that the data wasn’t cloned from a different device — called Active Authentication.
Human Identity Verification. Using the verified portrait obtained from the mDL and displayed on their Reader, the attendant should confirm that the mDL Holder is the person in the verified portrait.
Consent for Releasing Data. In disconnected mode, the action of tapping or allowing a QR to be scanned is proximal consent for Device Engagement — to connect the mDL to the Reader. The Reader requests data and the mDL is responsible to gather consent from the mDL Holder to release the requested data elements and to validate the Issuer signature on those data elements. The implementation of consent gathering isn’t standardized, but informed consent is recommended.
In-Person (Connected Devices)
Most mobile devices do reliably maintain their connection to the Internet.
When connected to the Internet, the Reader can instead ask for driver license data directly from the Issuing Authority using a protocol called Open ID Connect. This has the advantage of freeing the mDL from being held in place while data is obtained. The steps in this Token and Request process are:
Certificates and URLs from a Trust List. The Signer Certificates from the Trust Lists can also be used to validate the Base URLs of the Issuing Authority Server — called an Open ID Provider (OP). This functions very much like your browser when it protects you from malicious sites and encrypts data.
Tap or QR to Obtain a Token. An mDL that supports the Connected/Online interaction method will also include an Identity Token Hint in the Device Engagement Parameters exchanged using QR or NFC tap. This Identity Token Hint contains no personal data about the user, but allows the Reader to connect to the OP and request data for this specific mDL Holder.
Reader Exchanges the Token for Data from the Issuer. Readers should preregister with commonly-encountered Issuing Authority OPs, however Open ID Connect Discovery provides for dynamic discovery and registration. The Reader can use the Identity Token Hint to request the OP to authorize the release of the data needed to fulfill their use case. Again, Readers request only the data they need, and the user consents to the release.
Consent for Releasing Data. The model of the offline interaction, that the mDL Holder tap/scan as consent to share, can also cover the online interaction. In addition, Open ID Connect permits the OP to implement consent mechanisms and User Authentication, which is automated Identity Verification, for their mDL Holders.
Open ID Connect can also support unattended use cases and Internet login
Securing the Transaction
When the Devices are Disconnected
Local transmission links can only be made in this first version of ISO/IEC mDL 18013–5 through directed action by the mDL Holder — a tap or showing a QR code to a Reader. The connections are then secured by standardized key exchange and encryption of the transport of data. Readers can then validate that the received data is authentic and unchanged using the Signer Certificates. The process proves to the Readers that the data was not cloned from another, different mDL device.
When the Devices are Connected
Security certificates, TLS encryption, and the Open ID Connect (OIDC) infrastructure help to secure Reader connections to the Issuing Authority OP. Readers (called Clients wrt OIDC) can pre-register with an OP. OIDC Dynamic Client Registration can also be used for lower security, infrequent OP connections. Data returned by the OP is signed for integrity (passive authentication). Device management by the OP, along with user authentication, helps resist cloning (similar to Active Authentication from the Disconnected model) and resists impersonation.
Future Methods of Interaction
ISO/IEC 18013–5 provides for ‘namespace’ extensions to the data model to permit regional additions to standardized data (e.g., REAL ID across just the USA).
Unattended Use Cases
With no attendant, how do you know the mDL is in the hands of the Proper Holder? When the Use Case does not have an attendant (e.g. Beer Vending Machines!) the Reader can take action appropriate for its’ transmission method — Disconnected/Offline or Connected/Online.
Disconnected User Verification. For unattended, disconnected use cases, trusted biometric attachments to the Reader can verify the identity of the mDL Holder versus the signed portrait image verified during the data exchange.
Connected User Authentication. When the devices are connected (the majority case), the Issuing Authority OP can orchestrate User Authentication to prove that the mDL is with the proper mDL Holder. The Reader asks for User Authentication by providing the Authentication Context Request (acr) to the OP during the Open ID Connect Authorize call. While ‘acr’ has not been standardized in this first release of ISO/IEC 18013–5, ISO/IEC 29115 specifies level of assurance values to use across identity contexts.
On the Internet
Using your Driver’s License to login to websites may seem like a foreign concept, but it is quickly gaining momentum. With appropriate privacy protections in place, such as total user control over personal data released to Relying Parties (RP), the Connected mDL can be used to login to government services websites with high assurance for both the mDL Holder and the RP.
The mDL can support authorizing access to websites now or in the future as standardization evolves to specify the Open ID parameters. The value to all parties is that Users will want to keep their social and professional identities separate from their Legal Identity, and eGov RPs may not trust Social logins.
Over Distances
ISO/IEC 18013–5 currently constrains the Device Engagement Data, where the connection between two devices is made, to a tap or a scan of QR code. This enforces nearby usage as mDL Holder consent.
As the standard evolves to include broadcasting and secure distance engagement, you can envision how Bluetooth beacons and other Readers could create connections that further support unattended use cases. Of course, the privacy and security protections must be in place to protect snooping, sniffing, and unauthorized access. ISO/IEC 18013–5 will evolve toward distance engagement and transfer by solidifying these protections.
Use Cases for the mDL / mID
AAMVA’s Mobile Driver License Functional Needs Whitepaper describes the core of the use cases for an mDL and covers many of the considerations in how these use cases can be executed that make mDL unique. The future of today’s uses of a driver’s license can change dramatically as mDLs and Verifiers support additional interactions, trust evolves, and innovation happens.
Share Driving Privilege
The main purpose of a DL is to express one’s ability to drive a particular vehicle. Often, a driver must show their DMV their existing privilege to drive in order to be tested, upgrade vehicle classes, renew licenses, or select a vehicle for a road test.
Drivers must also show their driving privileges to police or law enforcement during a road or a traffic stop.
Age Verification
The purchase of certain commodities are generally restricted to persons above an age threshold — alcohol and tobacco products for example. Similarly, there are age restricted venues, like bars, clubs and casinos. Establishments complying with local laws can verify age using the mDL without needed full personal information. They can even provide superior user experiences or fast lane access. Purchases can be made in-person, from remote, or from a website, opening up new markets for user convenience.
Car Rentals, Car Sharing
For renting an automobile, an mDL can identify the renter as well as confirm driving privileges. This can happen at rental counters, vehicle exit gates, or through mobile applications. Many renters are members of loyalty programs with their DL Number on file. mDL could close the potential loophole of renting a vehicle to someone whose privileges were suspended. Exit gate identity checks, that are high-friction for the renter and high cost for the rental company, could be eliminated.
Innovative rental companies will re-imagine the whole process from booking the vehicle, walking past the rental counter, having the reserved vehicle unlock automatically when it detects the proper mDL, and allowing the mDL Holder, after identity verification, to drive off the lot without stopping.
For more information on ISO/IEC mDL 18013–5
ISO/IEC 18013–5 standard was published in October 2022 and is now adopted in multiple US States as well as around the world. The current document is available from the ISO Repository. Revisions and the latest versions are available within ISO Committees, regional standards organizations, liaisons to the ISO mdL team (JTC1/SC17/WG10), and from partner trade alliances such as Secure Technology Alliance. One vendor has set up a useful mDL Resources Page. The AAMVA Mobile Driver License white paper and other tools are available from the AAMVA mDL site. At the operating system level, reports are that Google is working on an Identity Credential API to support ISO 18013–5. For automated Identity Verification, see Fido Alliance UAF and WebAuthN.
Thank you to members of ISO/IEC JTC1/SC17/WG10 for content and review, to Tom Lockwood of Secure Technology Alliance for thorough feedback, to Underwriter’s Laboratory for explanations of mDL security, and students at New York University and Case Western Reserve University for their review.
