Why Blockchain Is Optional for the Future International Driving Permit (IDP)

A future International Driving Permit (IDP) needs transparency, trust anchors, and public accountability. What it does not need — by default — is putting drivers themselves on a distributed ledger.

Every serious conversation about a digital, cross-border IDP eventually attracts the same proposal: “Just put it on blockchain.” The appeal is understandable. Blockchains offer tamper evidence, shared visibility, and an append-only history. Those are real properties. But in the context of cross-border driver identity, they are very often applied to the wrong layer.

This article explains why, walks through what the standards actually say, and lays out a better architectural pattern.

What the Standards Actually Say About Blockchain

The W3C Verifiable Credentials Data Model is explicit that a verifiable data registry can take many forms, including:

• Trusted databases
• Decentralized databases
• Government identity databases
• Distributed ledgers

DID Core is equally clear: many DID methods use distributed ledger technology, but not all of them do. In other words, the standards already reject the idea that blockchain is a mandatory foundation for digital credentials.

That is the right starting point for a future IDP. The useful question is not “blockchain or no blockchain?” It is:

Which layer actually needs transparency, and which layer absolutely should not become public infrastructure by default?

Blockchain Is a Collection of Properties, Not a Requirement

The first mistake is treating “blockchain” as a single requirement. It is not. It is a bundle of possible properties, including:

• Shared publication
• Append-only history
• Distributed operation
• Receipt generation
• Resistance to unilateral changes

Some of these are useful for a future IDP. Some are irrelevant. And some are actively dangerous when applied to human credential subjects. The W3C registry model deliberately allows multiple implementations because different ecosystems need different trade-offs.

Three Problems That Should Not Be Combined

The second mistake is collapsing three different problems into one system. For a future IDP, these need to stay separate:

1. Where legal truth lives. The right to drive belongs in authoritative national license records.
2. How trust material is distributed. Issuer keys and verifier certificates belong in controlled trust registries.
3. How the ecosystem audits changes. This belongs in a transparency layer.

Real-world ecosystems already work this way. AAMVA’s Digital Trust Service distributes issuer public keys in a downloadable list before a verifier ever interacts with an mDL. The EU mobile driving license manual specifies that Member States notify the Commission of authorized mDL issuers, and the Commission publishes a verification list of those authorities. That is trust distribution without blockchain.

What Certificate Transparency Teaches Us

The most effective transparency model on the public internet is not a consumer blockchain. It is Certificate Transparency (CT).

RFC 9162 describes CT as a protocol for publicly logging TLS server certificates so that anyone can:

• Audit certification-authority activity
• Detect problematic or mis-issued certificates
• Audit the logs themselves

The key design lesson from CT: transparency is most valuable when it records issuer behavior and trust material — not end-user activity.

Applied to a future IDP, that means logging things like:

• Issuance and rotation of issuer keys
• Publication of trust anchors
• Registration of verifier categories
• Policy changes
• Conformance statements
• Security-relevant events

What it does not mean is creating a public or semi-public ledger of holders, credential identifiers, or presentation events. That is not transparency. That is excessive data collection.

SCITT: Why Transparency Is Not the Same as Truth

The IETF SCITT architecture draft extends this thinking. SCITT defines a Transparency Service that maintains a verifiable data structure and issues cryptographic receipts proving inclusion of signed statements. The identity of the Transparency Service is captured by a public key known to relying parties, and trust anchors and registration policies are themselves made transparent.

This is a powerful model for IDP infrastructure because it turns transparency into an auditable service around trust material and policy — not around personal travel events.

SCITT is also clear about the limits of transparency:

• A registered statement only proves that an issuer produced and registered it — not that the statement is correct indefinitely.
• A later signed statement may replace an earlier one.
• Transparency does not prevent dishonest or compromised issuers; it holds them accountable.

For driver identity, that distinction matters enormously: a transparency log is evidence and audit history, not the authoritative legal state of someone’s driving right.

SCITT also notes that a transparency service can protect its append-only sequence using a combination of trusted hardware, consensus protocols, and cryptographic evidence. Even the transparency layer does not require one specific blockchain design. Consensus is one option, not the only option.

The Correct Architectural Separation for a Future IDP

A future IDP should separate concerns into four distinct layers:

1. Authoritative records of who may drive (national licensing authorities)
2. Trust registries for issuer and verifier keys
3. Status infrastructure for freshness and revocation
4. An optional transparency layer for public audit of policies, trust anchors, receipts, and conformance statements

Once you separate these layers, the blockchain question becomes much sharper. It is no longer “should the future IDP be on a blockchain?” It becomes:

Which layer, if any, actually benefits from append-only public audit?

Five Reasons On-Chain Driver Identity Is the Wrong Default

1. It Creates Durable Tracking Signals

The EUDI privacy work explains that attestation presentations can contain unique values such as:

• Salts
• Hash values
• Revocation identifiers
• Device-binding public keys
• Signatures
• Timestamps

Because those values are fixed for the same attestation, they let relying parties link different transactions and build a behavioral profile of the user. EUDI explicitly warns this violates the reasonable expectation that separate wallet activities will not be combined.

If you publish stable holder identifiers, stable credential identifiers, reusable hashes, or individually traceable revocation events on a public ledger, you are not solving the tracking problem — you are making it permanent.

2. It Exposes Revocation and Freshness Events

The W3C Bitstring Status List Recommendation describes the problem clearly: if there is a one-to-one mapping between a credential and the URL where its status is published, the publisher can connect the holder, the verifier, and the time of the check. The spec uses a driver’s-license example to illustrate why being tracked by the issuer when entering an establishment violates a common privacy expectation.

The better default that Bitstring Status List proposes:

• Large, compressible status lists where many credentials share one status resource
• A default list length of 131,072 entries
• Relying parties downloading new versions separately, without authenticating themselves
• Randomized indices and group privacy guarantees

That is the opposite of individualized, on-chain revocation traces.

3. It Confuses Credential Status with Legal Driving Status

A digital credential can be revoked because its signing mechanism was compromised — even while the real-world driving right remains valid. A public ledger of credential events is not a clean substitute for the authoritative state of a national driving record.

SCITT reinforces the point: a registered statement may later be replaced by a new one, and relying parties decide what to trust based on policy and history. The log is not permanent truth. It is evidence about who said what, when, under what policy. The national licensing authority remains the root of legal truth.

4. It Targets the Wrong Governance Problem

Cross-border driver identity is not primarily a consensus problem. It is a governance problem:

• Who is allowed to issue?
• Which public keys are current?
• Which verifiers are authorized?
• Which data requests match their declared purpose?
• Which policy version was in force at the time?

Real ecosystems already answer these through governed trust infrastructure, not decentralized consensus:

• AAMVA’s Digital Trust Service publishes issuing-authority public keys in a downloadable list.
• The EU mobile driving license manual says the Commission publishes the list of authorized mDL issuers.
• ETSI’s wallet-relying-party certificate work provides machine-readable verifier authentication with intended use and registered requested attributes.

That is explicit public trust administration — not decentralized governance.

5. It Does Not Solve the Roadside Reality

Many blockchain proposals quietly assume live network access is a benefit. For driver credentials — particularly at the roadside or during travel — it often is not.

AAMVA’s implementation guidance specifies that:

• Device retrieval works without outside connectivity for both holder and reader at transaction time.
• ISO/IEC 18013-5 requires support for device retrieval.
• Verifier access to issuer public keys does not need to happen at transaction time. Keys can be downloaded in advance.

If a verifier can already validate locally using cached trust material, a live blockchain dependency is not essential. At best, it is an implementation choice for some backend audit function.

What Should Be Transparent in a Future IDP

A future IDP absolutely does need transparency — in the right place.

Make these transparent by default:

• Issuer public keys and key-rotation events
• Trust anchors and authorized issuer lists
• Verifier access certificates and registered-purpose metadata
• Policy versions and registration rules
• Conformance statements and security-relevant software release claims
• Auditable receipts proving these statements were registered

Do not make these public by default:

• Holder identifiers on a public ledger
• Stable credential identifiers reused across verifiers
• Per-presentation events
• Raw revocation entries that isolate one person
• Full signed statements containing personal data when hashes or metadata would do

SCITT explicitly warns issuers to review the inclusion of private, confidential, or personally identifiable information before submitting statements to a transparency service. It also notes that transparency services can retain only cryptographic metadata such as hashes — not complete signed statements.

A Better Pattern: Transparency Around the Ecosystem, Not Through the Person

A clean architecture for a future IDP looks like this:

• Authoritative national registry — remains the legal source of truth for the right to drive.
• Credential layer — carries machine-verifiable driving entitlements to the holder’s wallet.
• Trust registry layer — distributes issuer keys, verifier certificates, and authorized-issuer lists.
• Status layer — uses short-lived attestations or privacy-preserving status lists refreshed separately.
• Transparency layer — may or may not use consensus internally, and logs trust anchors, key changes, policy updates, receipts, and ecosystem statements that benefit from append-only public audit.

This architecture captures the useful parts of blockchain thinking — append-only auditability, public scrutiny, tamper evidence, receipts — without turning the driver into the public subject of the system. It also matches what the standards already describe: registries can take different forms, DIDs do not require distributed ledgers, trust registries already exist, and privacy-preserving status mechanisms are already standardized.

The Core Argument

The future IDP should adopt the best idea from blockchain — public accountability for infrastructure — without adopting its worst default for people: durable, globally visible tracking.

In practice, that means:

• Transparency for issuers, not exposure of holders
• Auditable trust anchors, not public travel records
• Receipts for policies and registrations, not permanent timelines of credential use
• Append-only evidence for ecosystem governance, not on-chain driver identity as a default

This is not an argument against blockchain. It is an argument against applying blockchain to the wrong layer.

A future IDP may well use consensus-backed transparency services somewhere in the ecosystem. But if the design starts by putting the driver, the credential, or the presentation trail on a ledger, it has already chosen the wrong default.