Nobody needs to know how old you are.

Meta agreed to settle claims from 52 state attorneys general that it built Instagram and Facebook to hook teenagers. The number carried the headlines. The dependency underneath it is the more interesting story.

The behavioral commitments are real. A default two-hour daily cap for under-18 accounts. A midnight-to-6am blackout. Notifications silenced during school hours. Like counts hidden by default.

Every one of them is a rule about teenagers. Which means every one of them requires knowing, correctly, which accounts belong to teenagers.

Meta says it is “investing in even stronger technology” to catch users who misrepresent their age. In the same filing, it asks app stores to take that job on. Not deeper into its own product — up the stack, to Apple and Google.

This is not hypothetical. Four states — Texas, Utah, Louisiana, and California — have passed App Store Accountability laws requiring Apple and Google to verify age at the account level and pass a signal down to every app installed. Apple built the Declared Age Range API for it. Google built Play Age Signals.

The name is the tell. Apple has positioned the Declared Age Range API explicitly as an alternative to biometric age checks. It does not require a birth date. Parents set the range for a child account, and the user decides which range to share — a 14-year-old can declare 13 to 15, an adult can declare 16 or over. The range reaches a developer only if the user allows it, and that permission can be withdrawn later.

There is also a quieter limitation. The obligations attach to new accounts created after each state’s cutoff date. Existing adult and child accounts are not affected. Most teenagers already have an account.

So the statute says verify and the implementation says declare. That gap is not an oversight — Apple has a real data-minimization argument for it, and we will come back to why that argument deserves respect. But it changes what the signal actually means.

It is worth noting how unsettled the legal picture is on top of that. Texas’s version is the only one currently in force, and it got there through a procedural Supreme Court decision not to block it while the appeal continues. This is a shift underway, not a shift that is finished.

Mechanically, the model works like a venue wristband. You get checked once at the door. You get a band. From that point on, every bar inside the venue trusts the band instead of your face.

There is a loud version of the privacy objection to age verification and a serious one. The loud version says any age check is surveillance. The serious version is much harder to dismiss: I am not worried about being asked whether I am over 18. I am worried about what you keep after I answer.

That worry is well-earned. The standard implementation of an age gate asks you to photograph a government ID and upload it. In that single act you disclose your full legal name, your exact date of birth, your home address, your document number, your height — and a high-resolution photo of your face, pre-matched to all of it.

The site needed one piece of information. It now holds a complete identity dossier, on a server you will never see, under a retention policy you did not read.

Framed that way, the privacy concern is not anti-verification. It is a data minimization argument, and it is correct.

Wink’s approach is built around the two problems above: the wristband that comes off, and the surplus that never goes away. Here is the mechanism, explicitly.

Once, at the start. A live face scan alongside a government-issued ID. Wink checks liveness, so a photograph of a photograph does not pass, confirms the document is real, and reads the date of birth. Biometric resolution runs in seconds.

Immediately after. That verification collapses into a token — a one-way derivative tied to the face, not the document. The ID itself is discarded rather than stored. What remains can confirm a threshold was met. It cannot be run backwards into a name, a birthday, or a photograph.

Every time after that. The check is a live face match against the token. No document re-enters the flow. No inherited session gets trusted. The question is never “is this device cleared?” It is “is this the face on file?”

For an age check, the merchant never receives the ID, the photograph, or the biometric. They get a yes, a no, or an age bracket. That is all an age check ever needed, and all a merchant should want to be responsible for holding.

Checkout is where most of this conversation happens, and for good reason — it is where the liability is most visible, and it is where our own customers feel it first. But age is a condition on far more than purchases. It gates services, records, physical spaces, and entire categories of care.

Healthcare shows how different the requirement looks outside retail. Pharmacies apply age thresholds to specific over-the-counter medications. Telehealth platforms need to know whether a patient is a minor before a consultation begins, because the consent rules, the prescribing rules, and the record-access rules all change at that line. Patient portals have to handle the moment a pediatric record becomes an adult one, and a parent’s access has to end when it should.

Gaming and gambling operate under some of the strictest thresholds anywhere, enforced per session rather than per account. Financial services gate account opening and the transition out of custodial accounts. Venues gate entry to specific areas rather than the whole building. Unattended retail — smart fridges, vending, kiosks, delivery lockers — has no staff member to look at anything at all, which is exactly where an automated check has to be strongest.

Operationally these have almost nothing in common. What they share is the underlying question, and the fact that most of them currently answer it by asking someone to photograph a driver’s license.

Which raises the practical objection nobody has answered well. If every one of those places runs its own age check, a person ends up uploading the same government ID dozens of times, to dozens of organizations, each retaining its own copy under its own policy. Every upload is a new place the document can leak from. The privacy cost is not one careless vendor. It is the multiplication.

A token does not have that problem, because a token is not a document. One enrollment produces a verified age credential that works everywhere Wink is deployed — the dispensary counter, the delivery handoff, the online checkout, the kiosk, the venue door — without the ID re-entering the flow a single time after the first check.

What each place learns stays scoped to what it needs. A bar needs one thing: over 21, yes or no. A telehealth platform may need a different threshold entirely. Neither needs the document behind it, and neither receives it.

And portability without control would just be a faster way to leak. So the credential does not travel on its own. Each business that wants an answer has to be granted permission by the person, one at a time. Enrolling once does not quietly enroll you into every merchant on the network. It means that when a new one asks, answering takes a glance instead of a document upload — and the person can decline, or grant access and revoke it later, without touching any of the others.

More than age travels this way. An age token is the smallest thing Wink can hand over. One bit: old enough, or not.

But age is rarely the only thing a business needs. A shop that ships something needs somewhere to send it. A service calling to check it is really you needs a number to dial. And a returning customer would rather not type the same address for the fortieth time.

So the wallet holds more than a threshold. An address you entered yourself. A phone number. A payment method. And every business that asks follows the same rule: it receives what its own transaction actually needs, and nothing sitting beside that.

Think of the door staff at a venue versus the driver delivering to your house. The door needs one fact — are you old enough. The driver needs a different one — where do you live. Neither needs both. Neither should get both.

Same shop, two situations. Buying at the counter, they get a yes. Delivering to your door, they get a yes and an address. What you decide is which businesses get a relationship with you at all — and you can end any one of them without touching the rest.

This is where Apple’s instinct deserves the credit we owed it earlier. Their age range is shared with a developer only if the user allows it, and the user can turn it back off. That part of the design is right, and anyone building in this space should copy it.

The difference is what sits behind the permission. In one case the user is granting access to a range they declared about themselves. In the other they are granting access to a threshold that was actually verified against a real document, and then reduced to something that cannot be turned back into one. Consent control and verification strength were never a trade-off. A system offering only one of them is half-built.

Age verification is not a standalone product bolted onto a checkout. It is one output of an identity layer that also handles login, fraud scoring, and payment authorization — which is why the same face scan that clears a 21+ threshold can also authorize the transaction that follows it.

That matters practically. An organization running age checks through one vendor, fraud through another, and payments through a third is maintaining three separate views of the same person, and reconciling them is where both cost and risk accumulate.

The settlement will push a lot of platforms to buy age assurance quickly, and quick procurement is how organizations end up holding data they never wanted. These three questions separate a real privacy architecture from a compliance checkbox.