The Stack Behind the Future IDP: Why It Takes a Layered Standards Architecture to Replace the Paper Permit

No single standard will replace the paper International Driving Permit (IDP). The real successor is a stack of standards working together — and understanding that stack is the key to understanding where cross-border digital driving credentials are actually heading.

Why No Single Standard Will Replace the Paper IDP

Most discussions about the future IDP open with the wrong question: which standard will replace the paper permit? That framing assumes one specification can do the entire job. It cannot.

NIST’s mDL (mobile driving license) work explicitly notes that new digital-credential standards are emerging across separate problem areas. The ISO 18013 family itself is already split across multiple parts covering physical design, security, mobile presentation, and internet extensions. A future cross-border driving credential is therefore not one specification — it is a coordinated stack of specifications, each handling a distinct concern.

The Future IDP Stack at a Glance

Here are the eight layers that, taken together, define what a future IDP looks like:

Layer 0 — Physical and data baseline: ISO/IEC 18013-1
Layer 1 — Credential security: ISO/IEC 18013-3
Layer 2 — Proximity (in-person) presentation: ISO/IEC 18013-5
Layer 3 — Remote / internet presentation: ISO/IEC 18013-7
Layer 4 — Credential semantics: W3C Verifiable Credentials Data Model 2.0
Layer 5 — Issuance protocol: OpenID4VCI
Layer 6 — Request and presentation protocol: OpenID4VP
Layer 7 — Trust distribution and verifier authorization: Trust registries (AAMVA’s VICAL model, the EUDI certificate-based relying-party model)

Every layer is grounded in current standards or active ecosystem documentation. The sections below explain what each layer does — and, just as importantly, what it does not do.

Layer 0 — ISO/IEC 18013-1: The Physical and Semantic Foundation

Part 1 matters more than most people realize, because it is not just about card design.

ISO/IEC 18013-1 defines the physical characteristics and basic data set of an ISO-compliant driving license, creating a common basis for international use and mutual recognition. It is built around a secure ID-1 card paired with a booklet for international use, replacing the older paper IDP model. ISO also notes that, in many cases, a single card can replace the need for two separate documents.

The practical implication is simple: the future IDP cannot start at the wallet layer. If the underlying document structure, data model, and layout are not standardized first, every digital layer above becomes a compatibility patch over fragmented national formats. Part 1 is the foundation the rest of the stack depends on.

Layer 1 — ISO/IEC 18013-3: Credential Security

Part 3 is where the credential transitions from being data on a document to being a security object. ISO describes 18013-3 as the part that specifies mechanisms for:

Access control to machine-readable data
Document authentication
Integrity validation

ISO is also explicit, however, that Part 3 does not address privacy issues related to the later use of the data — and that boundary matters.

In short, 18013-3 delivers credential security, not full ecosystem governance. It helps answer questions like: Was this credential issued by the claimed authority? Has the data been altered? It does not fully answer: Should this verifier even be requesting this field? Should this request be permitted in this context?

This is also an active layer rather than a finished product. ISO lists a 2022 amendment for the PACE protocol, a 2023 amendment for passive authentication updates, and a new draft of 18013-3 currently under development.

Layer 2 — ISO/IEC 18013-5: In-Person Mobile Presentation

If Part 1 defines the document and Part 3 secures it, Part 5 turns the license into a mobile credential.

ISO specifies that 18013-5 covers the interface between the mDL and the reader, and between the reader and issuing-authority infrastructure. It also enables third parties — including authorities and verifiers in other countries — to:

Obtain mDL data by machine
Connect that data to the holder
Authenticate its origin
Verify its integrity

What 18013-5 does not cover is equally important. ISO explicitly lists out-of-scope items, including how holder consent to share data is obtained and the requirements for storing mDL data and private keys. Part 5 is not a complete wallet product, not a complete user-consent model, and not a complete governance system. It is the transport and verification layer for mobile presentation.

AAMVA’s implementation guidance sharpens this further by distinguishing between two retrieval models:

Device retrieval, where the data is read directly from the holder’s device.
Server retrieval, which can allow the issuing authority to observe when the mDL is used, what data is shared, and even estimate physical location through IP analysis.

That second point is not a reason to reject the standard — it is a reason to be precise about which retrieval model a future IDP should use by default. AAMVA also requires the wallet to give the holder full control over which data elements are shared, which fits a future IDP far better than the older “show the entire document” model.

Layer 3 — ISO/IEC 18013-7: Internet Presentation

Part 5 solves the in-person problem. Part 7 extends that model to remote use.

ISO describes 18013-7:2025 as extending 18013-5 with internet presentation of an mDL to a reader. The internet is not a secondary consideration in this architecture; it is an explicit part of the standard.

The EU’s mobile driving license manual already treats internet presentation as practical rather than theoretical, describing scenarios such as:

Car-rental check-in, where users share their mDL either in person or remotely in advance
Roadside checks by police
A general mDL use profile built on ISO/IEC 18013-5 and 18013-7

That said, AAMVA’s current guidance is honest about the limitations: mDL use over the internet is highly desirable, but some supporting standards are still maturing. There are real gaps in current wallet-to-browser integration, and without a list of trusted readers, the mdoc side may have no reliable way to confirm certain security properties. Remote presentation is real — and still developing.

Even with those caveats, 18013-7 is the first serious answer to a problem the paper IDP never even attempted to solve: presenting driving entitlements remotely, before the person reaches the counter or checkpoint.

Layer 4 — W3C VC Data Model 2.0: The Semantics Layer

W3C’s Verifiable Credentials Data Model 2.0 is not a driving-license standard — and that is precisely why it matters.

The Recommendation defines an extensible data model for verifiable credentials, explains how they can be protected from change, and describes the ecosystem in terms of three core roles: issuers, holders, and verifiers. A driver’s license appears as one of its core examples.

For a future IDP, VC 2.0 contributes a general vocabulary for claims, presentations, and verifiable data registries. W3C is explicit that such registries can take several forms, including:

Trusted databases
Government identity databases
Decentralized databases
Distributed ledgers

That breaks the false binary between a blockchain-only approach and a fully proprietary one. The data model is broader than either.

VC 2.0 is also clear about selective disclosure. W3C notes that a driver’s license may carry more data than is needed for a given use case, and recommends either splitting information into smaller pieces or using mechanisms that enable selective disclosure. For a future IDP, this is not an optional privacy nicety — it is the difference between a modern credential and a digital photocopy of a plastic card.

VC 2.0 is not, however, a complete replacement for ISO 18013. W3C points out that the data model does not require a traditional certificate-authority chain-of-trust model. In practice, VC 2.0 is a strong semantics layer, but explicit trust-distribution and verifier-governance layers still need to sit on top.

Layer 5 — OpenID4VCI: The Issuance Protocol

A future IDP needs a standard way to move a credential from an issuer into a wallet. That is the role of OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0.

The specification defines an OAuth-protected API for issuing verifiable credentials, and it is intentionally format-independent. Among the credential formats it supports:

ISO mdoc
SD-JWT VC
W3C VCDM credentials

It also supports holder binding and later presentations without further issuer involvement. OpenID4VCI 1.0 was approved as a Final Specification in September 2025.

This makes OpenID4VCI strategically important for a future IDP ecosystem. Rather than building bespoke issuer-to-wallet pipelines for every jurisdiction or wallet provider, the ecosystem can define a governed issuance profile on top of a standard issuance framework — while still choosing whether the resulting credential is encoded as mdoc, VC, or another supported format. That flexibility is one of the strongest arguments for keeping the future IDP stack modular.

Layer 6 — OpenID4VP: The Request and Presentation Protocol

If OpenID4VCI moves the credential into the wallet, OpenID for Verifiable Presentations (OpenID4VP) moves it back out in a controlled way.

The specification defines a mechanism to request and present credentials. Its baseline uses HTTPS messages and redirects, but it also supports use over the W3C Digital Credentials API instead of redirect flows. OpenID4VP 1.0 reached Final Specification status in July 2025.

That matters because it gives the future IDP stack a web-native presentation layer that websites, applications, and online verifiers can implement directly. Several recent developments reinforce this:

In August 2025, the OpenID Foundation announced a formal security analysis of OpenID4VP used over the Digital Credentials API, with no new vulnerabilities found in the verified protocol model.
NIST’s current mDL draft builds its threat model around requesting and presenting mDLs via OpenID4VP over the W3C Digital Credentials API, with FIDO CTAP used to enforce proximity and resist phishing in relevant flows.

The web side of the stack and the mDL side are converging. OpenID4VP should not be read as a competitor to ISO 18013-7 — it is the web protocol layer that makes internet presentation practical across real-world browser, wallet, and verifier environments.

Layer 7 — Trust Registries: Where the Stack Becomes an Ecosystem

This is the layer many discussions skip — and the layer that determines whether the entire system actually works.

A verifier cannot do much with a signed credential unless it knows three things:

Which issuers are legitimate
Which public keys are current
Whether the requesting party is itself authorized

On the issuer side, AAMVA’s Digital Trust Service offers a concrete answer. It provides a single, secure, resilient way for relying parties to obtain issuing-authority public keys, distributed through the Verified Issuer Certificate Authority List (VICAL). AAMVA’s guidance describes the VICAL provider role in practical terms: collect public keys from legitimate issuing authorities, verify that those authorities manage their keys securely, combine the keys into a single VICAL, and deliver it to verifiers.

On the verifier side, Europe approaches the trust problem from another direction. In the EUDI Architecture and Reference Framework, relying parties register, obtain access certificates, and use those certificates to authenticate themselves to wallet applications when requesting attributes. The wallet then verifies the certificate chain, checks revocation status, presents the request to the user, and releases only the approved attributes.

W3C’s VC model contributes here too, treating verifiable data registries as a distinct ecosystem role. As noted earlier, those registries can be trusted databases, government identity databases, decentralized databases, or distributed ledgers. A future IDP trust registry does not need to be built on blockchain. It needs to be governed, auditable, and machine-readable.

If ISO 18013 defines how the credential looks and travels, trust registries decide whether anyone should believe it.

A future IDP is a stack, not a single spec

How a Future IDP Transaction Works End-to-End

Here is the stack in operation, broken into the four key moments of a credential’s life cycle.

1. Issuance. A national authority — or a tightly governed authorized issuer — verifies the underlying license record and issues a credential into the holder’s wallet. OpenID4VCI is the most practical issuance layer available today, because it already supports ISO mdoc, SD-JWT VC, and W3C VCDM formats. ISO 18013-5 itself leaves consent collection and private-key storage out of scope, which is exactly why issuance and wallet governance must operate above the basic ISO transport layer.

2. In-person presentation. At a roadside stop or rental desk, the wallet presents the credential using a proximity flow based on 18013-5. The reader validates origin and integrity using issuer keys obtained from a trust registry — rather than making trust decisions on its own. The holder approves only the fields needed for that specific situation.

3. Remote presentation. For pre-rental checks or other online processes, the verifier requests a minimal set of attributes over an internet-capable flow using 18013-7 and/or OpenID4VP. The wallet shows which attributes are being requested, the holder approves, and the verifier receives a structured presentation rather than a scan or PDF upload. NIST’s current architecture, built around OpenID4VP plus the Digital Credentials API, demonstrates that this is now a practical engineering path.

4. Trust and verifier authorization. The wallet does not blindly trust every requester. A mature ecosystem authenticates the relying party, validates certificate chains, checks revocation status, and gives the user visibility into who is asking for what data. The EUDI model is particularly strong here, treating verifier registration and access certificates as essential parts of the system rather than optional add-ons.

This complete flow is exactly why a future IDP must be a stack. No single layer can deliver it. Not ISO alone. Not VC alone. Not OpenID alone. And certainly not a PDF attached to a form.

What Is Still Missing from the Future IDP Stack

The hardest remaining problem is no longer creating new cryptography — it is achieving governed interoperability.

Consider where the ecosystem stands today:

NIST has described the current standards landscape as developing across separate areas.
AAMVA has built a regional trust service for North America.
Europe is building certificate-based relying-party trust into its wallet architecture.
OpenID has finalized issuance and presentation specifications and is expanding conformance infrastructure.

These are still ecosystem-specific answers. There is not yet one global cross-border trust layer for driver credentials. The remaining work is to define:

Which parts of the stack are mandatory
Which credential formats are acceptable
How issuer and verifier trust is distributed
How conformance is tested
How cross-border recognition is governed without compromising privacy

Conclusion: The Future IDP Is a Stack, Not a Document

A future IDP will not appear because one standards organization writes one document. It will emerge when a coherent stack is defined, governed, and adopted across jurisdictions. That stack already has identifiable layers: