Age-proof unlinkability and account uniqueness
An anonymous age proof can let one adult verify two accounts without revealing to the service that the same identity backed both proofs. That is not an automatic property of “zero knowledge,” however. It is an architectural choice about which kinds of linkage the protocol permits.
Three distinct properties
| Property | What the service can learn |
|---|---|
| Cross-service unlinkability | Two different services cannot recognize the same credential holder |
| Cross-session unlinkability | Repeated proofs at one service do not carry a stable proof identifier |
| Account uniqueness | One service can detect that the same eligible person created another account |
Strong cross-session unlinkability and strict one-person-one-account enforcement conflict unless the system adds controlled linkability. A credential can derive a stable pseudonym or nullifier that is unique to one service’s domain. That prevents correlation across services, while allowing that service to recognize a second presentation from the same credential holder.
Without such a per-service value, single-use proofs should not reveal that two accounts share an identity. The EU technical specification describes both single-use, unlinkable presentations and domain-specific pseudonyms. Which result applies therefore depends on the selected presentation profile and the relying service’s account design, not merely on whether a ZKP appears somewhere in the stack.
The proof is not the whole observation surface
Even a cryptographically unlinkable presentation does not prevent ordinary correlation through:
- email address, telephone number, or payment method;
- cookies, account-recovery details, and login behavior;
- IP address, device identifiers, and browser fingerprinting;
- reuse of the same adult-controlled device or wallet;
- collusion or logging outside the protocol’s promised trust boundary.
The precise answer is therefore: yes at the credential layer, if cross-session unlinkability is implemented; not necessarily at the service layer. If a policy requires one human to hold only one account, that requirement should be named explicitly because it deliberately sacrifices within-service anonymity.
This tradeoff is part of the wider architecture described in Age assurance and EU age verification and Internet privacy.