The Future IDP Is Not a Booklet. It Is a Privacy-Preserving Presentation Layer.

The international driving permit (IDP) of the future should not be another document to carry. It should be a governed, cryptographically verifiable way to present national driving privileges across borders — online and offline, with minimal disclosure and without turning every verification into surveillance.

Everyone says the future of the international driving permit is digital. That’s not wrong — but it’s not specific enough either.

A PDF booklet on a phone is not the future. A better-looking QR code is not the future. A blockchain token with “driving” in the marketing materials is not the future.

The real problem runs deeper than format. It comes down to one central question: how does a lawful driving privilege, issued by one authority, become understandable, trustworthy, and usable in another place, to another verifier, under pressure, sometimes with no network, and without exposing more personal data than necessary?

That’s the question the paper IDP never fully solved. And it’s the question the next-generation system must answer.

Why the Paper IDP Solved Readability but Not Trust

The paper IDP made sense in a world where paper was the primary medium. It acted as a compatibility layer — a human-readable connection between one licensing system and another. That was useful, and to some degree, it still is.

But the difficult part of modern cross-border mobility is no longer just readability. It’s trust.

Today’s verifiers face a series of harder questions:

• Can they determine whether the credential is genuine?
• Can they confirm it’s still valid?
• Can they check only the specific fields they actually need?
• Can they do that without contacting the issuing authority every time?
• Can they verify it online, in person, and at the roadside?
• Can they do it without turning travel into a global tracking system?

That’s why the future IDP should not be understood as a digital booklet project. It should be understood as a presentation architecture problem.

Standards That Already Point Toward a Digital IDP

This is no longer theoretical. The standards community has already moved in this direction:

• ISO/IEC 18013-1:2018 established a model in which a single secure license can serve both domestic and internationally recognized purposes, anticipating machine-readable technologies and the integration of biometrics, cryptography, and compression.
• ISO/IEC 18013-3 covers access control, authentication, and integrity validation.
• ISO/IEC 18013-5 defines the interfaces between the mobile driving license, the reader, and the issuing authority infrastructure, including use by verifiers in other countries.
• ISO/IEC 18013-7 adds presentation of a mobile driving license over the internet.
• UNECE work on electronic driving permits connects technical and security requirements to ISO/IEC 18013-5 compliance.

The Wrong Approach to Digitizing the IDP

The wrong approach is to take the current IDP, convert it to a digital format, and put it in an application. That sounds efficient, but it preserves the wrong focus — it keeps the system centered on the document as a physical object.

The better approach is to treat international driving as a controlled presentation of nationally issued driving rights.

That shift matters, because once you think about presentation, the design questions become more precise:

• Who issued the underlying right to drive?
• How does the holder receive and store the credential?
• How does a verifier request only the data it legitimately needs?
• How are issuer keys distributed and trusted?
• How is revocation checked without live tracking by the issuer?
• What works offline, and what still needs paper as a backup?
• Which verifier is allowed to see which data, and why?

That’s a much more serious way to design the replacement for the paper IDP.

A Better Definition of the Future IDP

Here’s a proposed definition:

A Future IDP is a standards-based, derivative cross-border credential that presents nationally issued driving privileges to a verifier in a context-appropriate way, under holder control, with cryptographic verification, role-based disclosure, online and offline presentation flows, and privacy-preserving status checking.

That definition is deliberately narrow. It does not:

• Make the Future IDP a standalone driving right
• Turn it into a universal identity data store
• Require a live connection to the issuer for every transaction
• Assume that a rental desk, a police officer, and an insurer should all see the same fields
• Require blockchain as the core of the system

It’s a disciplined answer to a trust problem.

The Seven Components of a Workable Future IDP

Stripped of marketing language, a workable Future IDP needs seven components:

1. An authoritative national source of truth. The legal right to drive comes from the domestic licensing authority. The international layer should never create driving rights — only present them.
2. An issuer. A trusted public authority, or a tightly governed authorized issuer acting on its behalf, issues the digital credential reflecting the current driving privilege.
3. A holder wallet. The driver needs a secure wallet that stores the credential, protects private keys, authenticates the holder, and presents the credential to verifiers.
4. A verifier or reader. This can be a police device, a rental desk reader, an online system, or another authorized verifier.
5. A trust registry. Verifiers need a reliable way to obtain the public keys and trust metadata of legitimate issuers.
6. A status layer. There must be a privacy-preserving way to express suspension, revocation, expiry, or status change.
7. A physical backup. Dead batteries, poor connectivity, damaged devices, conservative jurisdictions, and transitional policy environments are normal reality — not edge cases.

Role-Based Disclosure: One Credential, Different Audiences

One of the biggest design failures in identity systems is assuming that one credential means one disclosure. That’s the opposite of good design.

A police officer at a roadside stop doesn’t have the same legitimate need as a rental desk. A rental desk doesn’t have the same need as an employer. An employer doesn’t have the same need as an online pre-check system.

A Future IDP should support different disclosure sets for different verifier categories:

• Roadside stop: Identity, photo, categories and entitlements, restrictions, validity status. Nothing more by default.
• Rental desk: Identity, photo, driving categories, issue and expiry dates, possibly age information — but not every field in the credential.
• Online pre-check: Proof of identity, proof of relevant driving entitlement, proof of current validity, possibly a booking-linked confirmation.
• Employer or fleet compliance: A separate, explicitly consented workflow, not the same disclosure profile as travel verification.

The standards already support this model. NIST’s current mDL draft describes queries that let verifiers specify which attributes they request. AAMVA’s implementation guidelines require the application to clearly show what data was requested and give the holder full control over which data elements are shared.

A Future IDP should not be a digital card. It should be a controlled disclosure instrument.

Instant Verification Must Not Become Instant Surveillance

This is where many digital identity projects go wrong. They describe “real-time verification” as if it automatically means progress. It doesn’t.

A verifier needs timely trust. But the issuer does not need to learn every place and every moment when the holder presents the credential. That distinction is essential.

The EU Architecture and Reference Framework is clear on this point. Relying party instances should not request the relevant status list every time a credential is presented. Instead:

• Updated lists should be downloaded separately, at times and from locations unrelated to a specific user presentation.
• Status-list positions should be randomized, with enough entries to provide collective privacy.
• List requests must not become tracking signals for specific holders.

NIST’s current mDL draft describes verifier validation based on issuer signatures and public keys without needing to contact the issuer directly. AAMVA’s guidance prohibits server retrieval in its implementation guidelines and centers device retrieval plus trust-service-based public key distribution instead.

A Future IDP should support instant verification — without creating a global record of where and when a driver proved who they were.

Trust Distribution: Governance in Machine-Readable Form

Many people discuss wallets and cryptography. Far fewer discuss the infrastructure that actually makes trust work — but the infrastructure is the part that matters.

A verifier can only trust a credential if it can reliably discover and trust the issuer’s public keys and related metadata. A Future IDP ecosystem needs a machine-readable, governable answer to questions like:

• Which issuers are legitimate?
• Which public keys are current?
• Which issuers are authorized for which jurisdictions?
• Which verifier categories are registered or accredited?
• What happens when an issuer rotates keys or changes policy?

AAMVA’s Digital Trust Service is one concrete example: a single, secure, resilient way for relying parties to obtain the public keys of issuing authorities, delivered through a verified issuer certificate authority list. The EU’s mDL manual describes Member States notifying the Commission of authorized mDL issuers, the Commission publishing that list for verification purposes, and relying-party registration within the wallet trust framework.

That’s the direction a Future IDP needs — not a system where everyone scans a QR code and trusts the result without validation, but one where trust is distributed, versioned, and machine-checkable.

Online and Roadside Must Share One Unified System

A serious Future IDP cannot split itself into separate systems: one for roadside checks, one for car rental, one for remote onboarding, one for identity verification, and another for driving verification. That fragmentation is exactly what users already suffer from.

The technical standards now exist to avoid it:

• ISO/IEC 18013-5 defines the interfaces for mobile driving license presentation in person.
• ISO/IEC 18013-7 extends that to presentation over the internet.
• The EU mobile driving license manual lists both car rentals and roadside checks as verification scenarios, and describes remote sharing as well as proximity checks using QR-triggered flows, Bluetooth, Wi-Fi Aware, and NFC.

The future system must handle both online and in-person scenarios, because travel includes both. Mobility includes both. Trust requires both.

The Web-Native Protocol Layer Is Now Mature

For years, one reason identity discussions felt imprecise was that the protocol layer was still incomplete. That’s much less true now:

• OpenID for Verifiable Credential Issuance 1.0 defines an OAuth-protected API for issuing credentials, explicitly supporting multiple credential formats including ISO mdoc, SD-JWT VC, and W3C VCDM credentials.
• OpenID for Verifiable Presentations 1.0 defines a mechanism for verifiers to request and receive credential presentations.
• W3C’s Verifiable Credentials Data Model 2.0 formalizes the three-party ecosystem of issuers, holders, and verifiers.

That changes the conversation. The Future IDP no longer has to be imagined as a single government application with custom-built processes. It can be designed as a governed credential profile on top of a broader interoperable ecosystem.

That doesn’t remove the need for public governance. It removes the excuse that there’s no modern protocol stack to build on.

Why Blockchain Is Optional — But Recognition Is Not

A Future IDP does not need blockchain as its foundation. That doesn’t mean distributed-ledger technology is useless — it may be valuable in specific transparency or registry roles — but it shouldn’t be treated as the center of the driving-credential system.

W3C VC Data Model 2.0 is explicit that verifiable data registries can take many forms: trusted databases, decentralized databases, government identity databases, or distributed ledgers. DID Core is equally explicit that many, but not all, DID methods use distributed ledgers. The standards don’t force a blockchain-first architecture.

That’s the right position, because the hardest part of a Future IDP isn’t the technology. The hardest part is:

• Legal recognition
• Issuer governance
• Reader deployment
• Verifier accreditation
• Trust-list operations
• Revocation logic
• Cross-border policy alignment

AAMVA built a trust service. The EU manual includes issuer publication and relying-party registration. UNECE drafts connect electronic permits to ISO/IEC 18013-5. The real challenge isn’t the absence of cryptography — it’s the challenge of governed interoperability.

A Realistic Future IDP Flow in Practice

A Future IDP should be simple in practice. Here’s how it works across three common scenarios:

1. Issuance or Refresh

The national authority verifies the underlying license record and issues a credential into the holder’s wallet. The wallet stores it securely, protects keys, and can later refresh status or receive updated attestations through a governed issuance flow. OpenID4VCI provides a viable web-native issuance layer, while AAMVA guidance requires encryption at rest, secure key storage, and holder authentication when data is accessed or released.

2. Remote Car-Rental Pre-Check

A rental platform sends an authenticated request for a minimal driving-entitlement set. The wallet shows the request to the holder, who approves it. The verifier receives the presentation over an internet-capable flow, validates the issuer signature and key material, checks locally available trust and status information, and pre-approves the booking. The EU mDL manual already describes remote car-rental sharing; NIST’s draft describes query-driven attribute requests; OpenID4VP and ISO/IEC 18013-7 provide the broad presentation direction for internet-based flows.

3. Roadside Stop

An officer requests the roadside disclosure set. The holder presents via a proximity flow. The reader validates the credential locally, checks the driving entitlements and validity, and sees no more than needed. The issuer is not contacted by default. The EU manual describes QR-triggered, Bluetooth, Wi-Fi Aware, and NFC-based roadside verification, while ISO/IEC 18013-5 and AAMVA guidance center proximity and device retrieval rather than real-time issuer contact.

That’s the right user experience: fast, verifiable, minimally invasive, and simple.

What the Future IDP Is Not

To be clear, the Future IDP is not:

• A standalone driving license
• A picture of a card
• A universal collection of identity data
• A verifier-controlled surveillance channel
• Paper in a digital format
• A blockchain-dependent trust system

It is a carefully governed presentation layer over nationally issued driving privileges. That’s less dramatic — and much more likely to work.

Why the Migration Path Matters as Much as the Architecture

The best architecture is useless if the migration path isn’t realistic. Governments won’t replace every paper workflow overnight — and they shouldn’t.

A realistic path looks like this:

1. Phase 1: Keep paper. Add a secure digital companion.
2. Phase 2: Standardize issuer trust lists and verifier categories.
3. Phase 3: Support both proximity and remote presentation.
4. Phase 4: Move routine checks and rentals to digital-first flows.
5. Phase 5: Reduce the paper booklet to backup status rather than primary status.

That path matches where the standards and official ecosystem work are already heading: ISO’s one-document logic, AAMVA’s trust-service infrastructure, EUDI’s wallet-based mDL use cases, and UNECE’s movement toward electronic permit models aligned with ISO/IEC 18013-5.

The Core Argument in One Sentence

Here’s the argument distilled: The future IDP is not a digital booklet. It is a governed answer to a cross-border trust problem.

Not a better-looking version of the old document — a better system. A system where:

• The legal right still comes from the national authority
• The holder controls presentation
• The verifier gets only what it needs
• Trust can be checked without default surveillance
• Remote and in-person use share one architecture
• Paper survives only where it still has practical value

That’s the standard to aim for.

Once you see the problem that way, the interesting question is no longer whether the IDP should become digital. The interesting question becomes: who is willing to design the cross-border driver identity layer seriously enough to replace paper without reproducing its weaknesses — or adding new ones?

None of this is speculative. NIST’s current mDL work describes a wallet controlled by the user, a verifier that validates authenticity without needing to contact the issuer directly, and a credential ecosystem built around issuers, wallets, and verifiers. AAMVA’s Digital Trust Service already exists to distribute issuing-authority public keys. The EU’s mobile driving license manual describes authorized issuer lists and relying-party registration inside a broader trust framework.