Türkiye’deki yeni yaş doğrulama kuralları hakkında yazmaya başladığımda dönüp durduğum soru oldukça netti. Sistemin kendisi, platform iş birliği yapsa bile, devletin hangi kişinin hangi sosyal medya hesabını doğruladığını öğrenmesini teknik olarak engelliyor mu? Tokenın ad veya kimlik numarası içermediği söylendiğinde de bu soruyu sormak gerekiyor. Kişisel bilgileri gizlemek, takibi mutlaka engellemez. 1

10 Ekim’de yayımlanan yönetmelik, e-Devlet üzerinden kimlik doğrulamasının ardından alınan bir doğrulama belirteci, yani token tarif ediyor. Bu token, kullanıcının 15 yaşını doldurup doldurmadığını; doldurmuşsa 18 yaşını da doldurup doldurmadığını bildiriyor. Başka kişisel veya kimliği belirleyici bilgiler içermiyor ve platform tarafından yalnızca yaş doğrulama amacıyla kullanılabiliyor. Bunlar yararlı koşullar. Yönetmelik 1 Kasım’da yürürlüğe giriyor. Geçici madde kapsamındaki mevcut hesapların tokenla doğrulanması için son tarih ise 31 Mart 2027. 2

Bu koşullardan çıkaramadığım şey, sürecin tamamının, tokenı veren tarafın sonradan gerçekleşen kullanımı tokenı alan kişiyle ilişkilendirmesini nasıl engellediği.

Sorduğum bağlantı

Burada üç taraf var. Belgeyi düzenleyen taraf yaşımı tespit ediyor. Ben, ilgili yaş grubunda olduğumu kanıtlayan bir şey alıyorum. Bir platform da ben bir hesabı kullanırken bu kanıtı kontrol ediyor.

Belgeyi düzenleyen taraf zaten kim olduğumu biliyor olabilir. Platform da hangi hesabın doğrulandığını zaten biliyor. Mahremiyet açısından soru şu: Doğrulama süreci, bu iki bilgiyi birbirine bağlamak için karşılaştırabilecekleri bir veri üretiyor mu?

Yalnızca yaş grubu bilgisi ve rastgele bir referans değeri içeren bir token düşünelim. Bu değerin bir isme benzemesi gerekmez. Tokenı veren taraf onu hangi kişinin aldığını, platform da hangi hesabın sunduğunu kaydediyorsa, bu kayıtları bir araya getirmek hesabı tokenı alan kişiye bağlar. Benzersiz bir imza veya başka bir sabit değer de, onu görünür kılan bir tasarımda benzer bir sorun yaratabilir.

Bu, varsayımsal bir tasarım kusuru. Türkiye’de uygulanan sistemin böyle olduğuna dair bir iddia değil. Bunun yapıldığını iddia etmiyorum. Sorduğum, bunu neyin engellediği. Bunların gerçekleşmesi için kanıt algoritmasının kırılması gerekmiyor.

Seçici açıklama ve ilişkilendirilemezlik

Seçici açıklama, bir dijital belgedeki bilgilerin yalnızca seçilen kısmını karşı tarafa göstermektir. İlişkilendirilemezlik ise belgenin kullanıldığı işlemlerin birbirine bağlanıp bağlanamamasıyla ilgilidir. Bu ayrım önemli; çünkü bir sistem çok az veri paylaşırken yine de tanınabilir bir iz bırakabilir.

JSON Web Token’larda seçici açıklamayı tanımlayan RFC 9901, bu ayrımı somutlaştırıyor. Standardın mahremiyet bölümü, ilişkilendirilemezliğin farklı türlerini ele alıyor. Bunlardan biri, doğrulamayı yapan tarafın kendi isteğiyle veya zorunlu tutularak aldığı verileri paylaşması hâlinde, belgeyi düzenleyen tarafın o belgeyi tanıyıp tanıyamaması. SD-JWT bu daha güçlü özelliği sağlayamıyor: Doğrulamayı yapan taraf, düzenleyenin imzaladığı asıl belgeyi alıyor ve onu düzenleyene geri gönderebiliyor. 3

SD-JWT’yi bu ayrımı açıklamak için örnek veriyorum. Türkiye’deki yaş doğrulama sisteminin SD-JWT kullandığını söylemek için bir dayanağım yok. Bir protokolün olası zayıflığını anlatmak, teknik tasarımını incelemediğim bir sistemin hangi protokolü kullandığını ortaya koymaz.

Tanınıp eşleştirilebilen böyle bir kanıt bırakmamak üzere tasarlanmış yöntemler var. W3C’nin BBS kriptografik algoritma takımı çalışması, yöntemin güvenlik varsayımları altında, belge sahibinin yeni kanıtlar türetmesine olanak veriyor. Bu kanıtların kriptografik değerleri ne asıl imzayla ne de birbirleriyle ilişkilendirilebiliyor. Eylül 2026 tarihli belge, W3C’nin Candidate Recommendation Draft aşamasında bir taslak. Belge ayrıca, çevredeki verilerin ve sistemin geri kalanının yine de nasıl bağlantılar kurulmasına yol açabileceğini ele alıyor. Yararlı bir kriptografik özelliğin, uygulamanın geri kalanında da korunması gerekiyor. 4

Kanıtın etrafındaki ayrıntılar

Dikkat çektiğim ayrıntılardan biri imza anahtarlarıydı. Belgeyi düzenleyen tarafın, belirli bir kişiye yalnızca o kişi için kullanılan bir anahtarla belge verdiğini düşünelim. Doğrulama sırasında hangi anahtarın kullanıldığı ortaya çıkıyorsa, rastgeleleştirilmiş bir kanıt bile doğrulayan tarafa kimliği belirlemeye yarayan bir ipucu bırakabilir. Bunun daha az uç örnekleri de kullanıcıları küçük, tanınabilir gruplara ayırabilir.

Bu, bilinen bir tasarım sorunu. Privacy Pass mimarisini açıklayan RFC 9576, tokenı veren tarafın kullandığı anahtarların ve yapılandırmaların, kullanıcının içinde ayırt edilemez kalması gereken kullanıcı kümesini nasıl bölebileceğini ele alıyor. İstemcilerin kendilerine farklı yapılandırmalar verildiğini saptayabilmesi için tutarlılık mekanizmaları gerektiğini belirtiyor. İşlemlerin zamanlamasının da bu kümeyi nasıl daraltabileceğini açıklıyor. 5

Buradan somut sorular çıkıyor. Kullanıcılar, kendilerine de diğer kullanıcılarla aynı, sistemin kabul ettiği yapılandırmanın verildiğini doğrulayabiliyor mu? Anahtarlar, çok küçük kullanıcı grupları oluşturmadan nasıl yenileniyor? Belgenin geçerliliği veya iptal durumu kontrol edilirken, nerede kullanıldığını açığa çıkaracak biçimde belgeyi düzenleyen tarafla iletişim kuruluyor mu? Hangi kayıtlar saklanıyor?

Bu soruların yanıtlanabilmesi için tehdit modelinin açıkça tanımlanması gerekiyor. İlişkilendirilemeyen bir yaş kanıtı IP adresini ortadan kaldırmaz, platformun hesap kayıtlarını silmez veya bir cihazın parmak izinin çıkarılmasını imkânsız hâle getirmez. Benim talebim daha dar: Yaş doğrulama mekanizması, belgeyi düzenleyen taraf ile platform doğrulama kayıtlarını paylaşsa bile, kimlik ile hesap arasında güvenilir biçimde eşleştirme yapılmasını sağlayan yeni bir bağlantı oluşturmamalı. Diğer takip yöntemleri için ayrıca önlem gerekiyor.

Neyi incelemek isterim?

İstediğim akış, belirli bir kriptografik yöntemi seçmeden de anlaşılabilir. Yaşımı belgeyi düzenleyen tarafa doğrulatıyorum. Daha sonra gerekli yaş grubunda olduğumu bir platforma kanıtlıyorum. Kullandığım kanıt, belgeyi düzenleyen tarafın platformun doğrulama işlemine ait kayıtlardan hesabımı tanımasına izin vermiyor. Tasarımın, tekrarlanan kullanımları ve kanıtın çevresindeki bilgileri nasıl ele aldığını açıklaması gerekiyor.

Avrupa Veri Koruma Kurulu da yaşın doğrulanması ve tahmin edilmesi gibi yöntemlere ilişkin açıklamasında benzer bir ayrım yapıyor. Açıklamanın 34. paragrafı, tarafların iş birliği yapması veya veri ihlalleri yaşanması durumları da gözetilerek seçici açıklama ve ilişkilendirilemezliğe, ayrıca verilerin kullanıcıda tutulması ve yerel olarak işlenmesi gibi yaklaşımlara dikkat edilmesini öneriyor. Bu, karşılaştırma için yararlı bir ölçüt. Türkiye’deki hukuku tanımlamıyor veya belirli bir sistemin bu koşulları karşıladığını onaylamıyor. 6

Türkiye’deki yönetmeliğin 12. maddesi, bir teknik rehber hazırlanmasını ve sosyal ağ sağlayıcılarıyla paylaşılmasını öngörüyor. 13 Ekim itibarıyla kamuya açık bir kopyasını bulamadım. Bu, rehberin hazırlanıp hazırlanmadığını veya sağlayıcılarla paylaşılıp paylaşılmadığını göstermiyor. 2

Tasarımın bağımsız incelemeye açılmasını isterim. Her katılımcının hangi bilgileri görebildiği ve birlikte hareket ettiklerinde ne olduğu açıkça anlatılmalı. Testler, olağandışı anahtarları, üst verileri, tekrarlanan doğrulamaları ve tokenın dışında tutulan kayıtları da kapsamalı. Bir mahremiyet iddiasını değerlendirmek, hangi saldırgana karşı koruma sağladığı ve o saldırganın hangi verileri elde edebildiği belirtildiğinde çok daha kolay.

Belgeyi düzenleyen tarafın yaşımı tespit etmesi gerektiğini kabul edebilirim. Yaşımı nerede kanıtladığımı öğrenmesi gerektiğini de kabul etmiş olmam. Sistemin gerçek tasarımı bu ayrımı açıklayana kadar, “token kişisel bilgi içermiyor” ifadesi asıl soruyu yanıtsız bırakıyor.

Bu yazıya eşlik eden yazı: Açıklanan amaçlar neden yeterli değil?

Footnotes

  1. Furkan Mamuk’un X tartışması: ana paylaşım, Türkçe çerçeve, kapsam, istenen kanıt akışı, anahtarlarla parmak izi oluşturma ve güven. ↩

  2. Sosyal Ağ Sağlayıcı Tarafından Çocuklara Özgü Ayrıştırılmış Hizmet Sunulmasına ve Yaş Doğrulamaya İlişkin Yönetmelik. 10 Ekim 2026 tarihli ve 33396 sayılı Resmî Gazete. Millî Eğitim Bakanlığı sitesindeki resmî aktarım; özellikle 7, 10, 12 ve 13. maddeler ile Geçici Madde 1. ↩ ↩2

  3. IETF, RFC 9901: Selective Disclosure for JSON Web Tokens, Kasım 2025, Bölüm 10.1. ↩

  4. W3C, Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft, 10 Eylül 2026, Bölüm 1 ve 6.2. ↩

  5. IETF, RFC 9576: The Privacy Pass Architecture, Haziran 2024, Bölüm 6.2 ve 6.3. ↩

  6. Avrupa Veri Koruma Kurulu, Statement 1/2025 on Age Assurance, 11 Şubat 2025’te kabul edildi, 34. paragraf. ↩