Your digital ID phones home. It doesn't need to.

Tap to pay. Tap to get on the train. Tap to open the hotel room. Then the bouncer asks for ID and you’re digging through your jacket for a bit of plastic with a photo from 2017 on it.

The only reason you still carry a wallet is your government.

Now imagine the wallet told your government every pub you walked into. Which bar, which night, what time. That isn’t a dystopia I made up for an intro. It’s how the digital ID works in Victoria, in South Australia, in Louisiana, in Singapore and in South Korea. It’s what the barcode scanner on the door of an American bar does with your plastic. And it’s how every government sign-in in this post works for everything that isn’t a pub. I’m going to name them.

And your government knows it, which is why it’s building an app, and so is the next one over. The UK, Australia, Canada, the EU, South Korea, and the United States one state at a time, each building its own wallet, its own checker, its own vendors, its own bugs, and sixteen US states putting licences into Apple Wallet.¹ Add up the identity programmes with a published budget or audit and you pass US$3.7bn, counting only what’s on paper.²

At the point you use any of them, the product is this:

“How old are you?”

“18.”

A tick on a screen, and nobody, including the government, finds out you were asked. Everything else is plumbing, and the plumbing already exists. Most of the digital IDs governments run today get the plumbing wrong in the same way: a government server sits between you and whoever you’re proving yourself to, and it writes down every time. This is the version that doesn’t. I’ll show you what the apps do now, what it should feel like instead, how I’d build it, and then I’ll try to break it.

The rule is short. You decide who gets what. My ID. My choice.

The governments that know every pub you’ve been to

For these, there’s nothing to imagine. I went looking for the schemes where every check goes through a central server, and read what that server writes down. The pubs first.

Victoria: the bouncer needs the internet

Victoria says it plainly. “Digital licences need internet access for QR code scanning to work. You’ll get an error if you or the person checking your licence can’t connect.” Each scan “connects to their official licence records”.³ The state is in the loop for every bouncer in Melbourne, and no pub can check a licence in a basement. Every door you walk through is a request to a government server, and what that server keeps, Victoria doesn’t publish.

South Australia: the bouncer has to sign in

South Australia’s app shows a barcode that changes every 30 seconds, and “barcodes that have already been scanned won’t validate”. Something has to be keeping score of which codes were scanned, and that something isn’t the bouncer’s phone. To scan it at all, the person checking has to be signed in to the government’s own app.⁴ So the state knows the venue, the time and, because the checker logged in, who was on the door.

Singapore: the QR code points at the government

Singapore’s in-person check, Singpass Verify, the one a counter, a kiosk or a door uses, is a QR code that points at a government server. You scan it, the server tells the business who you are, and the business fetches your details from the government, server to server.⁵ The government is not a bystander to that check. It’s the switchboard.

South Korea: the check is live, until the building burns

South Korea’s mobile licence has a real-time authenticity check against a government system. When the data centre in Daejeon caught fire in September 2025, the mobile ID went with it and airports told travellers to bring plastic.⁶ A check that needs the server to say yes is a check the server watches every time.

Louisiana and Colorado: the bouncer calls the state

In Louisiana, three in four drivers carry LA Wallet, and the way a bar checks it is by scanning it with LA Wallet, which gives, in the vendor’s words, “immediate age verification from the State’s database”.⁷ The statute defines the credential as a data file on a device “which has connectivity to the internet”. The app’s privacy policy lists “precise geolocation” and “information about your activity” among what it collects, and nowhere says the state can’t see where you showed it. Then Louisiana made the same app the one state-approved way to prove your age to a porn site, and 2.9 million age checks went through it in the first year. The assurance that the broker in the middle keeps no log is the vendor’s president’s, in an interview.

And the database at the other end of every scan has already been emptied once. In June 2023 the MOVEit breach took Louisiana’s motor vehicle records, and the governor’s office told every Louisianan with a licence, an ID or a car registration to assume their name, address, Social Security number, birth date and licence number were gone. Oregon’s DMV said the same for 3.5 million of its drivers. Louisiana waited fifteen days to say so.⁸

Colorado is the cleanest contrast in the country, because one app carries both designs and the state documents both. Its 2019 Digital ID: “the data sharing process via a QR code requires internet service. In this case, if there’s no internet service, you’ll need to show your physical ID.” Its 2026 licence, built on the standard: “Do I need to have an internet connection? No, this works offline.” And: “The State of Colorado does not track where you use your mDL.”⁹ Same state, same phone, seven years apart. One phones home. One doesn’t.

America’s bars: the scanner on the door remembers

For everyone still on plastic, which is most of America, the scanner on the door is the server in the middle. Intellicheck, whose Age ID app sits on bar doors and shop counters across the country, says in its own privacy policy that “all scanned Document bar code data is retained”, and its app listing says it “keeps track of who was scanned and when”.¹⁰ Patronscan runs a “Flag Network” that shares “the date and venue” of a flag with every other bar in the network, and hands data to the police not only when compelled but “where disclosure is reasonably necessary”. That’s the status quo the digital version replaces, and it’s the American Outabox waiting to happen.

Twenty-six states: show your licence to a website

Twenty-six states now require adult websites to check your age, and the methods the laws allow are a government ID uploaded to a third-party verifier, a “digitized identification card”, or your transactional data.¹¹ In June 2025 the Supreme Court upheld Texas’s law six to three. The majority said adults “have no First Amendment right to avoid age verification” and that the websites and their verifiers “have every incentive to assure users of their privacy”. Justice Kagan’s dissent said what the burden is: “turning over information about yourself and your viewing habits” to a website operator “and then to … who knows? The operator might sell the information; the operator might be hacked or subpoenaed.” The verifiers’ own policies say how long they keep your licence: up to three years at Yoti, Persona and Jumio, three or five at AU10TIX. In October 2025 Discord’s support vendor lost about 70,000 government ID photos it had been holding for age appeals.

A wallet that answers “over 18” and nothing else is the fix for all of this, and it’s what the wine shop’s website does in the week below. Twenty-six legislatures wrote the demand. None of them wrote the answer.

And for everything that isn’t a pub, the sign-in services. These know every office you dealt with, every form, every night, and they keep it.

India: a court can pull your location from the log

Aadhaar is the biggest. The Act defines authentication as sending your number, with a fingerprint, an iris scan, a one-time code or your details, to the central repository, and the repository keeps a record of every one: the time, which organisation asked, and the answer. You can read your own history on the authority’s website, with the requesting agency’s name against each check. In September 2025 the Karnataka High Court ordered the authority to hand police “the details of location of the usage of Aadhaar card” of a missing man.¹² A family wanted that trail found. The point is that it exists for everyone, whether anyone’s looking or not. In 2018 a newspaper reported that access to the database was being sold for 500 rupees. The authority denied a breach and, in the same press note, pointed to its “complete log and traceability” as the way it would catch whoever did it. The log that watches every check is also its security answer. Three years later the national auditor found that one of the largest biometric databases in the world “did not have a data archiving policy”.¹³

Australia: the double blind that keeps your history

The federal digital ID is built around an “identity exchange” that, in the government’s own words, “mediate[s] all interactions” between the identity provider and the service you’re logging into. It’s called a double blind, because the two ends can’t see each other. The middle sees both. The exchange’s privacy policy says the transaction data is de-identified, then offers you your transaction history. The rules require the log to be kept for at least three years. When myID went down on 13 January 2025, the government systems that depend on it went with it.¹⁴

Denmark: people saw each other’s bank accounts

MitID logs “when, how and what you use your MitID for”, with a location worked out from your IP address. The name of the service is stored for every login and hidden from you by default. Every login passes through a broker and then the central service, and in January 2022 a bug in that service handed people other people’s bank sessions.¹⁵

The UK’s One Login keeps an audit trail of every service you used for seven years and shares it, for fraud, with the Home Office, the police and Experian. The US’s Login.gov keeps the agency, your IP, a device fingerprint and how you move the mouse, and its own privacy assessment says a privileged employee can pull a report of “which agencies a user has used Login.gov to access”. Before that, the IRS paid a contractor US$86m to put seven million taxpayers through facial recognition on a seven-year retention schedule, and reversed it in a fortnight once people noticed.¹⁶ Login.gov itself was found by the inspector general to have billed agencies over ten million dollars for an identity-proofing standard it didn’t meet, and this July the GAO found fraudulent accounts passing its proofing.¹⁷ Estonia keeps which e-service you used for ten years and charges for extracts, and in 2017 it had to suspend 760,000 of its ID cards because the chip’s keys could be factored, cutting holders off from close to 5,000 services until they renewed.¹⁸ Singapore keeps fifteen months and shows them to you, and in the last year its police have charged a ring that intercepted Singpass PIN mailers to take over accounts, then found another 171 compromised through a phone shop.¹⁹ China’s platform shows you your own history “on each internet platform” and hands it to the authorities on request. The quotes and the retention periods are in the table further down, each from the scheme’s own statute or privacy policy.^20212223

Every one of them sees every login, because that’s how a central sign-in works. It doesn’t have to work that way. A wallet can answer a website the same way it answers a bouncer, with nothing in the middle. Here’s the week that shows it.

A week with one wallet

One bloke, one wallet, one long week. The checks get harder as it goes on.

Friday: wine, and the till learns one thing

Dinner party, and you’re bringing the wine. Three bottles, because you know these people. Everything else in the basket goes through the self-checkout without comment. The wine stops it. The light comes on, someone walks over, looks at you, looks at the bottle, and asks for ID. You hand over a card with your name, your address, your birthday and your licence number on it, so a stranger can confirm one fact: over 18.

Instead, the checkout shows a code. You point your phone at it. Your screen says who’s asking and what they want: “Tesco wants to know: over 18. Nothing else.” You tap share. The light stays off and nobody walks over.

What your phone sent back is a card the government signed, and a signature here is maths, not ink. The till checks it with a public key it downloaded that morning, the way your browser checks a website’s padlock. Nobody can fake the signature without the government’s private key, and nobody called the government to check it. Tesco didn’t learn your name. It works in the Tesco Express under the railway arch with no signal.²⁴

The code is the version that works on every phone today. The version I actually want is a tap, the same one that pays for the wine, and the hardware is already in your pocket. Whether you’re allowed to use it is Apple’s and Google’s decision. Apple lets government IDs onto the chip only for issuers in the EU, New Zealand and the US, so a British or Australian wallet can’t tap today.²⁵ Getting on that list is a negotiation, and I come back to it in the technical half. Either way, the same check works at the pub door, at a festival gate with no signal, and at the shop that won’t sell you a kitchen knife. You don’t choose a card or open a department’s app. The wallet knows which credential answers the question and offers only that.

Saturday: the venue that has to know who you are

Saturday, and the dinner party has turned into a night out, because it always does. At most pub doors, Friday’s trick is enough: the bouncer’s phone asks “over 18”, yours answers, tick, in you go. Some doors aren’t most doors. If you’ve been out in Australia you’ve met one of these.

Some venues really are required to record who came in. Queensland’s licensing scheme makes certain venues scan IDs and check a banned list.²⁶ An age tick isn’t enough for that job, and the law isn’t going to change because I wrote a blog post.

Fine. Then give that venue permission to ask for more. Not “trust us, we’re a real venue”. A permission signed by the regulator, saying this venue, for this purpose, may ask for these fields and keep them for this long. Your wallet checks the signature before it shows you anything. Then it tells you exactly what you’re handing over, who’s getting it and when they have to delete it. You approve, or you go to a different pub. It’s 11pm. You approve.

The venue can’t ask for more than its permission says. And what the card-scanning box does today, photographing the whole licence and keeping it in a vendor’s cloud, goes away. In 2024 one of those vendors, Outabox, was breached, and the licence scans, photos and facial recognition data of more than a million club patrons in New South Wales and the ACT went with it.²⁷ A venue can’t leak what it never received.

The venue still runs its ban check against the regulator’s list, because the law says it must, and that is a record of you at that door. It’s the law’s record, kept by the party the law makes responsible, for as long as the law says. This design can’t remove it. It can make sure it’s the only one.

That permission model is the whole design, so here it is in three sentences. Anyone can ask whether you’re over 18, including a person: a landlord, a babysitter’s client. Only a business on the country’s register of approved askers, with a stated purpose, can ask your name, your photo, your date of birth or your address. And only whoever the owning department has signed off can ask for the numbers that run your life: HMRC decides who may ask for your National Insurance number, and a venue or a recruiter it hasn’t approved can’t put the question on your screen at all.

A permission to ask isn’t permission to take. You can still say no. But the request never reaches your screen unless the asker was allowed to make it. A lot of the personal data in systems with no business holding it got there because a form asked. I wrote about that already. This is the fix at the other end.

Monday: the airport, where the lane is the prize

Six in the morning, flying home on whatever sleep the weekend left you. Now the reader is an e-gate.

It asks for your travel credential and your photo, signed by the country that issued your passport. Your wallet shows the request, you approve, the gate compares your face, such as it is this morning, to the photo and runs the checks it runs today. Watchlists, visas, the stuff that needs a network. If those systems are down, the gate sends you to a desk, exactly as it does with a paper passport.

And yes, the bloke in this AI-generated video walks through the gate and leaves his bag behind. After the weekend he’s had, fair enough. Take your luggage with you.

The part I want is the lane. If you’ve sent your passport details ahead, the way you already type them into the airline’s site before you fly, the gate has nothing left to do but match your face. That’s a dedicated line for people on the digital system, and it moves faster than the passport line because the slow part happened on the plane. It’s a wish until a border agency builds it, and it isn’t in the diagrams later.

What I actually want is simpler still. I walk up to the gate with my phone in my pocket. The gate already knows a traveller is coming, because the phone told it from ten feet away. (There I go, using feet. Two passports and I’ve ended up with nobody’s units.) I tap, my face matches, the gate opens. No desk, no queue, no passport in a bag I left on the plane. That’s better than anything a government has proposed, or any consultancy has sold one, and every piece of it exists.

The pub door goes the same way: once the digital check is faster and can’t be forged, the quick queue is the phone queue.

Tuesday and Wednesday: no signal, same wallet

Tuesday, and you get pulled over in the middle of nowhere for being a bit wobbly on the road. You’re sober, it’s the lack of sleep, and the officer is about to confirm that. Don’t drink and drive, kids. Their reader asks for your licence fields. Your phone shows the request, you approve, they compare the photo to your face. No signal, no problem, the reader checks the signatures with the government’s public keys it downloaded this morning.

There’s a limit and the app should say so: if your licence was suspended five minutes ago and the reader hasn’t synced, it can’t know that. It shows what it can verify and when it last updated. The officer’s radio check is a separate thing, same as today.

Wednesday, and the licence is up for renewal, which after yesterday you’d like to go smoothly. At the transport department the wallet proves you’re you so they can find your record. They decide whether you get renewed, same as now. When they say yes, the new licence lands in the same wallet, and when your address changes you update it once, from the same wallet, with each department you choose. You don’t rediscover the “add document” button in six apps. Thursday you restock online, and the wine shop’s website asks the wallet the same single question through your browser, with nobody calling the government for the answer.

And if your phone’s dead, broken, stolen, or you don’t have one, the plastic card still works. Everywhere, always. A system that only works for people with the right phone isn’t a public service.

The same card, minus the oversharing

Everything in that week is the plastic card you already carry, doing the job it already does, with one change: it stops handing over things nobody asked for.

A signature is what stops fraud

Your plastic licence is hard to fake. Holograms, the laminate, the photo, the feel of it. A digital credential can’t be faked at all without the government’s private key, and that key never leaves the department’s vault. Anyone with the department’s public key can check the signature in a millisecond. Nobody without the private key can make one. A convincing plastic fake is a web search away. A convincing digital fake is a break-in at the government.

The credential is also tied to your phone. When it was issued, your phone made a key inside its secure chip, the private half never left, and the department wrote the public half into the credential before signing. So the till can check two things: that the government signed this, and that the phone holding it is the phone it was issued to. Copy the credential to another phone and it’s a screenshot of a card. Edit the birthday and the signature breaks.

That’s the fraud story at the till, and it’s better than plastic by a wide margin. It moves the fraud to two places. One is the oldest trick there is, an adult lending their phone to a 17-year-old, and the last section is honest about that. The other is enrolment: a real credential issued to the wrong person on forged documents, which is where identity fraud lives today and where it stays. This design makes the card unforgeable. It doesn’t make the government any better at knowing who you are.

The government hands you the card and leaves

When you buy wine today, the government isn’t told. Your plastic card doesn’t phone home. The digital one shouldn’t either, and in this design it can’t, because nothing at the till has the government’s number. The government checks you’re you, once, with the documents you already have, hands you the card, and keeps it fresh in the background the way a renewal arrives in the post. That’s the last it hears. Same card. Same issuer. The only thing that leaves your phone is the answer to the question.

Copenhagen, a bar, and one line of text

Say you’re in Copenhagen with a British licence in your wallet. The bar’s reader has the UK’s public keys in the bundle it fetched last week, alongside everyone else’s. It asks: over 18. You approve. The reader checks the British signature and your phone’s signature, and shows a tick. Nothing went to London. Nothing went to Copenhagen.

If that bar keeps a record of the check, the record is one line:

over_18 = true

Not your name. Not your birthday. Not your address, your licence number or your photo. The bar does know the card was British, because that’s whose key checked it. Compare that with tonight, where the same bar photographs the whole licence and keeps it in a vendor’s cloud until the vendor gets breached.

Read the exchange as a list

1. The pub → You: "Over 18?"
2. You → The pub: "Yes", on a card the government signed
3. The pub: Gets: over 18. Not your name, birthday, address or licence number.
4. The government: Gets: no notification. Nobody called it, so it doesn’t learn you went out, or where.
5. You: The card is single-use, so two pubs comparing notes can’t match you. If a pub sent the card back to the government, the government could recognise it. The technical half has the fix for that.

When is a record right? When the law puts it on the party in front of you. An employer has to keep proof you can work. A regulated venue has to check a ban list. A border keeps entry records. All of that stays, kept by the people the law makes responsible, for as long as it says, under a permission that names what they may keep. What goes is the other record, the one a central server keeps of every check, everywhere, whether any law asked for it or not.

But Will, surely it fails sometimes?

Less than you think. And when it does, the fallback is never “argue with the phone”.

No signal on either side. Nothing needs it. Both phones carry what they need from the last time they had signal.

The reader hasn’t synced in a while. It says so: “verified, revocations as of Tuesday”. The pub decides whether four days is fine, and it usually is. An e-gate decides it isn’t and sends you to the desk. A reader must never turn a four-day-old list into a clean tick.

Your phone is dead. It’s 2am, of course it is. Plastic. Always plastic. And, if Apple and Google allow it, the chip might answer anyway. A dead iPhone still taps a transit card or a car key for up to five hours, because those skip Face ID.²⁸ So this would be a mode you switch on, for over 18 and nothing else, knowing that a phone in that mode answers anyone who taps it, including a thief, and including a reader hidden in a bag in a queue. Off by default.

The government’s systems are down. Nothing already in your wallet stops working. In September 2025 a fire at a data centre in Daejeon took 647 South Korean government systems offline, the national mobile ID app among them, and airports told travellers to bring plastic.⁶ A wallet that needs a server to present goes dark with it. And on every other night that server sees the request: which door, which town, what time. No central log of where you showed your ID should exist, and the cheapest way to make sure is for no government server to be in the loop.

The standards bodies have already said no

The four schemes at the top aren’t the odd ones out. Here’s the rest of what I found, each line from the scheme’s own statute, rules or privacy policy. Most of the table is sign-in services, and a central sign-in sees every login because that’s what it’s for. The six in-person licence apps that phone home are the ones to notice, and so are the six at the bottom that don’t.

The standards bodies have already called this. ISO 18013-5, the licence standard, allows a “server retrieval” mode, where the reader asks the issuer’s server instead of the phone, and says in its own text that under it “the issuing authority knows when an mdoc is used and what data is shared”. In April 2025 the association of every US and Canadian licence authority changed server retrieval “from being optional to being prohibited”. The EU’s framework says wallets “SHALL NOT support server retrieval”. The US standards agency’s reference build doesn’t support it. Apple states that neither it nor the issuer can see when or where you present, and Google says nothing credential-related touches its servers.³¹ The people writing the standards agreed a while ago. The sign-in services haven’t caught up, and six of the licence apps haven’t either. One American legislature has written the rule into law: Utah’s 2026 statute says a state digital identity “may not include a mechanism that allows the department to monitor, surveil, or track the presentation”, requires offline presentation, keeps the only log on the holder’s phone, and sends the auditor in from 2028 to check.³⁰

The UK actually demonstrated how NOT to do it

In September 2025 the UK government announced a digital ID that would be mandatory for proving your right to work.³² The pitch was that it would stop illegal working and that it was secure. The public heard “ID card, on your phone, compulsory, built by the same state that let Horizon run for twenty years”. The petition against it closed at 2,984,191 signatures.³³ By January the government had made it voluntary. By July a new prime minister had cancelled it, in the same announcement as a cut in VAT on electricity bills, citing the £1.8bn it would have cost.³⁴ Ten months, announcement to cancellation.

The money is the other half of it. The UK spent £154m on Verify, then budgeted £709m for One Login to replace it, and the cancelled ID would have sat on top of both. Australia’s federal government has budgeted up to A$794m for digital identity since 2015, and the states don’t use it: Queensland budgeted A$52.9m for its own licence app, Western Australia has A$28m for another, New South Wales is upgrading its own for A$11.5m this year.²

The irony is that the GOV.UK Wallet, announced eight months before the scheme and the thing the scheme would have run on, survived, and it’s built on the right standard: the same document format and Bluetooth exchange I’m proposing, with no server in the presentation. Then it only releases to certified verification services, 66 at last count, which is the right gate for your name and address and the wrong one for an age check, and the driving licence promised for 2025 is now due in 2027.³⁵ My register of approved askers is the same idea for name and address. The difference is that an age check needs no registration at all, so a pub, a shop or a person can check it on day one.

The scheme’s purpose was right to work, and this design has a place for it. The Home Office issues a status credential. It’s a protected claim, so only an employer holding a Home Office permission can ask for it, and the employer keeps what the law says it must, for as long as it says. The voluntary version the government retreated to in January was most of the way there. What it lacked was everything else in this post: open age claims anyone can check, no server at the door, and code you can read.

I don’t think the uproar was about the technology. You don’t need to know what an mdoc is to have a view on this. It was about who holds the thing, who can demand it, and who built it. “Secure” isn’t an answer to any of those questions. Outabox was secure until May 2024.

The answer that would have worked is choice. You choose what to share. Nobody can ask for what they aren’t allowed to ask for. Your phone being dead changes nothing. And the software isn’t the government’s, in the sense that you can read every line of it and so can the people who spend their weekends breaking things for fun.

Why not just use the EU’s wallet

Because I read the code, and not everybody’s in the EU.

The EU is the furthest along of anyone. The regulation passed in 2024, every member state has to offer a wallet by the end of 2026, and the Commission publishes a reference implementation on GitHub.³⁶ It’s the obvious thing to copy. So I pulled it down.

As of the commits I cloned on 22 October 2026 it’s 86 repositories, about 234,000 lines of Kotlin for the Android wallet alone before you count its hundred dependencies,³⁷ and a 300,000-word architecture document with 725 numbered requirements, re-released 26 times in three years.³⁸ There’s a second, parallel set of apps just for proving your age online, and its own spec says buying something in a shop isn’t a priority.³⁹

The reference wallet ships with the trust checks relaxed. The registration-certificate check, the thing that’s supposed to stop a verifier asking for more than it’s registered for, is behind a settings switch that defaults to off on both platforms. The wallet provider, which is supposed to attest your device, is a mock that does no validation. The trust list is cached for 24 hours in a folder the operating system can purge, and when it expires offline there’s no fallback: the wallet stops presenting. The job that polls for revocations has an empty failure handler, so a revoked credential with an unreachable server keeps showing as valid, with no limit on how long and no warning to anyone.⁴⁰

Every service’s README carries the same warning: “We strongly recommend against putting this version of the software into production use.” Fair enough. I read the code rather than ran it, and a member state’s shipped wallet may well flip every switch. The point is what the reference teaches by default, because the reference is where thirty national teams start.

Some of it is right and I’d keep it. No server-side retrieval, so a phone can’t be turned into a tracking beacon. Credentials issued in single-use batches so two pubs can’t match your bytes. A zero-knowledge proof library for age that’s been reviewed by outside firms and already ships in Google Wallet.⁴¹ The people who wrote that part know what they’re doing.

So here’s the honest verdict, because I went in expecting a central database and didn’t find one. At the moment you tap, the EU design is decentralised and the code honours it. A Bluetooth presentation makes no network call. A website presentation talks to the website and a cached trust list. The wallet provider is kept out of presentations by rule, and server retrieval is banned. On that point the Commission’s architects and I agree.

It’s the plumbing that keeps the tap working where it centralises, and it’s thorough. Behind one tap at a bar sit nine organisations.⁴² Every credential is chained to three always-on services run by two of them, the identity issuer and the wallet provider, and in the default arrangement both are the member state or its contractor. The issuer stores, beside every credential it issues, the status indices that name your wallet, and the rules require it to poll them for the life of the credential. It holds the refresh token that ties every top-up to your original login, and because credentials come in batches of ten and refill at two, it hears from your wallet about once every eight presentations, timestamped. The wallet provider mints the per-wallet indices, is required to keep the register of which wallet is which, runs a user account for every wallet and a list of your devices, and the reference service logs every request it gets. On top of that your wallet phones the issuer’s status host every five to fifteen minutes whether you’ve used it or not, and the Commission’s trust list host at least daily.⁴³

Put that together and a member state that runs both ends, which is the default, can build a per-citizen picture of wallet activity: when you installed it, on what kind of phone, when and how often you use credentials, from which networks, and which version you’re on. What it can’t see is which pub, or which fields. Unless something leaks across a batch, and in the reference issuer something does: every credential in a batch gets the same document number and the same one-second timestamps, which the architecture’s own rule says must not happen, because two venues comparing notes can match them.⁴⁴ The fair summary is the one I’d put on the tin. Decentralised at the point of use, centralised in everything that keeps the point of use working. It won’t know where you drink. It will know how often.

And then the 86 repositories. I’ll say what I think happened, which is that a government hired a consortium and a consortium bills by the repository. Here’s the count. Ten of the libraries exist twice, once for Android and once for iOS, with no shared core, and on iOS the licence-standard library is three repos and remote signing is three more. There are three verifier endpoints and two trust validators. There are five Python issuer repos. The age verification app is a fork of the wallet, twice. Twelve repos exist for signing documents remotely, which is a different product. Nine are demos and testers.⁴⁵

The job needs, at most, this. One wallet per mobile operating system, so two. One verifier library per language businesses actually write in, the JVM, TypeScript, .NET and Python, and two of those four don’t exist anywhere in the 86 today. One issuer library per language, JVM and Python. A handful of small services: a wallet provider, one registry-and-trust-list service, a status list. Three named integrations: the browser’s credentials API, the zero-knowledge engine, the Keycloak plug-in. A specification. A demo repo. Continuous integration. That’s eighteen codebases, sixteen of which already exist somewhere in the 86, and it leaves seventy out: twenty-eight duplicates, twenty scaffolding, and the rest real work split too fine to maintain. Countries aren’t that different at a pub door, and neither are their code bases. Nobody needs the eighty-sixth repository. They need the verifier library in the language a web shop uses, and that one was never written.

One wallet, every country, built once

I have an Australian identity and a British one. Why would I need two apps?

Under Australia: my Queensland licence, birth certificate, Medicare, passport, tax office. Under the UK: HMRC, my driving licence, whatever else those departments issue. Each one signed by the department that owns the record. The grouping is for me, so I can find things. It isn’t a merged record, and it isn’t an identifier anyone can ask for. When Tesco asks if I’m over 18 it doesn’t get a list of my countries. When two of my countries could answer the same question, the wallet asks me once which to use and remembers.

For anyone who hasn’t been: Australia is six states and two territories, each with its own driving licence, its own liquor laws and, lately, its own app. Sydney is in New South Wales, Melbourne in Victoria, Brisbane in Queensland, Perth in Western Australia, Adelaide in South Australia, Hobart in Tasmania, and Canberra, the capital, sits in a small territory of its own, the ACT.

Australia alone has seven of these apps live, plus the banks’ ConnectID scheme inside their own apps. The tax office’s myID. The myGov wallet with your Medicare card in it. A licence app in New South Wales, one in Queensland, two in Victoria, one in South Australia. Australia Post built one as well and shut it down in May.

The Northern Territory and Western Australia are building theirs, Tasmania has funded a business case, and the ACT has held off until it can do it once, to a standard everyone shares, which is the only sane decision anyone in this story has made. Queensland venues accept four of the state licences. Victoria tells its drivers to carry the plastic interstate. And the scanner at the pub door reads a NSW licence by having you scan a second phone with your phone.⁴⁶

America has it worse, because it has fifty of them. A dozen or so states built their own app before Apple and Google turned up, and the bins are filling. Oklahoma decommissioned its app in February 2024 for “a lack of use cases”. Florida pulled its one in July 2024 promising a new vendor, shipped nothing, and its governor announced “No digital ID” sixteen months later.⁴⁷ Meanwhile twenty-one states’ licences work at airport security on one reader, built to the one standard, which by TSA’s own rule “never communicates with driver’s licensing agencies” about where you used it. Even that leaks at the vendor: the inspector general found the reader’s supplier “was able to access and extract” licence and passport images and TSA “did not track when this data was extracted”.⁴⁸ The good design still needs the audit.

The first time you open the one wallet, you pick your country and sign in to its identity service. If your country has a national ID, or is building one, that’s the sign-in. None of this is an argument against national ID. Departments keep their own records and their own numbers. They swap out the login in front of those records for the national one, and then each of them signs credentials from its own records into your wallet. One sign-in, many issuers, nothing merged, and no universal number that gets handed to a shop. If that sounds like the UK’s One Login with a wallet on top, it is, with two differences that are the whole post: the wallet answers websites and bouncers without the sign-in in the loop, and the code is public.

Then you prove who you are with the documents you already have. This is the slow part and I’m not going to animate a passport floating into a phone. Different people have different evidence, some will need an appointment, and some have no passport or licence to start from. Getting those people a credential is the government’s job today and stays its job. The government still does the actual work.

When they approve you, your departments start issuing credentials into the wallet, each one bound to a key made inside your phone’s secure chip that never leaves it. After that the everyday app is a camera, a code and a tap.

Who builds it

I’ll say it plainly, since it’s the point of the post. Digital ID built by a government is going to be crap. Not through malice, mostly. Through procurement, through a vendor that bills by the feature, through a minister who needs something to announce, and through the one incentive no department can shake: a system that sees everything is useful to the people who run it. Digital ID built in the open, by the people who break things for a living and the people who maintain the libraries everyone already depends on, is going to be good, because the only thing it can win on is being right.

So not governments. Not because they can’t run identity, Estonia and Denmark do, but because a government that builds its own wallet is asking you to trust the entity with the most to gain from seeing inside it, and the UK just found out what that costs. “Built by the people who’d otherwise be breaking it” is a better pitch than “secure”.

In September 2015 a small nonprofit called Let’s Encrypt issued its first certificate, the thing that puts the padlock on a website, and started giving away what every site had been paying a handful of companies for. Ten years on, Let’s Encrypt serves 762 million websites, issues ten million certificates on a busy day, and its certificates last 90 days and renew themselves.⁴⁹ The paid market shrank to the corners that need more than a domain check. Let’s Encrypt runs on sponsors, and this would too. It also needed the browsers to trust it before it could matter. This needs Apple and Google to let it near the chip, and today Apple says no to the UK and Australia. The foundation has no leverage there. Its member governments do, and that’s the first thing I’d ask them to spend.

So: a foundation. Two apps, which I’ll call ID Wallet and ID Check from here on, open source, built so that anyone can rebuild the Android app bit for bit and check the one in the store is the code on GitHub, with published fingerprints for the iOS build, which Apple’s re-signing makes harder to check. A profile of the existing standards, a test suite anyone can run, and a public changelog nobody can rewrite.

Countries join, contribute translations and security reviews and accessibility work, and keep their own records, their own issuers and their own rules. If Canada fixes a scanning bug, Australia gets the fix. If the foundation ever does something stupid, the code is public and anyone can carry on without it. You can’t copy an App Store listing or a membership the same way, so the governance has to be boring and public from day one. The countries share software, tests and a profile, and nothing else. There’s no shared database, no shared identifier, and nowhere in the system a transaction passes through on its way between two phones.

And if a government insists on its own app, fine. Make it open source, build it on the shared code, and rebase when the shared code moves. Your neighbours are building the same thing. Don’t rebuild it for the sake of a flag on the icon. Countries aren’t that different at a pub door, and anyone who tells you theirs is special has never used a cash machine abroad.

The refusals will be the interesting part. When a government won’t join, ask why. It’s free. It works offline. It’s the standard its own wallet already uses. The only features it lacks are the ones no citizen asked for: the server in the middle and the log. A government that wants those back has told you what its app was for. Why don’t you want free movement? Why don’t you want privacy? Those are the questions, and the answer is the test.

I can hear you shouting through the screen, so here are the three I hear loudest.

Identity is sovereign. Why would a government adopt software it doesn’t control? It already does. Every one of these wallets runs on an operating system its government didn’t write, on a phone it didn’t build. A country keeps every decision that matters: who it enrols, what its departments sign, which roots it trusts, who it registers as a reader, and what its law requires at a venue. The foundation ships the software and distributes each country’s list of trusted keys without signing it. The keys are the countries’ own, and a wallet learns them the way a browser learns which certificate authorities to trust, from a list it can inspect. Yes, that’s a trust list per country. Every country already runs one for passports.

Who pays? Member countries, as dues, for the app layer only: two apps, a profile, a test suite, audits. The expensive half of identity, checking who you are, stays with each government, as it does now. I don’t have a cost model and I’m not going to invent one in a blog post. What the dues buy is the thing every member is currently paying to build alone, and the UK’s cancelled scheme was costed at £1.8bn over three years. Where it lives is a real question. The OpenWallet Foundation already ships the libraries I’d build on, and it’s a Linux Foundation body with Google, Microsoft and Visa among its members, which is exactly what the crowd in the photo would object to. Hosted there, governed separately, or somewhere new: that’s a decision for the first two member countries, not for me.

Who’s liable when it goes wrong? The same people as today, under each country’s own law. The department that signed a wrong claim is liable for the claim. The venue that let someone in is liable for the check. The foundation certifies that a build passes the conformance suite, the way a certificate authority is audited, and a country that wants more can run its own audit on the same public code. That’s a certification gate, the same kind the UK runs for its verification services, and I’m fine with it where it belongs: on readers that ask for your name and address, never on a reader that asks whether you’re over 18.

The new world has proofs

The trick that proves you’re over 18 to a bouncer proves you’re a citizen to a website, and that’s where this stops being about pubs.

Say a social network asks your wallet one question: is this an Australian citizen? Your wallet answers yes, signed by Australia, from a single-use credential. The network now knows one true thing about you. It doesn’t know your name. Australia doesn’t know you signed up. And if one person tries to run a thousand accounts, the thousand credentials came out of the same issuer’s batches, which is exactly the thing an issuer can rate-limit and a network can refuse, without anyone learning who the person was. Nobody can trace the proof to a person. The issuer can say only that it issued it.

That’s a different internet from the one we’ve got, where every account is either a real name handed to a company’s database or a nothing that could be a person, a bot or a state. There’s a third option, and we’ve never had it: a proof. Someone real, from a real country, vouched for by a signature nobody can forge, with no name attached.

I know the objection, because I used to make it. Online anonymity is sacred. Here’s the thing: it has never been what we pretend. Walk into a venue and you’re on CCTV, and someone with a database can find you. Speak in a public square and someone can identify you. The rebel pasting posters about the Soviet Union in East Berlin was anonymous because nobody could trace the poster to the hand, not because a law said so. The anonymous account posting about the American president is in the same position. A proof of citizenship with no name on it leaves them both exactly where they were. It adds one thing: everyone else can tell the account is a person, from somewhere, and not a thousand of them in one coat.

We can keep places with no proofs at all. We should. But we keep falling back to the same problem, which is that a claim with no provenance is a refutable claim, and we’ve built an information ecosystem on them and called it free speech. It isn’t free speech. It’s recklessness with a nice name. The old world had a soap box, and you could see who was standing on it. The new world has proofs, and a proof can say “a citizen” without saying which one.

I’m not arguing for breaking the open internet. I’m arguing for laws that give people choice: the choice to speak, the choice to hear, and the choice over where their data goes. Governments want more checks. People want more freedom. That was an easier balance with fewer people in the world. A proof that says one true thing and nothing else is the balance that scales, and the people who’ll use it are the ones already glued to their phones, who’ll live on three continents before they’re forty and won’t stand in a passport queue for any of them.

The specification, the bare minimum

I was going to publish a companion repository. I’m not, because the thing worth agreeing on isn’t code. It’s a short list of what a digital ID must do and must not do, and a code base can be rebased onto a list. If a government wants to build digital ID infrastructure, stop tacking things onto it. Let it be this.

1. Open source, on a shared base. The wallet and the checker are public code. A country may ship its own build, name and icon, but it builds on the shared repository and rebases when it moves. Nobody rewrites what the neighbours already wrote.
2. Offline first. Every check between two devices in the same room works with no network on either side. Cell service at a festival is crap. Design for the festival.
3. No server in the middle. Nothing sits between the holder and the verifier at the moment of a check. Not the issuer, not the wallet provider, not the foundation. Trust material is fetched beforehand as signed static files.
4. No log of use. The issuer learns how many credentials it issued, never where they were shown. Nobody in the system can answer “where has this person shown their ID”.
5. Ask only what you need, and prove you may ask. Open claims anyone can request. Registered claims need a signed permission from the country’s registrar. Protected claims need one from the department that owns them. The wallet shows the request before anything leaves.
6. One answer per check. A check reveals the claim asked for and the country that signed it. Nothing else. Every presentation uses a fresh credential and a fresh session key.
7. The holder decides. Every request reaches a screen. Every answer needs a tap and a face or a passcode, except an age-only mode the holder switches on and can switch off.
8. Plastic always works. No check that accepts the digital credential may refuse the physical document. The phone is never mandatory.
9. Keys live in the chip. Credentials bind to keys made in the device’s secure hardware that never leave it. A copied credential is a screenshot.
10. Nothing a verifier relies on lives in app code. Only signatures the phone can’t forge.
11. Bounded staleness, shown honestly. A reader says how old its revocation data is and never renders stale as valid. Three outcomes: verified, indeterminate, invalid.
12. Biometrics travel, and only travel. Where a country already takes a fingerprint or a face for travel, the holder may carry it and present it at a border, to readers only a border authority can register, and nowhere else.
13. Standards, not inventions. ISO 18013-5 in the room, OpenID4VCI for issuance, OpenID4VP for the web, X.509 for who may sign. A profile pins the choices. No new wire format.
14. Public governance. Every permission to ask goes in a public, append-only log. Every build can be reproduced or checked against a published fingerprint. The foundation’s decisions are published.

That’s it. Fourteen lines. Line 4 is already law in Utah, down to the audit. Any country can meet them with code that already exists, and a country that won’t has told you which line it wanted to break. It won’t suit everyone and it doesn’t have to. There’s a learning curve, and some people will carry plastic for the rest of their lives, which is what line 8 is for. You don’t have to appease everybody. You have to agree the cheap framework now, while it’s cheap, so it scales when it isn’t.

If you stop here

You already carry the card. The proposal is the same card on your phone, signed so it can’t be faked, bound to your phone so it can’t be copied, and built so that each check reveals the answer and the country that signed it, and nothing else. The government does what it does today: checks you once and hands you the card. Then it leaves. No server sits between you and the bouncer, so there’s nothing to go down on a Friday night and no log of every check for anyone to trawl on a Monday morning.

That’s less than the apps being built now, not more. They want a login, a network connection and a record of every check. This wants a signature and a tap.

The part that isn’t technical is the part that matters. Nobody can ask you for what they aren’t allowed to ask. You can say no to anything. The plastic card always works. And the code is public, so you don’t have to take my word, or a minister’s, that it does what it says.

Here’s who I need.

If you just hate your wallet. Put two questions to whoever runs your licence app. Does it work with the internet switched off, and who hears about it when I use it? If the answers are no and everyone, that’s the problem, and it’s a cheap one to fix.

If you’re in government. Adopt the fourteen lines. Then pick a partner country and run the first trial: issue proof of age in one, check it in the other, both phones in flight mode. Two issuers, two readers, one credential type. Months, not years, with the cost published alongside the results.

If you build things. The next section is for you. Tell me where it breaks.

If you campaign. The line is “My ID. My choice.” It translates. Mon identité, mon choix. Mein Ausweis, meine Wahl.

If you fund things. The software is free. The readers, the venue systems, the payroll integrations and the checkout hardware are the market, and it’s the same size as the one ID-scanning vendors have today, minus the part where they keep everyone’s passport.

My ID. My choice.

The technical bit, you can stop now if you’re not interested

This half is the proof that the first half isn’t vapour: how I’d build it, and where it gets hard. “Trying to break it”, after it, is prose, it’s for everyone, and it’s where I say what the design can’t do.

Don’t invent a protocol

Every piece of this already has a standard, and most have a working open source implementation. The job is to pick a profile and refuse to deviate from it.

Multipaz, from the OpenWallet Foundation, already implements the mdoc and OpenID pieces for Android and iOS.⁵⁷ Start there. The foundation’s job is a profile, a test suite and two apps, not a new wire format.

The Friday check, in full

Here is the Tesco check from the first half, with the parts the prose skipped.

Read the exchange as a list

1. Both devices fetched the latest signed trust bundle earlier, while online. Nothing below needs a network.
2. At the till:
3. ID Wallet → ID Check: QR or NFC: how to reach me
4. ID Check → ID Wallet: Bluetooth: signed request for over_18, with the till’s registration
5. ID Wallet: Screen: "Tesco wants to know: over 18. Nothing else." You approve. Face ID unlocks the key.
6. ID Wallet → ID Check: One unused credential, plus a device signature over this session
7. ID Check Verifies against the cached bundle
8. Tick. Nobody called anyone. The reader keeps nothing but the used session.

“Verifies” in that diagram is six checks, all against data the reader already holds: the issuer certificate chains to a cached root, the issuer signature over the digest list is good, the over_18 digest matches, the device signature checks with the public key the issuer signed alongside that list (the mdoc’s deviceKeyInfo), the validity window includes now, and the credential isn’t in the cached revocation list. The till’s registration is a zero-field grant, which is how its verified name gets onto your screen. A till with no registration gets the same flow and the screen says “an unregistered reader”.

18013-5 in one picture

If you only learn one of those, learn 18013-5, because it’s the one that runs at the door. An mdoc is the credential: a set of fields, each with its own random salt, and an issuer-signed list of their digests, so the holder can hand over any subset and the reader can still check the signature. The standard also defines how two devices in the same room find each other and talk.

Read the exchange as a list

1. Engagement:
2. ID Wallet One-time key pair
3. ID Wallet → ID Check: QR or NFC: my one-time public key, how to reach me over Bluetooth
4. ID Check One-time key pair
5. Transfer, over Bluetooth:
6. ID Check → ID Wallet: Reader’s public key + encrypted request
7. ID Wallet Derives session keys, checks the reader, shows you the request. You approve.
8. ID Wallet → ID Check: Encrypted response: fields, issuer-signed digest list, device signature
9. ID Check Decrypts and verifies

The reader’s last step is the six checks listed above, plus decrypting the session. One honesty note about direction. In the standard, the phone shows the engagement code and the reader scans it. The videos in the first half show the till showing the code, because that’s what a self-checkout already does with barcodes. Offline, the reader-first direction is only standardised over NFC. Over QR, reader-first means an online flow, OpenID4VP cross-device, where the phone fetches the request from a URL.⁵² The profile should follow the standard’s direction for QR and make the tap the goal, because a tap has no direction problem.

Grants

The three claim tiers from the Saturday section, as a reader sees them:

A grant is a short signed document: reader public key, organisation, purpose, the exact claim names it may request, retention it may keep, not-before, expiry, and a status pointer. Grants live for 90 days and renew automatically, so revoking one takes effect within hours in practice, because wallets refresh the revocation list every time they have signal, and within a grant lifetime at worst.

A request is signed by the reader key the grant names, and carries something fresh to sign over (the session transcript in 18013-5, a nonce in OpenID4VP), the claims wanted, and the grant itself. On the wire the grant rides in the reader’s certificate chain, as an extension carrying the claim list and retention, signed by the registrar or the department, so 18013-5 reader authentication carries it with no new message type. The wallet checks the grant chains to a root it already trusts, checks the request signature, intersects the requested claims with the grant, and only then shows you anything. Unsigned requests get open claims and a visible “unregistered” label. A protected claim without a grant from its owner never reaches the screen.

Read the exchange as a list

1. Earlier, online:
2. ID Check → HMRC: Apply to ask for NI numbers: payroll
3. HMRC → ID Check: Signed grant, or a refusal
4. Later, offline:
5. ID Check → ID Wallet: Signed request for nino + grant
6. ID Wallet Grant from HMRC? If not, no prompt.
7. ID Wallet: Screen: "Acme Ltd is authorised by HMRC to ask for your National Insurance number." Approve or decline.
8. ID Wallet → ID Check: nino, signed

The regulated venue is the same shape with a different signer and more fields. The regulator’s grant says what the venue may collect and how long it may keep it. The ban check stays outside the exchange and happens before entry, against the regulator’s register when it’s reachable and against the regulator’s published fallback when it isn’t. In Queensland that fallback is a printed ban list, current for seven days, and a report to the regulator within 48 hours of the first entry during the outage.²⁶ The identity check never needs the network. The ban check never skips.

Read the exchange as a list

1. Months earlier, online:
2. ID Check → Regulator: Apply: name, photo, date of birth, kept 30 days
3. Regulator → ID Check: Signed grant, 90 days
4. At the door, offline:
5. ID Check → ID Wallet: Signed request + grant
6. ID Wallet: Screen: who, which fields, why, how long they keep it. You approve, or you leave.
7. ID Wallet → ID Check: Name, photo, date of birth, signed
8. ID Check Verifies. Staff compare the photo.
9. Ban check, before entry:
10. ID Check → Regulator: Is this person banned?
11. Regulator → ID Check: No: admit. Yes: refuse, notify police.
12. Register unreachable? Queensland’s fallback is a printed ban list, current for seven days, checked before entry, with a report to the regulator within 48 hours. The ID check is offline either way. The ban check never skips.

Who holds what

Offline only works if both sides already have what they need, so the question is who fetched what, and when.

The trust distributor is deliberately boring. It’s a set of signed, versioned files on a content delivery network: roots, chains, status lists, grant lists. No API, no per-person lookup, nothing that learns who’s being checked. A reader asks “anything since bundle 4,112?” and gets 4,113 or nothing. Same for a wallet. If the CDN is down, everyone keeps working on the bundle they have, until their own freshness rule says stop.

What offline can’t know, and how to bound it

An offline device can’t know something that happened after it last synced. Nothing fixes that. You can bound it, and make the result say what it knows.

Three outcomes. Verified, indeterminate, invalid. Call them green, amber and red. Stale status and uncertain time are amber. Amber must never render as a green tick, and what to do with it belongs to the operator, not the app.

Four lifetimes, set separately. A credential lives for days (I’d start at seven) and the wallet renews it at half life. A reader’s grant lives for 90 days and renews the same way. A reader’s maximum status age is the operator’s choice within the profile. Grace for an expired credential is the operator’s choice too, capped by the profile: a few days for open claims, none for registered ones. The long-lived thing is your enrolment.

Freshness is the verifier’s choice. Each reader carries a maximum age for its cached revocation list. A bar might accept a week. An e-gate accepts an hour. A holder can’t extend it, and neither can the reader’s operator mid-shift.

Trusted time. A holder winding their phone’s clock back must not make an expired credential look live at the reader. The reader keeps its last authenticated time plus elapsed monotonic time, detects rollback, and goes amber if it loses confidence after a reboot.

Each row below is a mode the apps implement, not an error message. Nothing in it is a server returning 500 to a person at a door.

The border is where people assume everything has to be online. The signature check and the face match are local. Only the decision needs the network, and that was true of a paper passport too.

Read the exchange as a list

1. At the gate, offline:
2. E-gate → ID Wallet: Signed request + border grant: travel credential, portrait
3. ID Wallet: Screen: "UK Border Force wants: passport data, photo." You approve.
4. ID Wallet → E-gate: Travel credential, portrait, device signature
5. E-gate Verifies, matches your face to the portrait
6. The decision, online:
7. E-gate → Border systems: Entry checks for this traveller
8. Border systems → E-gate: Open, or refer to an officer
9. Border systems down? The gate can’t decide and sends you to the desk, same as a paper passport.

Tap to ID

The standard already allows it. ISO 18013-5 lets the reader and the phone start over NFC or a QR code, then move the data over Bluetooth, NFC or Wi-Fi Aware. Apple and Google both ship NFC or QR to start and Bluetooth to transfer, because a portrait is tens of kilobytes and NFC is slow.⁵⁸ An age-only response is small enough to fit in the tap itself, though the exact size depends on the format and the zero-knowledge version needs measuring before anyone promises it. So the profile has two modes.

Open claims over NFC alone. Engagement and response in one tap, no Bluetooth. With the default key, the phone still asks for your face. The no-prompt version is a separate opt-in mode with its own key that isn’t biometric-gated. The issuer binds only age-only credentials to that key, so the most it can ever present is an age predicate. The issuing country is visible to any reader in every mode, because its key is what checks the signature. Off by default. That’s the payment-terminal experience, and it’s an explicit trade: a phone in that mode answers anyone who taps it, and the red team section says what that means.

Everything else over NFC then Bluetooth. The tap starts the session, the phone shows the request, you approve, the data moves over the encrypted Bluetooth channel the standard already defines.

What stands in the way isn’t the standard. On iPhone, a third-party wallet can only present a government ID over NFC through Apple’s secure element platform, which Apple opened to government IDs in iOS 26.4 under a commercial agreement, for issuers established in the EU, New Zealand or the US.²⁵ On Android, host card emulation is off when the screen is off, and the hardware-backed path, Android Ready SE’s mDL applet, was promised in 2021 and I can’t find a phone that shipped it.⁵⁹ Multipaz implements the NFC data channel on Android and throws “not yet implemented” for the wallet side on iOS.⁵⁷

Tap-to-ID is a platform negotiation, with a working fallback (QR to start, Bluetooth to carry) that every phone from the last eight years supports. Start there. Make the tap the headline ask of every country that joins.

Encrypt everything, trust nothing

The device is the holder’s, and the holder is sometimes the attacker. So the design relies on two things on the phone, the key in the secure chip and the issuer’s signatures over the claims, and treats everything else, the app, the operating system, the screen, as hostile.

Keys. Generated in the Secure Enclave or StrongBox, the separate chip in the phone that holds keys and does the signing, and never exportable from it. A compromised operating system can use them. It can’t extract them, and that’s the property we build on.⁶⁰ Signing requires Face ID, fingerprint or passcode, enforced by the key’s access policy inside the secure hardware, not by the app.⁶¹ The optional no-prompt key for tap-to-ID is the one exception, and the issuer only ever binds age-only credentials to it.

Issuance. OpenID4VCI with proof of possession. The issuer binds each credential to the key it was shown and never learns which reader will see it. A replacement phone gets new keys and re-issued credentials. It doesn’t restore the old keys from a backup. Backups hold encrypted metadata and your groupings, and the provider gets ciphertext.

At rest. Credentials and the portrait are encrypted with keys wrapped by the device’s data protection classes. A phone image copied off a rooted device is ciphertext.

Transport. Three pieces of standard cryptography, chained. Each side makes a one-time key pair and swaps public keys, and combining your private key with their public key gives both sides the same shared secret without ever sending it, which is Diffie-Hellman over an elliptic curve, ECDH. That secret, salted with a hash of everything said so far, the session transcript, goes through a key derivation function, HKDF, and comes out as two AES-256-GCM keys, one per direction. AES-GCM encrypts and also detects tampering.⁶² A sniffed Bluetooth stream is ciphertext bound to this one exchange. The QR itself is plaintext, a one-time public key and how to connect, and filming it buys an attacker only the chance to connect first, which reader authentication and your own screen are there to catch. Website presentations use JWE today and are moving to HPKE in the next version of the spec.⁶³

Read the exchange as a list

1. ID Wallet → ID Check: In the engagement: my one-time public key
2. ID Check → ID Wallet: First message: my one-time public key
3. Locally, nothing sent:
4. ID Wallet ECDH: shared secret
5. ID Check Same secret
6. ID Wallet HKDF over the secret and the transcript hash: two AES-256-GCM keys
7. ID Check Same keys
8. Ciphertext from here:
9. ID Check → ID Wallet: Encrypted request
10. ID Wallet → ID Check: Encrypted response, with the device signature over the transcript inside it
11. A filmed QR is a public key. Sniffed Bluetooth is ciphertext. A replay fails: different transcript, different keys.

Attestation, carefully. The issuer can ask the phone to prove its key lives in real hardware before issuing. Android’s remote key provisioning gives each app a rotating attestation key that Google says can’t be correlated back to a device.⁶⁴ That’s the kind to allow. Anything carrying a stable device identifier is a tracking handle and is out. iOS has no public equivalent of a per-app rotating attestation key as I write this, so the iPhone side of attestation is a known gap in this design, not a solved one.

Read the exchange as a list

1. Online, once:
2. ID Wallet → National sign-in: Sign in (OpenID Connect)
3. National sign-in Identity checks. Hours or days. Done once.
4. National sign-in → ID Wallet: Signed in: a token the issuers accept
5. ID Wallet Makes a batch of keys in the secure chip
6. ID Wallet → Issuer: Token, plus proof I hold each key (OpenID4VCI)
7. Issuer → ID Wallet: A batch of short-lived credentials, one per key
8. ID Wallet: Topped up in the background whenever there’s signal. You never see it.

Unlinkability isn’t optional, and it isn’t free

Taking the name off a credential doesn’t make it anonymous. The signature is unique. The device key is unique. If you present the same credential at two bars, those bars can match the bytes. Sixteen cryptographers wrote this to the EU about its architecture in 2024.⁶⁵

Two fixes exist, and the wallet should do both.

Batch issuance. The issuer signs a batch of short-lived credentials, each bound to a fresh device key. The wallet uses each once and tops the batch up in the background. Two presentations share nothing a verifier can match. The issuer knows how many it issued, not where they went.

Zero-knowledge proofs for the predicates. For “over 18”, the wallet proves the issuer signed a birth date before a cutoff, without revealing the signature or the date. Google’s longfellow-zk does this over existing mdocs and is open source.⁵⁴ It needs no change to issuers.

Batch issuance protects you from venues comparing notes. It doesn’t protect you from a venue handing what it received to the issuer, which can recognise the credential it issued. That’s the gap RFC 9901 spells out.⁵³ Closing it takes either anonymous-credential signatures such as BBS, which need issuers to change what they sign, or the zero-knowledge version, which doesn’t, because the issuer’s signature never leaves the phone. The catch in both is revocation: if the proof has to reveal which status-list entry to check, that entry links issuer and verifier again. Hiding it, or dropping per-credential revocation for seven-day credentials, is the open problem in this design.

The remaining identifier is the trust bundle fetch itself. Static files, fetched on a schedule, by every wallet, look the same whoever you are. Don’t let it become a per-person lookup, and don’t put analytics in the transaction path at all.

Biometrics travel, and only travel

Ordinary checks don’t need a face. The age check needs the key and the signatures. Where a venue wants to compare a face, it asks for the portrait under a registered grant, does the comparison locally on its own reader, and drops the image afterwards.

The stronger option, a face match on your own phone against the government’s photo, producing a signed “matched” result without the photo leaving the device, is real work. It needs a trusted capture path, an evaluated matcher, presentation attack detection, and attestation that doesn’t identify the phone to every venue. Face ID doesn’t do this. It compares you against your own enrolment, not a government portrait.⁶¹ Specify it as a later profile and don’t block the launch on it.

Travel is where I’d go further than the standards do. Countries already take a fingerprint or a face for a visa or a passport. A fingerprint is a fingerprint. If the holder has already given it to one government, let them carry it in the wallet and present it at the next border, signed by the country that took it, under a border profile with readers only a border authority can register.⁶⁶ The gate matches the live finger or face to the signed template, and the slow part of the border moves onto the phone.

The obvious objection is that a state can mint a fake. An intelligence service with access to its own country’s issuer can sign a fingerprint for a person who doesn’t exist, the way it prints passports today. Yes. And the check against it is the same as today’s, only sharper: the live biometric has to match the signed one, the signing country’s key sits on a list everyone can read, and a thumb at a border is harder to fake than a laminated page. If you want to keep one country’s spies out of another, a live print against a signed template is a better filter than an officer’s glance at a photo. Today’s documents can be fooled with a good printer. This one needs a chip, a key and a finger, and fails loudly on any of the three.

Permission to check age at a bar never grows into permission to collect fingerprints. The border profile is its own thing, with its own readers, and it never leaks into the pub.

The infrastructure, per country

Most of it exists.

The foundation runs the two apps, the pinned profile, the conformance suite, and a security programme with audits and disclosure.

Quantum, briefly

Every signature here is elliptic curve, which a large enough quantum computer breaks, and NIST’s draft timeline disallows today’s curves after 2035.⁶⁷ This design migrates well because credentials live for days and only roots and issuer chains are long-lived: move those to ML-DSA first and the credentials follow at their next renewal. The cost is size, an ML-DSA-44 signature is 2,420 bytes against 64 for P-256, which is fine over Bluetooth and tight over NFC alone, where the one-tap age mode would need measuring again before anyone promises it.

The first trial

Two countries. One credential type: proof of age. Issue in one, verify in the other, both devices in flight mode. Then run the failure table: a lost phone, a stale reader, a declined request, a request for a protected claim without a grant, a clock set a year ahead. Publish the results, including the ugly ones. Then add a regulated venue profile, then travel.

The specification is the fourteen lines in the first half. Everything in this half is one way to meet them, and the test suite is what turns the lines into a pass or a fail.

Trying to break it

This is the section the announcements skip: what the design defends against, what it doesn’t, and what I’d want a red team to go after first.

What a modified wallet can and can’t do

Say you root your phone and rebuild the wallet from source with the consent screen removed and the age check patched to say yes.

You still can’t forge an issuer signature. The claims you can present are the ones a department signed for you. A 17-year-old with a modified wallet is still 17.

You still can’t present someone else’s credential. It’s bound to a key in their secure chip, and the chip won’t sign without their face or passcode.

You can disclose more than you meant to. A modified wallet can ignore the grant and hand over everything it holds. That’s your data and your choice. The promise is that an honest wallet can’t be made to over-share, not that a sabotaged one won’t.

You can skip any check the app does on its own, like comparing your face to the portrait before signing. So nothing that matters to a verifier is allowed to depend on a check that lives in app code.

That last one isn’t hypothetical. In 2022 a researcher showed that the New South Wales digital licence kept its data on the phone behind a four-digit PIN, and that you could decrypt it, change the name and birth date, and display the result, because nothing a pub looked at was ever checked against a signature.⁶⁸ The fix isn’t a longer PIN. It’s that the thing a reader checks has to be a signature the phone can’t produce.

South Korea learned the same lesson this year. Its QR “confirmation service”, a screen that shows your licence to a checker, is being considered for abolition after forged screens were sold on social media, while the signed mobile ID next to it has had no forgery cases, according to the ministry.⁶⁹ Same country, same phone. The one with a signature held.

Fake readers

An unsigned request gets labelled “unregistered” and can only ask open claims. A registered claim needs a grant, and a grant that’s been revoked is in the next bundle every wallet fetches. The attacker’s remaining move is to register a real business, get a real grant for name and date of birth, and harvest. That’s a governance attack, not a cryptographic one, and it has a governance answer: every grant goes into a public, append-only log, the way every TLS certificate goes into Certificate Transparency. If a kebab shop has a grant for your address, a journalist can find it in an afternoon.

Readers get modified too. A venue could run a patched ID Check that stores the portrait it promised to delete. Nothing cryptographic stops a recipient keeping what it has seen. What limits it is that it only ever saw a handful of fields instead of a photographed licence, that the grant says what it may retain, and that the regulator can audit against a public log of what it was allowed. The design shrinks what a bad venue can leak. Enforcement still has to exist for the venue that tries.

Stolen, lost, coerced

A stolen phone can’t present without your face or passcode. When you report it, the issuer revokes the batch and the next bundle carries the revocation. Short credential lifetimes bound the window anyway. A lost phone gets new keys on the new phone and freshly issued credentials. The old keys are gone, and the backup held nothing that lets anyone, including the backup provider, rebuild a credential.

Coercion is a design constraint, not an edge case. The wallet presents without unlocking the rest of the phone, so handing over a claim never means handing over the device. An officer gets the fields their grant allows, on their reader. They don’t get your phone.

Supply chain and clocks

The app in the store isn’t the code on GitHub until someone checks. Reproducible builds let anyone check on Android, and on iOS it takes a published hash and a jailbroken phone, so “never trust the device” includes never trusting the app store. Clocks: the holder winds their phone’s date back so an expired credential looks live, and the reader ignores it, because it keeps its own trusted time and goes amber when it loses confidence in it.

Enrolment is where the fraud moves

Nothing in this half stops a real credential being issued to the wrong person. A forged birth certificate at enrolment produces a perfectly signed, perfectly bound credential that says what the fraudster wanted, and every check in the failure table passes. That’s where identity fraud lives today, and the design leaves it with the government’s identity checks, which are as good or as bad as they are now. The honest claim is narrower than “can’t be faked”: the card can’t be forged after issue, and the issuer’s enrolment is the whole of the remaining attack surface.

Skimming the tap mode

The no-prompt tap mode has a worse problem than a stolen phone. A reader in a bag in a queue taps every pocket it passes and harvests fresh “over 18” answers bound to engagements the attacker controls, then relays each one live to a confederate at a door. No theft, no owner interaction, no cooperating adult. It’s the contactless-payment relay applied to ID, and the mode removes the one barrier, the prompt, that makes the relay below need an accomplice. The mitigations are the ones card payments use: a counter the reader can see, engagement lifetimes of seconds, and the mode off by default. It also changes the framing of the relay: with the mode on, “a cooperative older sibling” becomes “anyone with a reader in a crowd”.

What I’d red team first

In order: the issuer’s enrolment process, because it’s the only forgery that works. The grant registrar’s approval process. The reader’s trusted-time handling after a reboot. The wallet’s behaviour when its batch runs dry offline. The bundle format’s parser, with a fuzzer. The attestation chain’s privacy, whether a device identifier leaks to every venue. The consent screen on a rooted phone, to confirm nothing a verifier relies on lives there. Whether a status-list index leaks across a batch or to the issuer. Whether the wallet knows a grant was logged, not just signed. And the one I’ve left to last because it’s the one the design doesn’t solve.

The relay

An open age claim says “someone over 18, with their phone and their face or passcode, approved this request”. It doesn’t say that person is standing at the door. A 17-year-old at the pub with a second phone relaying the request to an older friend at home gets a tick, and no cryptography in this post stops it. The Bluetooth session binds the response to this engagement, but two phones acting as proxies can forward it, and NFC relays have needed nothing but software since 2011.⁷⁰ The standard gives you an encrypted channel and reader authentication. It doesn’t give you distance bounding, and Bluetooth carries tens of metres, so proximity transport doesn’t mean proximity, and I won’t claim it.

Today that attack is “borrow your brother’s licence”, and the photo on the card is what catches it. The age-only profile has no photo, by design. So be honest about what it is: you can’t edit the birthday and keep a valid signature, and against a cooperating adult it does nothing. The on-device face match doesn’t fix this either. The adult at home passes the face check on their own phone and relays the result. The only thing that catches a relay is comparing the person at the door with the portrait, which means the venue asks for the portrait under a registered grant and a human looks at it. Where that doesn’t matter, which is most shops, the age tick is still a stronger check than the glance a cashier gives a card.

That’s the trade. A credential nobody can forge, carried by a person nobody can be sure is there. Every system that checks a card makes the same trade and hides it behind a photo. This one makes it out loud, and lets the venue decide how much it cares.

The whole design in five sentences

A credential is a signed set of claims bound to a key your phone made and can’t export. A reader is anyone, and what it may ask for is set by who signed its grant: nobody for open claims, the registrar for registered ones, the owning department for protected ones. Both sides fetch signed trust bundles when they have signal and talk to no one at the door. Every presentation uses a fresh credential and a fresh session key, so two readers can’t match you and, with the zero-knowledge proof, neither can the issuer. And nothing a reader relies on is ever a check that lives in app code, only a signature the phone can’t produce.

Everything else in this half is consequence. Four lifetimes, because offline needs bounds. Three outcomes, because stale isn’t valid. A zero-field grant, because a name isn’t a permission. A recovery key, because roots get compromised. A public grant log, because a governance attack needs a governance answer. A relay I can’t stop, because a signature proves a key was used, not where.

What you’re weighing

One side of the scale is a teenager with a cooperative older sibling, which has been true of every ID check since the first one, or, if you switch the tap mode on, a stranger with a reader in a crowd. The other side is what we have now: a million licence scans and face prints in a venue vendor’s cloud, a national ID announcement that collapsed in ten months because nobody believed “secure”, seven apps in one country that can’t read each other, an EU wallet whose trust checks ship turned off, and national schemes on three continents that log every check against your name and keep it for years.

None of this needs inventing. The data format is a published standard with two shipping implementations. The issuance and presentation protocols reached 1.0 last year. The zero-knowledge proof is open source and already shipping in Google Wallet. The secure chips are in the phones people already carry. The two apps start from libraries that already ship, and the first trial is two countries and a flight mode switch. What’s missing isn’t a protocol. It’s the decision to build one wallet instead of fifty, and to let the people who’d otherwise be breaking it build it in the open.

The phone in your pocket can already prove you’re over 18 to a bouncer without telling anyone else. Stop tacking things onto it. Let it be the bare minimum. Issue the credential. Let me carry it and decide who sees it. Publish the code.

Footnotes

1. Apple, IDs in Wallet lists sixteen states and Puerto Rico supporting driver’s licences and state IDs in Wallet as of October 2026. Florida and Rhode Island declined. Google Wallet covers twelve of them. ↩

2. Figures are generated by research/papers-please/spend.py and checked against this post by check_post.py. One Login: £708.86m whole-life cost in the NISTA Major Projects Annual Report 2025-26 data, July 2026. Verify: NAO, Investigation into Verify, March 2019, “The actual total cost of Verify from 2011 up to September 2018 was £154 million.” Mandatory digital ID: OBR Economic and fiscal outlook, November 2025, “provisionally forecast to cost £1.8 billion in total over the next three years.” Australia: the sum of nine Digital Identity measures in Budget Paper No. 2 from 2015-16 to 2024-25 at archive.budget.gov.au, an upper bound because two measures were already in the forward estimates, and excluding myGov. Queensland: ABC, 21 March 2025. WA: ABC, 23 April 2026. NSW: ministerial release, 30 September 2026. The total also includes the US (the IRS’s ID.me task order from USAspending, Login.gov’s Technology Modernization Fund award, California’s mobile licence budget line, Florida’s Smart ID contract and Utah’s 2026 programme fiscal note), Quebec’s wallet, the EU pilots, the EU age verification tender, Germany’s SPRIND competition, the Netherlands, Italy, France, South Korea’s 2024 mobile ID budget, India’s Aadhaar to 2019 and Estonia’s 2017 card remediation, converted at assumed rates of 1.30 USD per GBP, 0.66 per AUD, 1.08 per EUR, 0.73 per CAD, 1,400 KRW and 85 INR per USD. Without India it is US$2.4bn. Sources for each line are in the script. ↩ ↩²

3. Service Victoria, Having problems with your digital licence: “For now, digital licences need internet access for QR code scanning to work. You’ll get an error if you or the person checking your licence can’t connect.” Checking digital driver licences: “You’re viewing someone’s info by connecting to their official licence records.” The holder’s own card displays offline from a cache. Checked 22 October 2026. ↩

4. SA.GOV.AU, mySA GOV mobile app: “Each credential has a unique barcode that updates every 30 seconds. To verify someone else’s licence: 1. Tap Validate in your app … Barcodes that have already been scanned won’t validate.” Consumer and Business Services, 25 March 2019: “Once a mySA GOV account has been created, log into the app, press the validate button and point your camera at the barcode”. That a server keeps score of scanned codes is my inference from the replay rule. What it logs is unpublished. ↩

5. Singpass Verify API specification: “The user scans a Verify QR code pertaining to your application e.g. at a kiosk with Singpass Mobile”, then “Your application then make a series of calls to Verify in order to obtain the user’s data”, and “This API is a server-to-server call”. MDDI factsheet, 2 March 2022: Verify “enables users to perform face-to-face identity verification”. History: ask.gov.sg, “You can view up to 15 months of transaction history”. Verify is now closed to new onboarding and its replacement, Myinfo, is also server-mediated. ↩ ↩²

6. Korea Herald, 28 September 2025: “A total of 647 government information systems are housed at the NIRS in Daejeon”, with the mobile ID application among the services blocked. Airports: Korea Airports Corporation guidance as reported by Segye Ilbo, 27 September 2025, my translation: “identity confirmation via mobile ID or Government24 may be difficult, so bring a physical ID”. Secondary source carrying the operator’s notice. The Ministry of the Interior’s recovery list describes the mobile ID authenticity check as “a system that verifies in real time the validity and forgery status of mobile IDs”. ↩ ↩²

7. Envoc press release, 28 January 2019: VerifyYou “allows one LA Wallet user to scan another user’s LA Wallet digital identity” and provides “immediate age verification from the State’s database.” La. R.S. 32:411(F)(3)(a): a digitized driver’s licence is “a data file available on any mobile device which has connectivity to the internet”. LA Wallet privacy policy, 21 January 2025: collects “crash and analytical usage data, which includes error reports and information about your activity”, lists “precise geolocation” among sensitive data, and contains no statement that the state or the company cannot see where the ID is presented. Adoption: lawallet.com, “75% of all Louisiana drivers use LA Wallet”. Porn age checks: Louisiana Act 440 (2022), D(8)(a), “Provide a digitized identification card as defined in R.S. 51:3211”; Free Speech Coalition v. LeBlanc, E.D. La., 4 October 2023: “only LA Wallet satisfies the Act’s definition”. The 2.9 million sessions and the “non-logging infrastructure” claim are from the vendor’s president in an interview with GovTech, 5 April 2024, secondary and unlinked because I couldn’t fetch the article. A separate ISO 18013-5 Bluetooth flow exists for TSA. ↩ ↩²

8. Governor’s office release of 15 June 2023, carried by WAFB: “OMV believes that all Louisianans with a state-issued driver’s license, ID, or car registration have likely had the following data exposed to the cyber attackers”, listing name, address, Social Security number, birthdate, height, eye colour and licence number. WAFB, 16 June 2023: officials knew “for nearly three weeks” before the 15 June warning. Oregon: Oregon DMV, data breach page: “This data contains personal information for approximately 3.5 million Oregonians”, and anyone with an active licence, permit or ID card should assume their information was exposed. The Louisiana originals on gov.louisiana.gov are no longer online. ↩

9. Colorado Digital ID: “the data sharing process via a QR code requires internet service. In this case, if there’s no internet service, you’ll need to show your physical ID.” myColorado mDL reader: “Do I need to have an internet connection? No, this works offline.” myColorado mDL: “an mDL is a cryptographically secured, government-issued credential that meets the ISO/IEC 18013-5 international standard” and “The State of Colorado does not track where you use your mDL.” Checked 23 October 2026. ↩ ↩² ↩³

10. Intellicheck privacy policy, updated 26 August 2026: “All scanned Document bar code data is retained for the following purposes”, including “Transactional data (date, time, etc.)” used “to provide client activity reports”. Age ID App Store listing: “It keeps track of who was scanned and when.” Patronscan privacy policy, 11 May 2026 (archived, the live site blocks automated fetches): the Flag Network records “The date and venue at which the flag was recorded”, flags “are visible to other participating Customers when the same identity is scanned at their venue”, and disclosure to law enforcement happens “where we are legally compelled to do so or where disclosure is reasonably necessary”. Retention periods for ordinary scans are “as configured by the Customer”. ↩

11. Count: 26 states by statute per the Free Speech Coalition tracker and Mayer Brown’s tracker as of August 2026, plus Missouri by regulation. Methods: Texas HB 1181 §129B.003(b), “provide digital identification” or a system using “government-issued identification” or “public or private transactional data”. Free Speech Coalition v. Paxton, 27 June 2025: “adults have no First Amendment right to avoid age verification”; “Both those entities have every incentive to assure users of their privacy”; Kagan, J., dissenting: “It is turning over information about yourself and your viewing habits—respecting speech many find repulsive—to a website operator, and then to … who knows? The operator might sell the information; the operator might be hacked or subpoenaed.” Retention: Yoti biometrics policy, “a maximum of three years”; Persona, “within three years of your last interaction”; Jumio, “within three years”; AU10TIX, 19 August 2026, “5 years” for identity verification and “3 years” for age verification. Discord: company statement, October 2025, “approximately 70,000 users that may have had government-ID photos exposed”. ↩

12. Aadhaar Act 2016 s.2(c) defines authentication as submission “to the Central Identities Data Repository for its verification”, and s.2(d) an authentication record as “the time of authentication and identity of the requesting entity and the response”. Aadhaar (Authentication and Offline Verification) Regulations 2021, reg 27(1): “Authentication transaction data shall be retained by the Authority for a period of 6 months.” The Supreme Court in Puttaswamy, 26 September 2018, para 447(1)(d)(a), struck the five-year archive: “This provision which permits records to be archived for a period of five years is held to be bad in law.” UIDAI’s authentication history page lists, per check, “Auth Modality, Date & Time of Authentication, UIDAI Response code, AUA Name”. Karnataka High Court, Krishnamurthy v The Director, UIDAI, WP 105596/2025, 23 September 2025, para 12.2: “UIDAI is directed to furnish to respondent No.2 only the details of location of the usage of Aadhaar card of the missing son of the Petitioner”. Aadhaar also has an offline QR mode, defined in the 2019 amendment as verification “without authentication”, which is the contrast this post argues for. ↩

13. UIDAI press note, 4 January 2018, responding to a Tribune report of paid access: “UIDAI maintains complete log and traceability of the facility and any misuse can be traced and appropriate action taken.” Comptroller and Auditor General, Report 24 of 2021, press release: “UIDAI is maintaining one of the largest biometric databases in the world; but did not have a data archiving policy, which is considered to be a vital storage management best practice.” ↩

14. TDIF 06A Federation Onboarding Guidance 4.8: “Identity Exchanges which mediate all interactions between Identity Service Providers, Attribute Service Providers and Relying Parties” and “The presence of an Identity Exchange results in the creation of a double blind.” Digital ID Exchange privacy policy, Services Australia, January 2025: collects “the date and time of the transaction, whether the transaction was successful, the service that needs to verify your identity, who you’ve consented to share your information with”, says “This information is de-identified”, and “You can view your transaction history”. Digital ID (Accreditation) Rules 2024 r 4.20(5) and (7): the log includes “the names of any entities involved in the event” and “must be retained for a minimum of 3 years”. Outage: Department of Agriculture, industry advice notice 07-2025: “As of 08:55 Monday 13 January 2025 (AEDT). The Australian Taxation Office (ATO) myID system is currently experiencing an unplanned outage. As a result, there is an unplanned outage to the following departmental systems”. ↩

15. MitID privacy policy v1.8, section 5, my translation: “detailed information about the use of your MitID, including when, how and what you use your MitID for. This includes IP address, including geographic location based on the registered IP address.” Section 8 keeps it “as long as necessary”. MitID terms v1.3, D.6: an event log of “which digital services you have been logged in to. By default this view is switched off.” Om MitID, Baggrund v1.04: “All service providers connect through a certified MitID broker.” Datatilsynet, 23 June 2023: in January 2022 citizens logging in to their bank via MitID “got access to other citizens’ accounts”, because login requests within milliseconds “could result in MitID issuing a so-called token to another session”. Verdict: “alvorlig kritik”, serious criticism. ↩

16. House Oversight Committee letter to the IRS, 11 February 2022: “an $86 million contract with Veterans Tech, LLC, to provide the agency with ID.me facial recognition technology” and “seven million Americans had already been directed by the IRS to sign up with ID.me. Under IRS’s records retention requirements, ID.me will continue to possess biometric information on these individuals for seven years”. IRS Privacy Impact Assessment for ID.me, 1 November 2021: “ID.me adheres to NARA’s minimum records retention requirement of seven years”. USAspending: $86,073,159.90 obligated. Reversal: IRS IR-2022-27, 7 February 2022. ↩

17. GSA Office of Inspector General, JE23-003, 7 March 2023: “GSA misled their customer agencies when GSA failed to communicate Login.gov’s known noncompliance with … SP 800-63-3” and “GSA knowingly billed IAL2 customer agencies over $10 million for services, including alleged IAL2 services that did not meet IAL2 standards.” GAO-26-109261, 15 July 2026: “the program’s Anti-Fraud Team determined that fraudulent accounts passed the identity proofing services”. ↩

18. Estonian Information System Authority, 5 September 2017: “The possible vulnerability affects a total of almost 750,000 ID cards issued starting from October 2014”. RIA, 8 December 2017: “since the suspension of the 760 000 ID-card certificates a month ago” and “Owners of the security risk-affected ID-cards needed to update their certificates to continue using e-services.” RIA, 14 May 2018: “ID card is means of authentication and electronic signing for close to 5,000 public and private sector services.” The flaw was in the chip maker’s key generation, which let the private key be computed from the public one. ↩

19. Singapore Police Force, 9 December 2025: “a criminal network that allegedly intercepted ICA PIN mailers … to receive Singpass password reset mailers, which enabled them to take over the victims’ Singpass accounts.” Singapore Police Force, 26 August 2026: “Further investigations identified another 171 Singapore citizens and foreign workers whose Singpass accounts were linked to the same activity.” ↩

20. GOV.UK One Login privacy notice, updated 28 January 2026: “When you are referred to GOV.UK One Login by an online government service to sign in or prove your identity we will know what service you have come from.” “We will store information about the actions you take when you use your GOV.UK One Login in system logs for 1 year.” “We also maintain a secure audit trail of all GOV.UK One Login audit events and activity which we retain for 7 years for fraud monitoring purposes.” Fraud data, including “IP addresses”, “location, derived from the IP address” and “device ID”, may be shared with “the Home Office”, “law enforcement agencies” and “Experian (a credit reference agency)”. ↩ ↩²

21. Login.gov Privacy Impact Assessment, 10 March 2026: “a privileged user can generate a report on user activity, such as a user’s most recent sign-in, or which agencies a user has used Login.gov to access”. System of Records Notice GSA/TTS-1, 89 FR 41436, 13 May 2024: “Each partner agency whose services the user accesses via Login.gov may add its own unique identifier to that user’s account information”, and Login.gov collects “a Device ID including, for example browser type and internet protocol (IP) address, and usage patterns (e.g., keyboard, mouse, or touchscreen behavior)”. Retention under GRS 3.2 item 30: “Destroy when business use ceases.” Login.gov PIA, March 2026: “Login.gov creates a master UUID for each user in Login.gov, and an additional UUID to each agency that a user visits.” ↩ ↩²

22. SK ID Solutions, Smart-ID RP API v2: “a relying party to start a transaction by calling the Smart-ID server RP API”. SK privacy policy v8.0, section 6, lists “Person’s given name(s) and surname(s)”, “Personal identification number”, “Network IP address used by the device”, “E-service provider whose service is used”, and section 12 keeps logs “for at least 10 years”. SK General Terms v4.1, 7.4.1 and 11.8: ten-year retention of Smart-ID transaction logs, and “Extracts from audit trails constitute a separate service and SK may charge an extra fee.” MyID terms 2.3: “it is not possible to delete personal data related to service provision at the User’s request”. ↩ ↩²

23. National Network Identity Authentication Measures, CAC, effective 15 July 2025, English translation at China Law Translate. Ministry of Public Security Q&A, 23 May 2025, my translation: information provided to authorities “is limited to the real identity information corresponding to the network number and certificate, and the authentication log information”, and the app’s history shows “recent authentications on each internet platform, which gives traceability and non-repudiation”. Adoption per Xinhua, 13 July 2026: 40 million holders, 280 million authentications. The scheme is voluntary under Article 4. ↩ ↩²

24. In ISO 18013-5 the phone shows the code and the reader scans it. The videos show the till showing the code, because that’s what a self-checkout already does with barcodes. The difference, and why it matters offline, is in “Tap to ID” in the technical half. ↩

25. Reader: Apple, ID Verifier, “read ISO 18013-5 or ISO 23220-1 compliant mobile IDs, with no additional hardware required”, iPhone XS or later on iOS 17. Third-party wallets: Apple, NFC & SE Platform, “Government IDs are now supported, starting with iOS 26.4” and “For Government ID, be established in the European Union, New Zealand, or in the United States”, under a commercial agreement whose fees aren’t published. Apple’s own IDs use NFC to engage and then Bluetooth to transfer: Security of IDs in Apple Wallet. ↩ ↩²

26. Business Queensland, Requirements for ID scanning and Guideline 64: Privacy obligations, checked 22 October 2026. The requirements apply to regulated premises, not every venue. Fallback: Failure or malfunction of a networked ID scanner: “You must check each patron’s photo ID against a current physical list of banned patrons”, “Each manual ban list is current for 7 days”, “You must notify OLGR within 48 hours from the first time you allowed a patron entry during the system failure.” ↩ ↩²

27. NSW Government, Outabox data breach, May 2024, and ACS Information Age, 2 May 2024: “facial recognition biometrics, driver licence scans, signatures, addresses, dates of birth”. Every source says “more than 1 million” patrons. ↩

28. Apple, Use Express Mode with transit cards, passes, and keys in Apple Wallet: power reserve works “for up to five hours” with cards, passes and keys that have Express Mode turned on, and not if the phone is switched off. Apple doesn’t offer it for IDs today, and Android has no equivalent. That’s the “if they play ball”. ↩

29. New York DMV, Mobile ID: “There is no personal data in the QR code”, the channel is established “without having to have an internet connection”, and “MiD does not use geolocation tagging, and DMV cannot see when or where you present your MiD.” Checked 23 October 2026. Virginia and Hawaii publish the same statement for their ISO 18013-5 licences. ↩

30. Utah SB 275 (2026), enrolled, Utah Code 63A-20-301(3): “A state-endorsed digital identity may not include a mechanism that allows the department to monitor, surveil, or track the presentation of a state-endorsed digital identity to another entity.” 63A-20-101(10): “An individual has a right to be free from surveillance, profiling, tracking, or persistent monitoring of the individual’s assertions of digital identity by the state, except as authorized by law.” 63A-20-401(1): a wallet shall “support online and offline presentation” and “maintain a secure log … accessible only to the holder”. 63A-20-802(2)(b): the Legislative Auditor General audits “whether the department has met the restrictions on monitoring, surveillance, and tracking” from 1 January 2028. The current Utah app sunsets on 1 January 2027 under the same Act. ↩ ↩²

31. ISO/IEC 18013-5:2021, 8.3.2.2.1 NOTE 2: “The issuing authority infrastructure is involved in each server retrieval-based transaction; therefore, the issuing authority knows when an mdoc is used and what data is shared.” AAMVA mDL Implementation Guidelines 1.5, 17 April 2025, changelog: “Changed the server retrieval method from being optional to being prohibited”, and section 3.9: “Issuing Authorities must not implement the server retrieval method.” EU ARF v3.0.0, Annex 2, ProxId_02: “Wallet Units, PID Providers, Attestation Providers, Wallet Providers, and Relying Parties SHALL NOT support server retrieval as specified in ISO/IEC 18013-5”. NIST SP 1800-42A draft, March 2026: “Server retrieval is not supported.” Apple, Security of IDs in Apple Wallet: “Device retrieval obviates the need to make server calls during presentation, thereby protecting users from being tracked by Apple and the issuer.” Google, Verify with Google Wallet: “Google does not save credential-related data on its servers”. Apple does query its own servers periodically to check the ID’s key hasn’t been revoked, which is a status check, not a per-presentation call. Queensland: Digital Licence privacy notice: the department and vendor “do not collect information from the App about: verification attempts or transactions”. The Queensland site doesn’t say in words that the checker works offline, only that the holder’s app does and that sharing is over Bluetooth. ↩

32. GOV.UK, New digital ID scheme to be rolled out across UK, 26 September 2025: “Digital ID will be mandatory for Right to Work checks by the end of the Parliament.” ↩

33. Petition 730194, Do not introduce Digital ID cards, closed 9 January 2026 with 2,984,191 signatures. ↩

34. The cancellation release allocates £850m to the VAT cut in 2026-27, so the £1.8bn wasn’t handed over one for one. Made voluntary: Hansard, 15 January 2026, “If anyone does not want one, they do not have to have one.” Cancelled: GOV.UK, 21 July 2026, “the cancellation of the Digital ID programme, which was going to cost £1.8 billion over the next three years.” ↩

35. Announcement: TechCrunch, 21 January 2025, reporting the government’s press conference that day: “The first two cards it plans to add to its wallet will be a virtual driver’s license and a virtual veteran card” and “It plans to launch the service later this year”. Press coverage, since the GOV.UK release wasn’t fetched. The mandatory digital ID was announced on 26 September 2025, eight months later. GOV.UK Wallet documentation, verifying credentials: in-person verification “in line with ISO/IEC 18013-5”, over Bluetooth, and “You will only be able to access user information through a digital verification service (DVS).” The DVS register listed 66 certified services on 22 October 2026. Driving licence timing: GDS blog, 19 October 2026, “before we start to introduce the digital driving licence from next year.” ↩

36. Regulation (EU) 2024/1183, in force 20 May 2024. The Commission’s EUDI regulation page gives the end of 2026 deadline for member states to offer a wallet. The reference implementation is the eu-digital-identity-wallet organisation on GitHub. ↩

37. Counted on 22 October 2026 from shallow clones of the organisation’s repositories (Android wallet at commit ad96068, iOS wallet at b583f35, ARF at f5789a7): 86 repositories, the Android app at 101,776 lines of Kotlin, plus the wallet-core, OpenID4VCI, OpenID4VP, trust-list, status and ISO 18013 libraries it ships with, about 234,000 lines in total. The Android build declares 100 libraries and 17 plugins in gradle/libs.versions.toml. ↩

38. Architecture and Reference Framework, version 3.0.0, 21 July 2026. 78 markdown files, about 300,000 words, 725 high level requirement blocks in annex 2, 26 releases since 1.0.0 in February 2023. ↩

39. Age verification technical specification. Its scope section says purposes other than access to online services, “such as for purchasing age-restricted products”, are “not a current priority”. ↩

40. In the reference Android wallet, RegistrationCheckEnabled defaults to false in PrefsController.kt, and iOS validateIssuerRegistrationCertificate defaults to false in PrefsController.swift. The wallet provider README says it “acts as a MOCK” and issues attestations with “NO further checks”. The trust list cache (EtsiTrustConfig.kt) expires after 24 hours with no stale fallback in LoadSingleLoTEWithFileCache.kt. RevocationWorkManager.kt has onFailure = {}. The trust list cache directory is context.cacheDir (EtsiTrustProvider.kt), which Android may clear under storage pressure. Every service README carries the same block, for example eudi-srv-wallet-provider: “We strongly recommend against putting this version of the software into production use.” All checked 22 October 2026. ↩

41. EU age verification specification, Annex B, July 2026: the Longfellow zero-knowledge system was reviewed by Trail of Bits, ISRG and an academic panel, findings addressed, and is “deployed in Google Wallet”. ↩

42. The roles are from the ARF’s trust model chapter and the reference apps’ configuration: wallet provider at wallet-provider.eudiw.dev, two issuer hosts, four trust lists at trustedlist.serviceproviders.eudiw.dev, and status list URLs embedded in each credential. The Android wallet polls status every 15 minutes (revocationInterval in WalletCoreConfig.kt), iOS every 300 seconds. ↩

43. All from the reference implementation at the commits cloned on 22 October 2026 and ARF v3.0.0. Issuer stores the wallet’s attestation status indices beside each credential: eudi-srv-pid-issuer, adapter/out/persistence/IssuedCredentialEntity.kt lines 52-58. Issuer must poll them for the life of the PID: WUA_29, “Throughout the entire validity period of an issued PID, the PID Provider SHALL verify the revocation status of both the Wallet Instance and WSCD”. Refresh token and refill without re-authentication: eudi-lib-android-wallet-core, DefaultOpenId4VciManager.kt lines 417-450. Batches of ten, refill at two: WalletCoreConfigImpl.kt lines 212-233. Wallet provider mints per-unit indices and keeps the register: WUA_08 note b, WUA_37. User account per wallet: WIAM_06. Device list: docs/main/06-trust-model.md line 530. Reference wallet provider logs requests at INFO: wallet-provider-service/src/main/kotlin/config/WalletInstanceAttestationRoutes.kt. Status polling: WalletCoreConfig.kt line 181 (15 minutes), WalletKitConfig.swift line 368 (300 seconds). Relying parties never see the wallet attestation: WUA_07. Server retrieval banned: ProxId_02. ↩

44. eudi-srv-pid-issuer: GetPidDataFromKeyCloak.kt line 242 sets document_number to one random UUID per attribute fetch, and the fetch happens once per batch request; IssueMdoc.kt lines 57-64 give the batch one issuedAt and expiresAt, written into each credential’s signed validity info at one-second precision (EncodeAttestationAttributesInMdoc.kt lines 66-68). ARF v3.0.0, ISSU_36: batch issuance timestamps “SHALL” not allow relying parties to conclude that two attestations “belong to the same User”. The once-only policy also covers only PIDs, so every other attestation is a single rotating credential that every relying party sees for its lifetime. ↩

45. Counted from the organisation’s 86 repositories on 22 October 2026. Duplicates, 28: the 13 iOS twins of the Android libraries (three for ISO 18013-5, three for remote signing), 3 extra verifier endpoints and UIs, a second trust validator, 4 extra Python issuer repos, a status validator, a Java registration-certificate signer, 2 forked age-verification wallet apps, 3 extra remote-signing services. Scaffolding, 20: 9 demos and testers, CI and test bed, organisation pages, docs site, roadmap, a Swift macro, an issuer front end, a conformance site. Real and necessary, 38, split across repositories that a single wallet or SDK would hold as modules. The minimum set of 18: two wallets, verifier SDKs for JVM, TypeScript, .NET and Python, issuer SDKs for JVM and Python, a wallet provider, a registry and trust-list service, a status list, a remote-signing service, three integration shims, a specification repo, a demo repo and CI. The TypeScript and .NET verifier SDKs are the two that don’t exist. ↩

46. Counted on 22 October 2026. myID: myid.gov.au. myGov wallet and the identity exchange: Budget Paper No. 2, 2024-25. ConnectID: connectid.com.au, “accredited as an identity exchange by the Australian Government”. Australia Post: Digital iD, “Effective 1 May 2026, the Digital iD app is no longer available.” NSW: Service NSW. Queensland: Digital Licence App. Victoria: Premier, 13 May 2024, in both the Service Victoria and myVicRoads apps. South Australia’s mySA GOV is named on Queensland’s acceptance page, which lists the four state licences Queensland venues may accept. WA: ServiceWA, trial from mid-2027. NT: Inside State Government, 16 October 2026. ACT: Region, 24 October 2025, “ensuring we do it once and do it right.” Victoria interstate: Service Victoria, “Make sure you have your plastic licence with you when going interstate.” Scantek: How do I scan a NSW digital driver’s licence, “Use your personal phone (with the NSW Drivers License) to scan the second phone (displaying the Scantek app).” ↩

47. Service Oklahoma, 8 February 2024: “the OK Mobile ID App has officially been decommissioned” and “there was a lack of use cases with the app”. Florida: FLHSMV FAQ, archived 10 July 2024, “the Florida Department of Highway Safety and Motor Vehicles is removing the current Florida Smart ID application from the app store” and “The Florida Smart ID applications will be updated and improved by a new vendor”; Governor DeSantis, 28 November 2025: “The convenience of a digital drivers license is outweighed by the potential for government to abuse it. Not gonna happen in FL. No digital ID.” Florida’s contract: FACTS HSMV-0315-20, total US$2.2m, closed June 2024. ↩

48. TSA, participating states, 21 states and Puerto Rico on 23 October 2026. TSA final rule, 89 FR, 25 October 2024: “TSA emphasizes that it receives passenger data only from the passenger’s mobile device” and “never communicates with driver’s licensing agencies” about “the locations or instances” of use. DHS Office of Inspector General, OIG-26-27, 15 September 2026: “the CAT-2 vendor was able to access and extract sensitive passenger information, including driver’s license and passport images” and TSA “did not track when this data was extracted, could not verify that extracted information was properly deleted”. ↩

49. Let’s Encrypt, Our first certificate is now live, 14 September 2015, and end of year letter, 29 December 2025: “over the past year we went from serving 492 million websites to 762 million”, “issuing ten million certificates on some days”. 90-day lifetimes from Certificate lifetime rationale. ↩

50. OpenID for Verifiable Credential Issuance 1.0, final, 16 September 2025. ↩

51. ISO/IEC 18013-5:2021. QR or NFC engagement, then BLE, NFC or Wi-Fi Aware transfer, with no internet connection required for the transfer. ↩

52. OpenID for Verifiable Presentations 1.0, final, 9 July 2025. ↩ ↩²

53. RFC 9901, Selective Disclosure for JSON Web Tokens. Selective disclosure does not give unlinkability, see its privacy considerations. ↩ ↩²

54. google/longfellow-zk, zero-knowledge proofs over existing ECDSA-signed mdocs, open source. See also ⁴¹. ↩ ↩²

55. RFC 5280, certification path validation, name constraints and key usage. Which signer may assert which document type is an application policy on top. ↩

56. IETF Token Status List and W3C Bitstring Status List. Both are bulk, cacheable lists rather than per-person lookups. ↩

57. OpenWallet Foundation, Multipaz. Release 0.101.0, September 2026, adds wallet and reader NFC data transfer on Android. The iOS transport factory still reads MdocRole.MDOC -> throw NotImplementedError("Not yet implemented"). ↩ ↩²

58. EU ARF v3.0.0 section 5.7.2: “set up a communication channel using QR code or NFC, and to subsequently communicate over BLE, NFC, or Wi-Fi Aware”. Google’s reader guidance, Accepting IDs from Google Wallet offline, 16 October 2026: “hold the phone steady against the NFC target until the BLE connection is established.” The AAMVA guidelines set the portrait at a minimum of 192 by 240 pixels. ↩

59. Android, Host-based card emulation: “all card emulators … are unavailable when the device screen is off.” Android Ready SE Alliance, March 2021, promised “Mobile driver’s license and Identity Credentials” applets. In September 2026 Google folded it into an Android Digital Credential Alliance. I found no phone that ships the applet. ↩

60. Android Keystore system: with a compromised OS “the attacker might be able to use any app’s Android Keystore keys on the Android device, but it can’t extract them”. StrongBox support varies by device. ↩

61. Apple, Protecting keys with the Secure Enclave and Local Authentication. ↩ ↩²

62. ISO 18013-5 session encryption as implemented in Multipaz SessionEncryption.kt: ECDH shared secret, HKDF-SHA-256 salted with the hash of the session transcript, AES-256-GCM. ↩

63. OpenID4VP 1.0 encrypts responses with JWE, ECDH-ES in its examples, and mentions HPKE only as an option. The 1.1 editor’s draft makes HPKE normative: “If HPKE is used, the alg value MUST be specified according to I-D.ietf-jose-hpke-encrypt.” HPKE is RFC 9180. ↩

64. Android Developers, Upgrading Android Attestation: Remote Provisioning, March 2022: “it is not possible for Google to correlate attestation keys back to a particular device.” Devices launching with Android 16 support only remote provisioning. On the limits: Apple’s DeviceCheck documentation says App Attest “can’t definitively pinpoint a device with a compromised operating system.” ↩

65. Cryptographers’ feedback on the EU Digital Identity’s ARF, June 2024, sixteen authors including Jan Camenisch, Anna Lysyanskaya, Bart Preneel and Carmela Troncoso: “if the same attestation is used in two transactions, these transactions can be linked.” ↩

66. BSI TR-03139, the certificate policy for Extended Access Control on EU travel documents. ↩

67. NIST FIPS 204, August 2024, Table 2: ML-DSA-44 public key 1,312 bytes, signature 2,420 bytes. QR capacity from Denso Wave: version 40, binary, error correction L, 2,953 bytes. Timeline: NIST IR 8547 (draft), November 2024, 112-bit algorithms “Deprecated after 2030 Disallowed after 2035”. ICAO: TAG/TRIP/5 WP 18, November 2025, “a new work item aimed at producing a technical specification on the implementation of quantum-safe mechanisms”. ↩

68. iTnews, 18 May 2022, reporting Dvuln’s findings: “Once decrypted, the DDL data can be edited to change the details of the ID” and “DDL data is never validated against the Service NSW application programming interface and database.” NSW is now replacing it with a selective-disclosure licence, piloted from September 2026. ↩

69. Ministry of the Interior and Safety, explanatory statement, 2 July 2026, my translation: the signed mobile ID has had no forgery cases, and the separate QR confirmation service is under review for abolition after forged screens were sold on social media. ↩

70. Francis, Hancke, Mayes and Markantonakis, Practical NFC Peer-to-Peer Relay Attack using Mobile Phones, 2011: “a practical implementation of an NFC-enabled relay attack, requiring only suitable mobile software applications.” ↩