Credential Issuance Standards: What to Check Before You Trust an mDL

You can't verify what you don't understand. When your team accepts a mobile driver's license (mDL) for account opening or identity verification, you're trusting an issuance process you didn't control. The real question is whether the issuer applied controls rigorous enough for your risk tolerance.

This guide helps you evaluate digital credential issuance practices, focusing on mDLs as the most common use case. Use it when assessing vendor integrations, drafting acceptance policies, or explaining to your board why some credentials meet your standards and others don't.

Scope: What This Guide Covers

This guide addresses:

• Technical standards governing credential issuance (ISO/IEC 18013-5, NIST SP 800-63A, OpenID4VCI)
• Identity proofing requirements for remote mDL issuance
• Lifecycle management obligations (renewal, suspension, revocation)
• Trust establishment mechanisms for relying parties
• Gaps in current certification programs

It does not cover credential presentation protocols, wallet-to-verifier interactions, or biometric matching algorithms.

Key Concepts and Definitions

Verifiable Digital Credential (VDC): A digitally signed credential that a holder controls and a verifier can cryptographically validate. Includes mDLs, SD-JWT VCs, and W3C Verifiable Credentials.

Identity Proofing: Confirming that an individual is who they claim to be before issuing a credential. NIST SP 800-63A defines this across three Identity Assurance Levels (IAL1, IAL2, IAL3).

Credential Binding: Cryptographically linking a credential to a specific device or key pair so only the rightful holder can present it.

High Assurance Relying Party (HARP): Organizations like banks or healthcare providers that require strong identity verification and can't tolerate false positives.

OpenID for Verifiable Credential Issuance (OID4VCI): An API-based protocol from the OpenID Foundation that standardizes how issuers deliver credentials to wallets, building on OAuth 2.0 and OpenID Connect.

Requirements Breakdown

Remote mDL Issuance Flow

When a state DMV issues an mDL to someone who already holds a physical driver's license, the typical process includes:

1. Identity Proofing: The applicant submits their physical license details and a selfie. The issuer matches this against the portrait on file at the DMV.
2. Credential Creation: The issuer encodes verified attributes into an mdoc using ISO/IEC 18013-5 data elements.
3. Issuance Protocol: The credential transfers to a mobile wallet via a secure channel, with cryptographic keys binding it to the holder's device.
4. Lifecycle Management: The issuer maintains the ability to update, renew, or revoke the credential remotely.

Regulatory and Standards Context

REAL ID Act Compliance: The Transportation Security Administration issued a Final Rule in November 2024 covering security controls and issuance practices for mDLs. This rule defines identity proofing requirements for credentials used at federal checkpoints.

AAMVA Recommendations: The American Association of Motor Vehicle Administrators advises that digital issuance maintain the same rigor as physical issuance, with additional safeguards for credential lifecycle management.

NIST SP 800-63A Application: While not designed specifically for mDLs, NIST SP 800-63A's Identity Assurance Level Two (IAL2) controls provide a baseline for identity proofing consistency. The NCCoE's "Building Assurance in the mDL Ecosystem" paper proposes an 800-63A profile tailored to mDL scenarios.

Implementation Guidance

For Issuers: Building Defensible Processes

If you're issuing credentials, document your identity proofing controls against NIST SP 800-63A IAL2 as a minimum. This includes:

• Evidence collection (what documents you accept)
• Validation (how you confirm document authenticity)
• Verification (how you link the applicant to the evidence)

Consider encoding issuance metadata directly in the credential. The OpenID Foundation's Identity Assurance Working Group and ISO/IEC SC17 WG4's 23220-5 standard both address how to convey trust information about identity proofing and issuance practices within the credential itself.

Use OpenID4VCI as your issuance protocol. It's built on OAuth 2.0, which your team already understands, and the OpenID Foundation offers conformance tests for self-certification. This reduces integration time when you add new wallet providers.

For Relying Parties: Evaluating What You Accept

Before you accept mDLs from a new jurisdiction, ask:

• What identity proofing level does the issuer apply?
• Can the issuer provide evidence of REAL ID compliance?
• Does the credential include issuance metadata you can validate?
• Which wallets does the issuer support, and what security certifications do those wallets hold?

Currently, you'll need to conduct one-off assessments with each issuer because certification programs are still emerging. The FIDO Alliance Digital Credentials Working Group is developing a wallet certification program covering security, privacy, and interoperability criteria. Until that's operational, you're on your own.

For high-risk use cases (account opening, loan origination, healthcare record access), require issuers to demonstrate IAL2-equivalent controls. If they can't provide documentation, treat the credential as lower assurance.

Cross-Jurisdictional Acceptance

Variations in state DMV processes create risk when you accept credentials from multiple issuers. Consider a scenario where your financial institution operates in 15 states. Each DMV may apply different identity proofing technologies, document validation methods, and lifecycle management practices.

To manage this, create an issuer trust registry internally. Document:

• Which jurisdictions you've assessed
• What proofing level each applies
• Any exceptions or enhanced controls you require
• Review dates (reassess annually or when the issuer changes processes)

Common Pitfalls

Assuming format compliance equals trust: Just because a credential conforms to ISO/IEC 18013-5 doesn't mean the issuer applied rigorous identity proofing. The format standard says nothing about issuance controls.

Ignoring lifecycle management: If an issuer can't demonstrate how they handle revocation or suspension, you're accepting credentials that may remain valid after they shouldn't be. Ask about revocation checking mechanisms before you integrate.

Treating all wallets equally: Wallet security varies significantly. Some implement hardware-backed key storage; others don't. Until the FIDO Alliance wallet certification program launches, you need to assess wallet providers individually.

Skipping metadata validation: If the credential includes issuance metadata (proofing level, evidence types, validation methods), validate it. Don't just check the signature and move on.

Overlooking non-government use cases: The same issuance principles apply beyond driver's licenses. If you're considering professional licenses, educational credentials, or employee badges, the same trust questions arise. Apply the same evaluation framework.

Quick Reference Table

---

The credential issuance landscape is maturing, but it's not mature yet. Until certification programs close the current gaps, you're responsible for due diligence on every issuer and wallet you trust. Document your assessments, revisit them when standards evolve, and don't accept credentials just because they're technically valid. Trust requires evidence, not assumptions.