When I started writing about Turkey’s new age-verification rules, the question I kept returning to was fairly specific. Does the system itself prevent the state from learning which person verified which social-media account, even if the platform cooperates? That question is still worth asking after someone says the token contains no name or identity number. Hiding personal information doesn’t necessarily prevent tracking. 1

The regulation published on 10 October describes a token obtained after authentication through e-Devlet. It reports whether the user has reached 15 and, if so, 18, excludes other personal and identifying information, and limits the platform’s use to age verification. Those are useful requirements. The regulation takes effect on 1 November, with a 31 March 2027 deadline for token verification of existing accounts covered by the transitional provision. 2

What I cannot establish from those requirements is how the complete flow prevents the issuer from connecting a token’s later use to the person who obtained it.

The connection I am asking about

There are three parties here. The issuer establishes my age. I receive something that proves the relevant age category. A platform checks that proof while I am using an account.

The issuer may already know who I am. The platform already knows which account is being verified. The privacy question is whether the verification process gives them something they can compare to connect those two facts.

Imagine a token containing only an age category and a random reference. The reference need not look like a name. If the issuer records which person received it, and the platform records which account presented it, combining those records links the account to the person who received the token. A unique signature or another stable value can create a similar problem in a design that exposes it.

That is a hypothetical failure mode, not a claim about what Turkey has implemented. I am not claiming this is being done. The point is to ask what prevents it. The proof algorithm doesn’t need to be broken for any of this to happen.

Selective disclosure and unlinkability

Selective disclosure means revealing only selected information from a credential. Unlinkability concerns whether uses of that credential can be connected. The distinction matters because a system can disclose very little while still leaving a recognizable trace.

RFC 9901, the standard for Selective Disclosure for JSON Web Tokens, makes this concrete. Its privacy section distinguishes several kinds of unlinkability, including whether an issuer can recognize a credential when a cooperating or compelled verifier shares what it received. SD-JWT cannot provide that stronger property: the verifier receives the original issuer-signed credential and can send it back to the issuer. 3

I am using SD-JWT as an example of the distinction. I have no basis for saying Turkey’s age-verification system uses it. Naming a possible weakness in one protocol does not identify the protocol in a system whose technical design I have not inspected.

There are constructions designed to avoid that recognizable proof. Under the scheme’s security assumptions, the W3C’s BBS cryptosuite work allows a holder to derive fresh proofs whose cryptographic values cannot be linked to the original signature or to each other. Its September 2026 document is a Candidate Recommendation Draft. It also discusses ways the surrounding data and system can still create links. A useful cryptographic property needs to survive the rest of the implementation. 4

The details around the proof

One detail I raised was signing keys. Suppose an issuer gives a particular person a credential under a key used only for that person. If verification reveals which key was used, a randomized proof can still leave the verifier with an identifying clue. Less extreme variations can divide users into small, recognizable groups.

This is an established design concern. The Privacy Pass architecture, RFC 9576, discusses how issuer keys and configurations can split the set of users among whom someone is supposed to be indistinguishable. It calls for consistency mechanisms so clients can detect being given different configurations. It also explains why timing can narrow that set. 5

The practical questions follow from that. Can users verify that they receive the same accepted configuration as other users? How are keys rotated without creating tiny groups? Does checking validity or revocation contact the issuer in a way that reveals where a credential is being used? Which records are retained?

These questions require a specified threat model. An unlinkable age proof will not erase an IP address, remove a platform’s account records, or make a device impossible to fingerprint. My narrower requirement is that the age-verification machinery should not introduce a reliable identity-to-account connection, including when the issuer and platform share their verification records. Other tracking channels need their own protections.

What I would want to inspect

The flow I want is understandable without committing to one particular cryptographic scheme. I establish my age with an issuer. I later prove the required age category to a platform using evidence that does not let the issuer recognize my account from the platform’s verification transcript. The design must explain how it handles repeated use and the information surrounding the proof.

The European Data Protection Board makes a related distinction in its age-assurance statement. Paragraph 34 recommends attention to selective disclosure and unlinkability, including under collusion or data breaches, and to approaches such as user-held data and local processing. That is a useful external benchmark, not a statement of Turkish law or a certification of any particular system. 6

Article 12 of Turkey’s regulation provides for a technical guide to be prepared and shared with social-network providers. I have not located a public copy as of 13 October. That does not establish whether one has been produced or distributed. 2

I would want that design available for independent inspection, with a clear account of the information visible to each participant and what happens when they cooperate. Tests should cover unusual keys, metadata, repeated verification, and records kept outside the token itself. A privacy claim is much easier to evaluate when it names the adversary and the evidence that adversary receives.

I can accept that an issuer needs to establish my age without accepting that it needs to learn where I prove it. Until the actual design answers that distinction, “the token contains no personal information” leaves the main question open.

Companion essay: Why stated intentions are not enough

Footnotes

  1. Furkan Mamuk’s X discussion: main post, Turkish framing, scope, desired proof flow, key fingerprinting, and trust. ↩

  2. Regulation on child-specific differentiated services and age verification by social-network providers, published 10 October 2026, Official Gazette no. 33396. Official Ministry of National Education reproduction, especially Articles 7, 10, 12, 13 and Transitional Article 1. ↩ ↩2

  3. IETF, RFC 9901: Selective Disclosure for JSON Web Tokens, November 2025, Section 10.1. ↩

  4. W3C, Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft, 10 September 2026, Sections 1 and 6.2. ↩

  5. IETF, RFC 9576: The Privacy Pass Architecture, June 2024, Sections 6.2 and 6.3. ↩

  6. European Data Protection Board, Statement 1/2025 on Age Assurance, adopted 11 February 2025, paragraph 34. ↩