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

Terakhir diperbarui: 15 Juli 2025 (pasca-WWDC25)

Berikut adalah ringkasan singkat dukungan Digital Credentials API di browser utama:

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

Kredensial digital sedang menjadi topik 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 keadaan terkini dari Digital Credentials API, sebuah perkembangan penting yang menjanjikan untuk membentuk kembali cara kita berinteraksi dengan informasi identitas di web. Kita akan menjelajahi mekanisme yang mendasarinya, protokol yang didukungnya, adopsi browser saat ini, dan menawarkan rekomendasi bagi relying party maupun penerbit wallet dalam 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 muncul, terutama didorong oleh konsorsium bank awal yang mengembangkan layanan untuk memanfaatkan hubungan tepercaya yang sudah ada untuk identifikasi online. Pemerintah juga turun tangan, memberlakukan atau menyediakan layanan dan wallet identitas digital nasional. Namun, solusi-solusi ini sering kali terkotak-kotak, terbatas secara geografis, dan tidak dapat dioperasikan secara universal.

Solusi cadangan untuk verifikasi identitas di banyak wilayah secara tradisional melibatkan proses dengan friksi tinggi. Verifikasi fisik di kantor pos, misalnya, menimbulkan penundaan dan ketidaknyamanan yang signifikan. Panggilan video yang dikombinasikan dengan unggahan dokumen menjadi alternatif yang lebih digital, diikuti oleh maraknya pemindaian dokumen otomatis dan pemeriksaan keaktifan (liveness checks) baru-baru ini. Meskipun ada kemajuan, metode-metode ini memiliki kelemahan yang signifikan. Metode ini bisa memakan waktu, rentan terhadap kesalahan atau bias manusia, dan sering kali terbukti rentan terhadap pemalsuan canggih.

Tantangan ini 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 membuat 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 try digital credentials yourself in a demo?

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, berputar di sekitar 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 informasi (yaitu, pengguna) yang menerima kredensial dari penerbit dan menyimpannya di wallet digital. Pemegang mengontrol kapan dan informasi apa dari kredensial yang dibagikan.
3. 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. Verifier meminta informasi yang diperlukan dari pemegang.

Model tiga pihak ini penting karena bertujuan untuk menempatkan pengguna (pemegang) dalam kendali atas 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 bagian informasi mana yang akan dibagikan dari sebuah kredensial untuk transaksi tertentu, daripada mengungkapkan seluruh kredensial.

Aspek mendasar 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 sering kali diamankan di dalam wallet digital mereka (yang dilindungi oleh perangkat keras perangkat), untuk membuktikan kontrol atas kredensial dan untuk mengotorisasi penyajiannya kepada verifier. Ini biasanya melibatkan verifier yang menyajikan sebuah tantangan (challenge) (sepotong data acak) yang ditandatangani oleh wallet pemegang menggunakan kunci privat yang terkait dengan kredensial. Verifier kemudian dapat menggunakan kunci publik yang sesuai untuk mengonfirmasi tanda tangan, sehingga mengautentikasi penyajian tersebut.

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

Artikel ini berkonsentrasi pada verifikasi kredensial digital dan prinsip pengungkapan selektif, yang memungkinkan pengguna untuk membuktikan atribut tertentu (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 EU Digital Identity Wallet untuk tanda tangan yang mengikat secara hukum), fokus di sini, terutama untuk Digital Credentials API, adalah pada penegasan 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 jika kita 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 Digital Credentials API, 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 keterverifikasian secara kriptografis.
• Verifiable Credential: Sejenis kredensial digital, yang didefinisikan oleh W3C VC Data Model. Ini menambahkan bukti anti-rusak dan bukti kriptografis, dan selalu ada di dunia tiga pihak: penerbit → pemegang → verifier.
• Verifiable Credential API: Antarmuka layanan REST/HTTP untuk menerbitkan, menyimpan, menyajikan, dan memverifikasi VC antara sistem back-end (penerbit, wallet, verifier).
• Digital Credentials API (DC API): API browser / sistem operasi (JavaScript + perpipaan asli) yang memungkinkan situs web meminta wallet di sisi perangkat pengguna untuk menyajikan kredensial digital apa pun yang didukung (VC, ISO mDoc, SD-JWT …) dengan cara yang menghormati privasi.

Pikirkan VC sebagai model data, VC API sebagai spesifikasi back-end, dan DC API 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 bergantung pada format kredensial.

Alur end-to-end (contoh: verifikasi usia online):

1. Terbitkan (VC API - penerbit ↔ wallet): Dinas Lalu Lintas negara bagian menerbitkan Verifiable Credential yang menyatakan "Pemegang berusia di atas 18 tahun".
2. Simpan (Aplikasi Wallet - OS): Kredensial berada di wallet pengguna dengan bukti kriptografisnya.
3. Minta (navigator.credentials.get() melalui DC API - situs web → browser): Situs web toko bir bertanya: "Tunjukkan bukti bahwa pengguna berusia ≥18 tahun."
4. Sajikan (DC API mengirimkan ke wallet → OpenID4VP (protokol) → payload VC): Wallet menunjukkan UI persetujuan, pengguna menyetujui, wallet mengirimkan presentasi yang dapat diverifikasi kembali.
5. Verifikasi (VC API - 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 DC API, protokol pertukaran di bawahnya adalah OpenID4VP, dan pemeriksaan di sisi server menggunakan VC API.

Mengapa ada pemisahan:

• Model data yang dapat dioperasikan (bukti kriptografis, pengungkapan selektif): Dipecahkan oleh VC Data Model (& format lain).
• Endpoint REST standar untuk sistem back-end: Dipecahkan oleh VC API.
• Jabat tangan Wallet ↔ Situs web yang menjaga privasi: Dipecahkan oleh DC API.
• 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 DC API.

Poin-poin penting:

1. "Kredensial digital" adalah istilah payung.
2. Verifiable Credential adalah sejenis kredensial digital dengan keterverifikasian kriptografis bawaan.
3. VC API adalah perpipaan server-ke-server untuk operasi siklus hidup pada VC.
4. Digital Credentials API adalah jembatan browser-ke-wallet yang akhirnya memungkinkan kredensial tersebut mengalir dengan lancar ke aplikasi Web, apa pun format konkretnya.
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 secara keseluruhan dari kredensial digital, artikel ini sekarang akan membahas lebih dalam tentang lapisan presentasi, khususnya berfokus pada Digital Credentials API dan keadaannya saat ini.

Sebagai komponen krusial di lapisan presentasi, Digital Credentials API 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 wallet 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 tahun 2025, API ini masih digambarkan sedang mengalami perubahan signifikan. Ini menyoroti fase pengembangan aktifnya. Meskipun demikian, potensinya sangat besar. Chrome telah menjadi yang pertama merilis sesuatu secara publik, dengan Origin Trial-nya, yang memungkinkan pengembang untuk bereksperimen dengan kemampuannya. Chrome juga mendukung ini secara native di Android melalui sistem Credential Manager dan baru-baru ini juga menerbitkan dukungan untuk penggunaan Cross-Device Digital Credentials API di desktop.

API ini memperluas Credential Management API yang ada dengan memungkinkan permintaan kredensial digital melalui navigator.credentials.get(). Menurut W3C FedID WG Digital Credentials Explainer (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 mungkin memanggil API untuk meminta kredensial menggunakan OpenID4VP:

async function requestCredential() {
    // Periksa dukungan Digital Credentials API
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Parameter ini biasanya diambil dari backend.
            // Didefinisikan secara statis di sini untuk tujuan ilustrasi ekstensibilitas protokol.
            const oid4vp = {
                protocol: "oid4vp", // Contoh permintaan OpenID4VP ke wallet. // Berdasarkan https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Permintaan Presentation Exchange, dihilangkan untuk keringkasan
                    },
                },
            };
 
            // buat Abort Controller
            const controller = new AbortController();
 
            // Panggil Digital Credentials API menggunakan permintaan presentasi dari backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Kirim respons terenkripsi ke backend untuk dekripsi dan verifikasi
            // Dihilangkan untuk keringkasan
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // skenario fallback, hanya ilustrasi
        alert("Digital Credentials API tidak didukung di browser ini.");
    }
}

Contoh ini diambil dari sini.

Digital Credentials API pada dasarnya bertindak sebagai pembungkus atau perantara yang aman. Ini memungkinkan browser untuk menengahi permintaan informasi identitas, memanfaatkan kemampuan sistem operasi yang mendasarinya untuk menemukan wallet dan kredensial yang tersedia yang cocok dengan permintaan. Browser dan OS kemudian dapat menyajikan antarmuka pengguna yang konsisten untuk memilih kredensial dan mengotorisasi pelepasannya, 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 wallet/pemegang.

Digital Credentials API dirancang untuk menjadi agnostik-protokol, yang berarti dapat mendukung berbagai protokol yang mendasari untuk pertukaran kredensial. Namun, dua keluarga utama protokol 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 Standardisasi: 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 Digital Credentials API.

• 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 jaminan tinggi, baik secara langsung (misalnya, pemeriksaan lalu lintas, verifikasi usia untuk barang terbatas) maupun online (misalnya, mengakses layanan pemerintah, verifikasi identitas jarak jauh untuk pembukaan rekening bank).

• Asal dan Standardisasi: OpenID4VP (untuk presentasi) dan OpenID4VCI (untuk penerbitan) adalah spesifikasi yang dikembangkan oleh OpenID Foundation. Mereka memperluas OAuth 2.0 untuk mendukung pertukaran kredensial yang dapat diverifikasi. Ini adalah standar terbuka yang ditujukan untuk interoperabilitas luas untuk berbagai jenis kredensial, bukan hanya pemerintah. Pada awal 2025, OpenID4VP berada dalam tahap draf lanjutan (misalnya, draf 28 per April). OpenID4VCI juga sedang dimatangkan.
• Model Data: OpenID4VP/VCI dirancang untuk menjadi agnostik-format kredensial. Mereka dapat membawa W3C Verifiable Credentials (VC) dalam format JSON/JSON-LD atau JWT, mdocs, SD-JWT, dan format lainnya. Model interaksi melibatkan Permintaan Otorisasi dari Verifier (RP) dan respons dari Wallet Pemegang yang berisi vp_token (Verifiable Presentation Token). Pengungkapan selektif biasanya dikelola menggunakan bahasa kueri seperti Presentation Exchange (DIF PE) atau Digital Credentials Query Language (DCQL) yang lebih baru.
• Kasus Penggunaan Umum: Berbagai macam 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.

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

European Union Digital Identity (EUDI) Wallet adalah inisiatif besar yang bertujuan untuk menyediakan semua warga negara dan penduduk Uni Eropa dengan wallet digital yang aman untuk dokumen identitas dan atestasi. Arsitektur dan kerangka acuan EUDI Wallet secara eksplisit berencana untuk mendukung baik mdoc (terutama untuk Surat Izin Mengemudi Seluler) maupun W3C Verifiable Credentials, 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 formats. Dukungan ganda oleh proyek skala besar seperti ini menggarisbawahi pentingnya kedua keluarga protokol. Namun, arah ini bukannya tanpa kritik, karena beberapa pengamat mencatat bahwa Digital Credentials API, yang sangat dipengaruhi oleh perusahaan "Bigtech AS", mungkin akan sangat tergabung dalam spesifikasi akhir EUDI Wallet. 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 Digital Credentials API masih dalam proses pembentukan, dengan perbedaan mencolok dalam pendekatan dan tingkat dukungan.

Google Chrome, terutama di Android, telah menjadi pengadopsi dan pelaksana awal Digital Credentials API. Mereka telah menjalankan Origin Trials dan mengintegrasikannya dengan Credential Manager asli Android. Implementasi Chrome terutama memanfaatkan OpenID4VP sebagai protokol untuk meminta kredensial melalui panggilan API navigator.credentials.get(). Meskipun OpenID4VP sendiri agnostik-format dan dapat membawa org.iso.mdoc atau W3C Verifiable Credentials sebagai payload, penekanan praktis dari Google tampaknya adalah pada alur OpenID4VP sebagai mekanisme transport. Credential Manager Android juga secara native mendukung OpenID4VP untuk presentasi dan OpenID4VCI untuk penerbitan. Hal ini memungkinkan aplikasi Android untuk bertindak sebagai pemegang dan verifier kredensial menggunakan standar ini.

Dalam versi sebelumnya dari artikel ini, 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. Di konferensi tersebut, Apple secara resmi mengumumkan dukungan untuk API di Safari 26 (dirilis bersama iOS 26 dan pembaruan OS lainnya pada Musim Gugur 2025), mengonfirmasi bahwa implementasi mereka secara eksklusif mendukung protokol org.iso.mdoc 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.

Poin-poin 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 Digital Credentials API di Safari.
• Hanya Presentasi: API ini untuk presentasi (verifikasi) kredensial yang ada. Penerbitan ke Apple Wallet atau aplikasi lain tetap merupakan proses terpisah, non-browser.
• Berpusat pada Pengguna & Aman: Alur dimulai oleh gestur pengguna dan memanfaatkan mekanisme "permintaan parsial", di mana OS pertama-tama mengurai dan memvalidasi permintaan dalam sandbox sebelum meneruskannya ke aplikasi wallet, sehingga meningkatkan keamanan.
• Dapat Diperluas ke Aplikasi: Selain Apple Wallet, aplikasi pihak ketiga dapat bertindak sebagai penyedia dokumen dengan mengimplementasikan kerangka kerja IdentityDocumentServices yang baru dan ekstensi aplikasi.

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

async function verifyIdentity() {
    try {
        // Server menghasilkan dan menandatangani data permintaan secara kriptografis.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // Permintaan menentukan protokol 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data berisi permintaan mdoc yang ditandatangani secara kriptografis.
            data,
        };
 
        // API harus dipanggil dari dalam gestur pengguna.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Kirim respons terenkripsi dari wallet ke server untuk dekripsi dan validasi.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Tampilkan detail yang diverifikasi...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Tangani kesalahan, mis., pembatalan oleh pengguna.
    }
}

Konfirmasi ini memperkuat 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 "negatif" terhadap proposal Digital Credentials API 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 sejalan 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 kekuatan sosial yang ada.

Mozilla mengakui bahwa API semacam itu dapat menawarkan utilitas di atas metode ad-hoc yang ada untuk presentasi kredensial tetapi menekankan bahwa fitur platform web baru harus secara nyata 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 Digital Credentials API & Protokol

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

Mengingat Safari, dengan pangsa pasarnya yang signifikan, kemungkinan akan memprioritaskan interaksi org.iso.mdoc langsung melalui Digital Credentials API, dan Chrome/Android menekankan OpenID4VP (yang dapat membawa mdocs atau format Verifiable Credential lainnya), 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(), berpotensi menentukan parameter protokol yang berbeda ("org.iso.mdoc" atau "openid4vp") berdasarkan deteksi browser atau kapabilitas user agent.
2. Memproses respons yang mungkin datang langsung dalam format mdoc atau sebagai vp_token melalui OpenID4VP, yang kemudian perlu diurai untuk mengekstrak kredensial yang mendasarinya (yang bisa jadi mdoc 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 Android/Chrome, tergantung pada jalur yang dipilih. Pendekatan pragmatis, meskipun lebih intensif pengembangan, adalah membangun fleksibilitas untuk menangani keduanya.

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

• Pengungkapan Selektif mdoc: org.iso.mdoc memiliki mekanisme sendiri untuk pengungkapan selektif, biasanya melibatkan penerbit yang membuat hash dengan salt dari elemen data individual. Wallet pemegang kemudian hanya mengungkapkan elemen yang diminta beserta salt-nya, memungkinkan verifier untuk mengonfirmasinya terhadap hash tanpa melihat data lain. Permintaan untuk elemen spesifik terikat pada namespace dan pengidentifikasi elemen data yang telah ditentukan sebelumnya 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. Wallet kemudian membuat Verifiable Presentation yang hanya berisi informasi yang diminta, jika didukung oleh format kredensial dan wallet.

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 wallet mungkin juga berbeda, memerlukan logika penguraian dan validasi yang berbeda di backend RP.

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

Penerbit wallet menghadapi lanskap yang sangat berbeda di iOS dan Android mengenai pembuatan wallet, integrasi sistem, dan interaksi dengan Digital Credentials API.

• Android: Umumnya menawarkan ekosistem yang lebih terbuka. Android Credential Manager menyertakan Holder API yang memungkinkan aplikasi native pihak ketiga untuk mendaftar sebagai pemegang kredensial. Aplikasi pemegang terdaftar ini kemudian dapat berpartisipasi dalam alur presentasi kredensial yang dimediasi oleh sistem, menanggapi permintaan dari Digital Credentials API (melalui Chrome) atau verifier aplikasi native. Android juga secara eksplisit mendukung OpenID4VCI untuk penerbitan kredensial, memungkinkan pengguna untuk memilih wallet pihak ketiga yang kompatibel untuk menerima kredensial yang baru diterbitkan. Meskipun aplikasi native 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 wallet pihak ketiga dapat ada di App Store, kemampuan mereka untuk berintegrasi secara mendalam sebagai pemegang kredensial tingkat sistem untuk kredensial 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 Digital Credentials API 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 "walled garden" Apple sudah mapan, dan implementasi kredensial digital mereka tidak terkecuali. Namun, WWDC25 mengklarifikasi jalur untuk partisipasi pihak ketiga.

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

Untuk berpartisipasi dalam alur web, aplikasi native harus:

1. Mendaftarkan Dokumen: Gunakan 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: Tambahkan Ekstensi Aplikasi UI "Identity Document Provider" 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 wallet yang terintegrasi penuh di iOS memerlukan pembangunan aplikasi native dan menggunakan kerangka kerja spesifik Apple—bukan teknologi web seperti PWA—ada mekanisme yang jelas, meskipun dikontrol dengan ketat, bagi aplikasi pihak ketiga untuk bertindak sebagai penyedia dokumen di samping Apple Wallet. Ini mengonfirmasi bahwa interaksi dengan Digital Credentials API di Safari dikelola oleh OS, yang kemudian mengirimkan permintaan ke Apple Wallet atau aplikasi penyedia dokumen terdaftar dan resmi lainnya.

Digital Credentials API merupakan kemajuan signifikan dalam ruang identitas digital, menawarkan pendekatan yang lebih aman, berpusat pada pengguna, dan menjaga privasi untuk verifikasi identitas dan presentasi kredensial. Seiring berkembangnya ekosistem, sangat penting bagi relying party dan penerbit wallet 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 wallet 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 umat manusia. Fragmentasi saat ini dalam dukungan browser dan penekanan protokol berarti bahwa relying party dan penerbit wallet harus menavigasi lanskap yang kompleks untuk saat ini.