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

Son güncelleme: 26 Mart 2026

Başlıca tarayıcılarda Dijital Kimlik Bilgileri API'si (Digital Credentials API) desteğine hızlı bir bakış:

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

Want to experience digital credentials in action?

Try Digital Credentials

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

• Protokol yönetişiminde değişim: W3C FedID WG, TPAC'de (Kasım 2025) açık protokol kaydını kaldırdı ve artık desteklenen protokolleri doğrudan spesifikasyona kodluyor: OpenID4VP, OpenID4VCI ve ISO 18013-7 Ek C. API artık sadece bir "basit taşıyıcı" (dumb pipe) değil.
• İhraç (Issuance) özelliği geliyor: Chrome 143, navigator.credentials.create() aracılığıyla kimlik belgesi ihracı için bir Origin Trial başlattı ve API'yi sadece sunum yapmanın ötesine genişletti.
• Firefox uygulama süreci: Değişmeyen olumsuz standart pozisyonuna rağmen Mozilla, UX çalışmaları devam ederken Firefox 149'a temel DC API kodunu ekledi.
• AB koşullu zorunluluğu: EUDI Mimari Referans Çerçevesi (Konu F), artık tüm üye devlet cüzdanları için DC API desteğini koşullu olarak zorunlu kılıyor.
• Gerçek dünya benimsemesi: California DMV, OpenCred platformuna DC API desteği ekledi (Şubat 2026).

Dijital kimlik bilgileri şu anda kimlik alanındaki en sıcak konu. Hayatlarımız dijital dünyayla giderek daha fazla iç içe geçerken, kimliğimizi ve niteliklerimizi çevrimiçi ortamda iddia etmenin güvenli, kullanıcı odaklı ve gizliliği koruyan yollarına duyulan ihtiyaç hiç bu kadar kritik olmamıştı. Geleneksel yöntemler artık yetersiz kalıyor ve daha sağlam çözümlere yönelik talep açıkça hissediliyor.

Bu makalede, web'de kimlik bilgileriyle etkileşim şeklimizi yeniden şekillendirmeyi vaat eden önemli bir gelişme olan Dijital Kimlik Bilgileri API'sinin (Digital Credentials API) mevcut durumunu tartışmayı amaçlıyoruz. API'nin temel mekanizmalarını, desteklediği protokolleri, mevcut tarayıcı benimseme durumunu inceleyecek ve bu hızla gelişen ortamda yol alan hem güvenen taraflar (relying parties) hem de cüzdan vericileri için öneriler sunacağız.

Kimliği güvenilir ve emniyetli bir şekilde kanıtlamak, uzun yıllardır web mimarisinin süregelen bir zorluğu 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 de yeni kapılar açtı.

Bazı ülkelerde, öncelikle çevrimiçi tanımlama için mevcut güvenilir ilişkileri kullanmaya yönelik hizmetler geliştiren erken banka konsorsiyumlarının öncülüğünde çözümler ortaya çıktı. Hükümetler de devreye girerek ulusal dijital kimlik cüzdanları ve hizmetleri sağladı veya zorunlu kıldı. Ancak bu çözümler genellikle birbirinden kopuktu, coğrafi olarak sınırlıydı ve evrensel olarak birlikte çalışabilir değildi.

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

Deepfake'lerin, gelişmiş yapay zeka destekli taklit tekniklerinin ve giderek karmaşıklaşan oltalama (phishing) saldırılarının ortaya çıkmasıyla bu zorluk dramatik 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ırt etmesini inanılmaz derecede zorlaştırır. Sentetik kimlikler oluşturma veya kontrolleri atlamak için biyometrik verileri manipüle etme potansiyeli, özellikle finansal kurumlar ve sağlam "Müşterini Tanı" (KYC) süreçleri gerektiren herhangi bir hizmet 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, dahil olan kilit oyunculara ve işlevselliklerini sağlayan farklı teknolojik katmanlara bakmayı gerektirir.

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

1. Verici (Issuer): Bir özne hakkında belirli bilgiler için yetkili olan ve bu bilgileri doğrulayan bir dijital kimlik bilgisi verebilen bir varlık (ör. devlet, üniversite, işveren).
2. Tutucu (Holder): Bilginin öznesi (yani kullanıcı), kimlik bilgisini vericiden alır ve bunu bir dijital cüzdanda saklar. Tutucu, kimlik bilgisinden ne zaman ve hangi bilgilerin 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 tutucu hakkında belirli bilgileri doğrulaması gereken bir varlık (ör. bir web sitesi, çevrimiçi bir hizmet). Doğrulayıcı, gerekli bilgileri tutucudan talep eder.

Bu üç taraflı model önemlidir çünkü kullanıcıyı (tutucuyu) kendi verilerinin kontrolüne vermeyi amaçlar. Verilerin merkezi olarak saklandığı veya doğrudan kullanıcı aracılığı olmadan taraflar arasında paylaşıldığı geleneksel kimlik sistemlerinin aksine, bu model kullanıcı rızasını ve seçici ifşayı (selective disclosure) vurgular. Tutucu, tüm kimlik bilgisini ifşa etmek yerine, belirli bir işlem için kimlik bilgisinden hangi bilgi parçalarının paylaşılacağına karar verir.

Bu sistemlerin temel bir yönü, kriptografik anahtar çiftlerinin dahil olmasıdır. Verici, kimlik bilgisini dijital olarak imzalayarak orijinalliğini ve bütünlüğünü sağlar. Tutucu ise, genellikle cihaz donanımı tarafından korunan dijital cüzdanında güvence altına alınan ö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 meydan okuma (challenge - rastgele bir veri parçası) sunmasını ve tutucunun cüzdanının bunu kimlik bilgisiyle ilişkili özel anahtarı kullanarak imzalamasını içerir. Doğrulayıcı daha sonra imzayı doğrulamak için karşılık gelen açık anahtarı kullanabilir ve böylece sunumu doğrulayabilir.

Bu açıklama protokol bağımsızdır, çünkü ihraç etme, tutma ve kriptografik meydan okumalar yoluyla doğrulama temel ilkeleri farklı temel teknolojilerde ortaktır.

Bu makale, dijital kimlik bilgilerinin doğrulanmasına ve kullanıcıların tüm kaynak belgeyi ifşa etmeden belirli nitelikleri (ör. "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 temel sistemler, Nitelikli Elektronik İmzalar (QES) ve uzaktan imzalama yetenekleri (yasal olarak bağlayıcı imzalar için AB Dijital Kimlik Cüzdanı gibi kapsamlı çözümlerde görüldüğü gibi) gibi özellikleri destekleyebilse de, buradaki odak noktası, özellikle Dijital Kimlik Bilgileri API'si için, bu daha geniş imzalama işlevleri değil, çevrimiçi etkileşimler için kimlik iddiası ve nitelik doğrulamasıdır.

Dijital kimlik bilgilerinin nasıl işlediğini anlamak için katmanlı bir model görselleştirmek yararlı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 (Digital credential): Herhangi bir makine tarafından okunabilir kimlik bilgisi (barkodlu PDF, ISO mDL, W3C VC, SD-JWT, vb.). "Dijital" olması, kriptografik doğrulanabilirlik hakkında hiçbir şey söylemez.
• Doğrulanabilir Kimlik Bilgisi (Verifiable Credential - VC): W3C VC Veri Modeli tarafından tanımlanan bir tür dijital kimlik bilgisi. Tahrifat kanıtı ve kriptografik kanıt ekler ve her zaman üç taraflı bir dünyada yaşar: verici → tutucu → doğrulayıcı.
• Doğrulanabilir Kimlik Bilgisi API'si (VC API): Arka uç sistemleri (vericiler, cüzdanlar, doğrulayıcılar) arasında VC'lerin ihracı, 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 vb.) gizliliğe saygılı bir şekilde sunmasını isteyen bir tarayıcı / işletim sistemi API'si (JavaScript + yerel tesisat).

VC'leri bir veri modeli, VC API'sini bir arka uç spesifikasyonu ve DC API'sini kimlik bilgilerini Web'e sunan ön uç uygulaması olarak düşünün. Katman 1'in (Veri modeli katmanı) üzerindeki her şey format 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ğrulama):

End-to-end flow (example: online age verification):

Aşağıdaki diyagram, bu katmanların gerçek dünya senaryosunda nasıl birlikte çalıştığını göstermektedir.

Verinin bir VC, Web üzerindeki taşımanı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) tarafından çözüldü.
• Arka uç sistemleri için standart REST uç noktaları: VC API tarafından çözüldü.
• Gizliliği koruyan Cüzdan ↔ Web sitesi el sıkışması: DC API tarafından çözüldü.
• Farklı güven seviyeleri / belge türleri (devlet kimliği vs. kurs sertifikası): DC API altında doğru formatın (yüksek güvenceli kimlikler için ISO mDoc; genel iddialar için W3C VC) kullanılmasıyla çözüldü.

Önemli çıkarımlar:

1. "Dijital kimlik bilgisi" çatı 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ü operasyonları için sunucudan sunucuya tesisattır.
4. Dijital Kimlik Bilgileri API'si, bu kimlik bilgilerinin somut formatları ne olursa olsun Web uygulamalarına sorunsuz bir şekilde akmasını sağlayan tarayıcıdan cüzdana köprüdür.
5. Bu üç parça birbirini tamamlayıcıdır, rakip değil; aynı yığının farklı katmanlarında otururlar ve birlikte açık Web'de güvenli, kullanıcı odaklı 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 daha derinlemesine inecek, özellikle Dijital Kimlik Bilgileri API'sine ve mevcut durumuna odaklanacaktır.

Sunum katmanındaki en önemli bileşen olan 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 üzere geliştirilmekte olan bir web standardıdır. Bu çalışma, Nisan 2025'te FedID Topluluk Grubu'ndan taşınarak öncelikle W3C'nin Federe Kimlik Çalışma Grubu (FedID WG) bünyesinde yürütülmektedir. Resmi taslak spesifikasyon 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ı hem OpenID4VP hem de ISO 18013-7 Ek C'yi desteklerken, Safari yalnızca org-iso-mdoc protokolünü destekler.

Önemli (Mart 2026 güncellemesi): API'nin protokollerle ilişkisi temelden değişti. Kasım 2025'teki TPAC'de, W3C FedID WG açık protokol kaydını ortadan kaldırmak ve bunun yerine desteklenen protokollerin sonlu bir listesini doğrudan spesifikasyona gömmek (hardcode) konusunda uzlaşmaya vardı: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (sunum için) ve openid4vci-v1 (ihraç için). Kullanıcı aracılarının (user agents) listelenmemiş protokolleri reddetmesi bekleniyor. Bu, Çalışma Grubunu gelecekteki protokol eklemeleri için fiili bir bekçi (gatekeeper) yapar; bu, API üzerinden akan her şeyin bütünsel güvenlik ve gizlilik incelemesini sağlamak için kasıtlı bir takastır (bkz. mevcut Çalışma Taslağı).

Spesifikasyon artık navigator.credentials.create() aracılığıyla kimlik belgesi ihracını da kapsıyor. Chrome 143, web sitelerinin OpenID4VCI kullanarak cüzdan sağlama akışlarını tetiklemesine izin veren bir Origin Trial başlattı. Ancak, kötü niyetli bir cüzdan uygulamasının ihraç ön yetkilendirme kodlarını ele geçirebildiği bir cüzdan seçimi bağlama güvenlik açığı açık bir endişe kaynağı olmaya devam ediyor. Hükümet vericileri, bu sorun çözülene kadar tarayıcı aracılı ihracı benimsemeyeceklerini belirttiler.

Chrome, Credential Manager sistemi aracılığıyla Android üzerinde yerel olarak sunumu destekler ve ayrıca CTAP/BLE destekli QR devri aracılığıyla masaüstünde Cihazlar Arası Dijital Kimlik Bilgileri API'sini destekler.

API, navigator.credentials.get() aracılığıyla dijital kimlik bilgileri için istekleri etkinleştirerek mevcut Credential Management API'yi genişletir. W3C FedID WG Dijital Kimlik Bilgileri Açıklayıcısına (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md) göre API, daha önce önerilen navigator.identity yerine bu yerleşik arayüzü kullanmaya geri döndü. Bir web sitesi, dijital kimlik bilgileri için belirli parametrelerle navigator.credentials.get() çağrısı yaparak 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() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

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, alttaki işletim sisteminin istekle eşleşen mevcut cüzdanları ve kimlik bilgilerini keşfetme yeteneklerinden yararlanarak kimlik bilgisi isteğine aracılık etmesine olanak tanı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, böylece kullanıcı rızasını sağlayarak ve web sitelerinin hassas verilere sessizce erişmesini önleyerek güvenliği ve gizliliği artırır. Yanıttaki gerçek kimlik bilgisi verisinin tarayıcının kendisi için opak (şifrelenmiş) olması amaçlanmıştır; şifre çözme ve yorumlama güvenen taraf (relying party) ve cüzdan/tutucu tarafından gerçekleştirilir.

Dijital Kimlik Bilgileri API'si başlangıçta tamamen protokol bağımsız olacak şekilde, herhangi bir protokolün kaydolabileceği açık bir kayıt defteri ile bir "basit taşıyıcı" (dumb pipe) olarak tasarlanmıştı. Ancak, Ocak 2026 itibarıyla spesifikasyon artık desteklediği protokolleri açıkça isimlendiriyor — kullanıcı aracılarının listelenmemiş olanları reddetmesi bekleniyor. Şu anda spesifikasyonda sabit kodlanmış iki ana protokol ailesi şunlardır: org.iso.mdoc (ISO 18013-5 ve onun 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 İhracı için OpenID (OpenID4VCI) spesifikasyonları.

• Köken ve Standardizasyon: org.iso.mdoc, Uluslararası Standardizasyon Örgütü (ISO) ve Uluslararası Elektroteknik Komisyonu (IEC) tarafından standardize edilen, öncelikle mobil Sürücü Belgeleri (mDL'ler) olmak üzere mobil belgeler için veri formatını ve etkileşim modelini ifade eder. Temel standart, NFC, Bluetooth veya QR kodları gibi teknolojileri kullanarak yüz yüze (yakınlık) sunum için mDL uygulamasını, veri yapısını ve protokollerini 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ım için ISO/IEC TS 18013-7'de (Ek C) özel olarak tanımlanmıştır.

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

• Tipik Kullanım Durumları: Öncelikle sürücü belgeleri ve ulusal kimlikler gibi devlet tarafından verilen kimlik belgeleri. Hem yüz yüze (ör. trafik durdurmaları, kısıtlı ürünler için yaş doğrulama) hem de çevrimiçi (ör. devlet hizmetlerine erişim, banka hesabı açma 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 (ihraç için), OpenID Foundation tarafından geliştirilen spesifikasyonlardır. Doğrulanabilir kimlik bilgilerinin değişimini desteklemek için OAuth 2.0'ı genişletirler. Bunlar, sadece devlet değil, çeşitli kimlik bilgisi türleri için geniş birlikte çalışabilirliği hedefleyen açık standartlardır. 2025 başı itibarıyla OpenID4VP ileri taslak aşamalarındadır (ör. Nisan itibarıyla taslak 28). OpenID4VCI da 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ında W3C Doğrulanabilir Kimlik Bilgilerini (VC'ler), mdoc'ları, SD-JWT'leri ve diğer formatları taşıyabilirler. Etkileşim modeli, Doğrulayıcıdan (RP) bir Yetkilendirme İsteği ve Tutucunun Cüzdanından bir vp_token (Doğrulanabilir Sunum Belirteci) içeren bir yanıtı içerir. Seçici ifşa genellikle Presentation Exchange (DIF PE) veya Dijital Kimlik Bilgileri Sorgu Dili (DCQL) gibi sorgu dilleri kullanılarak yönetilir.
• Tipik Kullanım Durumları: Kimlik doğrulama, nitelik kanıtı sağlama (ör. eğitim diplomaları, profesyonel sertifikalar), üyelik tasdikleri ve daha fazlası dahil olmak üzere geniş bir uygulama yelpazesi. Bir güvenen tarafın çeşitli vericilerden gelen iddiaları doğrulaması gereken çevrimiçi etkileşimler için çok uygundurlar.

Bunların her zaman birbirini dışlayan şeyler olmadığı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 ihraç 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 uygulaması, mDoc'ları transfer eden OpenID4VP desteğini ve mDoc ile SD-JWT-VC formatlarında PID (Kişisel Kimlik Verileri) ve mDL'lerin ihracı için OpenID4VCI desteğini içerir. Böylesine büyük ölçekli bir proje tarafından sağlanan bu ikili destek, her iki protokol ailesinin de önemini vurgulamaktadır.

Mart 2026 güncellemesi: AB'nin Dijital Kimlik Bilgileri API'sine olan bağlılığı daha somut hale geldi. EUDI Mimari Referans Çerçevesi (ARF) Konu F, artık EUDI Cüzdan Birimlerinin ve Güvenen Tarafların uzaktan sunum ve tasdik ihraç akışları için DC API'sini desteklemesini koşullu olarak zorunlu kılıyor. Koşullar arasında DC API'sinin W3C Önerisi statüsüne ulaşması ve işlevsellik, tarayıcı/işletim sistemi tarafsızlığı, gizlilik ve hizmet reddi koruması ile ilgili beklentileri karşılaması yer alıyor. Avrupa Cüzdan Konsorsiyumu (EWC), DC API test senaryolarını uygunluk testi programına dahil etti ve NOBID konsorsiyumu, DC API'sinin şu anda taşıdığı protokol olan OpenID4VP kullanarak ödeme pilotlarını tamamladı.

Bununla birlikte, bazı gözlemciler "ABD'li Büyük Teknoloji" şirketlerinden büyük ölçüde etkilenen Dijital Kimlik Bilgileri API'sinin, nihai EUDI Cüzdan spesifikasyonlarına derinlemesine dahil edilebileceğini belirttikleri için bu yönelim eleştirisiz değil. Bu GitHub tartışması gibi topluluk forumlarında tartışıldığı üzere, AB dışı kuruluşların AB altyapısının kritik bir parçası üzerindeki potansiyel etkisi hakkında endişeler dile getirildi. Ayrı olarak, spesifikasyonda ISO 18013-7 referansının sabitlenmesi kararı, Ping Identity'den bir itiraz aldı; ücretli erişim duvarı (paywall) arkasındaki bir spesifikasyona normatif olarak referans vermenin açık web ilkeleriyle çeliştiği savunuldu — bu endişe, spesifikasyon Aday Öneri aşamasına geçtiğinde resmi bir itiraz olarak ortaya çıkabilir.

Dijital Kimlik Bilgileri API'si için tarayıcı manzarası artık şekillendi; Chrome 141 ve Safari 26, Eylül 2025'te kararlı destek sundu. Tarayıcılar arasında yaklaşım ve destek düzeylerinde dikkate değer farklılıklar var.

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

Özellik Tespiti (Feature Detection):

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

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

Bu makalenin önceki versiyonlarında, Apple'ın yaklaşımının org.iso.mdoc protokolüne odaklanarak Google'ınkinden ayrışacağını tahmin etmiştik. Tarihsel bağlam için gerekçemiz şuydu:

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

Bu durum, WWDC25 oturumu Web'de kimlik belgelerini doğrulama (Verify identity documents on the web)'da detaylandırıldı. API, web sitelerinin Apple Cüzdan'da veya üçüncü taraf belge sağlayıcı uygulamalarında saklanan sürücü belgesi gibi kimlik belgelerinden doğrulanabilir bilgiler talep etmesine olanak tanır.

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

• Sadece MDOC: API, ISO/IEC 18013-7 Ek C standardına dayalı olarak yalnızca "org-iso-mdoc" protokol dizesini kullanır. Dijital Kimlik Bilgileri API'sinin Safari uygulamasında OpenID4VP desteği yoktur.
• Sadece Sunum: API, mevcut kimlik bilgilerinin sunumu (doğrulanması) içindir. Apple Cüzdan'a veya diğer uygulamalara ihraç (issuance), ayrı ve tarayıcı dışı bir süreç olmaya devam etmektedir.
• Kullanıcı Odaklı & Güvenli: Akış bir kullanıcı hareketiyle başlatılır ve işletim sisteminin isteği cüzdan uygulamasına iletmeden önce bir korumalı alanda (sandbox) ayrıştırıp doğruladığı bir "kısmi istek" mekanizmasından yararlanarak güvenliği artırır.
• Uygulamalara Genişletilebilir: Apple Cüzdan'a ek olarak, üçüncü taraf uygulamalar da yeni IdentityDocumentServices çerçevesini ve bir uygulama uzantısını uygulayarak belge sağlayıcıları olarak hareket edebilir.
• Cihazlar Arası Destek: Apple olmayan platformlardan cihazlar arası sunum, bir QR kodu devrinden 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 {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Bu doğrulama, tarayıcı pazarındaki farklılaşan stratejileri pekiştiriyor. Chrome esnek OpenID4VP taşıma katmanının üzerine inşa ederken, Apple, resmi kimlik belgeleri için özel olarak tasarlanmış, son derece entegre ve güvenli, ancak daha az esnek bir çözüm sağlamak için ISO mdoc ekosistemine yaptığı derin yatırımdan yararlanıyor.

Mozilla başlangıçta Dijital Kimlik Bilgileri API'si hakkında olumsuz bir standart pozisyonu ifade etmişti. Detaylı olarak belgelenen endişeleri kapsamlıdır ve kullanıcı gizliliğini, iradesini koruma ve açık, adil bir web sağlama misyonlarına dayanmaktadır.

Mozilla tarafından dile getirilen temel endişeler şunlardır:

• Gizlilik Riskleri: Dijital kimlik bilgisi taleplerinin önemsiz etkileşimler için yaygınlaşması durumunda kişisel veri paylaşımının artması 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 devlet tarafından verilen kimlik bilgileri, bir bireyin kimlik sunum tercihiyle uyuşmayabilir.
• Birlikte Çalışabilirlik Sorunları: Kimlik bilgisi formatlarının çoğalmasının, evrensel olarak birlikte çalışabilir bir ekosistem yerine parçalanmış bir ekosisteme yol açması endişesi.
• Seçici İfşa: Seçici ifşanın gizlilik faydalarının, güçlü bağlantısızlık (unlinkability) garantileriyle uygulanmazsa veya kullanıcılar neyin paylaşıldığını tam olarak anlamazsa zayıflayabileceği endişeleri.
• Güvenin Merkezileşmesi ve Kullanıcı İradesi: API'nin güvenin merkezileşmesinin artmasına ve kullanıcı iradesinin azalmasına yol açarak mevcut toplumsal güç dengesizliklerini sürdürebileceği korkuları.

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 etti.

Mart 2026 güncellemesi — Uygulama devam ediyor: Resmi olumsuz pozisyon teknik olarak değişmeden kalsa da, Mozilla Dijital Kimlik Bilgileri API'sini aktif olarak uygulamaya başladı. 2026'nın 1. çeyreğinde, temel DC API desteği Firefox 149'a (bir tercih bayrağının arkasında) eklendi ve meta bug 2004828 altında izleniyor. Kaynak kodu DigitalCredential.cpp, WebIDL bağlamaları ve IPC tesisatı dahil olmak üzere mozilla-central'da yer alıyor. Masaüstü ve Android izin istemleri (bug 2010091, bug 2010093) üzerindeki çalışmalar devam ediyor.

Üç Mozilla mühendisi — John Schanck, Martin Thomson ve Benjamin VanderSloot — W3C FedID Çalışma Grubu'nun aktif üyeleridir ve Schanck, kimlik bilgisi sunum algoritması ve istek hazırlama algoritması dahil olmak üzere önemli spesifikasyon PR'larına (Pull Request) uygulama bilgisine dayalı geri bildirimler sağlamaktadır.

Bu önemli bir gelişmedir: Mozilla, API'nin kötüye kullanım potansiyeli konusundaki endişelerini sürdürürken, tasarımı diğer tarayıcı satıcılarına bırakmak yerine, hem spesifikasyon çalışmaları hem de uygulama yoluyla API'yi içeriden şekillendirmeyi seçtiği açıktır. Bu, Dijital Kimlik Bilgileri API'sinin, Mozilla'nın daha güçlü gizlilik korkulukları (kimlik bilgisi istekleri için önerilen bir şeffaflık günlüğü dahil) için bastırmasıyla birlikte, muhtemelen üç tarayıcı desteğine doğru bir yolda olduğunu işaret ediyor.

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

Kullanıcılardan dijital kimlik bilgileri 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 (mdoc) desteğiyle protokol bağımsız olduğu göz önüne alındığında, en geniş erişimi hedefleyen RP'ler her iki yaklaşıma dayalı etkileşimleri desteklemeye hazırlanmalıdır.

Bu, aşağıda gösterildiği gibi her iki protokol yolunu da yönetebilen sistemlerin mimarisini oluşturmak anlamına gelir.

Bu durum karmaşıklık eklese de, tüm kullanıcıları tek bir protokol yoluna zorlamaya çalışmak, seçilen yola bağlı olarak muhtemelen iOS veya Chrome/Android kullanıcı tabanının önemli bir kısmını dışlayacaktır. Daha fazla geliştirme gerektirse de pragmatik yaklaşım, her ikisini de idare edecek esnekliği oluşturmaktır.

Güvenen Taraflar, aynı mantıksal bilgi parçasını (ör. "kullanıcı 21 yaşından büyük mü?") talep ederken bile, 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ılaşabileceğinin kesinlikle farkında olmalıdır.

• mdoc Seçici İfşa: org.iso.mdoc, genellikle vericinin bireysel veri öğelerinin tuzlanmış (salted) karmalarını oluşturmasını içeren kendi seçici ifşa mekanizmalarına sahiptir. Tutucunun cüzdanı daha sonra sadece talep edilen öğeleri tuzlarıyla (salts) birlikte ifşa eder, böylece doğrulayıcının diğer verileri görmeden bunları karmalara karşı onaylamasına olanak tanır. Belirli öğeler için istek, 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şa: OpenID4VP genellikle isteğin presentation_definition'ına gömülü Presentation Exchange (DIF PE) veya daha yeni Dijital Kimlik Bilgileri Sorgu Dili (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 kendi veri gereksinimlerini bu değişen protokol yapılarıyla eşleştirmeleri gerekir. Yalnızca gereken minimum verinin talep edilmesini ve işlenmesini sağlamak, böylece gizlilik en iyi uygulamalarına ve veri minimizasyonu ilkelerine uymak için seçici ifşanın her bir protokolde nasıl uygulandığının ve talep edildiğinin nüanslarını anlamak çok önemlidir. Cüzdan tarafından döndürülen ifşa edilen verilerin formatı ve yapısı da farklı olabilir, bu da RP'nin arka ucunda (backend) ayrı ayrıştırma ve doğrulama mantığı gerektirir.

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

Cüzdan vericileri, cüzdan oluşturma, sistem entegrasyonu ve Dijital Kimlik Bilgileri API'si ile etkileşim konusunda 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 tutucusu olarak kaydolmasına olanak tanıyan bir Holder API içerir. Bu kayıtlı tutucu uygulamaları daha sonra sistem tarafından yönetilen kimlik bilgisi sunum akışlarına katılabilir, Dijital Kimlik Bilgileri API'sinden (Chrome aracılığıyla) veya yerel uygulama doğrulayıcılarından gelen isteklere yanıt verebilir. Android ayrıca kimlik bilgisi ihracı için OpenID4VCI'yı açıkça destekler ve kullanıcıların yeni verilen kimlik bilgilerini almak için uyumlu bir üçüncü taraf cüzdan seçmelerine olanak tanır. Tam kimlik bilgisi tutucu yetenekleri için yerel uygulamalar birincil odak noktası olsa da, sistem daha geniş katılım için tasarlanmıştır.

• iOS: Apple ekosistemi üzerinde daha sıkı bir kontrol sürdürür. Üçüncü taraf cüzdan uygulamaları App Store'da var olabilse de, yüksek güvenceli kimlik bilgileri (Apple Cüzdan için tasarlanan mDL'ler gibi) için sistem düzeyinde kimlik bilgisi tutucuları olarak derinlemesine entegre olma yetenekleri genellikle Apple'ın özel süreçlerine ve yetkilendirmelerine tabidir. Örneğin Apple Cüzdan'a bir kimlik eklemek, eyalet yetkili makamlarını 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 öncelikli odak noktası yetkili kaynaklardan, yani Apple Cüzdan'ın kendisinden ve kayıtlı üçüncü taraf belge sağlayıcı uygulamalarından sunulan org.iso.mdoc olacaktır.

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

Apple Cüzdan, 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 sağlayabilen 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üvenilen sertifika otoritelerini içerir.
2. Bir Uygulama Uzantısı Uygulamak: Projeye bir "Identity Document Provider" (Kimlik Belgesi Sağlayıcı) 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 üzerinde tam entegre bir cüzdan oluşturmanın yerel bir uygulama oluşturmayı ve PWA'lar gibi web teknolojilerini değil, Apple'ın özel çerçevelerini kullanmayı gerektirdiği anlamına gelse de, üçüncü taraf uygulamaların Apple Cüzdan'ın yanında belge sağlayıcıları olarak hareket etmesi için net, ancak sıkı bir şekilde kontrol edilen bir mekanizma vardır. Bu, Safari'deki Dijital Kimlik Bilgileri API'si ile etkileşimin, işletim sistemi tarafından yönetildiğini ve daha sonra istekleri Apple Cüzdan'a veya diğer herhangi bir kayıtlı ve yetkili belge sağlayıcı uygulamasına gönderdiğini doğrular.

Dijital Kimlik Bilgileri API'si, kimlik doğrulama ve kimlik bilgisi sunumuna daha güvenli, kullanıcı odaklı ve gizliliği koruyan bir yaklaşım sunarak dijital kimlik alanında önemli bir ilerlemeyi temsil ediyor. Chrome 141 (30 Eylül 2025) ve Safari 26'nın (15 Eylül 2025) kararlı sunum desteğini yayınlaması ve Firefox 149'un artık temel uygulama kodunu taşımasıyla API, üç tarayıcı desteğine doğru ilerliyor. Manzara değiştikçe bu makaleyi güncel tutacağız.

Ekim 2025'ten bu yana geçen dönem, API'nin deneysel bir taşıyıcıdan yönetilen bir standarda olgunlaşmasıyla tanımlandı. TPAC'de (Kasım 2025) açık protokol kaydının kaldırılması en net sinyaldir: W3C FedID WG artık API'nin desteklediği protokolleri açıkça isimlendiriyor ve yönetiyor. Bu, kapsamlı güvenlik ve gizlilik incelemesine olanak tanır ancak aynı zamanda Çalışma Grubunu bir bekçi yapar; bu, tüm katılımcıların rahat olmadığı kasıtlı bir takastır (özellikle Ping Identity'nin ISO ödeme duvarı itirazı çözülmeden kalmıştır).

Bu arada API, sunumdan tam yaşam döngüsüne genişliyor: Chrome 143'ün navigator.credentials.create() aracılığıyla ihraç Origin Trial'ı, web sitelerinin cüzdan sağlamayı tetiklemesine olanak tanır. Ancak, kötü niyetli cüzdan uygulamalarının ihraç kodlarını ele geçirebildiği bir cüzdan seçimi bağlama güvenlik açığı, bu özelliğin hükümet tarafından benimsenmesini engelliyor.

Düzenleyici cephede, AB'nin ARF Konu F belgesi, spesifikasyonun W3C Önerisine ulaşmasını bekleyerek tüm EUDI üye devlet cüzdanları için DC API desteğini koşullu olarak zorunlu kılıyor. Gerçek dünya benimsemesi hızlanıyor: California DMV DC API desteği ekledi ve Avrupa Cüzdan Konsorsiyumu tarafından uygunluk test takımları geliştiriliyor.

Zorluklar devam ediyor. Çift protokol gerçeği (Chrome'un çoklu protokol desteğine karşı Safari'nin sadece mdoc odağı), güvenen taraflar için devam ediyor. Tarayıcıların listelenen tüm protokolleri mi yoksa sadece birini mi desteklemesi gerektiği sorusu çözülmemiş durumda — bu doğrudan Apple'ın platform kısıtlamalarına bağlı. Ve gizlilik hususları, protokol dahil etme kriterleri için normatif gerekliliklerin hala yazılmamış olmasıyla, Aday Öneri'ye doğru ilerlemeyi engelleyen tek en büyük boşluk olmaya devam ediyor. Spesifikasyonun W3C Önerisi olmasına 1–2 yıl kaldığı tahmin ediliyor.