No Call-Home Verification: Why the Future Digital IDP Must Not Phone the Issuer on Every Use

Revocation is the hardest problem in any future digital International Driving Permit (IDP). The easiest way to solve it is also the most dangerous: make the issuer a participant in every single presentation. A modern cross-border driving credential should refuse this shortcut by default.

Almost every digital-identity proposal contains the same reassuring sentence:

“The credential can be verified instantly.”

Sometimes that sentence describes genuine progress. Sometimes it describes surveillance with a friendlier user interface.

Today’s published standards already make clear that a verifier does not need to contact the issuer every time a credential is shown:

• NIST’s current mDL architecture states that a verifier can validate authenticity and integrity by trusting the issuer’s signature and public keys, without any direct contact with the issuer.
• AAMVA confirms that ISO/IEC 18013-5 requires support for device retrieval and only optionally permits server retrieval.
• AAMVA also warns that under server retrieval, the issuing authority is involved in real time on every use — which means it can technically log when the credential is used, what data is shared, and even infer location from IP analysis.

That is not a minor footnote. It is the central design question for the next generation of cross-border driving credentials.

The Dangerous Shortcut: Collapsing Four Questions Into One Network Call

Bad architectures bundle four very different questions into a single live call to the issuer:

1. Is this credential authentic?
2. Is the person presenting it the rightful holder?
3. Is the credential itself still valid?
4. Is the underlying national driving right still in force?

A poorly designed system answers all four by phoning home in real time. A well-designed system separates them — because they are not the same problem and they should not share a mechanism.

Authenticity Should Be Verified Locally, Not Over the Network

A credential can be cryptographically genuine without the issuer ever observing the transaction.

• NIST’s mDL trust model says authenticity and integrity are validated from the issuer’s signature and public keys — no live issuer contact required.
• AAMVA’s Digital Trust Service exists precisely to give verifiers access to valid issuer public keys without per-transaction callbacks.

Design Principle 1: Do not use live connectivity to solve a problem that signatures already solve.

If a verifier holds trusted issuer keys and receives a standards-compliant presentation, authenticity is a local cryptographic check, not a network dependency.

Holder Binding Should Be Proven Locally, Not Reported Globally

The second question — is this the rightful holder? — also has a non-network answer.

The current EUDI architecture mandates device binding for PIDs and ISO/IEC 18013-5 attestations. The verifier asks the wallet to sign a fresh challenge using the private key that corresponds to the public key embedded in the credential:

• In ISO/IEC 18013-5 this is called mdoc authentication.
• In SD-JWT VC it is called key binding.

In both cases, possession is proven locally and cryptographically. No personal data ever needs to reach the issuer.

Design Principle 2: Prove possession locally. Do not prove identity globally.

A future IDP should exhaust device binding, local holder authentication, and verifier challenge-response before it considers any issuer-side mechanism.

Credential Status and Driving-Right Status Are Two Different Things

Many digital-identity designs blur this distinction, and that is where they go wrong.

W3C’s Bitstring Status List specification makes the point clearly: status information attached to a verifiable credential applies to the verifiable credential itself — not necessarily to the underlying real-world entitlement. A digital credential might be revoked because its signing mechanism was compromised, while the underlying driving right remains perfectly valid.

A future IDP therefore needs two distinct status layers:

• Credential-status layer — for the digital credential or presentation channel itself.
• Driving-right layer — for the underlying national entitlement to drive.

Sometimes these change together. Often they do not. A system that conflates them will overreact, expose more data than necessary, or both.

Wallet Compromise Should Cascade Through Status — Not Trigger Verifier Callbacks

A future IDP also needs a clean answer for what happens when a wallet is compromised.

The EUDI architecture provides one:

• The wallet provider issues Wallet Unit Attestations containing revocation information.
• Wallet integrity is re-verified over time; if a wallet is no longer secure, its attestation is revoked.
• PID providers must regularly check whether the wallet has been revoked. If it has, they revoke the PID.
• By verifying PID status, the relying party implicitly verifies wallet status.

This is the layering a future IDP should adopt. Do not ask every verifier to independently check the wallet provider. Let wallet compromise propagate through the existing credential-status pipeline, and let verifiers consult that single privacy-preserving channel.

Three Workable Revocation Patterns (No Callbacks Required)

EUDI requires providers to use one of three revocation methods:

• Short-lived attestations — valid for 24 hours or less, so revocation becomes unnecessary.
• Attestation Status List — a published list verifiers can consult.
• Attestation Revocation List — an explicit list of revoked credentials.

For attestations valid longer than 24 hours, EUDI requires embedding revocation information that includes:

• A URL where relying parties can fetch the status list.
• An identifier locating the credential within that list.

If reliable revocation information is unavailable — for example, when the relying party is offline — EUDI directs the relying party to perform a risk analysis before accepting or refusing the credential.

The takeaway: revocation is not a single mechanism, and certainly not a justification for mandatory issuer callbacks.

Short-Lived by Default, Long-Lived Only Where Necessary

One of the most effective privacy measures in the entire stack is also the simplest: keep what is presented short-lived.

• EUDI says attestations valid for 24 hours or less do not require revocation infrastructure — they expire before revocation would matter.
• W3C says verifiable presentations are typically short-lived and not designed for long-term storage.
• NIST warns explicitly against repeatedly transmitting reusable identifiers for everyday use. Day-to-day authentication should rely on technologies built for that purpose, such as passkeys, not the repeated presentation of an identity-rich credential.
• NIST also chose local device authentication over server-side biometric matching specifically because local authentication preserves privacy and is operationally more efficient.

Design Principle 3: The base credential may have a medium validity period, but the presentation itself should be short-lived, verifier-specific, and non-reusable.

Status Lists Are the Right Default Mechanism

When you cannot make everything short-lived, you need status infrastructure — and the status list is the right default.

W3C’s Bitstring Status List v1.0 describes a privacy-preserving, space-efficient, high-performance mechanism for publishing status data such as suspension or revocation. Key properties include:

• Each issuer manages a list for the credentials it has issued.
• The format compresses well, since most credentials remain unrevoked.
• The default list size is 131,072 entries, which W3C says provides adequate group privacy in the average case.
• Larger lists can be used where stronger group privacy is needed.

This shifts the question from:

“Can I ask the issuer about this user right now?”

to:

“Do I already have a recent enough privacy-preserving status list to decide locally?”

That is a much better question — both technically and politically.

“No Call-Home” Is a Download Pattern, Not a Slogan

The most important rule in EUDI’s privacy guidance is procedural, not philosophical.

Relying parties must not request the status list every time a credential is presented. Instead, they must:

• Download each new version of the list once.
• Do so at a time and from a location unrelated to any user presentation.
• Distribute the list internally within the relying-party organisation.
• Fetch the list without authenticating the relying party.

That is the operational core of no-call-home verification: refresh status separately from user presentations — never per person, never per transaction.

This single design choice prevents the issuer or status provider from learning which verifier checked which credential at which moment.

Group Privacy: The Requirement Most Designs Forget

Many systems trumpet selective disclosure inside the presentation itself, then quietly ignore the privacy of status lookups. That is a significant gap.

EUDI’s privacy requirements specify that:

• Indices in status lists must be randomly assigned, so the index itself never becomes a tracking signal.
• Each list must cover a sufficiently large number of credentials to ensure group privacy.
• If a list would otherwise be too small, providers should add unused entries to obscure the real credential count.

A future IDP cannot claim to be privacy-preserving on the strength of selective disclosure alone. If the revocation mechanism leaks the presentation event, the privacy design is incomplete.

Offline Operation Is Not an Edge Case — It Is a Core Requirement

Any travel system that assumes perfect connectivity is poorly designed.

• AAMVA confirms that device retrieval works without outside connectivity for both holder device and reader, and that ISO/IEC 18013-5 requires mDLs to support device retrieval.
• EUDI accepts that relying parties may be offline and lack a cached status list, in which case it recommends a risk analysis before deciding.

Accept this trade-off early:

You cannot have perfect offline operation and perfect real-time freshness at the same time.

Any architecture promising both without compromise is either imprecise or quietly reintroducing surveillance. The right response is to make freshness a policy input, not a universal network dependency.

Logs Are Where Privacy Quietly Fails

Even an excellent status architecture can be undone by careless logging.

• EUDI requires relying-party instances to discard unique elements and timestamps as soon as they are no longer needed, and forbids forwarding them.
• AAMVA prohibits stakeholders from tracking mDL holders or mDL usage except where required by law, requires issuing authorities to minimise sharing of static or long-lived metadata, and restricts activity-log access to the holder.
• AAMVA also requires that on-device deletion remove log information and metadata that could reveal usage history — and that this deletion be possible offline.

This is protocol behaviour, not administrative housekeeping. A future IDP must treat long-lived identifiers, timestamps, and logs as potential tracking tools unless explicitly proven otherwise.

A Concrete No-Call-Home Architecture for the Future IDP

Pulling the principles together, here is what the system should actually do:

1. Issue a device-bound base credential. Bind the credential to keys protected in the wallet’s secure environment — mandatory under EUDI for PIDs and ISO/IEC 18013-5 attestations.
2. Request only what is needed, with a fresh challenge. In an OpenID4VP transaction, a DCQL query lets the wallet show the holder which attributes are being requested, and the verifier issues a challenge to prevent replay (per NIST’s current mDL architecture).
3. Generate a short-lived presentation, not a reusable identifier. Each presentation should be specific to the verifier, the request, and the moment.
4. Verify authenticity locally. Validate issuer signatures and public keys offline; AAMVA’s trust service is built for exactly this.
5. Check status from cached, separately refreshed lists. Where credentials are too long-lived to skip revocation, use locally cached status lists refreshed on a schedule unrelated to user presentations.
6. Apply a risk policy when freshness is unavailable. Make offline decisions explicit verifier policy, not unstructured guesswork.
7. Delete tracking data aggressively. Discard transaction-unique elements and timestamps when no longer needed; do not retain logs that could reconstruct movement history.

This is what a serious no-call-home architecture looks like — layered, privacy-preserving, cryptographically local, and operationally honest about offline reality.

Three Patterns That Should Be Prohibited by Design

A mature future IDP ecosystem should treat these as architectural failures, not optimisation choices:

• Mandatory issuer callbacks on every presentation. AAMVA’s own privacy guidance explains why this is harmful.
• Using the driving credential as a routine login. NIST explicitly warns against repeatedly presenting identity-bearing credentials for daily authentication.
• Retaining identifiers, timestamps, and logs that can reconstruct presentation history. Both EUDI and AAMVA require the opposite.

The Core Argument in One Sentence

Instant verification must not become permission for issuer-side surveillance.

A future IDP should be able to:

• Prove authenticity locally.
• Prove possession locally.
• Check freshness privately.
• Tolerate offline reality.
• Function gracefully when perfect information is unavailable.

None of this makes the system weaker. It makes it worth deploying at scale.

The moment a driving credential becomes a tool for recording who showed what, where, and when, it stops being a safer version of paper. It becomes infrastructure for observation.

That is exactly what the future IDP should refuse to become.

Frequently Asked Questions

What is “call-home verification”?
It is any design in which a verifier contacts the issuer in real time to validate a credential. While it solves authenticity and revocation simultaneously, it also lets the issuer observe every presentation event.

Does ISO/IEC 18013-5 require online issuer contact?
No. AAMVA confirms ISO/IEC 18013-5 requires support for device retrieval and only optionally permits server retrieval.

How can revocation work without contacting the issuer?
Through short-lived credentials, attestation status lists, or attestation revocation lists — ideally with the relying party downloading status data separately from user presentations.

Why is “group privacy” important for status lists?
If a status list is too small or its indices are predictable, a status request can leak which specific credential was just presented. Random indices and large lists prevent this.

Is offline verification really practical?
Yes — and standards bodies including AAMVA and EUDI explicitly require it. The trade-off is that perfect real-time freshness is incompatible with perfect offline operation, so freshness must become a policy decision, not a hard dependency.