Four Bills, One Label: What People Mean by “Age Verification”

One of a Bend Privacy Alliance series on age verification and youth online safety. This explainer untangles the four very different bills that get filed under one phrase — and why telling them apart is the first step to getting the policy right.

“Age verification” sounds like a single idea. In practice it covers at least four different policies, each built differently, each touching different data, and each carrying a different privacy risk. When a headline says a state “passed age verification,” it could mean any of them. The fastest way to evaluate a proposal is to ask which of the four it actually is.

To keep them straight, this page describes each model along the same four lines: who checks the age, where the age information lives, what gets shared, and the main privacy risk. None of this is about opposing child safety. It is about making sure the right tool is matched to the right problem.

Model 1: School and EdTech privacy rules

The oldest model is not really an “age gate” at all. It governs the apps and online services used in K–12 classrooms and the student data they collect. Age here comes from the school context: the student is enrolled, so the rules apply. Oregon already does this. The Oregon Student Information Protection Act (OSIPA, ORS 336.184, enacted in 2015) bars education-technology operators from using K–12 student data for anything other than school purposes, prohibits targeted advertising to students, and requires reasonable security and deletion of student data at a school’s request; it is enforced as an unlawful trade practice. Federal FERPA and COPPA sit alongside it.

Who checks the age: the school or district context (enrollment), not a device or store.
Where the age lives: in the school and EdTech-vendor systems.
What gets shared: student records, limited to educational purposes.
Main privacy risk: how much student data is collected — and the danger of turning schools into an “age authority” for outside services.

Model 2: App-store accountability

This model puts the duty on the app store. Apple and Google must check a user’s age, link a minor’s account to a parent or guardian, and obtain parental consent before a minor downloads apps or makes purchases; developers receive an age category and assign age ratings. Texas, Utah, and Louisiana enacted the first such laws in 2025. Texas’s App Store Accountability Act (SB 2420) was signed in May 2025 and set to take effect January 1, 2026, but a federal court blocked it in December 2025. On June 4, 2026, the Fifth Circuit stayed that injunction, so the law is now in force while the appeal continues (Computer & Communications Industry Association v. Paxton, No. 25-51073). Utah’s law took effect May 6, 2026, and Louisiana’s is rolling out in 2026. These laws rely on “commercially reasonable” verification and carry civil penalties — up to $10,000 per violation in Texas.

The constitutional questions are still being worked out. In a separate but related case about age checks for adult websites, Free Speech Coalition v. Paxton (June 2025), the U.S. Supreme Court held that such an age-verification requirement is judged under “intermediate scrutiny.” That standard, and the app-store litigation above, will shape how far this model can go.

Who checks the age: the app store (Apple, Google).
Where the age lives: the app-store account; passed on to developers.
What gets shared: an age category and parental-consent status, sent to developers.
Main privacy risk: the age check can require identity or ID proof; developers receive age data; the rules face active First Amendment challenges.

Model 3: Operating-system age signals

This is the model now drawing the most attention, and the focus of the rest of this series. Instead of each site or store checking, the device or account creates a coarse age bracket and hands it to apps on request. California’s Digital Age Assurance Act (AB 1043), signed October 13, 2025 and taking effect January 1, 2027, is the leading example. Operating-system providers (think Apple, Google, Microsoft) ask for an age or birth date at setup and turn it into a bracket — under 13, 13–15, 16–17, or 18 and older. No exact birth date is shared. Under an AB 1043-style law, a developer that receives the signal is treated as having “actual knowledge” of the user’s age range. Enforcement rests with the state attorney general; there is no private right of action, and penalties run up to $2,500 per affected child for negligent violations and $7,500 for intentional ones.

The watch item is scope. California is now considering AB 1856, which would extend the same signal from apps to browsers and websites. It is not law: it passed the Assembly 68–1 on May 28, 2026, and is now before the state Senate. The current version adds a carve-out for open-source operating systems (such as Linux) and narrows the app “actual knowledge” rule, but it opens a new channel from browsers to websites. An Oregon proposal modeled on AB 1043 should be read as a possible first step toward that kind of expansion unless it is written to prevent it.

Who checks the age: the device, operating system, or account.
Where the age lives: the OS layer — reusable across many apps.
What gets shared: an age bracket to apps (and, under an AB 1856-style expansion, potentially browsers and websites).
Main privacy risk: a reusable “age layer” that can expand over time; mismatches on shared and school-managed devices; advertising or analytics code sitting next to the signal.

Model 4: Privacy-preserving proof-of-age

The fourth model is the one privacy and security experts most often point to as the narrow option. Rather than collecting an age and storing or broadcasting it, it lets a person prove a single fact — for example, “over 18” — without revealing a birth date or an identity. Approaches include cryptographic “zero-knowledge” proofs and digital credentials held in a wallet on the user’s own device, designed to disclose only the yes-or-no answer a service is entitled to ask. The goal is to avoid both the ID-upload problem and the reusable-tracking-signal problem at once.

The catch is in the implementation. A proof-of-age system is only as private as the way its credentials are issued and the way each check is logged: if it is tied to a government-ID database, or if verifications can be linked back to a person, the privacy promise weakens. The standards and tools for this model are still maturing — which is exactly why the details deserve scrutiny before a law assumes they already exist.

Who checks the age: a credential the user holds, checked at the moment of use.
Where the age lives: with the user, disclosed minimally.
What gets shared: only the specific fact requested (such as “over 18”), ideally not linkable back to identity.
Main privacy risk: weak implementations — ID-linked issuance or logged, linkable checks — can undo the privacy benefit.

How to tell them apart

The same proposal can look reasonable or alarming depending on which model it is. A quick way to place any bill:

If it is about classroom apps and student records, it is the school / EdTech model.
If the app store does the checking and passes age to developers, it is app-store accountability.
If the device or account creates an age bracket that apps (or later, browsers and websites) can request, it is an operating-system age signal.
If a person proves a single age fact without revealing identity, it is privacy-preserving proof-of-age.

Why it matters which model Oregon is debating

These models are not interchangeable, and a safeguard that fits one can be meaningless for another. A rule about deleting student data does nothing to limit a device-level age signal; a ban on ID uploads does not stop a reusable age layer from expanding to new services. That is why the first question to ask about any 2027 proposal is the plainest one: which model is this? Our companion explainer, OS Age Verification, Explained, goes deeper on the operating-system model — the one most likely to reach Oregon — and the safeguards that would keep it narrow.

The basic principle

Lumping four different policies under one label makes it easy to debate the wrong thing — to argue about child safety in the abstract while the real questions of data, scope, and accountability go unasked. Naming the model is how the conversation gets specific.

Different age-checking systems carry different risks, so the fix has to match the model — and any system powerful enough to collect, store, or broadcast a person’s age deserves clear public rules.

Prepared by the Bend Privacy Alliance. The platform tools and laws described here are new and changing; this page reflects the picture as of June 2026, and current status should be checked before relying on any specific detail.