Dijital Kimlik Bilgileri API'si (2025): Chrome ve Safari Desteği Aktif

Son güncelleme: 30 Ekim 2025

Büyük tarayıcılardaki Dijital Kimlik Bilgileri API'si desteğine hızlı bir genel bakış:

Dijital kimlik bilgileri dünyası hızla ilerliyor. İşte önemli gelişmelerin ve öngörülerin bir anlık görüntüsü:

Want to experience digital credentials in action?

Try Digital Credentials

Temmuz 2025'ten Bu Yana Neler Değişti?

• Yayınlandı: Chrome 141 (30 Eylül 2025) ve Safari 26 (15 Eylül 2025).
• Chrome: Protokolden bağımsız (OpenID4VP ve ISO 18013-7 Ek C), CTAP üzerinden masaüstü cihazlar arası destek.
• Safari: Yalnızca mdoc (org-iso-mdoc), CTAP üzerinden cihazlar arası akış.
• API şekli: navigator.credentials.get(); requests/data adlandırması; DigitalCredential özellik tespiti.

Dijital kimlik bilgileri, şu sıralar kimlik alanında popüler bir konu. Hayatlarımız dijital dünyayla giderek daha fazla bağlantılı hale geldikçe, çevrimiçi ortamda kimliğimizi ve niteliklerimizi güvenli, kullanıcı merkezli ve gizliliği koruyan yollarla kanıtlama ihtiyacı hiç bu kadar kritik olmamıştı. Geleneksel yöntemler artık eskimeye yüz tuttu ve daha sağlam çözümlere olan talep hissedilir derecede arttı.

Bu makalede, web üzerindeki kimlik bilgileriyle etkileşim şeklimizi yeniden şekillendirmeyi vaat eden önemli bir gelişme olan Dijital Kimlik Bilgileri API'sinin mevcut durumunu ele alacağız. Altta yatan mekanizmalarını, desteklediği protokolleri, mevcut tarayıcı benimsemesini ve bu hızla gelişen ortamda ilerleyen güvenen taraflar ve cüzdan yayıncıları için öneriler sunacağız.

Kimliği güvenilir ve güvenli bir şekilde kanıtlamak, yıllardır web'in mimarisinde kalıcı bir zorluk olmuştur. İnternet, benzeri görülmemiş bir bağlantı ve bilgi alışverişi sağlarken, aynı zamanda yanlış beyan ve dolandırıcılık için yeni yollar açtı.

Bazı ülkelerde, çözümler genellikle çevrimiçi kimlik tespiti için mevcut güvenilir ilişkilerden yararlanmak üzere hizmetler geliştiren erken banka konsorsiyumları tarafından yönlendirildi. Hükümetler de devreye girerek ulusal dijital kimlik cüzdanları ve hizmetleri zorunlu kıldı veya sağladı. Ancak, bu çözümler genellikle birbirinden kopuk, coğrafi olarak sınırlı ve evrensel olarak birlikte çalışabilir değildi.

Birçok bölgede kimlik doğrulama için başvurulan yöntemler geleneksel olarak yüksek sürtünmeli süreçleri içeriyordu. Örneğin bir postanede fiziksel doğrulama, önemli gecikmelere ve rahatsızlığa neden oluyordu. Belge yüklemeleriyle birleştirilen görüntülü aramalar daha dijital bir alternatif haline geldi ve bunu daha yakın zamanda otomatik belge tarama ve canlılık kontrollerinin yükselişi izledi. Gelişmelerine rağmen, bu yöntemlerin önemli dezavantajları var. Zaman alıcı, insan hatasına veya önyargıya açık olabiliyor ve sıklıkla gelişmiş sahteciliğe karşı savunmasız oldukları ortaya çıktı.

Deepfake'lerin, gelişmiş yapay zeka güdümlü taklit tekniklerinin ve giderek karmaşıklaşan oltalama saldırılarının ortaya çıkmasıyla bu zorluk çarpıcı bir şekilde artıyor. Bu teknolojiler, son derece gerçekçi ancak tamamen uydurma video, ses ve belge kanıtları oluşturabilir, bu da geleneksel sistemlerin ve hatta yapay zeka destekli doğrulama araçlarının gerçek kullanıcıları sahtekarlardan ayırmasını inanılmaz derecede zorlaştırır. Kontrolleri atlatmak için sentetik kimlikler oluşturma veya biyometrik verileri manipüle etme potansiyeli, özellikle finansal kurumlar ve sağlam Müşterini Tanı (KYC) süreçleri gerektiren tüm hizmetler için ciddi bir tehdittir. Bu artan tehdit ortamı, daha güvenli, kriptografik olarak doğrulanabilir çevrimiçi kimlik ve doğrulama mekanizmalarına duyulan acil ihtiyacın altını çiziyor.

Want to experience digital credentials in action?

Try Digital Credentials

Dijital kimlik bilgilerinin nasıl çalıştığını anlamak, ilgili kilit oyunculara ve işlevselliklerini sağlayan farklı teknolojik katmanlara bakmayı içerir.

Özünde, dijital kimlik bilgileri kavramı, özellikle yeni web API'leri bağlamında, üç taraflı bir model etrafında döner:

1. Yayıncı (Issuer): Bir konu hakkında belirli bilgiler için yetkili olan ve bu bilgiyi tasdik eden bir dijital kimlik bilgisi yayınlayabilen bir kuruluş (örneğin, hükümet, üniversite, işveren).
2. Sahip (Holder): Bilginin konusu olan (yani kullanıcı), kimlik bilgisini yayıncıdan alan ve bir dijital cüzdanda saklayan kişi. Sahip, kimlik bilgisinden hangi bilgilerin ne zaman paylaşılacağını kontrol eder.
3. Doğrulayıcı (Verifier) (veya Güvenen Taraf (Relying Party)): Bir hizmete veya kaynağa erişim izni vermek için sahip hakkında belirli bilgileri doğrulaması gereken bir kuruluş (örneğin, bir web sitesi, bir çevrimiçi hizmet). Doğrulayıcı, gerekli bilgiyi sahibinden talep eder.

Bu üç taraflı model önemlidir çünkü kullanıcıyı (sahibi) kendi verilerinin kontrolüne sokmayı amaçlar. Verilerin merkezi olarak saklanabileceği veya doğrudan kullanıcı aracılığı olmadan taraflar arasında paylaşılabileceği geleneksel kimlik sistemlerinin aksine, bu model kullanıcı rızasını ve seçici ifşayı vurgular. Sahip, tüm kimlik bilgisini ortaya çıkarmak yerine, belirli bir işlem için bir kimlik bilgisinden hangi bilgi parçalarını paylaşacağına karar verir.

Bu sistemlerin temel bir yönü, kriptografik anahtar çiftlerinin kullanılmasıdır. Yayıncı, kimlik bilgisini dijital olarak imzalayarak özgünlüğünü ve bütünlüğünü sağlar. Sahip ise, genellikle dijital cüzdanında (cihaz donanımı tarafından korunan) güvence altına alınmış özel anahtarını kullanarak kimlik bilgisi üzerindeki kontrolünü kanıtlar ve bir doğrulayıcıya sunulmasını yetkilendirir. Bu genellikle, doğrulayıcının bir sınama (rastgele bir veri parçası) sunmasını içerir ve sahibin cüzdanı bu sınamayı kimlik bilgisiyle ilişkili özel anahtarı kullanarak imzalar. Doğrulayıcı daha sonra ilgili açık anahtarı kullanarak imzayı onaylayabilir ve böylece sunumu doğrulayabilir.

Bu açıklama protokolden bağımsızdır, çünkü yayınlama, sahip olma ve kriptografik sınamalar yoluyla doğrulama temel ilkeleri farklı altta yatan teknolojilerde ortaktır.

Bu makale, dijital kimlik bilgilerinin doğrulanması ve kullanıcıların tüm kaynak belgeyi açıklamadan belirli nitelikleri (örneğin, "18 yaşından büyüğüm", "geçerli bir ehliyetim var") kanıtlamalarını sağlayan seçici ifşa ilkesine odaklanmaktadır. Dijital kimlik bilgileri için altta yatan sistemler Nitelikli Elektronik İmzalar (QES) ve uzaktan imzalama yetenekleri gibi özellikleri destekleyebilse de (AB Dijital Kimlik Cüzdanı gibi yasal olarak bağlayıcı imzalar için kapsamlı çözümlerde görüldüğü gibi), buradaki odak, özellikle Dijital Kimlik Bilgileri API'si için, bu daha geniş imzalama işlevlerinden ziyade çevrimiçi etkileşimler için kimlik beyanı ve nitelik doğrulamasıdır.

Dijital kimlik bilgilerinin nasıl çalıştığını anlamak için katmanlı bir model görselleştirmek faydalıdır. Her katman, veri formatının kendisinden bir web tarayıcısında kullanıcıya nasıl sunulduğuna kadar ekosistemin farklı bir yönünü ele alır. Bu makale öncelikle sunum katmanında çalışan Dijital Kimlik Bilgileri API'sine odaklanmaktadır.

Temel Terminoloji:

• Dijital kimlik bilgisi: Makine tarafından okunabilir herhangi bir kimlik bilgisi (barkodlu PDF, ISO mDL, W3C VC, SD-JWT, vb.). "Dijital" kelimesi kriptografik doğrulanabilirlik hakkında hiçbir şey söylemez.
• Doğrulanabilir Kimlik Bilgisi (Verifiable Credential): W3C VC Veri Modeli tarafından tanımlanan bir tür dijital kimlik bilgisi. Kurcalamaya karşı kanıt ve kriptografik ispat ekler ve her zaman üç taraflı bir dünyada yaşar: yayıncı → sahip → doğrulayıcı.
• Verifiable Credential API: Arka uç sistemler (yayıncılar, cüzdanlar, doğrulayıcılar) arasında VC'lerin yayınlanması, saklanması, sunulması ve doğrulanması için bir REST/HTTP hizmet arayüzü.
• Dijital Kimlik Bilgileri API'si (DC API): Bir web sitesinin, kullanıcının cihaz tarafındaki cüzdanından desteklenen herhangi bir dijital kimlik bilgisini (VC, ISO mDoc, SD-JWT…) gizliliği gözeten bir şekilde sunmasını istemesine olanak tanıyan bir tarayıcı / işletim sistemi API'si (JavaScript + yerel altyapı).

VC'leri bir veri modeli, VC API'sini bir arka uç belirtimi ve DC API'sini kimlik bilgilerini Web'e sunan ön uç uygulaması olarak düşünün. 1. katmanın (Veri modeli katmanı) üzerindeki her şey formattan bağımsızdır; altındaki her şey kimlik bilgisi formatına bağlıdır.

Uçtan uca akış (örnek: çevrimiçi yaş doğrulaması):

1. Yayınlama (VC API - yayıncı ↔ cüzdan): Eyalet Trafik Dairesi, "Sahip 18 yaşından büyüktür" diyen bir Doğrulanabilir Kimlik Bilgisi yayınlar.
2. Saklama (Cüzdan uygulaması - İşletim Sistemi): Kimlik bilgisi, kriptografik kanıtıyla birlikte kullanıcının cüzdanında durur.
3. Talep (navigator.credentials.get() aracılığıyla DC API - web sitesi → tarayıcı): Bira dükkanı web sitesi sorar: "Kullanıcının ≥18 olduğunun kanıtını gösterin."
4. Sunum (DC API cüzdana yönlendirir → OpenID4VP (protokol) → VC yükü): Cüzdan bir onay kullanıcı arayüzü gösterir, kullanıcı onaylar, cüzdan geri bir doğrulanabilir sunum gönderir.
5. Doğrulama (VC API - bira dükkanı arka ucu): Sitenin arka ucu, imzayı ve yayıncının DID/açık anahtarını doğrular; erişim izni verir.

Verinin bir VC, Web üzerindeki aktarımın DC API, alttaki değişim protokolünün OpenID4VP ve sunucu tarafı kontrolünün VC API kullandığına dikkat edin.

Bu ayrım neden var:

• Birlikte çalışabilir veri modeli (kriptografik kanıtlar, seçici ifşa): VC Veri Modeli (ve diğer formatlar) ile çözüldü.
• Arka uç sistemler için standart REST uç noktaları: VC API ile çözüldü.
• Cüzdan ↔ Web sitesi el sıkışmasının gizliliği koruyan şekilde olması: DC API ile çözüldü.
• Farklı güven seviyeleri / belge türleri (devlet kimliği vs. kurs sertifikası): DC API'nin altında doğru formatı (yüksek güvenceli kimlikler için ISO mDoc; genel iddialar için W3C VC) kullanarak çözüldü.

Önemli çıkarımlar:

1. "Dijital kimlik bilgisi" şemsiye terimdir.
2. Doğrulanabilir Kimlik Bilgisi, yerleşik kriptografik doğrulanabilirliğe sahip bir tür dijital kimlik bilgisidir.
3. VC API, VC'ler üzerindeki yaşam döngüsü işlemleri için sunucudan sunucuya altyapıdır.
4. Dijital Kimlik Bilgileri API'si, bu kimlik bilgilerinin somut formatları ne olursa olsun Web uygulamalarına sorunsuzca akmasını sağlayan tarayıcıdan cüzdana köprüdür.
5. Bu üç parça birbirini tamamlar, rekabet etmez—aynı yığının farklı katmanlarında yer alırlar ve birlikte açık Web üzerinde güvenli, kullanıcı merkezli kimliği mümkün kılarlar.

Katılımcıları ve dijital kimlik bilgilerinin genel katmanlı mimarisini inceledikten sonra, bu makale şimdi sunum katmanına, özellikle Dijital Kimlik Bilgileri API'sine ve mevcut durumuna daha derinlemesine inecek.

Sunum katmanındaki kritik bileşen olarak Dijital Kimlik Bilgileri API'si, web sitelerinin kullanıcıların dijital cüzdanlarından dijital kimlik bilgilerini talep etmesi ve alması için güvenli ve standartlaştırılmış bir yol sağlamak amacıyla geliştirilmekte olan bir web standardıdır. Bu çaba, Nisan 2025'te FedID Topluluk Grubu'ndan taşınarak öncelikle W3C'nin Federal Kimlik Çalışma Grubu (FedID WG) bünyesinde yer almaktadır. Resmi taslak belirtim burada bulunabilir: https://w3c-fedid.github.io/digital-credentials/.

Ekim 2025 itibarıyla, API hem Chrome 141 (30 Eylül 2025) hem de Safari 26'nın (15 Eylül 2025) kararlı sürümlerinde yayınlanmıştır. Chrome'un uygulaması protokolden bağımsızdır ve hem OpenID4VP'yi hem de ISO 18013-7 Ek C'yi desteklerken, Safari yalnızca org-iso-mdoc protokolünü desteklemektedir. Chrome, bunu Android üzerinde yerel olarak Credential Manager sistemi aracılığıyla destekler ve ayrıca masaüstünde CTAP/BLE destekli QR aktarımı yoluyla Cihazlar Arası Dijital Kimlik Bilgileri API'sini destekler.

API, navigator.credentials.get() aracılığıyla dijital kimlik bilgileri için talepleri etkinleştirerek mevcut Credential Management API'yi genişletir. W3C FedID WG Dijital Kimlik Bilgileri Açıklayıcısına göre (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), API, daha önce önerilen navigator.identity yerine bu yerleşik arayüzü kullanmaya geri dönmüştür. Bir web sitesi, navigator.credentials.get() fonksiyonunu dijital kimlik bilgileri için belirli parametrelerle çağırarak bir dijital kimlik bilgisi talep eder.

İşte bir web sitesinin OpenID4VP kullanarak bir kimlik bilgisi talep etmek için API'yi nasıl çağırabileceğine dair açıklayıcı bir örnek:

async function requestCredential() {
    // Dijital Kimlik Bilgileri API'si desteğini kontrol et
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Bu parametreler genellikle arka uçtan alınır.
            // Protokol genişletilebilirliğini göstermek için burada statik olarak tanımlanmıştır.
            const oid4vp = {
                protocol: "oid4vp", // Cüzdanlara yönelik bir OpenID4VP isteği örneği. // https://github.com/openid/OpenID4VP/issues/125'e dayanmaktadır
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange isteği, kısalık için atlanmıştır
                    },
                },
            };
 
            // Bir Abort Controller oluştur
            const controller = new AbortController();
 
            // Arka uçtan gelen sunum isteğini kullanarak Dijital Kimlik Bilgileri API'sini çağır
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Şifre çözme ve doğrulama için şifreli yanıtı arka uca gönder
            // Kısalık için atlanmıştır
        } catch (error) {
            console.error("Hata:", error);
        }
    } else {
        // yedek senaryo, yalnızca açıklayıcı amaçlı
        alert("Dijital Kimlik Bilgileri API'si bu tarayıcıda desteklenmiyor.");
    }
}

Bu örnek buradan alınmıştır.

Dijital Kimlik Bilgileri API'si esasen güvenli bir sarmalayıcı veya aracı görevi görür. Tarayıcının kimlik bilgisi talebini yönetmesine olanak tanır ve isteğe uyan mevcut cüzdanları ve kimlik bilgilerini keşfetmek için altta yatan işletim sisteminin yeteneklerinden yararlanır. Tarayıcı ve işletim sistemi daha sonra kimlik bilgisini seçmek ve serbest bırakılmasını yetkilendirmek için tutarlı bir kullanıcı arayüzü sunabilir, bu da kullanıcı rızasını sağlayarak ve web sitelerinin hassas verilere sessizce erişmesini önleyerek güvenlik ve gizliliği artırır. Yanıttaki gerçek kimlik bilgisi verilerinin tarayıcının kendisi için opak (şifreli) olması amaçlanmıştır; şifre çözme ve yorumlama güvenen taraf ve cüzdan/sahip tarafından gerçekleştirilir.

Dijital Kimlik Bilgileri API'si protokolden bağımsız olacak şekilde tasarlanmıştır, yani kimlik bilgisi değişimi için çeşitli altta yatan protokolleri destekleyebilir. Ancak, mevcut uygulamaların ve tartışmaların merkezinde iki ana protokol ailesi bulunmaktadır: org.iso.mdoc (ISO 18013-5 ve uzantısı ISO 18013-7 "Ek C"den türetilmiştir) ve OpenID Foundation'ın Doğrulanabilir Sunumlar için OpenID (OpenID4VP) ve Doğrulanabilir Kimlik Bilgisi Yayını için OpenID (OpenID4VCI) belirtimleri.

• Köken ve Standardizasyon: org.iso.mdoc, Uluslararası Standardizasyon Örgütü (ISO) ve Uluslararası Elektroteknik Komisyonu (IEC) tarafından standartlaştırılan mobil belgeler, özellikle de mobil Sürücü Belgeleri (mDL'ler) için veri formatını ve etkileşim modelini ifade eder. Temel standart, mDL uygulamasını, veri yapısını ve NFC, Bluetooth veya QR kodları gibi teknolojileri kullanarak yüz yüze (yakınlık) sunum için protokolleri tanımlayan ISO/IEC 18013-5'tir. ISO/IEC 18013-7, mDL'lerin çevrimiçi/uzaktan sunumunu sağlamak için bunu genişletir. "org.iso.mdoc" protokol dizesi, Dijital Kimlik Bilgileri API'si gibi API'lerle kullanılmak üzere özellikle ISO/IEC TS 18013-7'de (Ek C) tanımlanmıştır.

• Veri Modeli: mdoc'lar, kompaktlık ve verimlilik için CBOR (Concise Binary Object Representation) tabanlı, sıkı bir şekilde tanımlanmış bir veri yapısına sahiptir. Yaygın sürücü belgesi nitelikleri için ad alanlarını ve veri öğelerini belirtir ve yayıncı kimlik doğrulaması, cihaz bağlama, sahip kimlik doğrulaması (portre aracılığıyla), oturum şifrelemesi ve seçici ifşa dahil olmak üzere güçlü kriptografik güvenlik özelliklerini destekler.

• Tipik Kullanım Durumları: Başta sürücü belgeleri ve ulusal kimlikler gibi hükümet tarafından verilen kimlik belgeleri. Hem yüz yüze (örneğin, trafik kontrolleri, kısıtlı ürünler için yaş doğrulaması) hem de çevrimiçi (örneğin, hükümet hizmetlerine erişim, banka hesabı açılışı için uzaktan kimlik doğrulama) yüksek güvenceli senaryolar için tasarlanmıştır.

• Köken ve Standardizasyon: OpenID4VP (sunum için) ve OpenID4VCI (yayın için), OpenID Foundation tarafından geliştirilen belirtimlerdir. Doğrulanabilir kimlik bilgilerinin alışverişini desteklemek için OAuth 2.0'ı genişletirler. Bunlar, sadece hükümet değil, çeşitli kimlik bilgisi türleri için geniş birlikte çalışabilirliği hedefleyen açık standartlardır. 2025'in başları itibarıyla, OpenID4VP ileri taslak aşamalarındadır (örneğin, Nisan itibarıyla taslak 28). OpenID4VCI de olgunlaşmaktadır.
• Veri Modeli: OpenID4VP/VCI, kimlik bilgisi formatından bağımsız olacak şekilde tasarlanmıştır. JSON/JSON-LD veya JWT formatlarındaki W3C Doğrulanabilir Kimlik Bilgilerini, mdoc'ları, SD-JWT'leri ve diğer formatları taşıyabilirler. Etkileşim modeli, Doğrulayıcıdan (RP) bir Yetkilendirme İsteği ve Sahibin Cüzdanından bir vp_token (Doğrulanabilir Sunum Jetonu) içeren bir yanıtı içerir. Seçici ifşa genellikle Presentation Exchange (DIF PE) veya daha yeni Digital Credentials Query Language DCQL gibi sorgu dilleriyle yönetilir.
• Tipik Kullanım Durumları: Kimlik doğrulama, nitelik kanıtı sağlama (örneğin, eğitim diplomaları, profesyonel sertifikalar), üyelik tasdikleri ve daha fazlası dahil olmak üzere geniş bir uygulama yelpazesi. Bir güvenen tarafın, çeşitli yayıncılardan gelen iddiaları doğrulaması gereken çevrimiçi etkileşimler için çok uygundurlar.

Bunların her zaman birbirini dışlamadığını kabul etmek önemlidir. Örneğin OpenID4VP, bir [org.iso.mdoc] talep etmek ve taşımak için kullanılabilir. Seçim genellikle belirli kullanım durumuna, kimlik bilgisi türüne ve ekosistem katılımcılarına bağlıdır.

Avrupa Birliği Dijital Kimlik (EUDI) Cüzdanı, tüm AB vatandaşlarına ve sakinlerine kimlik belgeleri ve tasdikler için güvenli bir dijital cüzdan sağlamayı amaçlayan büyük bir girişimdir. EUDI Cüzdan mimarisi ve referans çerçevesi, sunum ve yayın akışları için OpenID4VP ve OpenID4VCI kullanarak hem mdoc'u (özellikle Mobil Sürücü Belgeleri için) hem de W3C Doğrulanabilir Kimlik Bilgilerini desteklemeyi açıkça planlamaktadır. Referans uygulama, mDoc'ları aktaran OpenID4VP ve mDoc ve SD-JWT-VC formatlarında PID'ler ve mDL'ler yayınlayan OpenID4VCI desteğini içerir. Bu kadar büyük ölçekli bir projenin bu ikili desteği, her iki protokol ailesinin de önemini vurgulamaktadır. Ancak bu yönelim eleştirisiz de değildir, çünkü bazı gözlemciler, büyük ölçüde "ABD Bigtech" şirketlerinden etkilenen Dijital Kimlik Bilgileri API'sinin, nihai EUDI Cüzdanı belirtimlerine derinden dahil olabileceğini belirtmektedir. AB dışı kuruluşların, AB altyapısının kritik bir parçası üzerindeki potansiyel etkisi hakkında, bu GitHub tartışması gibi topluluk forumlarında endişeler dile getirilmiştir.

Dijital Kimlik Bilgileri API'si için tarayıcı manzarası artık şekillenmiş durumda; Chrome 141 ve Safari 26, Eylül 2025'te kararlı destek sunmaya başladı. Tarayıcılar arasında yaklaşım ve destek seviyelerinde dikkate değer farklılıklar bulunuyor.

Chrome, Dijital Kimlik Bilgileri API'sini Chrome 141'de (30 Eylül 2025) yayınladı. Chrome'un uygulaması protokolden bağımsızdır: OpenID4VP ve ISO 18013-7 Ek C (çevrimiçi mdoc) ile uyumludur. Masaüstü, mobil cüzdanlardan cihazlar arası sunumu CTAP/BLE destekli bir kanal (QR aktarımı) aracılığıyla destekler ve yanıt tarayıcıya opaktır. API şekli navigator.credentials.get()'e taşındı; parametreler yeniden adlandırıldı: providers → requests, request → data.

Özellik Tespiti:

if (typeof DigitalCredential !== "undefined") {
    // Dijital Kimlik Bilgileri API'si destekleniyor
}

Android'in Credential Manager'ı, sunum için OpenID4VP'yi ve yayın için OpenID4VCI'yi yerel olarak destekler, bu da Android uygulamalarının bu standartları kullanarak kimlik bilgisi sahipleri ve doğrulayıcıları olarak hareket etmesine olanak tanır. Google, artan cüzdan desteğine dikkat çekiyor; Google Wallet erken benimseyenlerden biri, Samsung Wallet ve 1Password de duyuruldu.

Bu makalenin önceki sürümlerinde, Apple'ın yaklaşımının org.iso.mdoc protokolüne odaklanarak Google'dan ayrılacağını tahmin etmiştik. Tarihsel bağlam için, gerekçemiz şu şekildeydi:

Doğru bir şekilde öngördüğümüz gibi, WWDC25 bu stratejiyi doğruladı. Safari 26 (iOS/iPadOS/macOS), 15 Eylül 2025'te Dijital Kimlik Bilgileri API'si desteğiyle yayınlandı ve uygulamalarının sunum için yalnızca org-iso-mdoc protokolünü (tireli) desteklediğini onayladı.

Bu, WWDC25 oturumu olan Web'de kimlik belgelerini doğrulama bölümünde detaylandırıldı. API, web sitelerinin Apple Wallet'ta veya üçüncü taraf belge sağlayıcı uygulamalarında saklanan sürücü belgesi gibi kimlik belgelerinden doğrulanabilir bilgi talep etmesine olanak tanır.

Apple'ın uygulamasından önemli çıkarımlar:

• Yalnızca MDOC: API, ISO/IEC 18013-7 Ek C standardına dayalı olarak yalnızca "org-iso-mdoc" protokol dizesini kullanır. Safari'nin Dijital Kimlik Bilgileri API'si uygulamasında OpenID4VP desteği yoktur.
• Yalnızca Sunum: API, mevcut kimlik bilgilerinin sunumu (doğrulaması) içindir. Apple Wallet'a veya diğer uygulamalara yayınlama, ayrı, tarayıcı dışı bir süreç olarak kalır.
• Kullanıcı Odaklı ve Güvenli: Akış, bir kullanıcı hareketiyle başlatılır ve işletim sisteminin isteği bir sanal alanda (sandbox) ayrıştırıp doğruladıktan sonra cüzdan uygulamasına geçirdiği bir "kısmi istek" mekanizmasından yararlanır, bu da güvenliği artırır.
• Uygulamalara Genişletilebilir: Apple Wallet'a ek olarak, üçüncü taraf uygulamalar yeni IdentityDocumentServices çerçevesini ve bir uygulama uzantısını uygulayarak belge sağlayıcıları olarak hareket edebilir.
• Cihazlar Arası Destek: Apple dışı platformlardan cihazlar arası sunum, bir QR kodu aktarımından sonra yakınlık için CTAP kullanır; JS yanıtı tarayıcıya şifreli/opak kalır.

Apple, bir güvenen tarafın API'yi nasıl kullanacağına dair net bir kod örneği sağladı:

async function verifyIdentity() {
    try {
        // Sunucu istek verilerini oluşturur ve kriptografik olarak imzalar.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // İstek 'org-iso-mdoc' protokolünü belirtir.
        const request = {
            protocol: "org-iso-mdoc",
            // data, kriptografik olarak imzalanmış mdoc isteğini içerir.
            data,
        };
 
        // API bir kullanıcı hareketi içinden çağrılmalıdır.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Cüzdandan gelen şifreli yanıtı şifre çözme ve doğrulama için sunucuya gönder.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Doğrulanmış ayrıntıları göster...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Hataları işle, örn. kullanıcı iptali.
    }
}

Bu onay, tarayıcı pazarındaki farklı stratejileri pekiştiriyor. Chrome, esnek OpenID4VP taşıma katmanı üzerine inşa edilirken, Apple, ISO mdoc ekosistemindeki derin yatırımından yararlanarak resmi kimlik belgelerine göre uyarlanmış, son derece entegre ve güvenli, ancak daha az esnek bir çözüm sunuyor.

Mozilla, mevcut haliyle Dijital Kimlik Bilgileri API'si hakkında resmi olarak olumsuz bir standart pozisyonu ifade etti. Endişeleri kapsamlıdır ve kullanıcı gizliliğini, özerkliğini koruma ve açık, eşitlikçi bir web sağlama misyonlarına dayanmaktadır.

Mozilla tarafından dile getirilen temel endişeler şunları içerir:

• Gizlilik Riskleri: Dijital kimlik bilgisi talepleri önemsiz etkileşimler için yaygınlaşırsa, kişisel verilerin daha fazla paylaşılması ve çevrimiçi anonimliğin azalması potansiyeli.
• Kullanıcı Dışlanması: Dijital kimlik bilgilerini kullanamayan veya kullanmamayı seçen bireylerin çevrimiçi hizmetlerden ve topluluklardan dışlanma riski. Birincil kullanım durumu olan hükümet tarafından verilen kimlik bilgileri, bir bireyin kimlik sunum tercihiyle uyumlu olmayabilir.
• Birlikte Çalışabilirlik Sorunları: Evrensel olarak birlikte çalışabilir bir ekosistem yerine, parçalanmış bir ekosisteme yol açan kimlik bilgisi formatlarının çoğalmasıyla ilgili endişeler.
• Seçici İfşa: Seçici ifşanın gizlilik faydalarının, güçlü bağlantı kurulamama garantileriyle uygulanmazsa veya kullanıcılar neyin paylaşıldığını tam olarak anlamazsa zayıflatılabileceği endişeleri.
• Güvenin ve Kullanıcı Özerkliğinin Merkezileştirilmesi: API'nin güvenin daha fazla merkezileşmesine ve kullanıcı özerkliğinin azalmasına yol açarak mevcut toplumsal güç dengesizliklerini sürdürebileceği korkuları.

Mozilla, böyle bir API'nin mevcut geçici kimlik bilgisi sunum yöntemlerine göre fayda sağlayabileceğini kabul etmekle birlikte, yeni web platformu özelliklerinin web'i genel olarak gözle görülür şekilde daha iyi hale getirmesi ve kullanıcıların çıkarlarını önceliklendirmesi gerektiğini vurgulamaktadır. Bir W3C Konseyi, bu endişelerle ilgili resmi bir itirazı reddetmiş olsa da (çalışmanın potansiyel olarak daha az şeffaf mekanlar yerine W3C içinde ilerlemesine izin vermek için), Konsey Çalışma Grubunun bu potansiyel zararları azaltmak için aktif olarak çalışmasını tavsiye etmiştir.

Tablo 1: Dijital Kimlik Bilgileri API'si ve Protokolleri için Tarayıcı Desteği (Ekim 2025)

Kullanıcılardan dijital kimlik bilgilerini talep etmeyi ve doğrulamayı amaçlayan kuruluşlar (Güvenen Taraflar veya RP'ler) için mevcut manzara dikkatli bir stratejik planlama gerektirir.

Safari'nin (15 Eylül 2025'te yayınlandı) Dijital Kimlik Bilgileri API'si aracılığıyla yalnızca doğrudan org-iso-mdoc etkileşimlerini (ISO 18013-7 Ek C) desteklediği ve Chrome'un (30 Eylül 2025'te yayınlandı) hem OpenID4VP hem de ISO 18013-7 Ek C'yi (mdoc) destekleyen protokolden bağımsız olduğu göz önüne alındığında, mümkün olan en geniş kitleye ulaşmayı hedefleyen RP'ler, her iki yaklaşıma dayalı etkileşimleri desteklemeye hazırlanmalıdır.

Bu, aşağıdaki yeteneklere sahip sistemler tasarlamak anlamına gelir:

1. Tarayıcı tespiti veya user agent yeteneklerine dayanarak farklı protokol parametreleri ("org-iso-mdoc" Safari için veya "openid4vp" Chrome/OID4VP akışları için) belirterek navigator.credentials.get() API'si aracılığıyla kimlik bilgisi taleplerini başlatmak.
2. Doğrudan bir mdoc formatında (ISO 18013-7 Ek C) veya OpenID4VP aracılığıyla bir vp_token olarak gelebilecek yanıtları işlemek. Bu vp_token, altta yatan kimlik bilgisini (bu da bir mdoc veya başka bir VC formatı olabilir) çıkarmak için ayrıştırılmalıdır.

Bu, karmaşıklığı artırsa da, tüm kullanıcıları tek bir protokol yoluna zorlamaya çalışmak, seçilen yola bağlı olarak ya iOS ya da Chrome/Android kullanıcılarının önemli bir bölümünü dışlayacaktır. Pragmatik, ancak daha fazla geliştirme gerektiren bir yaklaşım, her ikisini de idare edecek esnekliği oluşturmaktır.

Güvenen Taraflar, aynı mantıksal bilgi parçasını talep ederken bile (örneğin, "kullanıcı 21 yaşından büyük mü?"), bunun bir istekte nasıl tanımlandığının ve bir yanıtta nasıl döndürüldüğünün, doğrudan bir mdoc sorgusu ile bir OpenID4VP sorgusu (Presentation Exchange veya DCQL kullanabilir) arasında önemli ölçüde farklılık gösterebileceğinin keskin bir şekilde farkında olmalıdır.

• mdoc Seçici İfşası: org.iso.mdoc, genellikle yayıncının bireysel veri öğelerinin tuzlanmış hash'lerini oluşturmasını içeren kendi seçici ifşa mekanizmalarına sahiptir. Sahibin cüzdanı daha sonra yalnızca talep edilen öğeleri tuzlarıyla birlikte açıklar, bu da doğrulayıcının diğer verileri görmeden bunları hash'lere karşı onaylamasına olanak tanır. Belirli öğeler için talep, mdoc standardı içindeki önceden tanımlanmış ad alanlarına ve veri öğesi tanımlayıcılarına bağlıdır.
• OpenID4VP Seçici İfşası: OpenID4VP genellikle, isteğin presentation_definition'ına gömülü Presentation Exchange (DIF PE) veya daha yeni Digital Credentials Query Language (DCQL) gibi bir sorgu dili kullanır. Bu, RP'lerin ihtiyaç duydukları kimlik bilgisi türlerini ve bireysel iddiaları belirtmelerine olanak tanır. Cüzdan daha sonra, kimlik bilgisi formatı ve cüzdan tarafından destekleniyorsa, yalnızca talep edilen bilgileri içeren bir Doğrulanabilir Sunum oluşturur.

RP'lerin, özel veri gereksinimlerini bu değişen protokol yapılarına eşlemeleri gerekir. Yalnızca minimum gerekli verinin talep edilmesini ve işlenmesini sağlamak ve böylece gizlilik en iyi uygulamalarına ve veri minimizasyonu ilkelerine uymak için, her protokolde seçici ifşanın nasıl uygulandığının ve talep edildiğinin inceliklerini anlamak çok önemlidir. Cüzdan tarafından döndürülen ifşa edilen verilerin formatı ve yapısı da farklılık gösterebilir ve RP'nin arka ucunda ayrı ayrıştırma ve doğrulama mantığı gerektirebilir.

Dijital kimlik bilgileri yayınlamak ve sahipler için cüzdan uygulamaları sağlamak isteyen kuruluşlar için işletim sistemi ortamı çok önemli bir rol oynar.

Cüzdan yayıncıları, cüzdan oluşturma, sistem entegrasyonu ve Dijital Kimlik Bilgileri API'si ile etkileşim konularında iOS ve Android'de belirgin şekilde farklı manzaralarla karşı karşıyadır.

• Android: Genellikle daha açık bir ekosistem sunar. Android Credential Manager, üçüncü taraf yerel uygulamaların kimlik bilgisi sahibi olarak kaydolmasına olanak tanıyan bir Holder API içerir. Bu kayıtlı sahip uygulamaları daha sonra, sistem tarafından yönetilen kimlik bilgisi sunum akışlarına katılabilir ve Dijital Kimlik Bilgileri API'sinden (Chrome aracılığıyla) veya yerel uygulama doğrulayıcılarından gelen taleplere yanıt verebilir. Android ayrıca kimlik bilgisi yayını için OpenID4VCI'yi açıkça destekler, bu da kullanıcıların yeni yayınlanan kimlik bilgilerini almak için uyumlu bir üçüncü taraf cüzdan seçmesine olanak tanır. Tam kimlik bilgisi sahibi yetenekleri için birincil odak yerel uygulamalar olsa da, sistem daha geniş katılım için tasarlanmıştır.

• iOS: Apple, ekosistemi üzerinde daha sıkı bir kontrol sağlar. App Store'da üçüncü taraf cüzdan uygulamaları bulunabilse de, yüksek güvenceli kimlik bilgileri (Apple Wallet için tasarlanan mDL'ler gibi) için sistem düzeyinde kimlik bilgisi sahipleri olarak derinlemesine entegre olma yetenekleri genellikle Apple'ın belirli süreçlerine ve yetkilerine tabidir. Örneğin, Apple Wallet'a bir kimlik eklemek, eyalet yayınlama yetkililerini ve Apple'ın doğrulamasını içeren kontrollü bir akıştır. Safari'deki Dijital Kimlik Bilgileri API'si için etkileşimler muhtemelen yakından yönetilecek ve birincil odak, yetkili kaynaklardan, yani Apple Wallet'ın kendisinden ve kayıtlı üçüncü taraf belge sağlayıcı uygulamalarından sunulan org.iso.mdoc olacaktır.

Apple'ın "duvarlı bahçe" yaklaşımı iyi bilinir ve dijital kimlik bilgileri uygulamaları da bir istisna değildir. Ancak, WWDC25 üçüncü taraf katılımı için yolu netleştirdi.

Apple Wallet, eyalet mDL'leri gibi kimlik bilgileri için birincil, yerleşik sağlayıcı olsa da, Apple, yerel iOS uygulamaları için IdentityDocumentServices çerçevesini tanıttı. Bu, üçüncü taraf geliştiricilerin kendi kimlik belgelerini tedarik edebilen ve sunabilen uygulamalar oluşturmasına olanak tanır.

Web akışına katılmak için bir yerel uygulamanın şunları yapması gerekir:

1. Belgeleri Kaydetmek: Uygulamanın yönettiği mdoc'ları işletim sistemine kaydetmek için IdentityDocumentProviderRegistrationStore kullanmak. Bu kayıt, belge türünü ve istek imzalama için güvenilir sertifika yetkililerini içerir.
2. Bir Uygulama Uzantısı Uygulamak: Projeye bir "Identity Document Provider" UI Uygulama Uzantısı eklemek. Bu uzantı, web tabanlı bir doğrulama akışı sırasında uygulama seçildiğinde kullanıcıya yetkilendirme kullanıcı arayüzünü görüntülemekten sorumludur.

Bu, iOS'ta tam entegre bir cüzdan oluşturmanın yerel bir uygulama oluşturmayı ve PWA'lar gibi web teknolojileri yerine Apple'ın özel çerçevelerini kullanmayı gerektirdiği anlamına gelirken, üçüncü taraf uygulamaların Apple Wallet'ın yanı sıra belge sağlayıcıları olarak hareket etmesi için açık, ancak sıkı bir şekilde kontrol edilen bir mekanizma olduğu anlamına gelir. Bu, Safari'deki Dijital Kimlik Bilgileri API'si ile etkileşimin işletim sistemi tarafından yönetildiğini ve ardından istekleri Apple Wallet'a veya diğer kayıtlı ve yetkili belge sağlayıcı uygulamalarına gönderdiğini doğrular.

Dijital Kimlik Bilgileri API'si, dijital kimlik alanında önemli bir ilerlemeyi temsil ediyor ve kimlik doğrulama ve kimlik bilgisi sunumu için daha güvenli, kullanıcı merkezli ve gizliliği koruyan bir yaklaşım sunuyor. Chrome 141 (30 Eylül 2025) ve Safari 26 (15 Eylül 2025) artık kararlı destek sunduğundan, API deneysel olmaktan çıkıp üretime hazır hale geldi. Ekosistem gelişmeye devam ettikçe, hem güvenen tarafların hem de cüzdan yayıncılarının bu yeni teknolojinin potansiyelini benimsemesi ve uyum sağlaması çok önemlidir. Manzara değiştikçe bu makaleyi güncel tutacağız.

Ancak zorluklar devam ediyor. Farklı kimlik bilgisi formatları, protokoller ve cüzdan uygulamaları arasında gerçek küresel birlikte çalışabilirliği sağlamak önemli bir girişimdir. Mozilla gibi kuruluşlar tarafından gizlilik, dışlanma ve kullanıcı özerkliği konusunda dile getirilen geçerli endişeleri ele almak, bu teknolojilerin insanlığa hizmet etmesini sağlamak için büyük önem taşımaktadır. Farklı yaklaşımlar—Chrome'un protokolden bağımsız uygulaması ile Safari'nin yalnızca mdoc odaklı olması—güvenen tarafların ve cüzdan yayıncılarının öngörülebilir gelecekte çift protokollü bir manzarada gezinmesi gerektiği anlamına geliyor.