API Kredensial Digital (2025): Dukungan Langsung di Chrome & Safari

Terakhir diperbarui: 30 Oktober 2025

Berikut adalah gambaran singkat tentang dukungan API Kredensial Digital di browser-browser utama:

Dunia kredensial digital bergerak dengan cepat. Berikut adalah ringkasan perkembangan utama dan proyeksinya:

Want to experience digital credentials in action?

Try Digital Credentials

Apa yang Berubah Sejak Juli 2025?

• Dirilis: Chrome 141 (30 Sep 2025) & Safari 26 (15 Sep 2025).
• Chrome: Agnostik protokol (OpenID4VP dan ISO 18013-7 Annex C), lintas perangkat desktop melalui CTAP.
• Safari: Hanya mdoc (org-iso-mdoc), alur lintas perangkat melalui CTAP.
• Bentuk API: navigator.credentials.get(); penamaan requests/data; deteksi fitur DigitalCredential.

Kredensial digital adalah topik yang sedang hangat di dunia identitas saat ini. Seiring hidup kita yang semakin terhubung dengan dunia digital, kebutuhan akan cara yang aman, berpusat pada pengguna, dan menjaga privasi untuk menyatakan identitas dan kualifikasi kita secara online menjadi semakin penting. Metode tradisional mulai terasa usang, dan permintaan akan solusi yang lebih kuat sangat terasa.

Dalam artikel ini, kita akan membahas kondisi terkini dari API Kredensial Digital, sebuah perkembangan penting yang menjanjikan akan mengubah cara kita berinteraksi dengan informasi identitas di web. Kita akan menjelajahi mekanisme dasarnya, protokol yang didukungnya, adopsi browser saat ini, dan menawarkan rekomendasi untuk relying party maupun penerbit dompet yang menavigasi lanskap yang berkembang pesat ini.

Membuktikan identitas secara andal dan aman telah menjadi tantangan yang terus-menerus dalam arsitektur web selama bertahun-tahun. Meskipun internet memfasilitasi konektivitas dan pertukaran informasi yang belum pernah terjadi sebelumnya, internet juga membuka jalan baru untuk penipuan dan pemalsuan identitas.

Di beberapa negara, solusi mulai muncul, terutama didorong oleh konsorsium bank awal yang mengembangkan layanan untuk memanfaatkan hubungan tepercaya yang sudah ada untuk identifikasi online. Pemerintah juga turut andil, memberlakukan atau menyediakan layanan dan dompet identitas digital nasional. Namun, solusi ini seringkali terisolasi, terbatas secara geografis, dan tidak dapat dioperasikan secara universal.

Solusi cadangan untuk verifikasi identitas di banyak wilayah secara tradisional melibatkan proses yang berbelit-belit. Verifikasi fisik di kantor pos, misalnya, menimbulkan penundaan dan ketidaknyamanan yang signifikan. Panggilan video yang digabungkan dengan unggahan dokumen menjadi alternatif yang lebih digital, diikuti oleh maraknya pemindaian dokumen otomatis dan pemeriksaan keaktifan (liveness check).

Meskipun ada kemajuan, metode-metode ini memiliki kelemahan yang signifikan. Prosesnya bisa memakan waktu, rentan terhadap kesalahan atau bias manusia, dan sering kali terbukti rentan terhadap pemalsuan canggih.

Tantangannya meningkat secara dramatis dengan munculnya deepfake, teknik peniruan canggih yang didorong oleh AI, dan serangan phishing yang semakin canggih. Teknologi ini dapat membuat bukti video, audio, dan dokumen yang sangat realistis tetapi sepenuhnya palsu, sehingga sangat sulit bagi sistem tradisional, dan bahkan alat verifikasi bertenaga AI, untuk membedakan pengguna asli dari penipu. Potensi untuk menciptakan identitas sintetis atau memanipulasi data biometrik untuk melewati pemeriksaan adalah ancaman serius, terutama bagi lembaga keuangan dan layanan apa pun yang memerlukan proses Know Your Customer (KYC) yang kuat. Lanskap ancaman yang meningkat ini menggarisbawahi kebutuhan mendesak akan mekanisme identitas dan verifikasi online yang lebih aman dan dapat diverifikasi secara kriptografis.

Want to experience digital credentials in action?

Try Digital Credentials

Memahami cara kerja kredensial digital melibatkan melihat para pemain kunci yang terlibat dan berbagai lapisan teknologi yang memungkinkan fungsionalitasnya.

Pada intinya, konsep kredensial digital, terutama dalam konteks API web baru, berkisar pada model tiga pihak:

1. Penerbit (Issuer): Entitas (misalnya, pemerintah, universitas, perusahaan) yang berwenang atas informasi tertentu tentang subjek dan dapat menerbitkan kredensial digital yang membuktikan informasi tersebut.
2. Pemegang (Holder): Subjek dari informasi (yaitu, pengguna) yang menerima kredensial dari penerbit dan menyimpannya dalam dompet digital. Pemegang mengontrol kapan dan informasi apa dari kredensial yang dibagikan.
3. Penguji (Verifier) (atau Relying Party): Entitas (misalnya, situs web, layanan online) yang perlu memverifikasi informasi tertentu tentang pemegang untuk memberikan akses ke layanan atau sumber daya. Penguji meminta informasi yang diperlukan dari pemegang.

Model tiga pihak ini penting karena bertujuan untuk menempatkan pengguna (pemegang) sebagai pengendali data mereka sendiri. Tidak seperti sistem identitas tradisional di mana data mungkin disimpan secara terpusat atau dibagikan antar pihak tanpa perantaraan langsung dari pengguna, model ini menekankan persetujuan pengguna dan pengungkapan selektif. Pemegang memutuskan informasi mana yang akan dibagikan dari sebuah kredensial untuk transaksi tertentu, daripada mengungkapkan seluruh kredensial.

Aspek fundamental dari sistem ini adalah keterlibatan pasangan kunci kriptografis. Penerbit menandatangani kredensial secara digital, memastikan keaslian dan integritasnya. Pemegang, pada gilirannya, menggunakan kunci privat mereka, yang seringkali diamankan di dalam dompet digital mereka (yang dilindungi oleh perangkat keras perangkat), untuk membuktikan kontrol atas kredensial dan untuk mengotorisasi penyajiannya kepada penguji. Ini biasanya melibatkan penguji yang menyajikan sebuah tantangan (sepotong data acak) yang kemudian ditandatangani oleh dompet pemegang menggunakan kunci privat yang terkait dengan kredensial tersebut. Penguji kemudian dapat menggunakan kunci publik yang sesuai untuk mengonfirmasi tanda tangan, sehingga mengotentikasi penyajian.

Penjelasan ini bersifat netral-protokol, karena prinsip-prinsip inti penerbitan, kepemilikan, dan verifikasi melalui tantangan kriptografis adalah umum di berbagai teknologi yang mendasarinya.

Artikel ini berkonsentrasi pada verifikasi kredensial digital dan prinsip pengungkapan selektif, yang memungkinkan pengguna untuk membuktikan atribut spesifik (misalnya, "Saya berusia di atas 18 tahun," "Saya memiliki SIM yang valid") tanpa mengungkapkan seluruh dokumen sumber. Meskipun sistem yang mendasari kredensial digital mungkin mendukung fitur seperti Tanda Tangan Elektronik Berkualifikasi (QES) dan kemampuan penandatanganan jarak jauh (seperti yang terlihat dalam solusi komprehensif seperti Dompet Identitas Digital Uni Eropa untuk tanda tangan yang mengikat secara hukum), fokus di sini, terutama untuk API Kredensial Digital, adalah pada asersi identitas dan verifikasi atribut untuk interaksi online, bukan terutama pada fungsionalitas penandatanganan yang lebih luas ini.

Untuk memahami bagaimana kredensial digital berfungsi, akan sangat membantu untuk memvisualisasikan model berlapis. Setiap lapisan menangani aspek yang berbeda dari ekosistem, dari format data itu sendiri hingga bagaimana data itu disajikan kepada pengguna di browser web. Artikel ini terutama berfokus pada API Kredensial Digital, yang beroperasi di lapisan presentasi.

Terminologi Inti:

• Kredensial digital: Kredensial apa pun yang dapat dibaca mesin (PDF dengan barcode, ISO mDL, W3C VC, SD-JWT, dll.). "Digital" tidak mengatakan apa-apa tentang verifikasi kriptografis.
• Kredensial Terverifikasi: Jenis kredensial digital, yang didefinisikan oleh Model Data VC W3C. Ini menambahkan bukti anti-pemalsuan dan bukti kriptografis, dan selalu berada dalam dunia tiga pihak: penerbit → pemegang → penguji.
• API Kredensial Terverifikasi: Antarmuka layanan REST/HTTP untuk menerbitkan, menyimpan, menyajikan, dan memverifikasi VC antara sistem back-end (penerbit, dompet, penguji).
• API Kredensial Digital (API DC): API browser/sistem operasi (JavaScript + penunjang asli) yang memungkinkan situs web meminta dompet di sisi perangkat pengguna untuk menyajikan kredensial digital apa pun yang didukung (VC, ISO mDoc, SD-JWT ...) dengan cara yang menjaga privasi.

Anggaplah VC sebagai model data, API VC sebagai spesifikasi back-end, dan API DC sebagai implementasi front-end yang menyajikan kredensial ke Web. Segala sesuatu di atas lapisan 1 (lapisan Model Data) bersifat agnostik-format; segala sesuatu di bawahnya tergantung pada format kredensial.

Alur menyeluruh (contoh: verifikasi usia online):

1. Penerbitan (API VC - penerbit ↔ dompet): Dinas Perhubungan menerbitkan Kredensial Terverifikasi yang menyatakan "Pemegang berusia di atas 18 tahun".
2. Penyimpanan (Aplikasi dompet - OS): Kredensial berada di dompet pengguna dengan bukti kriptografisnya.
3. Permintaan (navigator.credentials.get() melalui API DC - situs web → browser): Situs web toko bir bertanya: "Tunjukkan bukti bahwa pengguna berusia ≥18 tahun."
4. Penyajian (API DC meneruskan ke dompet → OpenID4VP (protokol) → payload VC): Dompet menampilkan UI persetujuan, pengguna menyetujui, dompet mengirimkan kembali presentasi yang dapat diverifikasi.
5. Verifikasi (API VC - back-end toko bir): Back-end situs memverifikasi tanda tangan dan DID/kunci publik penerbit; memberikan akses.

Perhatikan bagaimana datanya adalah VC, transport di Web adalah API DC, protokol pertukaran di bawahnya adalah OpenID4VP, dan pemeriksaan di sisi server menggunakan API VC.

Mengapa ada pemisahan ini:

• Model data yang dapat dioperasikan (bukti kriptografis, pengungkapan selektif): Dipecahkan oleh Model Data VC (& format lain).
• Endpoint REST standar untuk sistem back-end: Dipecahkan oleh API VC.
• Jabat tangan Dompet ↔ Situs web yang menjaga privasi: Dipecahkan oleh API DC.
• Tingkat kepercayaan/jenis dokumen yang berbeda (ID pemerintah vs. sertifikat kursus): Dipecahkan dengan Menggunakan format yang tepat (ISO mDoc untuk ID dengan jaminan tinggi; W3C VC untuk klaim umum) di bawah API DC.

Poin-poin penting:

1. "Kredensial digital" adalah istilah payung.
2. Kredensial Terverifikasi adalah jenis kredensial digital dengan verifikasi kriptografis bawaan.
3. API VC adalah penunjang server-ke-server untuk operasi siklus hidup pada VC.
4. API Kredensial Digital adalah jembatan browser-ke-dompet yang akhirnya memungkinkan kredensial tersebut mengalir dengan lancar ke aplikasi Web, dalam format konkret apa pun.
5. Ketiga bagian ini saling melengkapi, bukan bersaing—mereka berada di lapisan yang berbeda dari tumpukan yang sama dan bersama-sama memungkinkan identitas yang aman dan berpusat pada pengguna di web terbuka.

Setelah menjelajahi para partisipan dan arsitektur berlapis keseluruhan dari kredensial digital, artikel ini sekarang akan membahas lebih dalam tentang lapisan presentasi, dengan fokus khusus pada API Kredensial Digital dan keadaannya saat ini.

Sebagai komponen penting di lapisan presentasi, API Kredensial Digital adalah standar web yang saat ini sedang dikembangkan untuk menyediakan cara yang aman dan terstandarisasi bagi situs web untuk meminta dan menerima informasi identitas digital dari dompet digital pengguna. Upaya ini terutama berada di dalam Federated Identity Working Group (FedID WG) W3C, setelah bermigrasi dari FedID Community Group pada April 2025. Draf spesifikasi resmi dapat ditemukan di sini: https://w3c-fedid.github.io/digital-credentials/.

Pada Oktober 2025, API ini telah dirilis dalam versi stabil baik di Chrome 141 (30 Sep 2025) maupun Safari 26 (15 Sep 2025). Implementasi Chrome bersifat agnostik protokol, mendukung baik OpenID4VP maupun ISO 18013-7 Annex C, sementara Safari secara eksklusif mendukung protokol org-iso-mdoc. Chrome mendukung ini secara asli di Android melalui sistem Credential Manager dan juga mendukung API Kredensial Digital Lintas Perangkat di desktop melalui serah terima QR yang didukung CTAP/BLE.

API ini memperluas Credential Management API yang sudah ada dengan memungkinkan permintaan kredensial digital melalui navigator.credentials.get(). Menurut Penjelasan Kredensial Digital W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), API telah kembali menggunakan antarmuka yang sudah mapan ini daripada navigator.identity yang diusulkan sebelumnya. Sebuah situs web meminta kredensial digital dengan memanggil navigator.credentials.get() dengan parameter spesifik untuk kredensial digital.

Berikut adalah contoh ilustratif tentang bagaimana sebuah situs web dapat memanggil API untuk meminta kredensial menggunakan OpenID4VP:

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.");
    }
}

Contoh ini diambil dari sini.

API Kredensial Digital pada dasarnya bertindak sebagai pembungkus atau perantara yang aman. API ini memungkinkan browser untuk memediasi permintaan informasi identitas, memanfaatkan kemampuan sistem operasi yang mendasarinya untuk menemukan dompet dan kredensial yang tersedia yang cocok dengan permintaan. Browser dan OS kemudian dapat menyajikan antarmuka pengguna yang konsisten untuk memilih kredensial dan mengotorisasi rilisnya, meningkatkan keamanan dan privasi dengan memastikan persetujuan pengguna dan mencegah situs web mengakses data sensitif secara diam-diam. Data kredensial aktual dalam respons dimaksudkan untuk menjadi buram (terenkripsi) bagi browser itu sendiri, dengan dekripsi dan interpretasi ditangani oleh relying party dan pemegang/dompet.

API Kredensial Digital dirancang agar agnostik terhadap protokol, yang berarti dapat mendukung berbagai protokol yang mendasari untuk pertukaran kredensial. Namun, ada dua keluarga protokol utama yang menjadi pusat implementasi dan diskusi saat ini: org.iso.mdoc (berasal dari ISO 18013-5 dan ekstensinya ISO 18013-7 "Annex C") dan spesifikasi OpenID Foundation, yaitu OpenID for Verifiable Presentations (OpenID4VP) dan OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Asal dan Standarisasi: org.iso.mdoc mengacu pada format data dan model interaksi untuk dokumen seluler, terutama Surat Izin Mengemudi seluler (mDL), yang distandarisasi oleh Organisasi Internasional untuk Standardisasi (ISO) dan Komisi Elektroteknik Internasional (IEC). Standar dasarnya adalah ISO/IEC 18013-5, yang mendefinisikan aplikasi mDL, struktur data, dan protokol untuk presentasi tatap muka (jarak dekat) menggunakan teknologi seperti NFC, Bluetooth, atau kode QR. ISO/IEC 18013-7 memperluas ini untuk memungkinkan presentasi mDL secara online/jarak jauh. String protokol "org.iso.mdoc" secara spesifik didefinisikan dalam ISO/IEC TS 18013-7 (Annex C) untuk digunakan dengan API seperti API Kredensial Digital.

• Model Data: mdocs memiliki struktur data yang didefinisikan secara ketat berdasarkan CBOR (Concise Binary Object Representation) untuk kekompakan dan efisiensi. Ini menentukan namespace dan elemen data untuk atribut SIM umum dan mendukung fitur keamanan kriptografis yang kuat, termasuk otentikasi penerbit, pengikatan perangkat, otentikasi pemegang (melalui potret), enkripsi sesi, dan pengungkapan selektif.

• Kasus Penggunaan Umum: Terutama dokumen identitas yang dikeluarkan pemerintah seperti surat izin mengemudi dan KTP nasional. Ini dirancang untuk skenario dengan jaminan tinggi, baik secara langsung (misalnya, pemeriksaan lalu lintas, verifikasi usia untuk barang-barang terbatas) maupun online (misalnya, mengakses layanan pemerintah, verifikasi identitas jarak jauh untuk pembukaan rekening bank).

• Asal dan Standarisasi: OpenID4VP (untuk presentasi) dan OpenID4VCI (untuk penerbitan) adalah spesifikasi yang dikembangkan oleh OpenID Foundation. Mereka memperluas OAuth 2.0 untuk mendukung pertukaran kredensial terverifikasi. Ini adalah standar terbuka yang ditujukan untuk interoperabilitas yang luas untuk berbagai jenis kredensial, bukan hanya dari pemerintah. Pada awal 2025, OpenID4VP berada dalam tahap draf lanjutan (misalnya, draf 28 per April). OpenID4VCI juga sedang dimatangkan.
• Model Data: OpenID4VP/VCI dirancang agar agnostik terhadap format kredensial. Mereka dapat membawa Kredensial Terverifikasi W3C (VC) dalam format JSON/JSON-LD atau JWT, mdocs, SD-JWT, dan format lainnya. Model interaksi melibatkan Permintaan Otorisasi dari Penguji (RP) dan respons dari Dompet Pemegang yang berisi vp_token (Token Presentasi Terverifikasi). Pengungkapan selektif biasanya dikelola menggunakan bahasa kueri seperti Presentation Exchange (DIF PE) atau yang lebih baru, Digital Credentials Query Language (DCQL).
• Kasus Penggunaan Umum: Beragam aplikasi, termasuk verifikasi identitas, memberikan bukti kualifikasi (misalnya, ijazah pendidikan, sertifikasi profesional), atestasi keanggotaan, dan banyak lagi. Mereka sangat cocok untuk interaksi online di mana relying party perlu memverifikasi klaim dari berbagai penerbit.

Penting untuk menyadari bahwa ini tidak selalu saling eksklusif. OpenID4VP dapat, misalnya, digunakan untuk meminta dan mengangkut [org.iso.mdoc]. Pilihan seringkali bergantung pada kasus penggunaan spesifik, jenis kredensial, dan partisipan ekosistem.

Dompet Identitas Digital Uni Eropa (EUDI) adalah inisiatif besar yang bertujuan untuk menyediakan semua warga negara dan penduduk Uni Eropa dengan dompet digital yang aman untuk dokumen identitas dan atestasi. Arsitektur dan kerangka referensi Dompet EUDI secara eksplisit berencana untuk mendukung baik mdoc (terutama untuk Surat Izin Mengemudi Seluler) dan Kredensial Terverifikasi W3C, dengan memanfaatkan OpenID4VP dan OpenID4VCI untuk alur presentasi dan penerbitan. Implementasi referensi mencakup dukungan untuk OpenID4VP yang mentransfer mDocs dan OpenID4VCI untuk menerbitkan PID dan mDL dalam format mDoc dan SD-JWT-VC. Dukungan ganda oleh proyek skala besar seperti ini menggarisbawahi pentingnya kedua keluarga protokol. Namun, arah ini tidak tanpa kritik, karena beberapa pengamat mencatat bahwa API Kredensial Digital, yang sangat dipengaruhi oleh perusahaan "Bigtech AS", mungkin akan sangat tergabung dalam spesifikasi akhir Dompet EUDI. Kekhawatiran telah diangkat tentang potensi pengaruh entitas non-UE pada bagian penting dari infrastruktur UE, seperti yang dibahas dalam forum komunitas seperti diskusi GitHub ini.

Lanskap browser untuk API Kredensial Digital kini telah terbentuk, dengan Chrome 141 dan Safari 26 merilis dukungan stabil pada bulan September 2025. Ada perbedaan mencolok dalam pendekatan dan tingkat dukungan di antara browser.

Chrome merilis API Kredensial Digital di Chrome 141 (30 Sep 2025). Implementasi Chrome bersifat agnostik protokol: kompatibel dengan OpenID4VP dan ISO 18013-7 Annex C (mdoc online). Desktop mendukung presentasi lintas perangkat dari dompet seluler melalui saluran yang didukung CTAP/BLE (serah terima QR), dengan respons yang buram bagi browser. Bentuk API pindah ke navigator.credentials.get(); nama parameter diubah: providers → requests, request → data.

Deteksi Fitur:

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

Credential Manager Android secara asli mendukung OpenID4VP untuk presentasi dan OpenID4VCI untuk penerbitan, memungkinkan aplikasi Android bertindak sebagai pemegang dan penguji kredensial menggunakan standar ini. Google mencatat dukungan dompet yang terus bertambah; Google Wallet adalah pengguna awal, dengan Samsung Wallet dan 1Password telah diumumkan.

Dalam versi artikel ini sebelumnya, kami memprediksi bahwa pendekatan Apple akan berbeda dari Google dengan berfokus pada protokol org.iso.mdoc. Untuk konteks historis, alasan kami adalah sebagai berikut:

Seperti yang kami antisipasi dengan benar, WWDC25 mengonfirmasi strategi ini. Safari 26 (iOS/iPadOS/macOS) dirilis pada 15 September 2025 dengan dukungan API Kredensial Digital, mengonfirmasi bahwa implementasi mereka secara eksklusif mendukung protokol org-iso-mdoc (dengan tanda hubung) untuk presentasi.

Hal ini dirinci dalam sesi WWDC25 Verify identity documents on the web. API ini memungkinkan situs web untuk meminta informasi yang dapat diverifikasi dari dokumen identitas, seperti surat izin mengemudi, yang disimpan di Apple Wallet atau di aplikasi penyedia dokumen pihak ketiga.

Hal-hal penting dari implementasi Apple:

• Hanya MDOC: API ini secara eksklusif menggunakan string protokol "org-iso-mdoc", berdasarkan standar ISO/IEC 18013-7 Annex C. Tidak ada dukungan untuk OpenID4VP dalam implementasi API Kredensial Digital Safari.
• Hanya Presentasi: API ini untuk presentasi (verifikasi) kredensial yang ada. Penerbitan ke Apple Wallet atau aplikasi lain tetap merupakan proses terpisah di luar browser.
• Berpusat pada Pengguna & Aman: Alur dimulai oleh gestur pengguna dan memanfaatkan mekanisme "permintaan parsial", di mana OS pertama-tama mem-parsing dan memvalidasi permintaan dalam sandbox sebelum meneruskannya ke aplikasi dompet, sehingga meningkatkan keamanan.
• Dapat Diperluas ke Aplikasi: Selain Apple Wallet, aplikasi pihak ketiga dapat bertindak sebagai penyedia dokumen dengan mengimplementasikan kerangka kerja IdentityDocumentServices baru dan ekstensi aplikasi.
• Dukungan Lintas Perangkat: Presentasi lintas perangkat dari platform non-Apple menggunakan CTAP untuk kedekatan setelah serah terima kode QR; respons JS tetap terenkripsi/buram bagi browser.

Apple memberikan contoh kode yang jelas tentang bagaimana relying party akan menggunakan API:

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

Konfirmasi ini memantapkan strategi yang berbeda di pasar browser. Sementara Chrome membangun di atas lapisan transport OpenID4VP yang fleksibel, Apple memanfaatkan investasi mendalamnya dalam ekosistem ISO mdoc untuk menyediakan solusi yang sangat terintegrasi dan aman, meskipun kurang fleksibel, yang disesuaikan untuk dokumen identitas resmi.

Mozilla secara resmi menyatakan posisi standar yang negatif terhadap API Kredensial Digital seperti yang ada saat ini. Kekhawatiran mereka komprehensif dan berakar pada misi mereka untuk melindungi privasi pengguna, agensi, dan memastikan web yang terbuka dan adil.

Kekhawatiran utama yang diangkat oleh Mozilla termasuk:

• Risiko Privasi: Potensi peningkatan pembagian data pribadi dan pengurangan anonimitas online jika permintaan kredensial digital menjadi hal biasa untuk interaksi sepele.
• Eksklusi Pengguna: Risiko bahwa individu yang tidak dapat atau memilih untuk tidak menggunakan kredensial digital dapat dikecualikan dari layanan dan komunitas online. Kredensial yang dikeluarkan pemerintah, kasus penggunaan utama, mungkin tidak selaras dengan pilihan presentasi identitas individu.
• Masalah Interoperabilitas: Kekhawatiran tentang proliferasi format kredensial yang mengarah ke ekosistem yang terfragmentasi daripada yang dapat dioperasikan secara universal.
• Pengungkapan Selektif: Kekhawatiran bahwa manfaat privasi dari pengungkapan selektif dapat dirusak jika tidak diimplementasikan dengan jaminan ketidakterkaitan yang kuat, atau jika pengguna tidak sepenuhnya memahami apa yang dibagikan.
• Sentralisasi Kepercayaan dan Agensi Pengguna: Kekhawatiran bahwa API dapat menyebabkan peningkatan sentralisasi kepercayaan dan pengurangan agensi pengguna, melanggengkan ketidakseimbangan kekuasaan sosial yang ada.

Mozilla mengakui bahwa API semacam itu dapat menawarkan kegunaan di atas metode ad-hoc yang ada untuk presentasi kredensial, tetapi menekankan bahwa fitur platform web baru harus secara demonstratif membuat web menjadi lebih baik secara keseluruhan dan memprioritaskan kepentingan pengguna. Meskipun Dewan W3C menolak keberatan formal terkait dengan kekhawatiran ini (untuk memungkinkan pekerjaan dilanjutkan di dalam W3C daripada di tempat yang berpotensi kurang transparan), Dewan merekomendasikan agar Kelompok Kerja secara aktif bekerja untuk mengurangi potensi bahaya ini.

Tabel 1: Dukungan Browser untuk API & Protokol Kredensial Digital (Okt 2025)

Bagi organisasi (Relying Party atau RP) yang bermaksud untuk meminta dan memverifikasi kredensial digital dari pengguna, lanskap saat ini memerlukan perencanaan strategis yang cermat.

Mengingat Safari (dirilis 15 Sep 2025) secara eksklusif mendukung interaksi org-iso-mdoc langsung (ISO 18013-7 Annex C) melalui API Kredensial Digital, dan Chrome (dirilis 30 Sep 2025) bersifat agnostik protokol yang mendukung OpenID4VP dan ISO 18013-7 Annex C (mdoc), RP yang bertujuan untuk jangkauan seluas mungkin harus bersiap untuk mendukung interaksi berdasarkan kedua pendekatan tersebut.

Ini berarti merancang sistem yang dapat:

1. Memulai permintaan kredensial melalui API navigator.credentials.get(), dengan menentukan parameter protokol yang berbeda ("org-iso-mdoc" untuk Safari atau "openid4vp" untuk alur Chrome/OID4VP) berdasarkan deteksi browser atau kapabilitas user agent.
2. Memproses respons yang mungkin datang langsung dalam format mdoc (ISO 18013-7 Annex C) atau sebagai vp_token melalui OpenID4VP, yang kemudian perlu di-parse untuk mengekstrak kredensial yang mendasarinya (yang bisa jadi mdoc itu sendiri atau format VC lain).

Meskipun ini menambah kompleksitas, mencoba memaksa semua pengguna melalui satu jalur protokol kemungkinan akan mengecualikan sebagian besar basis pengguna, baik mereka yang menggunakan iOS atau mereka yang menggunakan Chrome/Android, tergantung pada jalur yang dipilih. Pendekatan yang pragmatis, meskipun lebih intensif pengembangan, adalah membangun fleksibilitas untuk menangani keduanya.

Relying Party harus sangat sadar bahwa bahkan ketika meminta informasi logis yang sama (misalnya, "apakah pengguna berusia di atas 21 tahun?"), cara ini didefinisikan dalam permintaan dan cara dikembalikan dalam respons dapat sangat berbeda antara kueri mdoc langsung dan kueri OpenID4VP (yang mungkin menggunakan Presentation Exchange atau DCQL).

• Pengungkapan Selektif mdoc: org.iso.mdoc memiliki mekanismenya sendiri untuk pengungkapan selektif, biasanya melibatkan penerbit yang membuat hash dengan salt dari elemen data individual. Dompet pemegang kemudian hanya mengungkapkan elemen yang diminta beserta salt-nya, memungkinkan penguji untuk mengonfirmasikannya terhadap hash tanpa melihat data lain. Permintaan untuk elemen spesifik terikat pada namespace dan pengidentifikasi elemen data yang telah ditentukan dalam standar mdoc.
• Pengungkapan Selektif OpenID4VP: OpenID4VP biasanya menggunakan bahasa kueri seperti Presentation Exchange (DIF PE) atau Digital Credentials Query Language (DCQL) yang lebih baru yang disematkan dalam presentation_definition dari permintaan. Ini memungkinkan RP untuk menentukan jenis kredensial dan klaim individual yang mereka butuhkan. Dompet kemudian membangun Presentasi Terverifikasi yang hanya berisi informasi yang diminta, jika didukung oleh format kredensial dan dompet.

RP perlu memetakan persyaratan data spesifik mereka ke struktur protokol yang bervariasi ini. Sangat penting untuk memahami nuansa bagaimana pengungkapan selektif diimplementasikan dan diminta di setiap protokol untuk memastikan bahwa hanya data minimum yang diperlukan yang diminta dan diproses, sehingga mematuhi praktik terbaik privasi dan prinsip minimalisasi data. Format dan struktur data yang diungkapkan yang dikembalikan oleh dompet mungkin juga berbeda, memerlukan logika parsing dan validasi yang berbeda di backend RP.

Bagi entitas yang ingin menerbitkan kredensial digital dan menyediakan aplikasi dompet untuk pemegang, lingkungan sistem operasi memainkan peran penting.

Penerbit dompet menghadapi lanskap yang sangat berbeda di iOS dan Android terkait pembuatan dompet, integrasi sistem, dan interaksi dengan API Kredensial Digital.

• Android: Umumnya menawarkan ekosistem yang lebih terbuka. Android Credential Manager menyertakan Holder API yang memungkinkan aplikasi asli pihak ketiga untuk mendaftar sebagai pemegang kredensial. Aplikasi pemegang yang terdaftar ini kemudian dapat berpartisipasi dalam alur presentasi kredensial yang dimediasi oleh sistem, menanggapi permintaan dari API Kredensial Digital (melalui Chrome) atau penguji aplikasi asli. Android juga secara eksplisit mendukung OpenID4VCI untuk penerbitan kredensial, memungkinkan pengguna untuk memilih dompet pihak ketiga yang kompatibel untuk menerima kredensial yang baru diterbitkan. Meskipun aplikasi asli adalah fokus utama untuk kemampuan pemegang kredensial penuh, sistem ini dirancang untuk partisipasi yang lebih luas.

• iOS: Apple mempertahankan kontrol yang lebih ketat atas ekosistemnya. Meskipun aplikasi dompet pihak ketiga dapat ada di App Store, kemampuan mereka untuk berintegrasi secara mendalam sebagai pemegang kredensial tingkat sistem untuk kredensial dengan jaminan tinggi (seperti mDL yang ditujukan untuk Apple Wallet) sering kali tunduk pada proses dan hak khusus Apple. Menambahkan ID ke Apple Wallet, misalnya, adalah alur terkontrol yang melibatkan otoritas penerbit negara bagian dan verifikasi Apple. Untuk API Kredensial Digital di Safari, interaksi kemungkinan akan dikelola dengan ketat, dengan fokus utama pada org.iso.mdoc yang disajikan dari sumber resmi, yaitu Apple Wallet itu sendiri dan aplikasi penyedia dokumen pihak ketiga yang terdaftar.

Pendekatan "ekosistem tertutup" (walled garden) Apple sudah mapan, dan implementasi kredensial digital mereka tidak terkecuali. Namun, WWDC25 memperjelas jalur untuk partisipasi pihak ketiga.

Sementara Apple Wallet adalah penyedia utama bawaan untuk kredensial seperti mDL negara bagian, Apple telah memperkenalkan kerangka kerja IdentityDocumentServices untuk aplikasi iOS asli. Ini memungkinkan pengembang pihak ketiga untuk membangun aplikasi yang dapat menyediakan dan menyajikan dokumen identitas mereka sendiri.

Untuk berpartisipasi dalam alur web, sebuah aplikasi asli harus:

1. Mendaftarkan Dokumen: Menggunakan IdentityDocumentProviderRegistrationStore untuk mendaftarkan mdocs yang dikelola aplikasi dengan sistem operasi. Pendaftaran ini mencakup jenis dokumen dan otoritas sertifikat tepercaya untuk penandatanganan permintaan.
2. Mengimplementasikan Ekstensi Aplikasi: Menambahkan Ekstensi Aplikasi UI "Penyedia Dokumen Identitas" ke proyek. Ekstensi ini bertanggung jawab untuk menampilkan UI otorisasi kepada pengguna ketika aplikasi dipilih selama alur verifikasi berbasis web.

Ini berarti bahwa meskipun membuat dompet yang terintegrasi penuh di iOS memerlukan pembuatan aplikasi asli dan menggunakan kerangka kerja spesifik Apple—bukan teknologi web seperti PWA—ada mekanisme yang jelas, meskipun dikontrol ketat, bagi aplikasi pihak ketiga untuk bertindak sebagai penyedia dokumen di samping Apple Wallet. Ini mengonfirmasi bahwa interaksi dengan API Kredensial Digital di Safari dikelola oleh OS, yang kemudian meneruskan permintaan ke Apple Wallet atau aplikasi penyedia dokumen lain yang terdaftar dan diotorisasi.

API Kredensial Digital merupakan kemajuan signifikan dalam ruang identitas digital, menawarkan pendekatan yang lebih aman, berpusat pada pengguna, dan menjaga privasi untuk verifikasi identitas dan presentasi kredensial. Dengan Chrome 141 (30 Sep 2025) dan Safari 26 (15 Sep 2025) yang kini merilis dukungan stabil, API ini telah beralih dari eksperimental menjadi siap produksi. Seiring ekosistem yang terus berkembang, sangat penting bagi relying party dan penerbit dompet untuk beradaptasi dan merangkul potensi teknologi baru ini. Kami akan terus memperbarui artikel ini seiring perubahan lanskap.

Namun, tantangan tetap ada. Mencapai interoperabilitas global yang sesungguhnya antara berbagai format kredensial, protokol, dan implementasi dompet adalah tugas yang signifikan. Mengatasi kekhawatiran valid yang diangkat oleh organisasi seperti Mozilla mengenai privasi, eksklusi, dan agensi pengguna adalah hal yang terpenting untuk memastikan teknologi ini melayani kemanusiaan. Pendekatan yang berbeda—implementasi agnostik protokol Chrome versus fokus hanya-mdoc Safari—berarti bahwa relying party dan penerbit dompet harus menavigasi lanskap protokol ganda untuk masa mendatang.