The Age of Mandatory Age Verification — Is Privacy-Preserving Identity Possible?

• Introduction — The End of a Free Internet?
• Problems With Current Age Verification
• The Core Idea of Privacy-Preserving Authentication
• Zero-Knowledge Proofs — Proving Without Revealing the Secret
• Verifiable Credentials and Selective Disclosure
• SD-JWT — The Actual Structure of Selective Disclosure
• mDL and mdoc — Another Standard Branch
• eIDAS 2.0 and the EU Digital Wallet
• Device-Side Verification Model
• Design Principles Developers Should Know
• Comparison With Korea Identity Verification System
• Policy Problems Technology Cannot Solve
• Closing — A Balanced Conclusion
• References

Introduction — The End of a Free Internet?

In June 2026, a blog post from Mullvad VPN sparked a major debate on Hacker News. The title was provocative: mandatory age verification on social media is the beginning of the end for a free internet. A translated summary spread quickly on GeekNews, bringing a familiar subject back into focus in Korea, a country that has long operated identity verification systems.

The shape of the debate is not simple. On one side is the legitimate goal of protecting minors; on the other is anonymity and privacy, fundamental values of the internet. Caught in between is the technology we developers have to build.

The question of this post is clear: is it technically possible to authenticate "you are 18 or older" without revealing who you are? And if it is, is that enough? The conclusion up front: technically much of it is possible, but technology does not solve policy problems for us. Separating these two things is the goal of this post.

Problems With Current Age Verification

The age verification methods most services use today are dismal from a privacy standpoint. There are broadly three.

Self-declaration stops nothing. The other three do stop something, but in exchange they hand the user full identity or biometrics to the service provider (or its outsourced verification vendor).

The core problem is over-collection. All the service needs to know is a single bit of information: the yes/no of "is this person 18 or older?" Yet current methods make you hand over name, address, national ID number, face, and ID number all at once. You expose hundreds of bits to confirm one.

Add to this the data breach risk. A database of ID images collected for age verification is itself an attractive hacking target. Several jurisdictions that introduced mandatory age verification have indeed reported data breaches at verification vendors. It is the paradox that the identities of all users, including the very minors you set out to protect, end up exposed to greater risk.

The Core Idea of Privacy-Preserving Authentication

The technical insight that solves this has existed since the 1980s. Two principles are key.

Principle 1: Data Minimization
  Prove only the single fact that is needed.
  Only the "18 or older" bit; do not even reveal the birthdate.

Principle 2: Separation of verification and identity (Unlinkability)
  The issuer (the state) does not know where I verified, and
  the verifier (the service) does not know who I am.
  Issuance and verification cannot be traced to each other.

The technologies that implement these two principles are zero-knowledge proofs, Verifiable Credentials, and selective disclosure. Let us look at each.

Zero-Knowledge Proofs — Proving Without Revealing the Secret

A zero-knowledge proof (ZKP) is a cryptographic technique that proves a statement is true without revealing the reason it is true (the secret) at all. The name is intimidating but the intuition is simple.

Here is a classic analogy. Suppose you want to prove to a colorblind friend that a red ball and a green ball are different colors. The friend decides whether or not to swap the two balls behind their back and shows you, and you can correctly say each time whether they were swapped. Repeat this many times, and the friend becomes convinced that "this person can distinguish the two balls." Yet you never once said which ball is which color. That is the core intuition of zero knowledge: proving a capability (or a fact) without disclosing its content.

Applied to age verification:

Claim: "I am 18 or older"
Proof: I hold a signed credential containing a birthdate,
       and I prove via ZKP that this birthdate is before (today - 18 years)
What becomes public: a single bit, the result "true"
What does not become public: the actual birthdate, name, ID number, all of it

Mathematically this uses a technique called a range proof: proving that "my secret value x lies within a certain range" without revealing x. Treating the birthdate as a number, "this number is less than a certain reference date" is exactly "18 or older."

The appeal of ZKP is powerful, but there are obstacles to practical use: the computational cost of proof generation, the need for a trusted setup, and above all the difficulty for ordinary users to understand it. For this reason the actual standardization trend pairs ZKP not alone but with the simpler and proven technique of selective disclosure.

Verifiable Credentials and Selective Disclosure

W3C Verifiable Credentials (VC) is the standard data model for digital credentials. Think of it as a paper ID moved to digital form. The difference is that three actors are clearly separated.

+-----------+   issue   +-----------+  present  +-----------+
| Issuer    |---------->| Holder    |---------->| Verifier  |
| e.g. state|           | e.g. user |           | e.g. svc  |
+-----------+           +-----------+           +-----------+
                              |
                       stored in wallet
                        (smartphone)

The key is that the issuer and verifier do not communicate directly. The user keeps a credential issued by the state in their own wallet and presents it to a service when needed. The state does not know which service it was presented to. This is one axis of the unlinkability mentioned earlier.

Selective disclosure is combined with this. A credential contains many attributes such as name, birthdate, and address, but when presenting, you can pick and show only what is needed. For age verification, you disclose only the single derived attribute "18 or older" and hide the rest.

SD-JWT — The Actual Structure of Selective Disclosure

The representative format implementing selective disclosure is SD-JWT (Selective Disclosure for JWTs). Standardization is underway at the IETF, and it is becoming the de facto foundation for digital identity documents. Let us look at the structure in code.

In an ordinary JWT, every claim sits directly in the payload, so to show even one you must show all. SD-JWT replaces each claim with a hash and separates the actual values into distinct disclosures.

{
  "iss": "https://issuer.example.gov",
  "iat": 1749686400,
  "vct": "https://credentials.example/identity",
  "_sd": [
    "MTHmVfX6cFTW6oqYk8s3lDxgZ9c0Q1d2e3f4g5h6i7j",
    "9pK2lM3nO4pQ5rS6tU7vW8xY0zA1bC2dE3fG4hI5jK6"
  ],
  "_sd_alg": "sha-256",
  "age_over_18": true
}

In the payload above, each entry in the _sd array is the hash of a hidden claim. Separately, the issuer also delivers disclosures that hold the actual value and salt of each claim.

Disclosure example (conceptual form, base64url-decoded):
  ["random-salt", "given_name", "Gildong Hong"]
  ["random-salt", "birthdate", "1990-03-15"]

At presentation time, the holder attaches only the disclosures they choose to reveal. The verifier hashes the attached disclosures and compares them against the hashes in _sd to confirm integrity. For claims that are not attached, only the hash exists, so the verifier cannot reconstruct the original.

The full flow of an age verification scenario looks like this.

1. The state issues an SD-JWT credential
   - Includes a derived boolean claim like age_over_18 in advance
   - Or includes birthdate as a hidden claim

2. The user keeps it in their wallet

3. The service requests "proof of being 18 or older"

4. The wallet creates a presentation disclosing only the age_over_18 claim
   - given_name, birthdate, etc. are not attached

5. The service verifies only the issuer signature + the disclosed claim
   - It never learns the user actual age or name

An important design choice appears here. You could include birthdate as a hidden claim and have the verifier compute, but that requires disclosing the birthdate. The better approach is for the issuer to pre-create a derived boolean claim like age_over_18. Then the verifier never needs to learn the birthdate at all. This is data minimization in practice.

Additionally, there is a mechanism called holder binding (key binding). You bind the holder public key into the credential and require the holder to sign with the matching private key at presentation. This blocks attacks that steal and reuse a credential.

mDL and mdoc — Another Standard Branch

Digital identity standards have two branches. One is the SD-JWT family we just saw; the other is the mDL (mobile Driving License) of ISO/IEC 18013-5 and its data format mdoc. This standardizes a digital version of a driving license and is already being adopted in several countries and some US states.

mdoc also supports selective disclosure. It precisely targets use cases like showing only "adult status" while hiding the address when presenting an ID at a bar. The EU digital identity wallet is being designed to accommodate both SD-JWT and mdoc.

The landscape of digital identity standards

  ZKP-based ---+
               |  stronger unlinkability, higher complexity
               |
  SD-JWT ------+--- W3C VC / OpenID4VP ecosystem
               |    web/OAuth friendly
               |
  mdoc (ISO) --+--- offline presentation, government-ID friendly

eIDAS 2.0 and the EU Digital Wallet

The largest attempt to weave these technologies into actual policy is the EU eIDAS 2.0 and the EUDI Wallet (European Digital Identity Wallet). The vision is to give every EU citizen a digital identity wallet that holds an ID and various credentials and presents them via selective disclosure.

The design intent itself is privacy-friendly. Data minimization, user control, and unlinkability are written in as explicit requirements. Age verification is cited as one of the key use cases of this wallet.

There is significant debate, however. Critics worry that a single state-issued digital identity scheme could instead become infrastructure for tracking and control. Even if unlinkability is guaranteed at the protocol level, it can collapse through gaps in implementation, operation, and policy. The gap between technical design and actual operation is the central point of contention.

Device-Side Verification Model

Another approach pushed by Apple and Google is device-side verification. You keep your ID in a smartphone wallet (Apple Wallet, Google Wallet) and process much of the verification inside the device.

[Server-side verification — traditional]
  User data --> sent to the server --> server verifies --> result
  (data reaches the server, exposure risk)

[Device-side verification — new model]
  Credential stored in a secure chip (Secure Enclave)
        |
        v
  The device builds a selective-disclosure presentation for the request
        |
        v
  Only minimal info is sent to the server (age_over_18, etc.)

The advantages are clear: sensitive data never leaves the device and is protected by a hardware security module. But there are drawbacks too. This model fundamentally concentrates trust in two platforms, Apple and Google. It draws criticism that gatekeeper power grows stronger, plus an equity concern that users who do not run either company OS could be excluded.

Design Principles Developers Should Know

Whether age verification or other identity checks, here are the principles for designing a privacy-preserving system.

1. Make data minimization the default
   - Request only the single "18 or older" boolean bit.
   - If you do not need the birthdate, do not collect the birthdate.

2. Create derived claims at the issuance stage
   - Do not make the verifier compute from the original.
   - Have the issuer pre-include age_over_18, age_over_21, etc.

3. Do not store the verification result
   - Discard immediately after verification. Keep only a session marker.
   - Keep only the fact "verified" and throw away the data used to verify.

4. Maintain issuance-verification unlinkability
   - Do not let verification logs flow back to the issuer.

5. Design fallback paths without discrimination
   - Ensure users without a digital wallet are not excluded.

6. Follow the standards
   - Do not invent your own crypto protocol.
   - Use proven standards: SD-JWT, OpenID4VP, mdoc.

The third principle is especially important. Many systems, in the name of keeping a "verification record," retain the data used for verification and then suffer a breach. The heart of privacy preservation is not storing data safely but not storing it in the first place.

Comparison With Korea Identity Verification System

Korea sits in a unique position in this debate, having long operated internet real-name and identity verification systems. Game shutdown laws and identity checks for adult content access are familiar.

The hallmark of the Korean model is intermediated verification through identity verification agencies. Designated bodies such as telecoms or credit bureaus hold the identity verification information, and services receive verification results (connecting information, duplicate-signup confirmation information, etc.) through those bodies. Some data minimization is applied in that services do not receive the national ID number directly, but ultimately data and verification history accumulate at the centralized point of the verification agency.

Compared with the distributed model seen earlier, the difference is clear.

Korea system has operated stably, but its structural traits of centralization and verification-history tracking differ from the direction that distributed privacy-preserving technology pursues. How these two models converge or clash in future digital ID discussions is worth watching.

Policy Problems Technology Cannot Solve

That was what is technically possible. Now it is time to be honest. Even if privacy-preserving technology is implemented perfectly, problems remain. This is exactly what the Mullvad post truly pointed at.

First, the chilling effect. The moment anonymous access becomes impossible, people start self-censoring political expression, searches for sensitive information, and participation in minority communities. Even if you only prove "18 or older," the very perception that anonymity is gone chills freedom of expression. Zero-knowledge proofs hide your identity, but they cannot hide the fact that the act of verification exists at all.

Second, scope creep. Identity infrastructure built for age verification is easily repurposed. It starts as protecting minors, then becomes content censorship, then tracking dissidents. Even if the technology is neutral, the infrastructure it creates is not.

Third, the problem of exclusion. What about people without a digital ID, without a smartphone, who do not use a particular platform? A system that preserves privacy perfectly is still another form of discrimination if it excludes from the internet those who cannot have it.

Fourth, a question about the mandate of verification itself. The most fundamental critique is "is it right to force age verification on everyone?" Even if protecting minors is a legitimate goal, is it proportionate to withdraw the anonymous access rights of the entire population as the means? This is a question cryptography cannot solve, one that society must answer.

Closing — A Balanced Conclusion

To summarize:

Technology lets us avoid much of the worst-case scenario we fear (ID uploads, face scans, data breaches). Zero-knowledge proofs, SD-JWT, Verifiable Credentials, and device-side verification genuinely make possible authentication that "proves one bit and hides the rest." As developers, if we must implement age verification, using these privacy-preserving standards rather than receiving ID photos on the server is clearly the right choice.

But technology does not solve policy problems for us. The chilling effect, scope creep, exclusion, and the legitimacy of mandating verification are not resolved by cryptographic protocols. We must clearly distinguish that the proposition "privacy-preserving age verification is technically possible" does not automatically lead to "therefore it is fine to mandate age verification."

The practical conclusions left for developers are two. First, if you are in a situation where you must implement age verification, push data minimization to the extreme and use proven standards. Second, never forget that the elegance of technology does not automatically guarantee the legitimacy of policy. Good technology can only make bad policy less bad; it cannot make it good.

Whether this is the end of a free internet depends, in the end, not on the technology but on which policies we choose.

References

• Mullvad — Age verification for social media: https://mullvad.net/en/blog/age-verification-for-social-media-the-beginning-of-the-end-for-a-free-internet
• W3C Verifiable Credentials Data Model 2.0: https://www.w3.org/TR/vc-data-model-2.0/
• IETF SD-JWT draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
• EU Digital Identity (eIDAS 2.0): https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet
• ISO/IEC 18013-5 (mDL): https://www.iso.org/standard/69084.html
• OpenID for Verifiable Presentations: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
• W3C Decentralized Identifiers (DID): https://www.w3.org/TR/did-core/
• Zero-knowledge proof overview (zkproof.org): https://zkproof.org/
• Hacker News: https://news.ycombinator.com/
• GeekNews: https://news.hada.io/