ISO 18013-5 vs 18013-7: Mobile Driver’s License Standards - Identity Authority

Scope

This guide explores the technical requirements and implementation considerations for mobile driver's license (mDL) presentation under ISO/IEC 18013-5 (in-person) and ISO/IEC 18013-7 (remote). You'll find protocol breakdowns, interoperability requirements, and practical guidance for IAM architects building or integrating mDL verification systems.

Key Concepts and Definitions

mDL (Mobile Driver's License): An ISO-defined credential stored in a digital wallet and presented cryptographically to verifiers.

Holder: The individual whose identity attributes are encoded in the mDL. The holder's device stores the credential and responds to presentation requests.

Verifier: The system or device that requests and validates mDL attributes. It bears the risk of accepting invalid or revoked credentials.

Relying Party: The organization or service that depends on the verifier's assessment. It may be the same entity as the verifier or a separate service consumer.

Device Retrieval: The mechanism by which a verifier's device establishes a secure channel with the holder's device to request credential attributes.

OpenID for Verifiable Presentation (OID4VP): A protocol that enables credential presentation over HTTP, supporting multiple formats including mDOC.

W3C Digital Credentials API (DC API): A browser-based API that mediates VDC presentation, currently supported by Chrome and Safari with Firefox support planned.

Requirements Breakdown

ISO/IEC 18013-5: In-Person Presentation

Transport layer requirements:

Near Field Communication (NFC)
Bluetooth Low Energy (BLE)
Wi-Fi Aware

Connection establishment:

Device-to-device secure channel required before attribute transfer
QR code initiation supported for BLE and Wi-Fi Aware sessions
Physical proximity enforced by transport layer constraints

Use case profile:

Attended transactions where verifier device is physically present
Examples: TSA checkpoint readers, point-of-sale age verification terminals
Latency-sensitive scenarios requiring immediate response

ISO/IEC 18013-7: Remote Presentation

Protocol options:

Annex B (OID4VP via HTTP redirects):

Uses HTTP redirects including custom schemes
References OpenID Foundation specifications
Supports multiple credential formats

Annex C (Device retrieval via DC API):

Builds on 18013-5 presentation framework
Currently supports mDOC format only
Work ongoing to add Selective Disclosure JSON Web Tokens (SD-JWT) support

Annex D (OID4VP via DC API - draft):

Uses W3C Digital Credentials API for credential transfer
Aligns to High Assurance Interoperability Profile (HAIP) for OID4VP
Enhanced security properties over Annex B

Cross-device flow requirements:

User initiates on one device (laptop) but credential resides on another (phone)
Session continuity across device handoff
User consent mechanisms for attribute disclosure

Implementation Guidance

Building a Verifier System

Step 1: Define your presentation context

Determine whether you're building for in-person, remote, or both. Users expect to pre-verify identity before arriving at your location.

Step 2: Maintain trusted issuer key sets

Your verifier must hold current public keys and metadata for all issuers you'll accept. Refresh these periodically or implement batch distribution. You own the risk if you accept a credential signed by a compromised or outdated key.

Step 3: Choose your remote protocol path

If implementing 18013-7:

Annex B offers broader wallet compatibility today but requires managing HTTP redirect flows.
Annex C limits you to mDOC format but leverages the DC API's phishing resistance.
Annex D offers the strongest security profile but is still in draft.

You'll likely need to support multiple paths during the transition period. Plan for protocol negotiation in your verifier logic.

Step 4: Handle credential status

Don't rely solely on signature validation. Issuers refresh credentials frequently, but latency exists between revocation and your knowledge of it. For higher-risk transactions, query issuer status services or check Token Status Lists (IETF active draft, referenced in upcoming 18013-5 revision).

Step 5: Implement selective disclosure

Request only the attributes you need. If you're verifying age for restricted content, request "over 18" rather than full date of birth. This isn't just privacy hygiene; it trains users to recognize appropriate requests and resist over-disclosure to malicious verifiers.

Wallet Selection Strategy

If you're building a holder-side wallet:

Support both 18013-5 and 18013-7 from day one. Users will encounter both in-person readers and remote verifiers. A wallet that only handles one context will fail in the field.

Implement DC API integration. Chrome and Safari support is live. Firefox support is planned. This API standardizes cross-device flows and reduces the risk of training users to accept phishing-style redirect patterns.

Plan for multi-credential scenarios. Users may need to present multiple credentials in a single session (e.g., mDL plus professional license). Your UX must make clear which credential is being requested and allow selective presentation.

Common Pitfalls

Assuming protocol convergence has already happened. Two presentation protocols exist in 18013-7 (Annex B/D and Annex C). An OIDF working group is now being chartered to harmonize them, but you're implementing during the transition. Build for both or accept that you'll exclude wallet implementations that chose the other path.

Treating revocation as someone else's problem. Verifiers bear the risk of accepting invalid credentials. If your system relies on batch key updates with 24-hour refresh cycles, you're exposed to credentials revoked in that window. Document your risk tolerance and implement status checks that match it.

Over-requesting attributes. Asking for full date of birth when you need age verification signals to users that your system isn't privacy-respecting. Worse, it trains them to accept over-disclosure from less trustworthy verifiers.

Ignoring cross-device complexity. Remote presentation often means the user is on a laptop but the credential is on their phone. If your flow assumes same-device operation, you'll create friction that drives users back to uploading photos of physical IDs.

Building only for in-person or only for remote. Users don't segment their lives this way. They'll expect to pre-verify online before showing up in person, or to fall back to in-person if remote verification fails.

Quick Reference Table

Requirement	ISO/IEC 18013-5	ISO/IEC 18013-7 Annex B/D	ISO/IEC 18013-7 Annex C
Context	In-person (attended)	Remote (unattended)	Remote (unattended)
Transport	NFC, BLE, Wi-Fi Aware	HTTP (redirects or DC API)	DC API + device retrieval
Protocol	Device-to-device retrieval	OID4VP	18013-5 framework via DC API
Format support	mDOC	Multiple (including mDOC)	mDOC (SD-JWT work ongoing)
Security profile	Physical proximity enforced	Standard (Annex B) or HAIP (Annex D)	Phishing-resistant via DC API
Use case	TSA checkpoints, POS age verification	Online account opening, remote KYC	Browser-based verification
Cross-device	Not applicable	Supported	Supported
Current status	Mature, widely implemented	Annex B mature, Annex D draft	Emerging, DC API adoption growing