OpenID Foundation Wants to Standardize US mDLs as Verifiable Credentials: What It Means for KYC Teams

On November 7, 2025, the OpenID Foundation published two technical papers aimed at a specific, underserved problem: US mobile driver's licenses (mDLs) are issued state by state, with no shared trust framework telling a financial institution how to evaluate one. "This work is key to making deployments viable in the United States where no other trust framework exists," said George Fletcher of the OpenID Foundation. The papers "mDL Metadata Requirements to support Know Your Customer (KYC)" and "Customer Identification Program (CIP) compliance and OIDF Extended KYC Considerations" propose standardized, machine-readable metadata so a relying party can evaluate an mDL's provenance, assurance level, and compliance status programmatically, instead of state by state, implementation by implementation.

The Problem Being Solved

As the OpenID Foundation put it: "Without standardized metadata, financial institutions face fragmented implementations that increase operational risk, compliance audits, and undermine assurance for account opening processes." Every state that issues an mDL does so slightly differently. Without a common metadata layer, a bank evaluating a digital driver's license from one state has no standardized way to compare it against one from another, or to confirm how it was issued, what assurance level it meets, or whether it's still valid. That's an interoperability gap and interoperability gaps are exploitable. Identity standards architect Juliana Cafik was direct about the stakes: "fragmented standards create exploitable gaps for synthetic identities, deepfake-driven onboarding, and AI-enabled attack surrogates."

The Underlying Shift: mDLs as Verifiable Credentials

The reason this initiative matters beyond the US mDL context is the model it's built on. Treating a driver's license as a verifiable credential means restructuring identity verification around three roles issuer (the state DMV), holder (the citizen's wallet), and verifier (the bank or platform doing KYC) with cryptographic signatures doing the work a human reviewing a plastic card or a scanned PDF417 barcode used to do. A verifier doesn't inspect the document; it checks a signature chain back to a trusted issuer and reads standardized metadata about assurance level and status. That's a structural shift in what "verifying an ID" means, and it's the same shift already underway in the EU through eIDAS 2.0 and the EU Digital Identity Wallet just arriving in the US through a different standards body and a different regulatory path.

Where a Credential-Based Architecture Already Lines Up With This

Hypersign issues identity verification results as W3C Verifiable Credentials on exactly the issuer-holder-verifier model this initiative is standardizing for mDLs: a credential is issued after verification, held by the user, and checked by any relying party against a signature and an on-chain revocation registry no synchronous callback to the original issuer required. That's the same architectural shape a bank checking mDL metadata would need: a verifiable, machine-readable trust signal instead of a document inspection.

To be direct about scope: Hypersign does not today natively ingest the ISO/IEC 18013-5 mdoc wire format an mDL wallet speaks, or implement the OpenID4VP/OpenID4VCI presentation flows this specific initiative is built around. What's already in place is the credential architecture underneath document verification (currently covering 14,000+ document types across 189+ countries, including physical and scanned driver's licenses today) that produces the same kind of portable, cryptographically checkable output an mDL-as-VC framework is standardizing toward. Businesses building compliance infrastructure on that model now aren't rebuilding their verification pipeline later they're extending a wire format, not replacing an architecture.

The Fraud Problem This Is Actually Trying to Close

Cafik's warning about synthetic identities and deepfake-driven onboarding isn't abstract it's the specific failure mode fragmented, undocumented trust metadata enables. If a verifier can't confirm how a credential was issued or whether it's still valid, an attacker only needs to defeat the weakest implementation in the fragmented landscape, not the strongest. This is where the identity side of the stack has to carry equal weight to the metadata standard: deepfake detection analyzing facial geometry, texture consistency, and temporal signals to catch synthetic or manipulated faces before a credential is ever issued, plus cross-session duplicate detection that flags a document number, face hash, or device fingerprint reappearing under a different email or user ID even when each individual session looks clean on its own. Standardized credential metadata answers "is this a valid mDL." Fraud detection at the point of issuance answers "was this a real person to begin with." Both have to hold for the trust chain to mean anything.

What This Means for Compliance Teams Today

Financial institutions and other regulated verifiers don't need to wait for a finished US mDL trust framework to start benefiting from this shift. The practical move is the same one already playing out around eIDAS 2.0 in the EU: build KYC around verifiable, holder-controlled credentials and selective disclosure so a verifier receives only the specific claim it needs like age, KYC status, or document validity rather than a full document image, and design fraud detection to catch synthetic identity and deepfake attempts before a credential is ever issued, not after. When a standardized mDL trust framework does land, that KYC pipeline is extending a metadata format it's not rebuilding a verification model from scratch under deadline pressure.

Pages worth reviewing if you're evaluating this for your own stack:

• Verifiable Credentials the issuer-holder-verifier architecture this initiative is standardizing mDLs toward.
• Selective Disclosure & Zero-Knowledge Proofs sharing only the claim a verifier needs, not the full document.
• ID Verification document coverage across 189+ countries and 14,000+ document types, including driver's licenses today.
• Biometric Verification deepfake and synthetic identity detection at the point of onboarding.
• Decision Engine cross-session duplicate detection and manual review for cases automated checks can't resolve alone.

About Hypersign

Hypersign runs identity verification on the same issuer-holder-verifier, cryptographically checkable credential model this OpenID Foundation initiative is standardizing for US mDLs pairing it with deepfake detection and cross-session fraud checks at the point of issuance, so the credential a business ends up trusting was verified against a real person in the first place.