SUMMARY
- The Digital Age Assurance Act of 2026 (S. 5090), introduced July 22 by Sens. Andy Kim, Cynthia Lummis, Adam Schiff and John Barrasso, would move age checks from individual websites down to the operating system layer.
- The bill contains some data-minimization language. It bars selling age data, using it for profiling or targeted advertising, and combining it with other personal information.
- It names zero-knowledge proofs and verifiable credentials, but does not require them. A separate rule of construction states that nothing in the Act requires “a particular technological method.” This leaves the door open for operating systems to undermine anonymity with their age checks.
- At the same time, the bill says it does not require government ID, biometrics or facial age estimation. It does not prohibit them, and a conflict-resolution provision instructs operating system providers to “verify the age of the user” without specifying how.
- Nothing in the text addresses the record of who asked for an age signal about whom, and when. That is the metadata layer where a device-level architecture would generate its most sensitive data.
Most American age verification proposals to date have put the burden on the destination: the pornography site, the social media platform, the app. The Digital Age Assurance Act of 2026 takes a different route. It would push the check down to the operating system, where Apple, Google and Microsoft would collect a date of birth once, sort users into four age brackets, and broadcast a “signal” to any app, browser or covered website that asks.
Over 400 Cybersecurity and Privacy Experts Warn of Digital ID Threat to Internet Security
Industry has broadly preferred this design, and so have a number of privacy advocates, on the basis that one disclosure to a device maker is better than a hundred disclosures to apps and websites. The question worth asking is narrower than whether device-level checks are a good idea. It is whether this particular text delivers the privacy properties its architecture promises. The answer is mixed.
What the bill actually protects
Section 6 forbids operating system providers, developers and covered website operators from selling age bracket data, from using it for “profiling, engagement optimization, or targeted advertising,” and from combining age bracket data “with other personal or inferred information regarding a user.”
That last clause is the one doing real anonymity work. The recurring failure mode of identity infrastructure is not the initial disclosure but the combinations of data that follow, as the age attribute becomes one more column in a profile that also contains location, purchase history and behavioral inference. Section 6(4) prohibits the combination outright. Whether the Federal Trade Commission would enforce it against a firm arguing that its age gate and its ad stack are technically separate systems is another matter.
Section 3(b) limits the operating system provider to sending brackets only for the statutory purpose, requires “reasonable security safeguards,” caps retention at what is necessary to generate the signal, and requires deidentification or deletion when a user deletes the account. Section 4(d) bars developers from requesting anything more than the bracket, or passing it downstream. Section 7 prohibits targeted advertising to known children and bars disclosing children’s personal data to data brokers, while explicitly preserving contextual advertising.
Section 10(5)(B) states plainly that nothing in the Act shall be construed to require age verification through “the collection of a government-issued identification document, biometric information, or other sensitive personal information,” or through “facial age estimation technology.” Compared to a number of state laws now in force, this is a meaningful drafting choice.
What the bill does not do
It does not mandate zero-knowledge proofs. The relevant sentence, in Section 3(a)(1)(B)(ii), requires the signal to be delivered “through a reliable real-time application programming interface, using, where technically feasible, in an interoperable format, and subject to paragraph (3), a verifiable credential or zero-knowledge proof.” The syntax is ambiguous about how far “where technically feasible” reaches. But Section 3(a)(3) resolves it by implication, because it addresses only a provider “that uses a verifiable credential or zero-knowledge proof,” language that presupposes a provider might not. Section 10(7) then closes the question, stating that nothing in the Act shall be construed to “require a particular technological method of generating, transmitting, or verifying a signal.”
A “verifiable credential” must be tamper-evident, cryptographically signed, and disclose “no other information” about the user, a stricter bar than most deployed credential systems currently meet. The zero-knowledge proof definition is serviceable. They are simply optional.
It does not name a standard. Section 3(a)(3) requires consistency with “widely adopted, consensus-based interoperability standards.” No standard is named. Not the W3C Verifiable Credentials Data Model, not OpenID for Verifiable Presentations, not ISO/IEC 18013-5. The provision is a standard-shaped hole with nothing written in it, to be filled later by whatever the largest platforms converge on. The FTC’s rulemaking authority under Section 8(a)(2)(E) is the only lever for tightening it.
The document-check doorway is left open. Section 10(5)(B) is a rule of construction, not a prohibition. It says the Act does not require ID or face scans, not that they are barred. Meanwhile Section 3(d) provides that when an operating system provider receives “clear and convincing information” that a user’s age differs from the bracket on file, the provider “shall verify the age of the user.” No method is specified and no privacy constraint attaches. That is the seam through which document or biometric checks would enter, and it is worth watching in markup.
Nothing addresses request metadata. Section 3(b) governs retention of the age bracket data. It says nothing about the log of which developer requested a signal for which user, and when. In a device-level architecture, that log is the sensitive artifact: a running record of which apps a person opened and which age-restricted sites they reached through which browser. Section 6(1)’s minimization language is too general to clearly reach it. There is no unlinkability requirement, no pairwise-pseudonym requirement, and nothing preventing the same user identifier from being observable across relying parties. A serious cryptographic design specifies exactly these properties. This bill does not mention them.
Under-17s are linked by statute. Section 3(a)(1)(C) requires any user identified as a child to link their account to a parent or guardian’s. Whatever else it accomplishes, it obliges operating system providers to maintain a family graph by force of law, with an emancipated-minor exception that raises the obvious question of how emancipation would be demonstrated without documents.
Preemption is narrow. Section 13 preempts state law only where it conflicts, and preserves any state or federal rule “at least as protective.” Since “covered internet website” is itself defined by reference to sites already required by other law to verify age, S. 5090 layers on top of existing state regimes rather than displacing their ID-upload mandates. A user in a state with a document-based law is not relieved of it by this bill.
Enforcement runs through the FTC and state attorneys general. There is no private right of action. Penalties are $2,500 for negligent violations and $7,500 for knowing ones, multiplied by the number of children affected.
The wider context
None of this is being drafted in a vacuum. Age assurance has become the principal vector for identity infrastructure across the democratic world, and the justifications offered in public have not always matched the ones offered in committee.
In Britain, the campaign that produced the Online Safety Act’s verification duty was organized around anonymous “trolling” rather than child safety. Its founder described the goal as “the freedom not to be shouted at,” and the group now argues openly that platform verification could “drive take-up of digital identity products.” In Germany, Chancellor Friedrich Merz has called directly for “real names on the internet,” specifying that those who “critically examine our country and our society” should do so under their identified names, a rationale with no child-protection pretext at all.
In March 2026, 405 cybersecurity and privacy researchers from 30 countries signed an open letter warning that mandatory age assurance risks “establishing an infrastructure that could be exploited to ban access to Internet services for reasons unrelated to safety.” Their more specific complaints concerned biometric collection, unreliable AI age estimation, breaches exposing government IDs, and downstream pressure against VPN use. Those are failure modes that S. 5090’s device-level design avoids at the front door. That letter also noted that zero-knowledge methods exist and have not been mandated anywhere. S. 5090 continues the pattern, though it comes closer than most.
Assessment
5090 is better understood as a data-minimization and signal-plumbing statute than as an age-verification-technology statute. On the downstream questions, meaning what apps and websites may do with age information once they have it, it is among the more restrictive proposals currently in circulation, and Section 6’s anti-combination rule is a real contribution.
On the upstream questions, meaning how the signal is produced, what the platform learns from producing it, and whether the resulting record is unlinkable, the bill declines to legislate. It names the right cryptographic primitives and then makes them optional. It disclaims ID and biometrics as a rule of construction while leaving a verification mandate with no specified method in Section 3(d). It regulates the payload and ignores the metadata.
The practical effect is to delegate the privacy architecture to Apple, Google and Microsoft, with an undefined “consensus-based standards” hook and FTC rulemaking as the only correctives. Whether that is acceptable depends heavily on how much one trusts three firms to build, unsupervised, a system that will gatekeep a substantial fraction of American internet access.
There is an 18-month runway before the Act would take effect, and a markup ahead. The provisions worth watching are narrow and identifiable. Whether “verifiable credential or zero-knowledge proof” becomes mandatory rather than permissive. Whether Section 3(a)(3) names a standard. Whether Section 3(d) acquires method constraints. And whether anything at all is added about request logs. Those four edits would change the answer to the question in the title considerably.
