IAM architects are increasingly tasked with evaluating mobile driver's license (mDL) integration for their organizations. Whether they're building systems for financial services or healthcare, or considering federation trust models for multiple state issuers, they need clear answers about what's standardized and what's still evolving.
Do mDLs Meet the Same Identity Proofing Standards as Physical Licenses?
The answer varies by state and their issuance processes.
For a physical driver's license, identity proofing happens in person at the DMV. Some states allow remote mDL issuance if you already have a valid physical license, verifying your identity by matching your license details and a selfie with the DMV's records.
The Transportation Security Administration issued a Final Rule in November 2024 outlining security controls and issuance practices for mDLs, including identity proofing. The American Association of Motor Vehicle Administrators also provides guidelines for secure issuance. However, these are broad frameworks, and the specific technology and processes differ by state.
This variation is important if you're setting a consistent risk threshold. Not all states apply the same rigor to biometric matching or device binding. While NIST SP 800-63A wasn't specifically for mDLs, the NCCoE developed a profile applying Identity Assurance Level Two (IAL2) controls to mDLs. Their paper, Building Assurance in the mDL Ecosystem, suggests attributes issuers could include to describe the proofing process.
You'll need to evaluate each issuer's practices individually if your compliance standards are strict.
How Does the Credential Get from the DMV to My Phone?
This happens through an issuance protocol connecting the state's system to your wallet app.
The OpenID Foundation's OpenID for Verifiable Credential Issuance (OID4VCI) specification defines a standardized, API-based protocol for this process. It builds on OAuth 2.0 and OpenID Connect, using familiar security patterns like client authentication and token proof-of-possession.
OID4VCI provides a standard interface for discovering available credentials and requesting specific ones. It supports multiple formats and can be used with the W3C Digital Credentials API for secure cross-device transfer.
The protocol is evolving, but conformance tests are available for issuers and wallet providers to validate interoperable implementations. If you're designing an issuance flow, check if your wallet supports OID4VCI and has passed conformance testing.
How Do We Know Which Wallets Are Secure Enough?
Currently, there's no standardized answer, but certification programs are in development.
If you're an issuer, you need to conduct individual security assessments with each wallet provider. This is time-consuming and slows down the adoption of new wallets. As a relying party, you must trust the issuer's judgment on supported wallets.
The FIDO Alliance Digital Credentials Working Group is developing a wallet certification program to establish security, privacy, and interoperability criteria. This will help issuers confirm that wallets follow common practices for mDL issuance and provide relying parties with more information about wallet security.
Until the certification program is live, ask issuers which wallets they've vetted and the criteria used. For high-assurance systems, consider requiring specific wallet capabilities like hardware-backed key storage and biometric binding.
Can the mDL Itself Indicate How It Was Issued?
Not consistently today, but efforts are underway to change this.
The NCCoE's Building Assurance in the mDL Ecosystem paper suggests attributes that issuers could include to describe the issuance process, allowing relying parties to evaluate proofing rigor without maintaining a separate database.
Two groups are developing this capability. The OpenID Foundation's Identity Assurance Working Group is working on issuance metadata for credentials, and ISO/IEC SC17 WG4 is developing 23220-5 to encode and convey trust information in mdocs and transaction data.
If you're designing a relying party system, plan for a future where you can parse issuer metadata from the credential itself. Don't expect it to be present in early deployments.
Can We Use mDL Standards for Non-Government Credentials?
Yes, the same model applies to any credential where a trusted authority confirms identity before granting access or privilege.
The mDL standard, initially for government-issued IDs, extends to healthcare credentials, professional licenses, university diplomas, or corporate access badges. The principles remain the same: identity proofing, credential creation with standardized attributes, secure delivery to a wallet, and lifecycle management.
Non-government deployments are already in pilots. As an issuer, you'll follow the same pattern: define identity proofing requirements, choose a credential format, implement OID4VCI for delivery, and establish lifecycle policies.
Using mDL-adjacent standards ensures interoperability. If your credential format and issuance protocol align with existing wallet support, you won't need custom integrations.
What Should We Read to Stay Current?
Start with the OpenID Foundation's OID4VCI specification and track the conformance test suite. Review NIST SP 800-63A if you need to map identity proofing practices to assurance levels. The NCCoE's Building Assurance in the mDL Ecosystem is a key resource for understanding proofing rigor.
Watch the FIDO Alliance's Digital Credentials Working Group for wallet certification criteria. For mdocs, ISO/IEC 18013-5 and -7 define the credential format, and ISO/IEC 23220-5 will define trust metadata encoding.
For policy context, review the TSA's Final Rule from November 2024 and AAMVA's guidelines for mDL issuance. These clarify the regulatory baseline.
Next Steps
If you're evaluating mDL integration, start by mapping your identity assurance requirements to NIST SP 800-63A levels. Inventory which state issuers and wallet providers meet those standards. Don't assume consistency across issuers.
If you're building an issuance system, implement OID4VCI and validate your implementation against the OpenID Foundation's conformance tests. Plan to include issuance metadata in future credentials.
If you're waiting for the ecosystem to mature, track the FIDO wallet certification program and the ISO 23220-5 standard. These will drive consistency in what's currently a fragmented landscape.
