Polis, Kiralama Masaları, İşverenler, Sigortacılar: Neden Aynı Verileri Görmemelidir

Gelecekteki bir Uluslararası Sürücü Belgesi’nin (USB) tasarımında yapılabilecek en büyük hata, her doğrulayıcıya aynı doğrulayıcı gözüyle bakmak olurdu. Bir polis memuru, bir araç kiralama masası, bir işveren ve bir sigortacı aynı soruyu sormaz; dolayısıyla aynı yanıtı almamalıdır.

Tek bir sürücü. Araç kullanma hakkına dair tek bir temel kayıt. Tek bir cüzdan. Ama dört çok farklı doğrulayıcı:

• Yol kenarındaki bir polis memuru
• Araç tesliminde bir kiralama masası
• Filo uygunluğunu kontrol eden bir işveren
• Bir talebi inceleyen bir sigortacı

Gelecekteki USB aynı verileri dört tarafa da gösterirse sistem zaten başarısız olmuş demektir. Kimlik bilgisinin güvensiz olduğundan değil, ifşa modelinin fazla basit olduğundan.

Standartlar topluluğu bu basit modelden uzaklaşmaya zaten başladı. W3C’nin doğrulanabilir kimlik bilgileri çalışması; ihraç edenler, sahipler ve doğrulayıcılar etrafında şekillenen ekosistemi, doğrulayıcılara örnek olarak işverenleri ve web sitelerini göstererek tanımlıyor. AB’nin mobil sürücü belgesi çalışması ise yol kenarı denetimleri ile araç kiralamalarını; kiralamalar için uzaktan ön paylaşım ve polis için yüz yüze kontrol dahil olmak üzere, ayrı doğrulama senaryoları olarak ele alıyor. Mimari, birden fazla doğrulayıcı türü için tasarlanmış durumda. Yapılacak hata, kullanıcı deneyimini yalnızca bir tür doğrulayıcı varmış gibi tasarlamak olur.

Fiziksel Kart Bizi Neden Yanlış Düşünmeye Alıştırdı

Fiziksel bir ehliyet, bize her şeyi gösterme yaklaşımını alışkanlık hâline getirdi. Kartı uzatırsınız. Karşınızdaki kişi üzerinde ne yazıyorsa görür. Etkileşim bundan ibarettir.

Bu yaklaşım kâğıt dünyasında kabul edilebilir çünkü başka seçenek yoktur. Dijital dünyada ise kabul edilemez hâle gelir.

W3C VC Veri Modeli 2.0 doğrudan şunu belirtir: bir sürücü belgesi kimlik numarası, boy, kilo, doğum tarihi ve ev adresi içerebilir; ancak bu, belirli bir işlem için gerekenden çok daha fazlası olabilir. Mevcut standartlardan öne çıkan noktalar:

• W3C en iyi uygulaması: seçici ifşayı destekle ve yalnızca kesinlikle gerekli olanı talep et
• AB veri koruma rehberliği: işlem belirtilen amaçlarla sınırlandırılmalı ve işlenen veriler gerekli ve orantılı olmalıdır
• Gelecekteki USB’nin ilk ilkesi: aynı kimlik bilgisi, inceleme hakkının da aynı olduğu anlamına gelmez

Doğru Model: Politika Tabanlı İfşa

Ciddiye alınacak bir mimari istiyorsanız, doğru model dijital kart sunumundan çok nitelik tabanlı erişim denetimine daha yakındır.

NIST SP 800-205, erişim denetimi kararlarını politikaya karşı; konu, nesne, talep edilen işlem ve ortam koşullarıyla ilişkili niteliklerin değerlendirmeleri olarak tanımlar. Bu yapı, gelecekteki USB için tam olarak doğru çerçevedir:

• Konu: sürücü
• Nesne: talep edilen veri alanları
• Eylem: soyut anlamda “ehliyet görme” değil, “yol kenarında B kategorisi araç kullanma hakkını doğrulama” ya da “bir rezervasyon için kiralama uygunluğunu doğrulama” gibi özgül bir şey
• Ortam: yol kenarı, kiralama masası, uzaktan ön denetim, filo kayıt işlemi ve hasar sonrası talep incelemesi farklı ortamlardır; farklı kararlara yol açmalıdır

NIST ayrıca nitelik sistemlerinin ayrıntı düzeyi, yönetişim ve niteliklerin azaltılması, gruplanması ile en aza indirilmesi için mekanizmalar gerektirdiğini de vurgulamaktadır.

Bu nedenle gelecekteki USB şunu sormaktan vazgeçmelidir: Bu doğrulayıcı ehliyet okuyabilir mi? Şunu sormalıdır: Bu doğrulayıcı hangi talepleri alabilir, hangi amaçla, bu ortamda, hangi saklama kuralları çerçevesinde?

Bir Doğrulayıcı, Herhangi Bir Şey Talep Etmeden Önce Kendini Tanıtmalıdır

Gelecekteki USB, cüzdanın veri göstermesiyle başlamamalıdır. Doğrulayıcının kim olduğunu kanıtlamasıyla başlamalıdır.

EUDI mimarisi bu konuda açıktır. Bağımlı tarafların yapması gerekenler:

• Hangi nitelikleri hangi amaçla talep etmeyi düşündüklerini kayıt altına almak
• Erişim sertifikası almak
• Herhangi bir ifşadan önce cüzdana kimliklerini doğrulatmak
• Kayıt bilgisinin mevcut olduğu durumlarda, kayıtlı kapsamlarıyla karşılaştırılarak denetlenmek

Kullanıcı daha sonra kimin sorduğunu, neyin istendiğini ve talebin kayıtlı kapsam dahilinde olup olmadığını görebilir.

ETSI’nin güncel cüzdan-bağımlı taraf sertifikası çalışması bunu daha somut hâle getirir. Bir cüzdan-bağımlı taraf kayıt sertifikası, bağımlı tarafın amaçlanan kullanımını ve talep etmek üzere kayıt yaptırdığı nitelikleri tanımlayabilir. İlgili erişim sertifikası ise talebin meşru ve yetkili bir taraftan geldiğini güvence altına alır. ETSI ayrıca aşağıdaki gibi bağımlı taraf meta verilerini de kapsar:

• Ticari ad
• Destek URI’si
• Amaçlanan kullanım
• Yetkiler
• Sicil URI’si
• Denetleyici kurum bilgileri

Gelecekteki USB’nin ikinci ilkesi: doğrulayıcı kimliği yoksa ifşa da yok.

Onay Ekranları Neden Yeterli Değildir

Burada bir hata daha var: kullanıcı onayını yasal meşruiyetle aynı şey saymak.

EUDI mimarisi, niteliklerin sunulmasına ilişkin kullanıcı onayının bağımlı tarafın kişisel veri işlemesine yasal dayanak olarak kabul edilmemesi gerektiğini açıkça belirtir. Bağımlı tarafın yine de kendi yasal dayanağı olmalıdır. EUDI ayrıca, bağımlı tarafın kolluk kuvvetleri ya da başka bir kamu kurumu olduğu durumlar dahil, tüm kullanım senaryolarında kullanıcı onayını zorunlu kılar.

İyi bir cüzdan arayüzü yardımcı olabilir; ancak doğrulayıcı aşımını tek başına çözemez. Kural, arayüzden önce var olmalıdır.

Bu nedenle gelecekteki USB’nin ikisine birden ihtiyacı vardır:

• Kimin sorduğunu doğrulamak için kriptografik doğrulayıcı kimlik doğrulaması
• O doğrulayıcı kategorisinin neleri talep edebileceğine ilişkin politika kısıtlamaları

Her ikisi olmadan “kullanıcı seçimi”, politika başarısızlığını bireyin sırtına yıkmanın bir yoluna dönüşür.

1. Polis: Kişinin Tamamını Değil, Araç Kullanma Hakkını Doğrulayın

Polis yol kenarı senaryosu, odağı en dar olandır.

AB mDL kılavuzu bunu doğrudan şöyle açıklar: polis veya diğer yetkililer, ehliyet geçerliliği ve araç kategorisi yetkilendirmeleri dahil olmak üzere gerektiğinde ehliyet denetimi yapar. Kullanıcı yolculuğunda memur, QR tetiklemeli akış, Bluetooth, Wi-Fi Aware veya NFC aracılığıyla ehliyet doğrulaması gerçekleştirir. Bu odaklanmış bir doğrulama görevidir:

• Bu kişi belgenin sahibi mi?
• Kimlik bilgisi geçerli mi?
• Hangi araç kategorisi yetkilendirmeleri ve kısıtlamalar geçerli?

Varsayılan olarak izin verilenler:

• Ad soyad
• Fotoğraf
• Ehliyet durumu
• Düzenleme ve geçerlilik tarihleri
• Kategoriler
• Sürüşle ilgili kısıtlamalar
• İhraç eden kurum ve yetki alanı
• Güncellik/durum sonucu

Varsayılan olarak izin verilmeyenler:

• Ev adresi
• Yol kenarı kullanımı için gerekli olmayan dahili tanımlayıcılar
• Diğer belgelerden ilgisiz nitelikler
• Geçmiş sunum kayıtları
• Ticari meta veriler

AAMVA’nın uygulama rehberi, fotoğraf konusunu pekiştirir: fotoğraf talep edilirse ve başka bir unsur da paylaşılıyorsa, doğrulayıcının veriyi belgeyi sunan kişiyle ilişkilendirebilmesi için fotoğraf da paylaşılmalıdır. Aynı rehber ayrıca paydaşların kanunun gerektirdiği durumlar dışında mDL sahiplerini veya mDL kullanımını takip etmemesi gerektiğini belirtir.

Polis senaryosu, devletin her şeye erişmesiyle ilgili değildir. Devletin yol kenarı denetimi için gereken sürüşe özgü verilere erişmesiyle ilgilidir. Bu önemli bir farktır.

2. Kiralama Masaları: Uygunluk, Kimlik Eşleşmesi ve Gereksiz Hiçbir Şey

Kiralama senaryosu daha ayrıntılıdır; zira burada gerçekte iki ayrı an söz konusudur: varmadan önce uzaktan ön denetim ve anahtarların teslim edildiği alım anı.

AB mDL kılavuzu her ikisini de modellemektedir. Bir araç kiralama şirketi, rezervasyon sırasında kimlik belgesiyle birlikte mDL talep edebilir, belgeleri doğrulayabilir ve aracı teslim etmeden önce müşteriyi alım noktasında yüz yüze doğrulayabilir. Kullanıcılar mDL’lerini araç kiralama şirketleriyle yüz yüze ya da önceden uzaktan paylaşabilir.

Bir kiralama masasının öncelikli amacı olayı araştırmak değildir. Şunu karara bağlaması gerekir: Bu aracı bu müşteriye, bu rezervasyon ve poliçe kapsamında kiralayabilir miyim?

Uzaktan ön denetim şunları içermelidir:

• Kimlik bağlantısı
• Fotoğraf veya eşdeğer kimlik bağlama unsuru
• İlgili araç kategorisi
• Düzenleme ve geçerlilik tarihleri
• Güncel geçerlilik
• Muhtemelen bir yaş eşiği veya yaş aralığı

Alım noktasında şunlar teyit edilmelidir:

• Belge sahibinin ön denetimi tamamlayan kişiyle aynı olduğu
• Güncel geçerlilik
• İlgili yetkilendirmeler

Varsayılan olarak gerekmeyenler:

• Rezervasyon profilinde iletişim bilgileri zaten mevcut olduğunda tam ev adresi
• Yaş üstü veya yaş aralığının yeterli olduğu durumlarda tam doğum tarihi
• İlgisiz kimlik nitelikleri
• Bir rezervasyon belgesi zaten mevcutsa tam kimlik bilgisinin tekrar tekrar sunulması

NIST’in güncel mDL mimarisi, bağımlı tarafın yalnızca gerekli nitelikleri talep etmek için DCQL kullandığını göstermekte ve bunun, talebi tek bir birim olarak ele almak yerine yapılandırarak veri minimizasyonunu ve sahip onayını desteklediğini açıkça belirtmektedir. AAMVA ise uygulamanın hangi verilerin istendiğini ve doğrulayıcının bu bilgileri saklayıp saklamayacağını açıkça göstermesi gerektiğini eklemektedir.

3. İşverenler: Bir Doğrulayıcı Kategorisi, Tam Kimliğe Açılan Bir Kapı Değil

W3C’nin genel bakışı, bir işverenin dijital sisteminin üniversite diplomasını doğruladığı senaryoyu doğrulayıcı örneği olarak kullanmaktadır. Bu, işveren doğrulamasının kimlik bilgisi ekosistemlerinde zaten tanınan bir örüntü olduğunu hatırlatır.

Bir işveren veya filo operatörünün meşru olarak bilmesi gereken şeyler şunlar olabilir:

• Çalışanın belirli araç kategorilerini kullanmaya hâlihazırda yetkili olup olmadığı
• Önemli kısıtlamaların bulunup bulunmadığı
• Yetkilendirmenin geçerliliğini sürdürüp sürdürmediği

Bu gerçek bir iş ihtiyacıdır. Ancak bu durum, tüm sürücü belgesine, tam kimlik verilerine veya sürekli tekrarlanan sunumlara kalıcı erişimi otomatik olarak meşrulaştırmaz.

NIST, yeniden kullanılabilir bir tanımlayıcının sık sık iletilmesinin ve kullanıcıların kimlik taşıyan bir kimlik bilgisini tekrar tekrar sunmaya koşullandırılmasının istenmeyen bir durum olduğunu vurgular; günlük kimlik doğrulamanın, parolalar yerine geçiş anahtarları gibi bu amaç için tasarlanmış teknolojilere dayandırılması gerektiğini belirtir. NIST, gizliliği daha iyi koruduğu gerekçesiyle sunucu taraflı biyometrik eşleştirme yerine yerel cihaz kimlik doğrulamasını tercih etmektedir.

Gelecekteki USB, bir işyeri erişim kartına dönüşmemelidir.

İşveren ve filo kullanımı için doğru örüntü genellikle şudur:

• İşle ilgili yetkilendirme denetimi
• Belki dönemsel uyumluluk belgesi
• Belki belge sahibinin belirtilen kategoriler için geçerliliğini koruduğuna dair bir talep
• Ancak çalışanın bir sisteme her giriş yaptığında ya da vardiyaya başladığında tüm ehliyet verilerinin varsayılan olarak aktarılması değil

Filo uyumluluğu, ayrı bir amaçlanan kullanımı ve ayrı bir ifşa profiline sahip, ayrı bir bağımlı taraf kategorisidir.

4. Sigortacılar: Tazminat Talepleri, Sürekli Görünürlük İzni Değildir

Sigorta davası çoğu zaman gerçek bir durumdur. AB mDL kullanım senaryosu materyallerinde sigortacılar, kiralama senaryosunda dolaylı biçimde yer alır: sigorta şirketleri, araç kiralama şirketlerinden aracı kiralayan kişinin araç kullanma hakkına sahip olup olmadığını kontrol etmelerini ister. Sigorta, sürücü doğrulama akışını zaten etkiliyor.

Ancak bu, bir sigortacının polisle aynı verileri alması ya da kimlik belgesine kalıcı erişim hakkı edinmesi anlamına gelmez.

Gelecekteki USB, sigortacıları ayrı amaçlanan kullanımlara sahip ayrı bir doğrulayıcı kategorisi olarak ele almalıdır:

• Poliçe değerlendirmesi
• Kiralama riski doğrulaması
• Hasar sonrası tazminat işlemi
• Dolandırıcılık incelemesi

Bunlar aynı amaç değildir. AB veri koruma ilkeleri çerçevesinde kişisel veriler belirtilen amaçlar doğrultusunda toplanmalı ve bu amaç için gerekli ve orantılı olanla sınırlı tutulmalıdır. W3C’nin VC rehberliği de teknik açıdan aynı sonuca ulaşır: doğrulayıcılar yalnızca kesinlikle gerekli olanı talep etmelidir.

Meşru, olaya özgü örnekler:

• Ehliyetin ilgili anda geçerli olduğunun kanıtı
• İlgili araç kategorisi yetkisinin kanıtı
• Tazminat talebi için gerekli olduğu durumlarda kimlik bağlantısının kanıtı
• Talebe özgü ifşa

Varsayılan olarak izin verilmeyenler:

• Temel kimlik belgesine kalıcı erişim
• Müşterinin sigortacıyla her etkileşiminde tekrarlanan genel doğrulama
• Sürücü belgesinin giriş jetonu olarak kullanılması
• İlgisiz niteliklerin toplanması

Bir sürücü belgesi, izleme aboneliği değildir. Ve sessiz sedasız buna dönüşmemelidir.

Aracıların Neden Görünür Olması Gerekir

Gerçek piyasalar aracıları kapsar. Kiralama platformları, filo tedarikçileri, işveren İK sistemleri ve sigorta tazminat işlemcileri çoğu zaman üçüncü taraflar aracılığıyla hareket eder.

EUDI mimarisi bunu şu yollarla çözer:

• Aracıları bağımlı taraf olarak tanımlamak
• Kayıt olmalarını zorunlu kılmak
• Aracılı bağımlı taraf adına talep edilen niteliklerin kayıtlı olmasını şart koşmak
• Hem aracıyı hem de son bağımlı tarafı kullanıcıya göstermek
• Aracıların işlemin içeriğine ilişkin verileri saklamamasını yasaklamak

Gelecekteki USB, kullanıcının kiralama şirketine ifşa ettiğini sandığı hâlde gerçekte görünmez bir doğrulama komisyoncusuna, analitik işlemciye ve tazminat satıcısı zincirine ifşa ettiği bir örüntüye asla izin vermemelidir.

ETSI bu noktada devreye girer. Cüzdan-bağımlı taraf sertifika modeli; destek URI’lerini, amaçlanan kullanımı, sicil URI’lerini ve denetleyici kurum meta verilerini kapsar. Kullanıcıların talebin karşı tarafında gerçekte kimin bulunduğunu anlamaları ve silme ya da düzeltme istediklerinde nereye başvuracaklarını bilmeleri için gereken makine tarafından okunabilir altyapı işte budur.

Saklama, Erişim Denetiminin Bir Parçasıdır

Seçici ifşa hakkındaki tartışmaların çoğu çok erken sona erer. Neyin ifşa edildiğine odaklanır. Bunun ardından ne kadar süre kaldığına yeterince odaklanmaz.

Mevcut rehberlik zaten birbirine yaklaşıyor:

• AAMVA: cüzdan, hangi verilerin istendiğini ve doğrulayıcının bu bilgileri saklayıp saklamayacağını belge sahibine açıkça bildirmelidir; paydaşlar, kanunun gerektirdiği durumlar dışında belge sahiplerini veya mDL kullanımını takip etmemelidir
• W3C: sahip yazılımı, aşırı taleplerin tespit edilebilmesi için doğrulayıcılarla paylaşılan bilgilerin günlüklerini sunmalıdır
• EUDI: kullanıcılar işlem günlüklerine erişebilmeli, şüpheli talepleri raporlayabilmeli ve silme talep edebilmelidir

Saklama sınıfı, ifşa politikasının kendisinin bir parçası olmalıdır:

• Polis yol kenarı: yasal operasyonel kayıt dışında varsayılan olarak saklama yapılmaz
• Kiralama ön denetimi: yeniden kullanılabilir bir kimlik kopyası değil, rezervasyona bağlı işlem kaydı
• İşveren filo uyumluluğu: ham kimlik bilgisi verisi değil, uyumluluk kaydı veya belge sonucu
• Sigortacı tazminat talebi: kalıcı erişim değil, talep kapsamıyla sınırlı talep kaydı

Saklama sorununu görmezden gelen bir USB, yalnızca kısmen gizlilik koruyucudur.

Cüzdanın Gerçekte Neye Karar Vermesi Gerekir

Bu makalenin tamamını tek bir uygulama kuralına indirgemem gerekseydi şunu seçerdim:

Cüzdan “Bu kimlik bilgisini sunabilir miyim?” sorusunu yanıtlamamalıdır. “Bu talep kümesini, bu kimliği doğrulanmış doğrulayıcıya, bu amaçlanan kullanım için, bu bağlamda, bu saklama sınıfı kapsamında sunabilir miyim?” sorusunu yanıtlamalıdır.

Bu karar en az şu girdilere dayanmalıdır:

• Doğrulayıcı kimliği
• Doğrulayıcı kategorisi
• Amaçlanan kullanım
• Kayıtlı nitelik kapsamı
• Varsa ihraç edenden gelen ifşa politikası
• Ortam (yol kenarı, teslim alma, uzak bağlantı, filo, tazminat talebi)
• Sahip onayı
• Geçerli saklama politikası

Standartlar bu mekanizmanın büyük bölümünü zaten içeriyor: seçici ifşa, bağımlı taraf kimlik doğrulaması, kayıtlı amaçlanan kullanım, erişim sertifikaları, ifşa politikası değerlendirmesi ve amaca bağlı talepler. Hâlâ eksik olan şey, bu parçaları tek bir tutarlı ifşa mimarisi olarak ele alma disiplinidir.

Temel Argüman

Gelecekteki USB, verinin ifşa edilip edilemeyeceğini sormaktan vazgeçmelidir. Şunu sormalıdır:

• Kim soruyor?
• Hangi amaçla?
• Hangi yetkiye dayanarak?
• Hangi bağlamda?
• Ne tür saklama sonuçlarıyla?

Polis, kiralama masaları, işverenler ve sigortacılar, bir talebin karşı tarafında yer alan dört logo değildir. Bunlar dört farklı risk modeli, dört farklı hukuki bağlam, dört farklı soru sorma nedenidir; ve dört farklı ifşa kümesi üretmelidir.

Bu gereksiz karmaşıklık değildir. Her doğrulayıcıya aynı doğrulayıcı gözüyle bakmaktan vazgeçildiğinde, modern bir sürücü belgesinin nasıl göründüğü budur.