Do Digital IDs Track You? The mDL "Phone Home" Problem, Explained

A digital ID does not have to track you, but some implementations can. Whether presenting a mobile driver's license notifies the government depends on a technical choice most holders never see: does the verifier check the credential with your phone, or with the state that issued it?

The question reached prime time in July 2026, when PBS NewsHour ran a segment on digital IDs. Twenty states and Puerto Rico now offer a digital driver's license or state ID, and TSA accepts mobile driver's licenses at more than 250 airport checkpoints. In the segment, ACLU senior policy analyst Jay Stanley put the concern plainly: "The standard for digital ID that a lot of the states, although not all of them, are adopting, would actually let the government track you."

That warning is specific, technical, and fixable. This article explains the "phone home" problem behind it: where tracking can enter a digital ID system, what the industry changed in 2025, and what to require from any digital ID verification, especially online, where the same credentials are starting to power age checks and account verification.

Digital IDs went mainstream fast

For most of a decade, digital driver's licenses were a pilot-program curiosity. That changed quickly. Apple and Google both support IDs in their wallets, twenty states and Puerto Rico issue some form of digital credential, and TSA accepts mobile driver's licenses from participating states at checkpoints across the country.

The pull is convenience, but the push is regulatory. Age-assurance rules now cover adult content, alcohol, cannabis, vaping, gaming, and app stores across a growing set of jurisdictions, and businesses need a way to check ages that does not involve collecting ID uploads. A cryptographically signed credential that lives in a phone wallet is the strongest candidate. Which is exactly why its privacy properties matter beyond the airport: the same mDL presented at a TSA checkpoint is starting to be presented to websites.

What "phone home" actually means

Mobile driver's licenses are standardized under ISO/IEC 18013-5, which defines how a wallet presents a credential to a verifier: a TSA reader, a point-of-sale terminal, a website. The standard contains two retrieval modes, and the privacy difference between them is the whole story.

Device retrieval: your phone answers directly

In device retrieval, the verifier asks your phone for specific fields, and the phone responds directly over NFC, Bluetooth, or a QR-initiated channel. The response was signed by the issuing state when the credential was provisioned, so the verifier can check its authenticity offline, with no call to the DMV during the presentation. The protocol sends the issuer no signal that the presentation happened. The verifier or wallet software can still keep its own records. This is the mode Apple and Google wallet IDs use at TSA checkpoints today.

Server retrieval: the issuer joins every check

In server retrieval, the verifier takes a token from your phone and redeems it with the issuing authority's server, which returns your identity data. The verification works, but the issuer receives a real-time signal that your ID was checked and can log when and by whom. Multiply those records across bars, pharmacies, banks, hotels, and websites, and the issuing agency can accumulate a pattern-of-life log of everywhere you proved who you are. That is the architecture privacy advocates call "phoning home."

Nothing about server retrieval requires malicious intent. The log exists as a side effect of the protocol, which is precisely the problem. Data that exists gets requested, subpoenaed, shared, and breached.

The industry pushed back in 2025

The phone-home fight came to a head last year. In June 2025, the ACLU, the Electronic Frontier Foundation, and dozens of digital-identity technologists signed the "No Phone Home" statement, urging issuers to reject server-retrieval architectures outright.

The standards side moved too. AAMVA, the association of motor vehicle administrators that publishes mDL implementation guidance for state agencies, prohibited phone-home architectures in its Implementation Guidelines as of version 1.5, published in April 2025. Draft legislation has been proposed that would go further and require mDLs to operate without any remote-verification dependency.

But guidelines are not law. AAMVA cannot enforce its recommendations on the fifty states, the ISO standard still defines server retrieval as a valid mode, and deployments that predate the guidance change are already in the field. Stanley's "a lot of the states, although not all of them" is the accurate summary: the architecture varies by state, and holders mostly cannot tell which one they carry.

The other half of the problem: what the verifier keeps

Phone home is issuer-side tracking. Verifier-side data hoarding is quieter and at least as consequential, and it is the half that every business checking IDs controls directly.

A physical license overshares by design: the bartender checking your age also sees your name, address, and exact birthdate. Digital credentials fix this with selective disclosure. A verifier can request a single derived attribute, like "over 21: yes," without receiving the birthdate behind it. The mDL data model supports exactly this kind of minimal query.

Selective disclosure only limits what a verifier asks for. What the verifier stores afterward is a separate decision. A business that requests minimal attributes but logs full presentation payloads is still building a database of personally identifiable information: the same breach liability that makes ID-upload systems dangerous, in newer packaging. And online presentment, where protocols like OpenID4VP carry wallet credentials to websites, adds a third requirement: unlinkability, so two sites (or the same site twice) cannot correlate presentations into a cross-site identity graph.

Those records can support more than identity checks. The PBS NewsHour segment highlighted surveillance pricing: a retailer can combine a verified identity with purchase history and other signals to personalize offers or prices. Device retrieval prevents issuer-side phone home, but it does not stop a verifier from building that profile. Data minimization and retention controls still matter after the credential is verified.

What privacy-preserving digital ID verification requires

Put together, the phone-home debate and the verifier-retention problem produce a concrete checklist. A digital ID system protects its holders when it delivers all five properties:

• Device retrieval, not server retrieval. The issuer is not contacted at presentation time and holds no record that the check occurred.
• Selective disclosure. The verifier requests the minimum attribute: an age tier, not a birthdate; a validity result, not a full identity record.
• No retention by default. The verifier keeps the outcome of the check, not a copy of the credential or the personal data inside it.
• Unlinkability. Presentations cannot be correlated across verifiers, or by the issuer, into a profile of where an ID has been used.
• Cryptographic verification. Trust comes from the issuer's signature, not from a human looking at a screen. A screenshot of an ID app is not a credential.

The direction of travel is toward proving even less. In 2025, Google added zero-knowledge age proofs to Google Wallet and then open-sourced the underlying library, Longfellow ZK, which proves a statement like "over 18" against an mdoc credential without revealing the underlying birthdate. The EU's digital identity wallet program is moving in the same direction for age verification. Zero-knowledge proofs reduce the credential data disclosed, but they do not erase verifier logs, IP addresses, or other transaction metadata.

How Stile verifies digital IDs without the tracking

Stile is designed to keep raw credential data out of merchant systems. Our digital ID and mDL verification uses device-side wallet presentment where it is supported and verifies the issuer's signature cryptographically. By default, the merchant receives a signed verification result, such as an age tier or a pass/fail decision, rather than a copy of the credential.

Stile still processes the credential attributes requested by the configured verification method. Current mDL flows may request name, date of birth, and other fields needed to verify the credential, and Stile applies the account's configured retention policy to that data. The default merchant webhook omits raw identity fields; a merchant-specific flow can explicitly request additional configured result fields.

Merchants integrate one API: create a verification session, let the user present whatever credential they have, and receive a signed webhook with the outcome. Because not every user carries an mDL, the routing layer can fall back to other verification methods with the same default merchant-facing contract: the business receives a decision, not source documents. The audit trail records the method and outcome to support compliance evidence without turning the business into a custodian of raw identity documents. See docs.stile.id for integration details.