Türkiye’nin Dijital Kimlik Cüzdanı Nasıl Tasarlanmalı?

Bir dijital kimlik cüzdanının başarısı mobil uygulamanın görünümünden önce güven modeline bağlıdır. Yanlış tasarlanmış bir cüzdan; sabit QR kod, merkezî takip sistemi veya kişisel verilerin yeni bir kopyası hâline gelebilir. Doğru tasarım ise vatandaşın yalnızca gerekli özelliği paylaşmasını ve kurumun bu özelliği yetkili kaynaktan doğrulamasını sağlar.

Bu yazı, Türkiye için uygulanabilir bir dijital kimlik cüzdanının issuer–wallet–verifier mimarisini, QR akışını, seçici veri paylaşımını, anahtar güvenliğini ve geliştirme yol haritasını ele alıyor.

Temel aktörler

Issuer — kimlik bilgisini yayınlayan kurum

Issuer, belirli bir bilginin yetkili kaynağıdır. Nüfus ve Vatandaşlık İşleri temel kişi kimliğini; üniversite veya YÖK diplomayı; SGK uygunluk bilgisini; yetkili meslek kuruluşu meslek yeterliliğini yayınlayabilir.

Her kurum yalnızca yetkili olduğu credential türünü imzalamalıdır. Bir üniversite ikamet bilgisi, bir alışveriş sitesi sürücü belgesi yayınlayamamalıdır.

Holder ve wallet — vatandaş ve cüzdan

Cüzdan, vatandaş adına credential’ları saklar veya gerektiğinde erişir. Kurumun istediği bilgileri anlaşılır biçimde gösterir, kullanıcı onayı alır ve gerekli minimum alanlardan doğrulanabilir sunum üretir.

Verifier — doğrulama isteyen kurum

Banka, hastane, işveren veya e-ticaret sitesi verifier olabilir. Fakat verifier da kendi kimliğini ve yetkisini kanıtlamalıdır. Cüzdan, talebin gerçekten belirtilen kuruma ait olduğunu ve kurumun istenen veri kategorisini talep etmeye yetkili bulunduğunu kontrol etmelidir.

Trust registry — güven listesi

Güven listesi hangi kurumun hangi credential’ı yayınlayabileceğini ve hangi verifier’ın hangi bilgiyi isteyebileceğini gösterir. Liste dijital olarak imzalanmalı, sürümlenmeli ve cüzdanlar tarafından güvenli biçimde güncellenebilmelidir.

Status ve revocation servisi

Credential süresi dolabilir, iptal edilebilir veya yeniden yayınlanabilir. Verifier sunulan bilginin durumunu kontrol edebilmelidir. Bu kontrol, yayıncı kuruma vatandaşın her kullanım yerini göstermeyecek şekilde mahremiyet korumalı tasarlanmalıdır.

Credential yaşam döngüsü

Kayıt ve güçlü kimlik doğrulama
        ↓
Credential yayınlama
        ↓
Cihaz ve kullanıcıya kriptografik bağlama
        ↓
Sunum ve seçici paylaşım
        ↓
Durum / geçerlilik kontrolü
        ↓
Yenileme, askıya alma veya iptal

Credential’ın ilk yayınlanması en kritik aşamalardan biridir. Başlangıç kimlik doğrulaması zayıfsa sonraki bütün dijital imzalar yanlış kişiyi güvenilir biçimde temsil eder. Kayıt sürecinde e-Devlet, T.C. kimlik kartı, yüz yüze doğrulama veya uygun güven seviyesindeki başka yöntemler birlikte kullanılabilir.

Kimlik bilgisinin örnek yapısı

Aşağıdaki yapı kavramsal bir örnektir:

{
  "type": ["VerifiableCredential", "PersonIdentityCredential"],
  "issuer": "did:gov:tr:nvi",
  "validFrom": "2026-10-17T09:00:00Z",
  "validUntil": "2027-10-17T09:00:00Z",
  "credentialSubject": {
    "given_name": "Örnek",
    "family_name": "Kullanıcı",
    "age_over_18": true,
    "nationality": "TR"
  }
}

Gerçek sistemde bütün alanların tek credential içinde bulunması şart değildir. Veri minimizasyonu ve farklı kullanım süreleri için yaş kanıtı, adres, sürücü yetkisi ve temel kimlik ayrı credential’lar hâlinde yayınlanabilir.

Dinamik QR akışı

QR’ın içine T.C. kimlik numarası veya kişisel veri konulmamalıdır. Verifier tek kullanımlık bir talep oluşturur:

{
  "request_uri": "https://bank.example/request/8f7a...",
  "client_id": "bank-example",
  "nonce": "128-bit-rastgele-deger",
  "purpose": "customer_onboarding",
  "requested_claims": [
    "identity_verified",
    "legal_name",
    "over_18"
  ],
  "expires_in": 90
}

1. Verifier imzalı ve kısa ömürlü talep oluşturur.
2. Vatandaş QR’ı dijital cüzdanla okutur.
3. Cüzdan verifier sertifikasını ve güven listesindeki yetkisini kontrol eder.
4. İstenen alanlar ve işlem amacı vatandaşa gösterilir.
5. Vatandaş PIN veya cihaz biyometrisiyle işlemi onaylar.
6. Cüzdan yalnızca seçilen alanları içeren, nonce ve verifier’a bağlı sunum üretir.
7. Verifier yayıncı imzasını, hedef kurum bilgisini, süreyi, nonce’u ve credential durumunu doğrular.
8. Aynı QR ikinci kez kullanılamaz.
9. Vatandaşa işlem makbuzu kaydedilir.

Seçici veri paylaşımı

Selective disclosure, cüzdanın tüm credential’ı açıklamak yerine yalnızca istenen alanı kanıtlamasını sağlar. Örneğin doğum tarihi paylaşılmadan 18 yaş sınırının aşıldığı gösterilebilir.

Bunun için SD-JWT VC, ISO mdoc veya uygun sıfır bilgi ispatı teknikleri kullanılabilir. Her kullanım senaryosunun aynı karmaşık kriptografik yönteme ihtiyacı yoktur. Çözüm güvenlik, performans, denetlenebilirlik ve birlikte çalışabilirlik dengesiyle seçilmelidir.

Kuruma özel takma tanımlayıcı

Sürekli müşteri ilişkisi için kurumun kişiyi sonraki işlemlerde tanıması gerekebilir. Bütün kurumlarda aynı vatandaşlık numarasını kullanmak yerine pairwise pseudonymous identifier üretilebilir:

PPID = HMAC(
  government_secret,
  internal_person_id || verifier_id
)

Bu sadece kavramsal bir formüldür. Gerçek uygulamada anahtar rotasyonu, alan ayrımı, versiyonlama ve HSM politikaları tasarlanmalıdır. Aynı kişi farklı kurumlarda farklı PPID alır; kurumlar doğrudan ortak tanımlayıcı üzerinden veri birleştiremez.

Çevrimiçi ve çevrimdışı doğrulama

Çevrimiçi model

Verifier veya wallet işlem sırasında devlet servisine bağlanır. Güncel durum ve yetki anında kontrol edilir. Buna karşılık merkezî servis işlem bağlamını görebilir ve servis kesintisi doğrulamayı durdurabilir.

Çevrimdışı model

Credential yayıncının dijital imzasıyla cüzdanda bulunur. Verifier imzayı yerel olarak doğrular. Yayıncı her kullanımdan haberdar olmaz. Ancak iptal bilgisinin güncelliği ve çevrimdışı geçerlilik süresi sınırlı olmalıdır.

Türkiye için hibrit model daha uygundur: düşük riskli kanıtlar çevrimdışı veya yayıncıya kullanım bilgisini göstermeden sunulabilir; yüksek riskli banka/KYC veya kritik kamu işlemlerinde çevrimiçi durum kontrolü yapılabilir.

Anahtar güvenliği

Issuer imza anahtarları HSM içerisinde üretilmeli ve kullanılmalıdır. HSM anahtarın dışarı çıkarılmasını önlese de yanlış credential yayınlanmasını engellemez; yetkilendirme ve iş kuralları ayrıca korunmalıdır.

Vatandaşın cihaz anahtarı Secure Enclave, Android StrongBox veya eşdeğer donanım destekli güvenlik alanında tutulmalıdır. Anahtar mümkünse cihazdan çıkarılmamalı ve kritik sunumlarda kullanıcı doğrulaması zorunlu olmalıdır.

Kayıp cihaz ve kurtarma

Özel anahtarı normal bulut yedeğine kopyalamak kolay fakat riskli bir yöntemdir. Daha güvenli yaklaşım:

1. Kayıp cihazdaki cüzdan birimi askıya alınır.
2. Yeni cihazda vatandaş yeniden yüksek güven seviyesinde doğrulanır.
3. Yeni cihaz için yeni anahtar çifti oluşturulur.
4. Credential’lar yeni cihaza yeniden yayınlanır.
5. Eski cihaz ve credential bağları iptal edilir.

Kurtarma süreci, saldırganların çağrı merkezi veya SIM değişimi üzerinden hesap ele geçirmesine izin vermeyecek biçimde tasarlanmalıdır.

İşlem makbuzu ve denetim

Vatandaş şu bilgileri görebilmelidir:

• Hangi kurum talepte bulundu?
• İşlem amacı neydi?
• Hangi alanlar istendi?
• Hangi alanlar paylaşıldı?
• Ne zaman ve hangi cihazla işlem yapıldı?
• Çevrimiçi merkezî doğrulama kullanıldı mı?

Denetim logları da kişisel veridir. Ham T.C. kimlik numarası içermemeli; erişimi sınırlandırılmalı, bütünlüğü dijital imzalar veya hash zinciriyle korunmalı ve belirli sürenin sonunda silinmelidir.

Standartlar

• Credential veri modeli — W3C Verifiable Credentials 2.0
• Credential yayınlama — OpenID for Verifiable Credential Issuance
• Credential sunma — OpenID for Verifiable Presentations
• Mobil belge — ISO/IEC 18013-5 mdoc yaklaşımı
• JSON imza/şifreleme — JOSE, JWS, JWE
• CBOR tabanlı koruma — COSE
• Web kimlik doğrulama — WebAuthn ve passkey
• Anahtar koruma — HSM ve cihaz secure element

Blokzincir zorunlu değildir. Ulusal PKI, imzalı güven listeleri ve HSM ile korunan yayıncı anahtarları yeterli bir güven modeli kurabilir. Kişisel veri veya kimlik kullanım geçmişi değiştirilemez bir blokzincire yazılmamalıdır.

Referans geliştirme bileşenleri

İlk açık kaynak referans uygulama dört parçadan oluşabilir:

1. Demo Issuer: Sentetik vatandaşlara yaş ve temel kimlik credential’ı yayınlar.
2. Mobil Wallet: Credential saklar, QR okur ve seçici sunum üretir.
3. Verifier Portal: Yaş veya kimlik doğrulama isteği oluşturur.
4. Trust/Status Service: Issuer ve verifier sertifikalarıyla iptal durumunu yönetir.

Prototip gerçek vatandaş verisi kullanmamalıdır. Sentetik kimlikler, test kök sertifikaları ve açık tehdit modeliyle çalışmalıdır.

Geliştirme yol haritası

Aşama 1 — yönetişim ve veri sözlüğü

Credential türleri, yetkili issuer’lar, verifier yetkileri, güven seviyeleri, saklama politikaları ve vatandaş hakları belirlenir.

Aşama 2 — 18+ doğrulama prototipi

Az veri gerektiren, selective disclosure faydasını açıkça gösteren bir kullanım senaryosu geliştirilir.

Aşama 3 — diploma ve meslek belgesi

Üniversite ve meslek kuruluşlarıyla doğrulanabilir belge yayınlama test edilir.

Aşama 4 — banka ve hastane sandbox’ı

Sentetik veriyle KYC, hasta kaydı, kayıp cihaz, iptal, kötü niyetli verifier ve çevrimdışı doğrulama senaryoları test edilir.

Aşama 5 — bağımsız güvenlik değerlendirmesi

Kriptografik inceleme, mobil uygulama testi, mahremiyet etki değerlendirmesi, erişilebilirlik ve kırmızı takım çalışmaları yapılır.

Aşama 6 — gönüllü sınırlı pilot

Belirli üniversite, belediye veya kamu hizmetlerinde fiziksel alternatifi koruyan pilot başlatılır.

Kaçınılması gereken tasarımlar

• QR içerisine açık kişisel veri koymak,
• Bütün kurumlarda aynı sabit sanal kimliği kullanmak,
• Her işlemi merkezî olarak takip etmek,
• Kapalı ve tek üreticiye bağımlı protokol geliştirmek,
• Özel anahtarları normal bulut yedeğinde tutmak,
• Kullanıcı onayını tek hukuki dayanak kabul etmek,
• Akıllı telefonu olmayan vatandaşı hizmet dışı bırakmak,
• Kişisel verileri blokzincire yazmak.

Referans demoda uygulanan güven ve yönetişim katmanı

20 Ekim 2026 sürümünde mimarinin bazı parçaları çalışan yazılıma dönüştürüldü: HTTPS portalı, kurum hesabına bağlı oturum, kısa ömürlü iki QR akışı, iPhone cihaz imzası ve izole SoftHSM servisi. İhraççı ile doğrulayıcı iş mantığı hâlâ merkezi API’de; imzalama ayrı serviste. Dolayısıyla üç rolü tanımlamak, üç bağımsız güven kuruluşu kurmakla aynı şey değil.

Dinamik kurum kaydı ve alan yetkisi

Kurum kaydı kurum adı, türü ve ayrı hesapla başlıyor. Yeni kurum onay bekliyor. Yönetici, kurum türünün katalogda izin verdiği alanlardan uygun olanları seçip demo kullanımını onaylıyor. Kurum hesabı kendi yetki kapsamını değiştiremiyor; başka kurumun taleplerini okuyamıyor veya sürdüremiyor.

Sürümlü talep şablonları

Şablon; işlem adı, açık amaç, katalogdan seçilmiş bilgi alanları, her alanın gerekçesi ve gerekli/isteğe bağlı durumunu içeriyor. Yeni veya değiştirilmiş sürüm ayrıca inceleniyor. Gönderilmiş talep ilk sürümün alanlarını ve zorunluluklarını koruyor; imzalı sonuca şablon kimliği ve sürümü ekleniyor.

Kurumlar, alan yetkileri, kurum hesaplarının tuzlanmış scrypt parola özetleri ve şablon sürümleri SQLite içinde kalıcı tutuluyor. Bu yerel yönetişim kaydı; imzalı ulusal güven listesi, kurumsal SSO, sertifika yaşam döngüsü veya gerçek tüzel kişi doğrulaması değildir. Yeni hesaplar uygulama oturumu içindir; mevcut dış web giriş kapısına otomatik kullanıcı eklenmez.

İhraççı özel anahtarı SoftHSM’de, cihaz özel anahtarı gerçek iPhone’da Secure Enclave’de bulunur. SoftHSM’nin yazılımsal korumasından donanımsal HSM’ye geçiş; üretici entegrasyonu, yeni anahtar politikası, rotasyon, yedekleme ve eski imzaların doğrulanmasıyla birlikte tasarlanmalıdır.

Sonuç

Türkiye’nin dijital kimlik cüzdanı; mobil uygulamadan önce açık standartlar, mahremiyet, anahtar yönetimi ve güçlü yönetişim projesidir. Sistem kimlik numarasını dijitalleştirmek yerine kimlik özelliklerinin minimum ve doğrulanabilir paylaşımını sağlamalıdır.

Serinin sonraki yazısı: Hastaneden bankaya dijital kimlik cüzdanının gerçek kullanım senaryoları.

Resmî kaynaklar

• W3C Verifiable Credentials Data Model 2.0
• OpenID for Verifiable Presentations 1.0
• OpenID for Verifiable Credential Issuance 1.0
• EUDI Wallet Architecture and Reference Framework
• TÜBİTAK BİLGEM — Elektronik Kimlik Doğrulama Sistemi

Örnek veri yapıları kavramsaldır; üretim protokolü veya güvenlik profili yerine geçmez.