The driver’s license is already the world’s most widely accepted identity credential. The mobile driver’s license (mDL), defined by ISO/IEC 18013-5, transforms it into a cryptographically verifiable digital credential that can be stored on a phone and verified instantly, online or offline.
From US states and the EU’s EUDI Wallet to deployments across Asia and Latin America, mDLs are moving verifiable credentials from theory to real-world adoption. This edition explores how mDLs work, how they relate to the W3C verifiable credentials ecosystem, and why they are becoming a foundational layer for reusable digital identity infrastructure.
If you have not yet read our edition on the verifiable credential lifecycle, it is the natural starting point for the material below.
What an mDL is
An mDL is a digital driver’s license that lives in a wallet application on a citizen’s phone, signed by the issuing motor vehicle authority, and structured to be presented to a verifier offline or online. The citizen holds the credential in their wallet. The verifier, when checking, performs a cryptographic operation against the issuer’s public key to confirm the credential is genuine and unaltered.
The standard that defines this is ISO/IEC 18013-5: Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application. The standard specifies the data structure of the credential, the signing scheme, the device-to-device presentation protocols, and the rules for selective disclosure. A companion standard, ISO/IEC 18013-7, extends the model to online unattended presentation, addressing the case where a verifier is reached over a network rather than face-to-face.
The architectural goal of the standard is to give a citizen a digital driving licence that works for every common scenario the plastic card already covers, including age verification at a venue, identity proof at a roadside stop, and presentation at a border crossing, without requiring the verifier to reach the issuer in real time.
How an mDL is structured
An mDL is encoded differently from a W3C verifiable credential, and the differences are deliberate.
A W3C verifiable credential is typically a JSON-LD document or an SD-JWT, signed using JOSE-family signature suites. An mDL is encoded in CBOR, the Concise Binary Object Representation, signed using COSE, the CBOR Object Signing and Encryption format. The structure that holds the signed credential is called a Mobile Security Object, or MSO, which contains the credential data along with metadata required for presentation and verification.
The reason the standard chose CBOR and COSE rather than JSON and JOSE is that mDLs were designed to work in resource-constrained presentation environments: a roadside Bluetooth handshake to a police officer’s tablet, an NFC tap at an airport security checkpoint, a QR exchange at a venue door. CBOR is significantly more compact than JSON, COSE is significantly more efficient than JOSE for signing and verifying small payloads, and the combined choice keeps the credential payload small enough to transmit reliably over short-range device-to-device protocols.
Inside the MSO, an mDL contains the same fields the plastic card carries: name, date of birth, driver’s licence number, document number, issuing authority, expiry date, address, and license categories. Each field is hashed individually, so the citizen can present some fields and withhold others without invalidating the issuer’s overall signature. This is the architectural foundation for selective disclosure, which the standard treats as a default capability rather than an optional extension.
How an mDL is presented
ISO 18013-5 defines three presentation modes, each addressing a different scenario the plastic license covers today.
Device retrieval is the offline mode, in which the citizen and the verifier exchange the credential directly between phones, or between a phone and a verifier device. The transport is typically NFC for tap-and-go or Bluetooth Low Energy for slightly longer interactions, with QR codes used to bootstrap the connection. No internet access is required at either end. The roadside-stop scenario is the canonical case for this mode, and it is the scenario the standard was most carefully designed around.
Server retrieval is a hybrid mode, in which the verifier receives a token from the citizen’s phone and uses that token to retrieve the credential from a server endpoint that the issuer maintains. Server retrieval is useful when the verifier wants additional issuer-side context, although it reintroduces a dependency on the issuer being reachable at presentation time, which is one of the dependencies the offline mode was designed to remove.
Online unattended presentation, defined in ISO 18013-7, addresses the case where the verifier is a website or a service rather than a person with a device. The flow uses an OpenID-based protocol to authorize and transmit the credential, and is the bridge that makes mDLs presentable to e-commerce, banking, and government online services. ISO 18013-7 is the companion standard most deployments are now building toward for online verification scenarios.
How an mDL is verified
When a verifier receives an mDL, the verification operation has three parts.
The verifier confirms that the issuer’s signature over the MSO is valid, using the issuer’s public key. The public key is published by the issuing authority through a trust registry that the verifier has access to, typically maintained by AAMVA in the United States, by national authorities in the EU under the EUDI Wallet ARF, and through equivalent national bodies elsewhere. The verifier confirms that the selective disclosure is consistent, by checking the hashes of the fields the citizen chose to reveal against the hashes in the MSO. The verifier confirms that the credential has not been revoked, by consulting the issuer’s status mechanism.
Selective disclosure deserves a closer look, because it is one of the architectural choices that gives mDL its operational character. A bouncer checking that a citizen is over 21 receives the answer “yes” along with the cryptographic proof that the answer came from the issuing authority, without receiving the citizen’s date of birth, name, or address. The same credential supports a banking verifier asking for full name and date of birth for know-your-customer purposes. The citizen controls which fields are released for each presentation, and the cryptographic structure of the MSO guarantees that withheld fields cannot be inferred from the disclosed ones.
We covered the cryptographic primitives behind selective disclosure in our February 26 edition on zero-knowledge proofs, which is the reference for readers who want a deeper view of how the math works.
Where Sovra fits
Sovra builds the institutional layer that issuing authorities and verifiers operate on top of. SovraGov handles the issuance side: how a government agency configures credential types, signs them, manages keys, and publishes its trust roots. SovraID handles the verification side: how a verifying institution registers as a counterparty, retrieves trust list data, and performs the cryptographic checks against incoming credentials. SovraWallet holds credentials on the citizen side, including W3C-format credentials and ISO mDL credentials in the same wallet, presented through OpenID4VP and through ISO 18013-5 device-retrieval protocols where the use case calls for them.
The institutional infrastructure remains the same regardless of which credential stack a particular deployment uses. The signature suites differ, the encoding differs, the presentation protocols differ, and the trust registry mechanics, the key rotation behavior, the revocation publication, and the institutional onboarding stay consistent across both formats. Across the production stack, 10M+ credentials have been issued and 50M+ verifications processed against this architecture, spanning multiple credential formats and multiple presentation contexts.
Continue the conversation
More technical resources on the verifiable credentials stack, including reference implementations and deployment case studies across W3C and ISO 18013-5 formats, are available at sovra.io/knowledge.
If you are working on mDL deployment or evaluating how it fits with existing W3C-based infrastructure, reply. We read every response.
If this edition was useful, forwarding it to one colleague working on identity standards is the most direct way to grow this community.
Subscribe to The Identity Brief, published every Thursday.
The Identity Brief is published weekly by Sovra, the Digital Identity Stack for the Institutional World.