Hastaneden Bankaya: Dijital Kimlik Cüzdanının Gerçek Kullanım Senaryoları

Dijital kimlik cüzdanının değeri kullandığı kriptografik algoritmadan önce gerçek hayatta hangi gereksiz veri paylaşımını ortadan kaldırdığıyla ölçülür. İyi bir kullanım senaryosu “kimlik kartını telefonda göstermek” değildir; belirli bir hizmet için gereken özelliği minimum veriyle kanıtlamaktır.

Bu yazıda hastane, banka, e-ticaret, eğitim, araç kiralama, otel, kamu yardımı ve şirket yetkilendirme senaryolarını; paylaşılan veri, teknik akış ve dikkat edilmesi gereken risklerle birlikte inceliyoruz.

1. Hastanede hasta kabul

Bugünkü süreçte vatandaş T.C. kimlik numarasını sözlü olarak söyleyebilir veya kimlik kartını görevliye verebilir. Numara ekran, çağrı merkezi, log veya farklı hastane sistemlerinde saklanabilir.

Dijital cüzdan modelinde hastane şu sonuçları isteyebilir:

• Kimlik doğrulandı mı?
• Sağlık güvencesi aktif mi?
• Bu hastanedeki mevcut hasta kaydıyla eşleşiyor mu?
• Acil durumda erişilebilecek, vatandaş tarafından önceden belirlenmiş kritik bilgi var mı?

{
  "identity_verified": true,
  "insurance_eligible": true,
  "hospital_patient_id": "HSP-A-72F91...",
  "assurance_level": "high"
}

Hastane için kuruma veya sağlık sektörüne özel bir takma tanımlayıcı kullanılabilir. Sağlık kayıtlarının farklı kurumlar arasında devamlılığı ile kurumlar arası izlenebilirlik riski arasında dikkatli denge kurulmalıdır.

Acil durumda kullanıcı onayı alınamayabilir. “Break glass” erişimi ayrı yetki, gerekçe, güçlü log, sonradan vatandaşa bildirim ve bağımsız denetim gerektirmelidir.

2. Bankada müşteri edinimi

Bankalar müşteri tanıma ve finansal suçlarla mücadele yükümlülükleri nedeniyle yüksek güven seviyesinde kimlik doğrulamak zorundadır. Dijital cüzdan bu yükümlülükleri ortadan kaldırmaz; fakat veri toplama ve doğrulama akışını daha güvenli hâle getirebilir.

Banka aşağıdaki credential veya kanıtları isteyebilir:

• Temel kimlik doğrulandı,
• Ad ve soyad,
• Yaş şartı sağlandı,
• İkamet bilgisi doğrulandı,
• Kimlik belgesi geçerli,
• Cüzdan cihaz ve kullanıcıya bağlı,
• Gerekliyse T.C. kimlik numarası yetkili arka kanaldan alındı.

Mevzuat T.C. kimlik numarasının alınmasını gerektiriyorsa numara tamamen ortadan kaldırılamaz. Fakat vatandaşın numarayı web formuna yazması, belge görüntüsünü e-postayla göndermesi ve verinin çok sayıda ara sisteme kopyalanması engellenebilir.

3. E-ticarette yaş doğrulama

Yaş sınırı bulunan ürün veya hizmetlerde sitenin çoğu zaman tam doğum tarihini ve T.C. kimlik numarasını bilmesine gerek yoktur.

{
  "age_over_18": true,
  "issuer_trusted": true,
  "presentation_bound_to": "shop.example",
  "expires_in": 120
}

Sunum yalnızca ilgili site için ve kısa süreli üretilir. Başka bir siteye kopyalandığında çalışmaz. Kullanıcı hesabının devamlılığı gerekiyorsa siteye özel takma tanımlayıcı kullanılabilir.

4. Diploma ve öğrenci durumu

İşveren veya burs sağlayıcı PDF diploma istemek yerine üniversite ya da YÖK tarafından imzalanmış bir credential doğrulayabilir:

{
  "degree": "Bilgisayar Mühendisliği",
  "level": "Lisans",
  "graduation_verified": true,
  "issuer": "yetkili-universite",
  "status": "valid"
}

İşveren kişinin not dökümüne ihtiyaç duymuyorsa transkript paylaşılmaz. Öğrenci indirimi için yalnızca “aktif öğrenci” sonucu verilebilir; bölüm veya doğum tarihi açıklanmayabilir.

5. Araç kiralama ve sürücü yetkisi

Araç kiralama şirketi ehliyet görüntüsü yerine şu alanları doğrulayabilir:

• Sürücü belgesi geçerli,
• Gerekli araç sınıfı mevcut,
• Minimum yaş şartı sağlanıyor,
• Belge askıya alınmamış.

Şirketin adres, doğum yeri veya kimlik kartı seri numarası gibi işlemle ilgisiz alanları toplamasına gerek kalmaz. Çevrimdışı teslim noktalarında imza yerel olarak doğrulanabilir; iptal bilgisinin ne kadar güncel olması gerektiği risk politikasında belirlenir.

6. Otel ve konaklama

Otel, mevzuatın gerektirdiği kayıtları almak zorunda olabilir. Cüzdan yasal yükümlülüğü ortadan kaldırmaz; fakat resepsiyon görevlisinin belgeyi fotokopilemesi veya bilgilerinin elle yazılması yerine, yetkili alanların doğrulanmış biçimde aktarılmasını sağlayabilir.

Kullanıcı, paylaşım ekranında hangi alanların yasal zorunlulukla istendiğini ve ne kadar saklanacağını görmelidir.

7. Havayolu ve seyahat

Havayolu veya seyahat platformu:

• Rezervasyondaki kişi ile belge sahibinin eşleşmesini,
• Seyahat belgesinin geçerlilik durumunu,
• Gidilecek ülke için gerekli süre şartını,
• Belgenin yetkili ülke tarafından düzenlendiğini

doğrulayabilir. Uluslararası sınır kontrolü ve pasaport ibrazı devam eder; fayda, rezervasyon ve destek zincirindeki gereksiz belge kopyalarını azaltmaktır.

8. Kamu yardımı ve uygunluk kanıtı

Bir yardım programı kişinin bütün gelir ve aile kayıtlarını başvuru sistemine kopyalamak yerine yetkili kurumlardan şu sonucu alabilir:

{
  "program": "destek-programi-x",
  "eligibility_criteria_met": true,
  "valid_until": "2026-12-31"
}

Kararın açıklanabilir olması gerekir. Vatandaş hangi kriterlerin kullanıldığını görebilmeli, yanlış kaynağa itiraz edebilmeli ve yalnızca otomatik karara mahkûm edilmemelidir.

9. Şirket temsil yetkisi

Ticaret sicili veya yetkili kurum, kişiye süre ve işlem limiti içeren temsil credential’ı verebilir:

{
  "company": "Örnek A.Ş.",
  "role": "authorized_representative",
  "transaction_limit": "5000000 TRY",
  "valid_until": "2027-01-01",
  "status": "active"
}

Çalışan ayrıldığında veya yönetim kararı değiştiğinde credential iptal edilir. Banka, noter veya tedarikçi eski imza sirküsü PDF’ine güvenmek yerine güncel durumu doğrular.

10. Kamu binası ve fiziksel erişim

Ziyaretçi QR’ı içinde T.C. kimlik numarası bulunmaz. Bina sistemi yalnızca ziyaretin onaylı, zaman aralığının geçerli ve davet eden birimin doğru olduğunu kontrol eder.

Aynı credential’ın başka bina veya tarihte tekrar kullanılmasını önlemek için audience, nonce ve geçerlilik süresi kullanılmalıdır.

Kullanım senaryosu tasarlama şablonu

Her yeni kullanım senaryosu için şu tablo doldurulmalıdır:

• İş amacı nedir? — 18 yaş sınırını doğrulamak
• Minimum claim nedir? — age_over_18=true
• Issuer kimdir? — Yetkili kamu kimlik servisi
• Verifier kimdir? — Lisanslı e-ticaret platformu
• Kalıcı tanımlayıcı gerekli mi? — Hayır veya siteye özel PPID
• Çevrimiçi kontrol gerekli mi? — Risk politikasına göre
• Sunum süresi ne kadar? — 90–120 saniye
• Hangi kayıt tutulur? — Amaç, verifier, claim ve sonuç
• Fiziksel alternatif nedir? — Kimlik kartıyla görevli doğrulaması

İlk pilot için geliştirme örneği

En anlaşılır pilot 18 yaş doğrulamasıdır.

Issuer servisi

1. Sentetik vatandaş kaydı oluşturur.
2. Yaşı hesaplar.
3. age_over_18 claim’ini cüzdanın cihaz anahtarına bağlayarak imzalar.
4. Credential durum kaydını yayınlar.

Verifier uygulaması

1. İşlem için nonce üretir.
2. Yalnızca age_over_18 alanını isteyen imzalı talep hazırlar.
3. Talebi QR olarak gösterir.
4. Cüzdandan gelen sunumun issuer imzasını, audience, nonce ve süresini doğrular.

Mobil cüzdan

1. QR talebini okur.
2. Verifier’ın güvenilir ve yaş bilgisi istemeye yetkili olduğunu kontrol eder.
3. Kullanıcıya kurum, amaç ve paylaşılacak tek alanı gösterir.
4. Cihaz biyometrisi veya PIN ile onay alır.
5. Verifier ve nonce’a bağlı sunum üretir.
6. İşlem makbuzunu saklar.

Test edilmesi gereken olumsuz senaryolar

• QR ekran görüntüsünün yeniden kullanılması,
• Talebin başka verifier’a yönlendirilmesi,
• Süresi dolmuş credential,
• İptal edilmiş cihaz,
• Sahte issuer sertifikası,
• Yetkisiz verifier’ın sağlık verisi istemesi,
• Kullanıcının paylaşımı reddetmesi,
• Çevrimdışı verifier ve eski status bilgisi,
• Kayıp telefon kurtarma saldırısı,
• Erişilebilirlik modunda yanlış kullanıcı onayı.

Onay ile hukuki dayanak aynı şey değildir

Cüzdanın kullanıcıdan işlem onayı alması iyi bir şeffaflık ve güvenlik kontrolüdür. Ancak bu onay her zaman KVKK anlamında açık rıza değildir. Banka, hastane veya kamu kurumu veri işlemesini kanuni yükümlülük, sözleşmenin ifası veya başka geçerli işleme şartına dayandırabilir.

Cüzdan, hukuki dayanağı görünür kılmalı fakat mevzuat kararını kullanıcı arayüzündeki tek bir butona indirgememelidir.

Başarı ölçütleri

Pilotun başarısı indirilen uygulama sayısıyla değil şu göstergelerle ölçülmelidir:

• Toplanması önlenen T.C. kimlik numarası sayısı,
• Önlenen belge görüntüsü kopyası,
• Paylaşım başına açıklanan ortalama claim sayısı,
• Başarılı ve reddedilen sahte verifier talepleri,
• Kayıp cihaz iptal süresi,
• Çevrimdışı doğrulama başarı oranı,
• Erişilebilirlik ve kullanıcı anlama oranı,
• Veri ihlali durumunda açığa çıkan kişisel veri miktarı.

Bugün demoda çalışan senaryolar

Yukarıdaki sektör örnekleri hedef tasarımlardır; mevcut uygulamada gerçekleştirilen işlemler yalnızca sentetik demo paylaşımıdır. Ayrı ekranlar şu kapsamlarla çalışır:

• Banka — Demo işlemi: Hesap ön başvurusu; Örnek alanlar: Kimlik doğrulandı sonucu, ad-soyad, reşitlik ve seçili adres alanları
• Hastane — Demo işlemi: Hasta ön kaydı; Örnek alanlar: Ad-soyad, doğum tarihi, telefon, sağlık güvencesi durumu
• Belediye — Demo işlemi: Hemşehri başvurusu; Örnek alanlar: Kişisel bilgi ve seçili ikamet/adres alanları
• Market — Demo işlemi: Reşitlik doğrulaması; Örnek alanlar: Yalnızca 18 yaş eşiği sonucu
• Üniversite — Demo işlemi: Öğrenci avantajı; Örnek alanlar: Aktif öğrencilik ve üniversite adı
• Kargo — Demo işlemi: Teslimat paylaşımı; Örnek alanlar: Alıcı adı, telefon ve teslimat adresi
• Mobilite — Demo işlemi: Sürücü ön kontrolü; Örnek alanlar: Ad, yaş eşiği, sürücü belgesi geçerliliği ve sınıfı
• Sosyal destek — Demo işlemi: Hane özeti; Örnek alanlar: Hane büyüklüğü, çocuk sayısı, medeni durum

Örnek: Eren Baş Üniversitesi kendi talebini tasarlıyor

1. Kurum ve ayrı kullanıcı hesabı oluşturulur; kurum başlangıçta onay bekler.
2. “Öğrenci kayıt başvurusu” şablonu hazırlanır. Ad-soyad gerekli, telefon gerekli, il isteğe bağlı seçilebilir. Her alan için neden istendiği yazılır.
3. Yönetici kurumun alan yetkilerini, ardından şablon sürümünü onaylar.
4. Kurum hesabıyla giriş yapılarak onaylı senaryo seçilir; öğrencinin geçici cüzdan koduyla eşleştirilir.
5. Açık iPhone uygulaması talebi alır. Kullanıcı kurumun işlem QR’ını okutur, alanları seçer ve cihazıyla onaylar.
6. API kontrollerinden sonra SoftHSM sonucu imzalar; API açık anahtarla doğrular ve kuruma iletir.

Bu örnek yeni bir belge türü veya diploma üretmez; katalogda bulunan alanları isteyen bir verifier şablonudur. Kullanıcının gerekli alanı paylaşmaması durumunda sonuç incomplete olur. “Bilgi geldi” ile “işlem için yeterli bilgi geldi” ayrı sonuçlardır.

Bir hastane talebini market hesabından sürdürme denemesi HTTP 403 ile durdurulur ve ekranda nedeni gösterilir. Şablonu değiştirmek de eski talebin alanlarını genişletmez. Bu iki kontrol hem kullanıcı deneyiminin hem de sunucu yetkilendirmesinin parçasıdır.

Sonuç

Dijital kimlik cüzdanı tek bir uygulama değil, kamu ve özel sektör arasında yeni bir veri paylaşım sözleşmesidir. Hastane bütün kimliği değil sağlık uygunluğunu; alışveriş sitesi doğum tarihini değil yaş eşiğini; işveren diploma kopyasını değil doğrulanmış mezuniyeti almalıdır.

Başarılı sistem, vatandaştan daha fazla veri toplayan değil; aynı güveni daha az veriyle kurabilen sistemdir.

Resmî kaynaklar

• W3C Verifiable Credentials Data Model 2.0
• OpenID for Verifiable Presentations 1.0
• EU Digital Identity Wallet FAQ — Selective Disclosure
• NVI — Kimlik Paylaşımı Sistemi
• Kişisel Verileri Koruma Kurumu — Kişisel Veriler

Bu yazı genel teknik ve hukuki değerlendirme amacı taşır; sektör bazındaki veri işleme yükümlülükleri ayrıca incelenmelidir.