Geleceğin UEB'inin Arkasındaki Yığın: Kâğıt İzni Değiştirmek İçin Neden Katmanlı Bir Standartlar Mimarisi Gerekiyor?

Tek bir standart, kâğıt Uluslararası Ehliyet Belgesinin (UEB) yerini alamaz. Gerçek halef, birlikte çalışan standartların oluşturduğu bir yığındır; bu yığını anlamak, sınır ötesi dijital sürücü kimlik bilgilerinin gerçekte nereye gittiğini anlamanın da anahtarıdır.

Neden Tek Bir Standart Kâğıt UEB’in Yerini Alamaz?

Gelecekteki UEB’e ilişkin çoğu tartışma yanlış bir soruyla başlar: Kâğıt izni hangi standart değiştirecek? Bu çerçeve, tek bir spesifikasyonun tüm işi yapabileceğini varsayar. Oysa yapamaz.

NIST’in mDL (mobil sürücü belgesi) çalışmaları, farklı sorun alanlarında yeni dijital kimlik bilgisi standartlarının ortaya çıktığını açıkça belirtmektedir. ISO 18013 ailesi zaten fiziksel tasarım, güvenlik, mobil sunum ve internet uzantılarını kapsayan birden fazla bölüme ayrılmış durumdadır. Gelecekteki sınır ötesi sürücü kimlik bilgisi bu nedenle tek bir spesifikasyon değil; her biri ayrı bir sorunu ele alan, koordineli bir spesifikasyon yığınıdır.

Gelecekteki UEB Yığınına Genel Bakış

İşte bir arada değerlendirildiğinde gelecekteki UEB’in neye benzediğini tanımlayan sekiz katman:

Katman 0 — Fiziksel ve veri temeli: ISO/IEC 18013-1
Katman 1 — Kimlik bilgisi güvenliği: ISO/IEC 18013-3
Katman 2 — Yakınlık (yüz yüze) sunumu: ISO/IEC 18013-5
Katman 3 — Uzaktan / internet sunumu: ISO/IEC 18013-7
Katman 4 — Kimlik bilgisi semantiği: W3C Doğrulanabilir Kimlik Bilgileri Veri Modeli 2.0
Katman 5 — Düzenleme protokolü: OpenID4VCI
Katman 6 — Talep ve sunum protokolü: OpenID4VP
Katman 7 — Güven dağıtımı ve doğrulayıcı yetkilendirmesi: Güven kayıt defterleri (AAMVA’nın VICAL modeli, EUDI sertifika tabanlı bağımlı taraf modeli)

Her katman, mevcut standartlara veya aktif ekosistem belgelerine dayanmaktadır. Aşağıdaki bölümler her katmanın ne yaptığını — ve en az o kadar önemli olan, ne yapmadığını — açıklamaktadır.

Katman 0 — ISO/IEC 18013-1: Fiziksel ve Anlamsal Temel

Bölüm 1, çoğu insanın fark ettiğinden daha önemlidir; çünkü yalnızca kart tasarımıyla ilgili değildir.

ISO/IEC 18013-1, ISO uyumlu bir sürücü belgesinin fiziksel özelliklerini ve temel veri setini tanımlayarak uluslararası kullanım ve karşılıklı tanıma için ortak bir zemin oluşturur. Standart, uluslararası kullanım için bir kitapçıkla eşleştirilen güvenli bir ID-1 kartı etrafında kurgulanmış olup eski kâğıt UEB modelinin yerini almaktadır. ISO ayrıca pek çok durumda tek bir kartın iki ayrı belgeye duyulan ihtiyacı ortadan kaldırabileceğini belirtmektedir.

Pratik çıkarım basittir: Gelecekteki UEB, cüzdan katmanından başlayamaz. Temel belge yapısı, veri modeli ve düzen önce standartlaştırılmazsa, üstteki her dijital katman parçalı ulusal formatlar üzerindeki bir uyumluluk yamasına dönüşür. Bölüm 1, yığının geri kalanının bağlı olduğu temeldir.

Katman 1 — ISO/IEC 18013-3: Kimlik Bilgisi Güvenliği

Bölüm 3, kimlik bilgisinin bir belgedeki veriden güvenlik nesnesine dönüştüğü noktadır. ISO, 18013-3’ü aşağıdakiler için mekanizmaları belirleyen bölüm olarak tanımlar:

Makine tarafından okunabilir verilere erişim kontrolü
Belge kimlik doğrulaması
Bütünlük doğrulaması

Bununla birlikte ISO, Bölüm 3’ün verilerin sonraki kullanımına ilişkin gizlilik sorunlarını ele almadığını açıkça belirtmektedir — ve bu sınır önemlidir.

Özetle, 18013-3 kimlik bilgisi güvenliği sağlar; tam ekosistem yönetişimi sağlamaz. Şu soruların yanıtlanmasına yardımcı olur: Bu kimlik bilgisi, iddia edilen otorite tarafından mı düzenlendi? Veriler değiştirildi mi? Şu soruları tam olarak yanıtlamaz: Bu doğrulayıcının bu alanı talep etmesi gerekir mi? Bu talebe bu bağlamda izin verilmeli mi?

Bu ayrıca tamamlanmış bir ürün olmaktan çok aktif bir katmandır. ISO, PACE protokolü için 2022 tarihli bir değişikliği, pasif kimlik doğrulama güncellemeleri için 2023 tarihli bir değişikliği ve şu anda geliştirme aşamasında olan 18013-3’ün yeni bir taslağını listelemektedir.

Katman 2 — ISO/IEC 18013-5: Yüz Yüze Mobil Sunum

Bölüm 1 belgeyi tanımlarken ve Bölüm 3 onu güvence altına alırken, Bölüm 5 ehliyet belgesini mobil bir kimlik bilgisine dönüştürür.

ISO, 18013-5’in mDL ile okuyucu arasındaki ve okuyucu ile düzenleyici otorite altyapısı arasındaki arayüzü kapsadığını belirtmektedir. Ayrıca diğer ülkelerdeki yetkililer ve doğrulayıcılar dahil olmak üzere üçüncü tarafların şunları yapmasına olanak tanır:

mDL verilerini makine aracılığıyla edinme
Bu verileri belge sahibiyle ilişkilendirme
Kaynağını doğrulama
Bütünlüğünü kontrol etme

18013-5’in kapsamadıkları da bir o kadar önemlidir. ISO, kapsam dışı kalan maddeleri açıkça sıralamaktadır: bunlar arasında belge sahibinin veri paylaşımına onay vermesinin nasıl sağlandığı ve mDL verilerinin ile özel anahtarların depolanmasına ilişkin gereklilikler yer almaktadır. Bölüm 5, eksiksiz bir cüzdan ürünü, eksiksiz bir kullanıcı onay modeli veya eksiksiz bir yönetişim sistemi değildir. Mobil sunum için taşıma ve doğrulama katmanıdır.

AAMVA’nın uygulama kılavuzu, iki alma modelini birbirinden ayırt ederek bu noktayı daha da netleştirmektedir:

Verilerin doğrudan belge sahibinin cihazından okunduğu cihazdan alma.
Düzenleyici otoritenin mDL’nin ne zaman kullanıldığını, hangi verilerin paylaşıldığını ve hatta IP analizi yoluyla fiziksel konumu tahmin etmesine olanak tanıyabilen sunucudan alma.

Bu ikinci nokta, standardı reddetmek için değil; gelecekteki bir UEB’in varsayılan olarak hangi alma modelini kullanması gerektiği konusunda kesin olmak için bir nedendir. AAMVA ayrıca cüzdanın belge sahibine hangi veri unsurlarının paylaşılacağı üzerinde tam kontrol vermesini zorunlu kılmaktadır; bu durum, eski “belgenin tamamını göster” modeline kıyasla gelecekteki bir UEB için çok daha uygundur.

Katman 3 — ISO/IEC 18013-7: İnternet Sunumu

Bölüm 5 yüz yüze sorunu çözerken, Bölüm 7 bu modeli uzaktan kullanıma genişletir.

ISO, 18013-7:2025’i bir mDL’nin okuyucuya internet üzerinden sunulması amacıyla 18013-5’i genişleten bölüm olarak tanımlamaktadır. İnternet bu mimaride ikincil bir unsur değil; standardın açık bir parçasıdır.

AB’nin mobil sürücü belgesi el kitabı, internet sunumunu teorik değil pratik bir konu olarak ele almakta ve şu gibi senaryoları açıklamaktadır:

Kullanıcıların mDL’lerini yüz yüze veya önceden uzaktan paylaştıkları araç kiralama check-in işlemleri
Polis tarafından yol kenarı kontrolleri
ISO/IEC 18013-5 ve 18013-7 üzerine inşa edilmiş genel bir mDL kullanım profili

Bununla birlikte AAMVA’nın mevcut kılavuzu sınırlamalar konusunda dürüsttür: İnternet üzerinden mDL kullanımı son derece arzu edilir, ancak bazı destekleyici standartlar olgunlaşmaya devam etmektedir. Mevcut cüzdan-tarayıcı entegrasyonunda gerçek boşluklar mevcuttur ve güvenilir okuyucuların bir listesi olmaksızın mdoc tarafının belirli güvenlik özelliklerini doğrulamak için güvenilir bir yolu bulunmayabilir. Uzaktan sunum gerçektir — ve gelişmeye devam etmektedir.

Tüm bu çekincelere rağmen, 18013-7, kâğıt UEB’in hiç çözmeye çalışmadığı bir soruna verilen ilk ciddi yanıttır: Sürücülük yetkilerini kişi sayaca ya da kontrol noktasına ulaşmadan önce uzaktan sunmak.

Katman 4 — W3C VC Veri Modeli 2.0: Semantik Katman

W3C’nin Doğrulanabilir Kimlik Bilgileri Veri Modeli 2.0, bir sürücü belgesi standardı değildir — ve bu, tam da neden önemli olduğunu açıklar.

Tavsiye, doğrulanabilir kimlik bilgileri için genişletilebilir bir veri modeli tanımlamakta, bunların değişikliğe karşı nasıl korunabileceğini açıklamakta ve ekosistemi üç temel rol açısından ele almaktadır: düzenleyiciler, belge sahipleri ve doğrulayıcılar. Sürücü belgesi, temel örneklerinden biri olarak yer almaktadır.

Gelecekteki bir UEB için VC 2.0, iddialar, sunumlar ve doğrulanabilir veri kayıt defterleri için genel bir söz dağarcığı sağlar. W3C, bu tür kayıt defterlerinin aşağıdakiler dahil çeşitli biçimlerde olabileceğini açıkça belirtir:

Güvenilir veritabanları
Devlet kimlik veritabanları
Merkezi olmayan veritabanları
Dağıtık defterler

Bu durum, yalnızca blok zinciri yaklaşımı ile tamamen özel bir yaklaşım arasındaki yanlış ikilemi ortadan kaldırmaktadır. Veri modeli her ikisinden de daha kapsamlıdır.

VC 2.0 ayrıca seçici açıklama konusunda da nettir. W3C, bir sürücü belgesinin belirli bir kullanım durumu için gerekenden fazla veri taşıyabileceğini belirtmekte ve bilgilerin daha küçük parçalara bölünmesini ya da seçici açıklamayı mümkün kılan mekanizmaların kullanılmasını önermektedir. Gelecekteki bir UEB için bu, isteğe bağlı bir gizlilik kolaylığı değil; modern bir kimlik bilgisi ile plastik bir kartın dijital fotokopisi arasındaki farktır.

Bununla birlikte VC 2.0, ISO 18013’ün tam anlamıyla yerini alamaz. W3C, veri modelinin geleneksel bir sertifika otoritesi güven zinciri modelini gerektirmediğini vurgulamaktadır. Pratikte VC 2.0 güçlü bir semantik katmandır; ancak açık güven dağıtımı ve doğrulayıcı yönetişim katmanlarının üzerine eklenmesi hâlâ gerekmektedir.

Katman 5 — OpenID4VCI: Düzenleme Protokolü

Gelecekteki bir UEB’in, bir kimlik bilgisini düzenleyiciden cüzdana taşımak için standart bir yola ihtiyacı vardır. Bu, Doğrulanabilir Kimlik Bilgisi Düzenlemesi için OpenID’nin (OpenID4VCI) 1.0 rolüdür.

Spesifikasyon, doğrulanabilir kimlik bilgileri düzenlemek için OAuth korumalı bir API tanımlar ve kasıtlı olarak formattan bağımsızdır. Desteklediği kimlik bilgisi formatları arasında şunlar yer almaktadır:

ISO mdoc
SD-JWT VC
W3C VCDM kimlik bilgileri

Ayrıca belge sahibi bağlamasını ve düzenleyicinin daha fazla müdahalesi olmaksızın sonraki sunumları da desteklemektedir. OpenID4VCI 1.0, Eylül 2025’te Nihai Spesifikasyon olarak onaylanmıştır.

Bu durum, OpenID4VCI’yi gelecekteki bir UEB ekosistemi için stratejik açıdan önemli kılmaktadır. Her yetki alanı veya cüzdan sağlayıcısı için özel düzenleyici-cüzdan iletişim hatları oluşturmak yerine ekosistem, sonuçta ortaya çıkan kimlik bilgisinin mdoc, VC veya desteklenen başka bir formatta kodlanıp kodlanmayacağını seçme esnekliğini korurken standart bir düzenleme çerçevesi üzerine yönetilen bir düzenleme profili tanımlayabilir. Bu esneklik, gelecekteki UEB yığınını modüler tutmanın en güçlü gerekçelerinden biridir.

Katman 6 — OpenID4VP: Talep ve Sunum Protokolü

OpenID4VCI kimlik bilgisini cüzdana taşırken, Doğrulanabilir Sunumlar için OpenID (OpenID4VP) onu kontrollü bir şekilde geri çıkarır.

Spesifikasyon, kimlik bilgilerini talep etmek ve sunmak için bir mekanizma tanımlar. Temel kullanımı HTTPS iletileri ve yönlendirmelere dayanmakla birlikte, yönlendirme akışları yerine W3C Dijital Kimlik Bilgileri API’si üzerinden kullanımı da desteklemektedir. OpenID4VP 1.0, Temmuz 2025’te Nihai Spesifikasyon statüsüne ulaşmıştır.

Bu önemlidir; çünkü gelecekteki UEB yığınına, web sitelerinin, uygulamaların ve çevrimiçi doğrulayıcıların doğrudan uygulayabileceği web’e özgü bir sunum katmanı kazandırır. Bu durumu pekiştiren birkaç son gelişme şöyle sıralanabilir:

Ağustos 2025’te OpenID Vakfı, Dijital Kimlik Bilgileri API’si üzerinden kullanılan OpenID4VP’nin resmi bir güvenlik analizini duyurdu; doğrulanan protokol modelinde yeni bir güvenlik açığı bulunmadığı açıklandı.
NIST’in mevcut mDL taslağı, tehdit modelini W3C Dijital Kimlik Bilgileri API’si üzerinden OpenID4VP aracılığıyla mDL talep etme ve sunma işlemleri etrafında oluşturmakta; ilgili akışlarda yakınlığı zorlamak ve kimlik avına karşı direnmek için FIDO CTAP’ı kullanmaktadır.

Yığının web tarafı ile mDL tarafı yakınsamaktadır. OpenID4VP, ISO 18013-7’nin rakibi olarak değil; gerçek dünya tarayıcı, cüzdan ve doğrulayıcı ortamlarında internet sunumunu pratik kılan web protokolü katmanı olarak okunmalıdır.

Katman 7 — Güven Kayıt Defterleri: Yığının Ekosisteme Dönüştüğü Yer

Bu, pek çok tartışmanın atladığı katmandır — ve tüm sistemin gerçekten çalışıp çalışmayacağını belirleyen katmandır.

Bir doğrulayıcı, imzalı bir kimlik bilgisiyle üç şeyi bilmeden fazla bir şey yapamaz:

Hangi düzenleyicilerin meşru olduğu
Hangi açık anahtarların güncel olduğu
Talepte bulunan tarafın kendisinin yetkilendirilip yetkilendirilmediği

Düzenleyici tarafında AAMVA’nın Dijital Güven Hizmeti somut bir yanıt sunmaktadır. Bağımlı taraflara düzenleyici otorite açık anahtarlarını edinmeleri için tek, güvenli ve dayanıklı bir yol sağlamakta; bu anahtarlar Doğrulanmış Düzenleyici Sertifika Otoritesi Listesi (VICAL) aracılığıyla dağıtılmaktadır. AAMVA’nın kılavuzu VICAL sağlayıcısının rolünü pratik terimlerle şöyle tanımlamaktadır: meşru düzenleyici otoritelerden açık anahtarlar toplamak, bu otoritelerin anahtarlarını güvenli biçimde yönetip yönetmediğini doğrulamak, anahtarları tek bir VICAL’de birleştirmek ve doğrulayıcılara iletmek.

Doğrulayıcı tarafında ise Avrupa, güven sorununa farklı bir yönden yaklaşmaktadır. EUDI Mimarisi ve Referans Çerçevesi’nde bağımlı taraflar kayıt yaptırmakta, erişim sertifikaları edinmekte ve öznitelikleri talep ederken bu sertifikaları cüzdan uygulamalarına kendilerini doğrulamak için kullanmaktadır. Cüzdan ardından sertifika zincirini doğrular, iptal durumunu kontrol eder, talebi kullanıcıya sunar ve yalnızca onaylanan öznitelikleri paylaşır.

W3C’nin VC modeli de burada katkı sağlamakta; doğrulanabilir veri kayıt defterlerini ayrı bir ekosistem rolü olarak ele almaktadır. Daha önce belirtildiği gibi, bu kayıt defterleri güvenilir veritabanları, devlet kimlik veritabanları, merkezi olmayan veritabanları veya dağıtık defterler olabilir. Gelecekteki bir UEB güven kayıt defterinin blok zinciri üzerine kurulması şart değildir. Yönetilen, denetlenebilir ve makine tarafından okunabilir olması gerekmektedir.

ISO 18013 kimlik bilgisinin nasıl göründüğünü ve iletildiğini tanımlarken, güven kayıt defterleri ona kimin inanması gerektiğine karar verir.

Gelecekteki UEB tek bir spesifikasyon değil, bir yığındır

Gelecekteki Bir UEB İşlemi Uçtan Uca Nasıl İşler?

İşte bir kimlik bilgisinin yaşam döngüsünün dört temel anına ayrılmış yığın uygulaması.

1. Düzenleme. Ulusal bir otorite — ya da sıkı biçimde yönetilen yetkili bir düzenleyici — temel lisans kaydını doğrular ve belge sahibinin cüzdanına bir kimlik bilgisi düzenler. OpenID4VCI, ISO mdoc, SD-JWT VC ve W3C VCDM formatlarını zaten desteklediğinden günümüzde mevcut en pratik düzenleme katmanıdır. ISO 18013-5’in kendisi onay toplama ve özel anahtar depolamayı kapsam dışında bırakmaktadır; bu da neden düzenleme ve cüzdan yönetişiminin temel ISO taşıma katmanının üzerinde çalışması gerektiğini açıklar.

2. Yüz yüze sunum. Yol kenarı denetiminde veya kiralama masasında cüzdan, 18013-5 tabanlı bir yakınlık akışı kullanarak kimlik bilgisini sunar. Okuyucu, güven kararlarını kendi başına almak yerine bir güven kayıt defterinden edinilen düzenleyici anahtarlarını kullanarak kaynağı ve bütünlüğü doğrular. Belge sahibi yalnızca o duruma özgü alanları onaylar.

3. Uzaktan sunum. Ön kiralama kontrolleri veya diğer çevrimiçi süreçler için doğrulayıcı, 18013-7 ve/veya OpenID4VP kullanarak internet özellikli bir akış üzerinden minimum düzeyde öznitelik talep eder. Cüzdan hangi özniteliklerin istendiğini gösterir, belge sahibi onaylar ve doğrulayıcı tarama veya PDF yüklemesi yerine yapılandırılmış bir sunum alır. OpenID4VP ile Dijital Kimlik Bilgileri API’si üzerine kurulu NIST’in mevcut mimarisi, bunun artık pratik bir mühendislik yolu olduğunu ortaya koymaktadır.

4. Güven ve doğrulayıcı yetkilendirmesi. Cüzdan her talep edene körü körüne güvenmez. Olgun bir ekosistem bağımlı tarafın kimliğini doğrular, sertifika zincirlerini geçerlilik açısından inceler, iptal durumunu kontrol eder ve kullanıcıya kimin hangi verileri istediğine dair görünürlük sağlar. EUDI modeli bu noktada özellikle güçlüdür; doğrulayıcı kaydını ve erişim sertifikalarını isteğe bağlı eklentiler yerine sistemin temel parçaları olarak ele almaktadır.

Bu eksiksiz akış, gelecekteki bir UEB’in neden bir yığın olması gerektiğini tam olarak açıklamaktadır. Hiçbir tek katman bunu tek başına sunamaz. Ne ISO tek başına. Ne VC tek başına. Ne OpenID tek başına. Ve kesinlikle bir forma ekli bir PDF ile değil.

Gelecekteki UEB Yığınında Hâlâ Eksik Olanlar

Geri kalan en zor sorun artık yeni kriptografi geliştirmek değil, yönetilen birlikte çalışabilirliği sağlamaktır.

Ekosistemin bugün bulunduğu durumu ele alalım:

NIST, mevcut standartlar ortamını ayrı alanlarda gelişmekte olarak tanımlamaktadır.
AAMVA, Kuzey Amerika için bölgesel bir güven hizmeti oluşturmuştur.
Avrupa, cüzdan mimarisine sertifika tabanlı bağımlı taraf güvenini entegre etmektedir.
OpenID, düzenleme ve sunum spesifikasyonlarını kesinleştirmiş; uyumluluk altyapısını genişletmektedir.

Bunlar hâlâ ekosisteme özgü yanıtlardır. Sürücü kimlik bilgileri için henüz tek bir küresel sınır ötesi güven katmanı bulunmamaktadır. Kalan çalışma şunları tanımlamaktır:

Yığının hangi bölümlerinin zorunlu olduğu
Hangi kimlik bilgisi formatlarının kabul edilebilir olduğu
Düzenleyici ve doğrulayıcı güveninin nasıl dağıtılacağı
Uyumluluğun nasıl test edileceği
Sınır ötesi tanımanın gizliliği zedelemeden nasıl yönetileceği

Sonuç: Gelecekteki UEB Bir Belge Değil, Bir Yığındır

Gelecekteki UEB, tek bir standart kuruluşunun tek bir belge yazmasıyla ortaya çıkmayacaktır. Tutarlı bir yığın tanımlandığında, yönetildiğinde ve yetki alanları genelinde benimsendiğinde gün yüzüne çıkacaktır. Bu yığının belirlenebilir katmanları zaten mevcuttur: