Argues the actual payload of age-verification laws is the token schema itself, not the age attribute. Once browsers and signup flows universally understand attestation tokens, regulators can cheaply mandate new claims like citizenship, sanctions status, or 'verified human' — turning a child-safety mechanism into infrastructure for attributing all online speech to a government ID.
Points to existing statutory language in the UK Online Safety Act requiring platforms to offer 'verified user' tiers, and notes the technical scaffolding for those tiers is identical to what's being rolled out for age checks. Treats this as evidence that the extension from age to broader identity attestation is not hypothetical but already encoded in law.
Argues that a handful of attestation providers — Onfido, Persona, Veriff, Jumio, plus Apple and Google's native implementations — will become a de facto PKI for personhood. The risks developers should care about are vendor lock-in, single points of failure, and outage blast radius across the entire web, not just the privacy story that has already been litigated.
A 923-point Hacker News thread surfaced a long-form essay arguing that the wave of age-verification laws now passing in the UK, EU, Australia, and a growing list of US states is not really about children. The essay's central claim is that age verification is the first deployment of a general-purpose identity-attestation layer — a signed token format that, once normalized, can be extended to carry any claim a regulator decides to require.
The mechanic is worth understanding precisely. A user uploads a government ID to a third-party verifier. The verifier returns a cryptographically signed token asserting an attribute — initially `age >= 18`. The relying site never sees the ID itself. Privacy advocates have been told this is the privacy-preserving design. The essay's argument is that the token *schema* is the payload, not the value of the attribute. Once every browser, every signup flow, and every comment box knows how to present and consume an attestation token, the marginal cost of adding new mandatory claims — `citizenship US`, `not_on_sanctions_list true`, `employer_disclosed true`, `verified_human true` — drops to a config change at the verifier.
The HN comment section largely agreed with the framing, with the most-upvoted reply pointing out that the UK's Online Safety Act already contains language about "verified user" tiers that platforms may be required to offer, and that the technical scaffolding for those tiers is exactly the same scaffolding being deployed now for age.
The surveillance critique has been made. What hasn't been made loudly enough is the infrastructure critique, which is the part developers should care about. A small number of attestation providers — likely the same incumbents who now run KYC for fintech: Onfido, Persona, Veriff, Jumio, plus whatever Apple and Google build natively — will become a de facto PKI for personhood, with the same centralization, vendor-lock, and outage-blast-radius problems as the certificate authority ecosystem.
Consider what happens the first time a major verifier has an outage. With TLS, a CA outage means new certs can't be issued; existing certs still work. With personhood attestation, an outage means no one can post, comment, sign up, or in the worst case, log in. The token is short-lived by design — that's the privacy story — so a four-hour Onfido incident becomes a four-hour global comment-box outage. We have no SRE playbook for this because we've never had a hard dependency on a third party for *speech*.
The second problem is revocation. CAs revoke certificates; attestation providers will revoke *people*. The criteria will start narrow — duplicate accounts, sanctions hits, court orders — and broaden under the same pressure that broadened content moderation. There is no appeals process for a CA decision either, but a CA decision affects a domain, not a person's ability to leave a GitHub issue. Every developer who integrates an attestation API is wiring their product to a third party that can, with no recourse, render specific human beings unable to use it.
The third problem is the one practitioners will feel first: compliance creep at the integration layer. Cookie banners taught the industry that a once-narrow regulation (ePrivacy Directive, 2002) becomes a mandatory middleware layer in every web stack within a decade. GDPR consent flows are the same pattern. Age verification is on the same trajectory, except the integration burden is higher (you're brokering signed tokens, not setting a cookie) and the failure modes are worse (your users can't speak vs. your analytics get blocked).
The most under-discussed implication is for open source. The Linux kernel has accepted anonymous patches. Bitcoin was authored under a pseudonym. A large fraction of independent security research is published under handles. The day GitHub is required to gate "high-risk" actions — pushing to a repository above some star threshold, publishing an npm package, opening a PR against a critical-infrastructure project — behind an attested account, the pseudonymous-contributor era of open source ends quietly. There will be no announcement. The signup flow will just acquire one more step, and the people who can't or won't complete it will stop contributing.
If you ship anything user-facing in a jurisdiction with active age-verification legislation — and that list now includes most of the English-speaking internet — you have three concrete things to do this quarter.
First, inventory your exposure. Age-verification mandates currently apply to adult content, gambling, and increasingly social platforms above a user-count threshold. The thresholds drop every legislative cycle. If your product has a comment system, a DM, a profile page, or any user-to-user surface, model what happens when the threshold reaches you. The integration is non-trivial: you need a verifier contract, a token-validation library, a re-verification cadence, a fallback for verifier outages, and an audit trail.
Second, treat the attestation provider as a Tier-0 dependency, the way you treat your auth provider or your payment processor. That means: SLO it, monitor it, have a runbook for its failure, and avoid single-provider lock-in if your jurisdiction allows multi-provider acceptance (the UK and EU drafts do; some US state laws do not). Budget for the per-verification cost — current pricing runs roughly $0.50–$2.00 per check, which is fine until you're verifying every new account in a free-tier consumer product.
Third, architect for claim expansion. The token format is extensible by design. The codebase you write this year to consume an `age_over_18` claim will, with high probability, be the codebase that consumes `citizenship`, `humanness`, and `employer_disclosed` claims within five years. Build the validation layer as a pluggable claim handler, not as an `if (token.ageOver18)` check buried in a signup controller. The refactor cost later will be enormous.
The historical parallel that fits best is not cookie banners — it's the gradual mandatory deployment of TLS. The first wave was specific (banking, login forms). The second wave was an industry consensus (HTTPS-everywhere). The third wave was structural (browsers marking HTTP as insecure, search engines penalizing it). Identity attestation is currently in the first wave. The token schema being shipped this year is the equivalent of TLS 1.0 — the part that locks in. The interesting question is not whether the system expands; it's which open standards, if any, get adopted before the incumbents' proprietary formats become the de facto interface. If the IETF and W3C don't ship a credible open standard for verifiable credentials in the next 24 months, the answer will be "whichever three companies Apple, Google, and Cloudflare partner with."
Age verification is just one part of this crackdown.Device attestation is another - making sure you're using an unmodified government approved operating system and apps linked to your ID.
Age verification starts the gating of Internet access by governments.Any site, with any concern about age of user liability, is likely to adopt the practice. Strong laws, sold on their face value safety benefits, will increase that liability.You won’t see any laws removing or limiting that liability
It gives a new spin to:> Everything you say CAN and WILL be used against you.Especially when what you said has already been recorded and tied to your identity before you faced the authorities.Edit: from last week https://news.ycombinator.com/item?id=48632269
Cory Doctorow had a very profound talk about it very long time ago (10+years).https://www.youtube.com/watch?v=HUEvRyemKSgAs the internet become the place where people do a lot of things, no government (and especially no security services) will be able to keep themselves from trying to
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
If we taught systems thinking in schools things like internet age verification would never get past being an idea on the back of a napkin. People struggle to consider the second-, third-, and nth-order effects of anything so asking them to consider what else might happen if we bring in laws and tech