Police, Rental Desks, Employers, Insurers: Why They Must Not See the Same Data

The biggest design mistake in a future International Driving Permit (IDP) would be treating every verifier as the same verifier. A police officer, a car rental desk, an employer, and an insurer do not ask the same question — so they should not receive the same answer.

One driver. One underlying right to drive. One wallet. But four very different verifiers:

• A police officer at the roadside
• A car rental desk at pickup
• An employer checking fleet eligibility
• An insurer reviewing a claim

If the future IDP shows the same data to all four, the system has already failed. Not because the credential is insecure, but because the disclosure model is too simple.

The standards community is already moving away from that simple model. W3C’s verifiable-credentials work describes the ecosystem around issuers, holders, and verifiers, using employers and websites as examples of verifiers. The EU’s mobile driving-license work already treats roadside checks and car rentals as separate verification scenarios, including remote advance sharing for rentals and in-person checks for police. The architecture is already designed for multiple verifier types. The mistake would be designing the user experience as if only one type exists.

Why the Physical Card Trained Us to Think Incorrectly

A physical license trained us into a show-everything approach. You hand over the card. The other person sees what is on the card. That is the entire interaction.

That approach is acceptable in a paper world because there is no alternative. It becomes unacceptable in a digital one.

The W3C VC Data Model 2.0 states directly: a driver’s license may contain ID number, height, weight, birthday, and home address — but that can still be far more than necessary for a given transaction. Key points from current standards:

• W3C best practice: support selective disclosure, and request only what is strictly necessary
• EU data-protection guidance: processing must be limited to specified purposes, and the data processed must be necessary and proportionate
• The first principle of a future IDP: same credential does not mean same right to inspect

The Right Model Is Policy-Based Disclosure

If you want a serious architecture, the right model is closer to attribute-based access control than to digital card presentation.

NIST SP 800-205 defines access-control decisions as evaluations of attributes associated with the subject, object, requested operation, and environment conditions, against policy. That is exactly the right structure for a future IDP:

• Subject: the driver
• Object: the requested data fields
• Action: not “see license” in the abstract, but something specific like “verify entitlement to drive category B at roadside” or “verify rental eligibility for a booking”
• Environment: roadside, rental desk, remote pre-check, fleet onboarding, and post-loss claim review are different environments and should lead to different decisions

NIST also notes that attribute systems need granularity, governance, and mechanisms for reduction, grouping, and minimization of attributes.

So the future IDP should not ask: Can this verifier read the license? It should ask: Which claims may this verifier receive, for which intended use, in this environment, with what retention rules?

A Verifier Should Identify Itself Before Requesting Anything

The future IDP should not begin with the wallet showing data. It should begin with the verifier proving who it is.

The EUDI architecture is clear on this. Relying parties must:

• Register what attributes they intend to request and for what purpose
• Receive access certificates
• Authenticate to the wallet before any disclosure
• Be checked against their registered scope, where registration information is available

The user can then see who is asking, what is being asked for, and whether the request is within the registered scope.

ETSI’s current wallet-relying-party certificate work makes this more concrete. A wallet-relying-party registration certificate can describe the relying party’s intended use and the attributes it registered to request. The related access certificate exists to ensure the request comes from a legitimate, authorized party. ETSI also includes relying-party metadata such as:

• Trade name
• Support URI
• Intended use
• Entitlements
• Registry URI
• Supervisory-authority information

The second principle of a future IDP: no verifier identity, no disclosure.

Why Consent Screens Are Not Sufficient

There is another mistake here: treating user approval as the same thing as legal legitimacy.

The EUDI architecture explicitly says user approval to present attributes must not be treated as lawful grounds for the relying party’s processing of personal data. The relying party must still have its own lawful basis. EUDI also requires user approval in all use cases, including cases where the relying party might be part of law enforcement or another government agency.

A good wallet interface can help, but it cannot solve verifier overreach by itself. The rule has to exist before the interface.

A future IDP therefore needs both:

• Cryptographic verifier authentication to confirm who is asking
• Policy constraints on what that verifier category may request

Without both, “user choice” becomes a way of shifting policy failure onto the individual.

1. Police: Verify the Right to Drive, Not the Entire Person

The police roadside scenario is the most focused one.

The EU mDL manual describes it directly: police or other officials check the license when required, including license validity and vehicle entitlements. In the user journey, the officer verifies the license through a QR-triggered flow, Bluetooth, Wi-Fi Aware, or NFC. That is a focused verification task:

• Is this person the holder?
• Is the credential valid?
• What vehicle entitlements and restrictions apply?

Allowed by default:

• Name
• Portrait
• License status
• Issue and expiry dates
• Categories
• Driving-relevant restrictions
• Issuer and jurisdiction
• Freshness/status result

Not allowed by default:

• Home address
• Internal identifiers not needed for roadside use
• Unrelated attributes from other attestations
• Historical presentation logs
• Commercial metadata

AAMVA’s implementation guidance reinforces the portrait point: if the portrait is requested and any other element is released, the portrait should be shared so the verifier can connect the data to the person presenting it. The same guidance also says stakeholders must not track mDL holders or mDL usage except where required by law.

The police case is not about the state receiving everything. It is about the state receiving the driving-specific data needed for roadside enforcement. That is an important difference.

2. Rental Desks: Eligibility, Identity Match, and Nothing Unnecessary

The rental case is more detailed because there are really two moments: remote pre-check before arrival, and pickup when a person or kiosk hands over the keys.

The EU mDL manual already models both. A car-rental service may request the mDL alongside proof of identity during booking, validate the attestations, and later verify the customer in person at pickup before releasing the vehicle. Users can share their mDLs with car-rental companies either in person or remotely in advance.

A rental desk does not primarily need to investigate an incident. It needs to decide: Can I rent this vehicle to this customer under this booking and policy?

Remote pre-check should include:

• Identity linkage
• Portrait or equivalent identity-binding element
• Relevant vehicle category
• Issue and expiry dates
• Current validity
• Possibly an age threshold or age band

Pickup should confirm:

• The holder is the same person who completed the pre-check
• Current validity
• Relevant entitlements

Not needed by default:

• Full home address when a booking profile already contains contact details
• Full birth date where age-over or age-band is sufficient
• Unrelated identity attributes
• Repeated re-presentation of the full credential if a booking attestation already exists

NIST’s current mDL architecture shows the relying party using DCQL to request only the needed attributes, and explicitly says this supports data minimization and holder consent by structuring the request rather than treating the credential as a single unit. AAMVA adds that the application should clearly show what data was requested and whether the verifier intends to retain the information.

3. Employers: A Verifier Category, Not an Opening Into Full Identity

W3C’s overview uses an employer’s digital system checking a university degree as a verifier example. That reminds us that employer verification is already a recognized pattern in credential ecosystems.

An employer or fleet operator may legitimately need to know:

• Whether a worker is currently entitled to drive certain vehicle categories
• Whether key restrictions exist
• Whether the entitlement remains valid

That is a real business need. But it does not automatically justify permanent access to the entire driving credential, the full identity data, or a continuous stream of repeated presentations.

NIST warns that frequently transmitting a reusable identifier and conditioning users to repeatedly present an identity-bearing credential is undesirable, and says day-to-day authentication should rely on technologies designed for authentication, such as passkeys. NIST prefers local device authentication over server-side biometric matching because it better preserves privacy.

A future IDP should not become a workplace access badge.

For employer and fleet use, the right pattern is usually:

• A job-relevant entitlement check
• Perhaps a periodic compliance attestation
• Perhaps a claim that the holder remains valid for specified categories
• But not a default transfer of all license data every time the employee signs into a system or starts a shift

Fleet compliance is a separate relying-party category, with a separate intended use, and a separate disclosure profile.

4. Insurers: Claims Are Not Permission for Continuous Visibility

The insurance case is often real. In the EU mDL use-case material, insurers appear indirectly in the rental scenario: insurance companies require car-rental companies to check whether the person renting the car has the right to drive. Insurance already influences the driving-verification flow.

But that does not mean an insurer should receive the same data as police, or a permanent right to access the credential.

A future IDP should treat insurers as a separate verifier category with separate intended uses:

• Underwriting
• Rental-risk verification
• Post-loss claim handling
• Fraud review

Those are not the same purpose. Under EU data-protection principles, personal data must be collected for specified purposes and limited to what is necessary and proportionate for that purpose. W3C’s VC guidance reaches the same conclusion technically: verifiers should request only what is strictly necessary.

Legitimate, event-specific examples:

• Proof that the license was valid at the relevant moment
• Proof of relevant vehicle entitlement
• Proof of identity linkage where necessary for a claim
• Claim-specific disclosure

Not permitted by default:

• Persistent access to the underlying credential
• Repeated generic verification every time the customer interacts with the insurer
• Use of the driving credential as a login token
• Collection of unrelated attributes

A driving credential is not a monitoring subscription. And it should not quietly become one.

Why Intermediaries Must Be Visible

Real markets involve intermediaries. Rental platforms, fleet vendors, employer HR systems, and insurance claims processors often act through third parties.

The EUDI architecture handles this by:

• Treating intermediaries as relying parties
• Requiring them to register
• Requiring attributes requested for the intermediated relying party to be registered
• Showing both the intermediary and the end relying party to the user
• Prohibiting intermediaries from storing data about the content of the transaction

A future IDP should never allow a pattern where the user believes they are disclosing to the rental company, but in reality they are disclosing to an invisible verification broker, analytics processor, and claims vendor chain.

ETSI helps here. Its wallet-relying-party certificate model includes support URIs, intended use, registry URIs, and supervisory-authority metadata. That is the type of machine-readable infrastructure needed for users to understand who is actually on the other end of the request and where to go when they want deletion or correction.

Retention Is Part of Access Control

Most discussions about selective disclosure end too early. They focus on what is disclosed. They do not focus enough on how long it remains afterward.

Current guidance is already converging:

• AAMVA: the wallet must clearly tell the holder what data was requested and whether the verifier intends to retain it; stakeholders must not track holders or mDL usage except where required by law
• W3C: holder software should provide logs of information shared with verifiers, so excessive requests can be identified
• EUDI: users should be able to access transaction logs, report suspicious requests, and request erasure

Retention class should be part of the disclosure policy itself:

• Police roadside: no retention by default beyond lawful operational record
• Rental pre-check: transaction record tied to booking, not a reusable identity copy
• Employer fleet compliance: compliance record or attestation result, not raw credential data
• Insurer claim: claim record limited to the claim, not permanent access

A future IDP that ignores retention is only partially privacy-preserving.

What the Wallet Should Actually Decide

If I had to reduce this entire article to one implementation rule, it would be this:

The wallet should not answer “Can I present this credential?” It should answer “Can I present this set of claims to this authenticated verifier, for this intended use, in this context, under this retention class?”

That decision should be driven by at least these inputs:

• Verifier identity
• Verifier category
• Intended use
• Registered attribute scope
• Disclosure policy from the issuer, if present
• Environment (roadside, pickup, remote, fleet, claim)
• Holder approval
• Applicable retention policy

The standards already contain much of the machinery for this: selective disclosure, relying-party authentication, registered intended use, access certificates, disclosure policy evaluation, and purpose-bound requests. What is still missing is the discipline to treat those pieces as one coherent disclosure architecture.

The Core Argument

The future IDP should not ask whether data can be disclosed. It should ask:

• Who is asking?
• For what purpose?
• Under which authority?
• In which context?
• With what retention consequences?

Police, rental desks, employers, and insurers are not four logos at the other end of a request. They are four different risk models, four different legal contexts, four different reasons to ask — and they should produce four different disclosure sets.

That is not unnecessary complexity. That is what a modern driving credential looks like when it stops treating every verifier as the same verifier.