Digital Credentials API (2025): Chrome ve Safari (WWDC25)

Son güncelleme: 15 Temmuz 2025 (WWDC25 sonrası)

Büyük tarayıcılardaki 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 anlık görüntüsü:

Dijital kimlik bilgileri, şu sıralar kimlik alanında oldukça popüler bir konu. Hayatlarımız dijital dünyayla giderek daha fazla iç içe geçerken, kimliğimizi ve niteliklerimizi çevrimiçi ortamda güvenli, kullanıcı merkezli ve gizliliği koruyan yollarla kanıtlama ihtiyacı hiç bu kadar kritik olmamıştı. Geleneksel yöntemler eskimeye başladığını gösteriyor ve daha sağlam çözümlere olan talep elle tutulur düzeyde.

Bu makalede, web'de kimlik bilgileriyle nasıl etkileşim kurduğumuzu yeniden şekillendirmeyi vaat eden önemli bir gelişme olan Digital Credentials API'nin mevcut durumunu ele almayı amaçlıyoruz. Temel mekanizmalarını, desteklediği protokolleri, mevcut tarayıcı benimsemesini inceleyecek ve bu hızla gelişen ortamda yol alan hem relying party'ler hem de wallet issuer'ları için öneriler sunacağız.

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

Bazı ülkelerde, çözümler öncelikle mevcut güvenilir ilişkileri çevrimiçi kimlik tespiti için kullanmak üzere hizmetler geliştiren ilk 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öntem, geleneksel olarak yüksek efor gerektiren 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 video görüşmeleri 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 olabilirler ve sık sık gelişmiş sahteciliğe karşı savunmasız oldukları ortaya çıkmıştır.

Bu zorluk, deepfake'lerin, gelişmiş yapay zeka güdümlü taklit tekniklerinin ve giderek daha sofistike hale gelen kimlik avı saldırılarının ortaya çıkmasıyla ç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ırt etmesini inanılmaz derecede zorlaştırır. Sentetik kimlikler oluşturma veya kontrolleri atlatmak 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 olan acil ihtiyacın altını çiziyor.

Want to try digital credentials yourself in a demo?

Try Digital Credentials

Dijital kimlik bilgilerinin nasıl çalıştığını anlamak, ilgili 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. Issuer: Bir konu hakkında belirli bilgiler için yetkili olan ve bu bilgiyi kanıtlayan bir dijital kimlik bilgisi düzenleyebilen bir kurum (ör. hükümet, üniversite, işveren).
2. Holder: Bilginin sahibi olan (yani kullanıcı), kimlik bilgisini issuer'dan alan ve bir dijital cüzdanda saklayan kişi. Holder, kimlik bilgisinden hangi bilgilerin ne zaman paylaşılacağını kontrol eder.
3. Verifier (veya Relying Party): Bir hizmete veya kaynağa erişim izni vermek için holder hakkında belirli bilgileri doğrulaması gereken bir kurum (ör. bir web sitesi, bir çevrimiçi hizmet). Verifier, gerekli bilgiyi holder'dan talep eder.

Bu üç taraflı model önemlidir çünkü kullanıcıyı (holder) 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. Holder, tüm kimlik bilgisini ifşa etmek 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 dahil edilmesidir. Issuer, kimlik bilgisini dijital olarak imzalayarak özgünlüğünü ve bütünlüğünü sağlar. Holder ise, genellikle dijital cüzdanı içinde (cihaz donanımı tarafından korunan) güvence altına alınan özel anahtarını kullanarak kimlik bilgisi üzerindeki kontrolünü kanıtlar ve bir verifier'a sunulmasını yetkilendirir. Bu genellikle verifier'ın bir sınama (rastgele bir veri parçası) sunmasını içerir ve holder'ın cüzdanı bu sınamayı kimlik bilgisiyle ilişkili özel anahtarı kullanarak imzalar. Verifier daha sonra ilgili açık anahtarı kullanarak imzayı onaylayabilir ve böylece sunumu doğrulayabilir.

Bu açıklama protokol-bağımsızdır, çünkü kriptografik sınamalar yoluyla düzenleme, tutma ve 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 gibi özellikleri (yasal olarak bağlayıcı imzalar için AB Dijital Kimlik Cüzdanı gibi kapsamlı çözümlerde görüldüğü gibi) destekleyebilse de, buradaki odak, özellikle Digital Credentials API 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 Digital Credentials API'ye odaklanmaktadır.

Temel Terminoloji:

• Dijital kimlik bilgisi: Herhangi bir makine tarafından okunabilir kimlik bilgisi (barkodlu PDF, ISO mDL, W3C VC, SD-JWT, vb.). "Dijital" kelimesi kriptografik doğrulanabilirlik hakkında bir şey söylemez.
• 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: issuer → holder → verifier.
• Verifiable Credential API: Arka uç sistemler (issuer'lar, cüzdanlar, verifier'lar) arasında VC'leri düzenlemek, saklamak, sunmak ve doğrulamak için bir REST/HTTP hizmet arayüzü.
• Digital Credentials API (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ğe saygılı 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'yi bir arka uç belirtimi ve DC API'yi kimlik bilgilerini Web'e sunan ön uç uygulaması olarak düşünün. Katman 1'in (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. Düzenleme (VC API - issuer ↔ cüzdan): Eyalet DMV, "Holder 18 yaşından büyüktür" diyen bir Verifiable Credential düzenler.
2. Saklama (Cüzdan uygulaması - OS): Kimlik bilgisi, kripto kanıtıyla birlikte kullanıcının cüzdanında durur.
3. Talep (DC API aracılığıyla navigator.credentials.get() - web sitesi → tarayıcı): Bira dükkanı web sitesi sorar: "Kullanıcının ≥18 olduğuna dair kanıt göster."
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 bir doğrulanabilir sunum geri gönderir.
5. Doğrulama (VC API - bira dükkanı arka ucu): Sitenin arka ucu imzayı ve issuer'ın DID/açık anahtarını doğrular; erişim izni verir.

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ç sistemler için standart REST uç noktaları: VC API tarafından çözüldü.
• Cüzdan ↔ Web sitesi el sıkışması (gizliliği koruyan): 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ı (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. Verifiable Credential, 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 bir altyapıdır.
4. Digital Credentials API, 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 tamamlar, rekabet etmezler—aynı yığının farklı katmanlarında yer alırlar ve birlikte açık Web'de güvenli, kullanıcı merkezli kimlik sağlarlar.

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

Sunum katmanındaki kritik bileşen olarak Digital Credentials API, 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 çaba, Nisan 2025'te FedID Topluluk Grubu'ndan taşınarak öncelikle W3C'nin Federated Identity Çalışma Grubu (FedID WG) bünyesinde yer almaktadır. Resmi taslak belirtimi burada bulunabilir: https://w3c-fedid.github.io/digital-credentials/.

2025 itibarıyla, API'nin hala önemli değişikliklerden geçtiği belirtilmektedir. Bu, aktif geliştirme aşamasında olduğunu vurgulamaktadır. Buna rağmen potansiyeli önemlidir. Chrome, Origin Trial ile halka açık bir şey sunan ilk tarayıcı oldu ve geliştiricilerin yetkinliklerini denemelerine olanak tanıdı. Chrome ayrıca bunu Android'de Credential Manager sistemi aracılığıyla yerel olarak desteklemekte ve yakın zamanda masaüstünde Cihazlar Arası Digital Credentials API kullanımını da yayınlamıştır.

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 Digital Credentials 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, 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() {
    // Digital Credentials API 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 amacıyla burada statik olarak tanımlanmıştır.
            const oid4vp = {
                protocol: "oid4vp", // Cüzdanlara bir OpenID4VP talebi örneği. // https://github.com/openid/OpenID4VP/issues/125'e dayanmaktadır
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange talebi, kısalık için atlandı
                    },
                },
            };
 
            // bir Abort Controller oluştur
            const controller = new AbortController();
 
            // Arka uçtan gelen sunum talebini kullanarak Digital Credentials API'yi çağır
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Şifrelenmiş yanıtı şifre çözme ve doğrulama için arka uca gönder
            // Kısaltma amacıyla atlandı
        } catch (error) {
            console.error("Hata:", error);
        }
    } else {
        // yedek senaryo, sadece açıklayıcı
        alert("Digital Credentials API bu tarayıcıda desteklenmiyor.");
    }
}

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

Digital Credentials API, 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 temel işletim sisteminin yeteneklerinden yararlanarak talebe uyan mevcut cüzdanları ve kimlik bilgilerini keşfeder. Tarayıcı ve işletim sistemi daha sonra kimlik bilgisini seçmek ve yayınlanması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 kendisine opak (şifreli) olması, şifre çözme ve yorumlamanın relying party ve cüzdan/holder tarafından yapılması amaçlanmaktadır.

Digital Credentials API, protokol-bağımsız olacak şekilde tasarlanmıştır, yani kimlik bilgisi değişimi için çeşitli temel 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 Verifiable Presentations için OpenID (OpenID4VP) ve Verifiable Credential Issuance için OpenID (OpenID4VCI) belirtimleri.

• Köken ve Standardizasyon: org.iso.mdoc, öncelikle mobil Sürücü Belgeleri (mDL'ler) olmak üzere mobil belgeler için veri formatını ve etkileşim modelini ifade eder ve Uluslararası Standardizasyon Örgütü (ISO) ile Uluslararası Elektroteknik Komisyonu (IEC) tarafından standartlaştırılmıştır. 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 protokollerini tanımlayan ISO/IEC 18013-5'tir. ISO/IEC 18013-7, bunu mDL'lerin çevrimiçi/uzaktan sunumunu sağlamak için genişletir. "org.iso.mdoc" protokol dizesi, Digital Credentials API 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 issuer kimlik doğrulaması, cihaz bağlama, holder 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 Alanları: Öncelikle sürücü belgeleri ve ulusal kimlikler gibi hükümet tarafından verilen kimlik belgeleri. Hem yüz yüze (ör. trafik kontrolleri, kısıtlı ürünler için yaş doğrulaması) hem de çevrimiçi (ör. hükümet hizmetlerine erişim, banka hesabı açmak 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 (düzenleme için), OpenID Foundation tarafından geliştirilen belirtimlerdir. Doğrulanabilir kimlik bilgilerinin değişimini 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 amaçlayan açık standartlardır. 2025 başı itibarıyla, OpenID4VP ileri taslak aşamalarındadır (ör. 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ında W3C Verifiable Credentials (VC'ler), mdoc'lar, SD-JWT'ler ve diğer formatları taşıyabilirler. Etkileşim modeli, Verifier'dan (RP) bir Yetkilendirme Talebi ve Holder'ın Cüzdanından bir vp_token (Verifiable Presentation Token) içeren bir yanıt içerir. Seçici ifşa genellikle Presentation Exchange (DIF PE) veya daha yeni olan Digital Credentials Query Language DCQL gibi sorgu dilleri kullanılarak yönetilir.
• Tipik Kullanım Alanları: Kimlik doğrulama, nitelik kanıtı sağlama (ör. eğitim diplomaları, mesleki sertifikalar), üyelik tasdikleri ve daha fazlası dahil olmak üzere geniş bir uygulama yelpazesi. Bir relying party'nin çeşitli issuer'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 düzenleme akışları için OpenID4VP ve OpenID4VCI'yi kullanarak hem mdoc'u (özellikle Mobil Sürücü Belgeleri için) hem de W3C Verifiable Credentials'ı desteklemeyi açıkça planlamaktadır. Referans uygulaması, mDoc'ları aktaran OpenID4VP ve mDoc ve SD-JWT-VC formatlarında PID ve mDL'ler düzenleyen OpenID4VCI desteğini içerir. Böylesine 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ğildir, çünkü bazı gözlemciler, büyük ölçüde "ABD Bigtech" şirketlerinden etkilenen Digital Credentials API'nin, nihai EUDI Cüzdan belirtimlerine derinden dahil olabileceğini belirtmektedir. Bu GitHub tartışması gibi topluluk forumlarında tartışıldığı üzere, AB dışı kuruluşların AB'nin kritik bir altyapı parçası üzerindeki potansiyel etkisi hakkında endişeler dile getirilmiştir.

Yaklaşım ve destek seviyelerinde belirgin farklılıklarla birlikte, Digital Credentials API için tarayıcı manzarası hala şekillenmektedir.

Google Chrome, özellikle Android'de, Digital Credentials API'nin erken bir benimseyicisi ve uygulayıcısı olmuştur. Origin Trial'lar yürüttüler ve bunu Android'in yerel Credential Manager'ı ile entegre ettiler. Chrome'un uygulaması, navigator.credentials.get() API çağrısı aracılığıyla kimlik bilgileri talep etmek için protokol olarak öncelikle OpenID4VP'den yararlanır. OpenID4VP'nin kendisi formattan bağımsız olsa ve yük olarak org.iso.mdoc veya W3C Verifiable Credentials taşıyabilse de, Google'dan gelen pratik vurgu, taşıma mekanizması olarak OpenID4VP akışına yönelik gibi görünüyor. Android'in Credential Manager'ı ayrıca sunum için OpenID4VP'yi ve düzenleme için OpenID4VCI'yi yerel olarak destekler. Bu, Android uygulamalarının bu standartları kullanarak kimlik bilgisi sahipleri ve doğrulayıcıları olarak hareket etmelerini sağlar.

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 şöyleydi:

Doğru tahmin ettiğimiz gibi, WWDC25 bu stratejiyi doğruladı. Konferansta Apple, Safari 26'da (2025 Sonbaharında iOS 26 ve diğer işletim sistemi güncellemeleriyle birlikte gönderilecek) API desteğini resmi olarak duyurdu ve uygulamalarının sunum için yalnızca org.iso.mdoc protokolünü 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:

• Sadece MDOC: API, ISO/IEC 18013-7 Ek C standardına dayalı olarak yalnızca "org-iso-mdoc" protokol dizesini kullanır. Safari'nin Digital Credentials API uygulamasında OpenID4VP desteği yoktur.
• Sadece Sunum: API, mevcut kimlik bilgilerinin sunumu (doğrulanması) içindir. Apple Wallet'a veya diğer uygulamalara düzenleme, ayrı, tarayıcı dışı bir süreç olarak kalır.
• Kullanıcı Merkezli ve Güvenli: Akış bir kullanıcı hareketiyle başlatılır ve işletim sisteminin talebi cüzdan uygulamasına geçirmeden önce bir sanal alanda ayrıştırıp doğruladığı bir "kısmi talep" 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.

Apple, bir relying party'nin API'yi nasıl kullanacağına dair net bir kod örneği sundu:

async function verifyIdentity() {
    try {
        // Sunucu, talep verilerini oluşturur ve kriptografik olarak imzalar.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // Talep, 'org-iso-mdoc' protokolünü belirtir.
        const request = {
            protocol: "org-iso-mdoc",
            // data, kriptografik olarak imzalanmış mdoc talebini 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önderin.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Doğrulanmış ayrıntıları görüntüleyin...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Hataları ele alın, ör. kullanıcı iptali.
    }
}

Bu onay, tarayıcı pazarındaki farklı stratejileri pekiştiriyor. Chrome esnek OpenID4VP taşıma katmanı üzerine inşa ederken, Apple, resmi kimlik belgelerine göre uyarlanmış, daha az esnek olmasına rağmen son derece entegre ve güvenli bir çözüm sağlamak için ISO mdoc ekosistemindeki derin yatırımından yararlanıyor.

Mozilla, mevcut haliyle Digital Credentials API önerisi hakkında resmi olarak "olumsuz" bir pozisyon ifade etmiştir. Endişeleri kapsamlıdır ve kullanıcı gizliliğini, özerkliğini koruma ve açık, adil bir web sağlama misyonlarına dayanmaktadır.

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

• Gizlilik Riskleri: Dijital kimlik bilgileri taleplerinin önemsiz etkileşimler için yaygınlaşması durumunda 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 devlet tarafından verilen kimlik bilgileri, bir bireyin kimlik sunumu seçimiyle 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ı endişeleri.
• Seçici İfşa: Seçici ifşanın gizlilik faydalarının, güçlü bağlantısızlık garantileriyle uygulanmazsa veya kullanıcılar neyin paylaşıldığını tam olarak anlamazsa baltalanabileceği endişeleri.
• Güvenin ve Kullanıcı Özerkliğinin Merkezileştirilmesi: API'nin güvenin artan 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 daha iyi hale getirmesi ve kullanıcıların çıkarlarına öncelik vermesi 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 Grubu'nun bu potansiyel zararları azaltmak için aktif olarak çalışmasını tavsiye etmiştir.

Tablo 1: Digital Credentials API ve Protokoller için Tarayıcı Desteği

Kullanıcılardan dijital kimlik bilgileri talep etmeyi ve doğrulamayı amaçlayan kuruluşlar (Relying Party'ler veya RP'ler) için mevcut manzara dikkatli stratejik planlama gerektirir.

Önemli pazar payına sahip Safari'nin, Digital Credentials API aracılığıyla doğrudan org.iso.mdoc etkileşimlerine öncelik vermesi muhtemel olduğundan ve Chrome/Android'in mdoc'ları veya diğer Verifiable Credential formatlarını taşıyabilen OpenID4VP'yi vurguladığı 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, şunları yapabilen sistemler tasarlamak anlamına gelir:

1. navigator.credentials.get() API'si aracılığıyla kimlik bilgisi talepleri başlatmak, potansiyel olarak tarayıcı algılamasına veya user agent yeteneklerine göre farklı protokol parametreleri ("org.iso.mdoc" veya "openid4vp") belirtmek.
2. Doğrudan bir mdoc formatında veya OpenID4VP aracılığıyla bir vp_token olarak gelebilecek yanıtları işlemek, bu da daha sonra temel kimlik bilgisini (kendisi bir mdoc veya başka bir VC formatı olabilir) çıkarmak için ayrıştırılması gerekir.

Bu karmaşıklık eklese de, tüm kullanıcıları tek bir protokol yoluna zorlamaya çalışmak, seçilen yola bağlı olarak ya iOS ya da Android/Chrome 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 etmek için esneklik oluşturmaktır.

Relying Party'ler, aynı mantıksal bilgi parçasını (ör. "kullanıcı 21 yaşından büyük mü?") talep ederken bile, bunun bir talepte 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 farkında olmalıdır.

• mdoc Seçici İfşa: org.iso.mdoc, seçici ifşa için kendi mekanizmalarına sahiptir, bu genellikle issuer'ın bireysel veri öğelerinin tuzlanmış hash'lerini oluşturmasını içerir. Holder'ın cüzdanı daha sonra yalnızca istenen öğeleri tuzlarıyla birlikte ifşa eder, bu da verifier'ı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şa: OpenID4VP genellikle talebin presentation_definition'ı içine gömülü Presentation Exchange (DIF PE) veya daha yeni olan 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 istenen bilgileri içeren bir Verifiable Presentation 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, 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 farklı ayrıştırma ve doğrulama mantığı gerektirebilir.

Dijital kimlik bilgileri düzenlemek ve holder'lar için cüzdan uygulamaları sağlamak isteyen kurumlar için işletim sistemi ortamı çok önemli bir rol oynamaktadır.

Wallet issuer'ları, cüzdan oluşturma, sistem entegrasyonu ve Digital Credentials API 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 sahibi olarak kaydolmasına olanak tanıyan bir Holder API içerir. Bu kayıtlı holder uygulamaları daha sonra sistem tarafından yönetilen kimlik bilgisi sunum akışlarına katılabilir ve Digital Credentials API'den (Chrome aracılığıyla) veya yerel uygulama doğrulayıcılarından gelen taleplere yanıt verebilir. Android ayrıca kimlik bilgisi düzenlemesi için OpenID4VCI'yi açıkça destekler, bu da kullanıcıların yeni düzenlenen kimlik bilgilerini almak için uyumlu bir üçüncü taraf cüzdanı seçmelerine 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 tasarlanmış mDL'ler gibi) için sistem düzeyinde kimlik bilgisi sahipleri olarak derinlemesine entegre olma yetenekleri genellikle Apple'ın özel süreçlerine ve yetkilerine tabidir. Örneğin, Apple Wallet'a bir kimlik eklemek, eyalet düzenleyici makamlarını ve Apple'ın doğrulamasını içeren kontrollü bir akıştır. Safari'deki Digital Credentials API 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 "kapalı bahçe" 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 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 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 Kaydetme: Uygulamanın yönettiği mdoc'ları işletim sistemine kaydetmek için IdentityDocumentProviderRegistrationStore'u kullanın. Bu kayıt, belge türünü ve talep imzalama için güvenilir sertifika yetkililerini içerir.
2. Bir Uygulama Uzantısı Uygulama: Projeye bir "Identity Document Provider" UI Uygulama Uzantısı ekleyin. 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östermekten sorumludur.

Bu, iOS'ta tam entegre bir cüzdan oluşturmanın, PWA'lar gibi web teknolojileri yerine yerel bir uygulama oluşturmayı ve Apple'ın özel çerçevelerini kullanmayı gerektirdiği anlamına gelir - ancak üçüncü taraf uygulamaların Apple Wallet'ın yanı sıra 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 Digital Credentials API ile etkileşimin işletim sistemi tarafından yönetildiğini ve ardından talepleri Apple Wallet'a veya diğer kayıtlı ve yetkili belge sağlayıcı uygulamalarına gönderdiğini doğrular.

Digital Credentials API, dijital kimlik alanında önemli bir ilerlemeyi temsil ediyor ve kimlik doğrulama ve kimlik bilgisi sunumuna daha güvenli, kullanıcı merkezli ve gizliliği koruyan bir yaklaşım sunuyor. Ekosistem geliştikçe, hem relying party'lerin hem de wallet issuer'ları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 çok önemlidir. Tarayıcı desteği ve protokol vurgusundaki mevcut parçalanma, relying party'lerin ve wallet issuer'ların şimdilik karmaşık bir manzarada yol alması gerektiği anlamına geliyor.