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

Terakhir diperbarui: 26 Maret 2026

Berikut adalah gambaran cepat mengenai dukungan API Kredensial Digital di browser-browser utama:

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

Want to experience digital credentials in action?

Try Digital Credentials

Apa yang Berubah Sejak Oktober 2025?

• Pergeseran tata kelola protokol: W3C FedID WG menghapus registri protokol terbuka di TPAC (Nov 2025) dan sekarang menetapkan protokol yang didukung secara permanen (hardcode) langsung dalam spesifikasi: OpenID4VP, OpenID4VCI, dan ISO 18013-7 Annex C. API ini bukan lagi sekadar "pipa kosong".
• Penerbitan telah tiba: Chrome 143 meluncurkan Origin Trial untuk penerbitan kredensial melalui navigator.credentials.create(), memperluas API di luar fungsi presentasi saja.
• Firefox mengimplementasikan: Meskipun posisi standar negatif tidak berubah, Mozilla mendaratkan kode dasar API DC di Firefox 149 dengan pengerjaan UX yang sedang berlangsung.
• Mandat kondisional UE: Architecture Reference Framework (Topik F) EUDI sekarang secara kondisional mewajibkan dukungan API DC untuk semua wallet negara anggota.
• Adopsi dunia nyata: DMV California menambahkan dukungan API DC ke platform OpenCred mereka (Feb 2026).

Kredensial digital adalah topik hangat di ruang identitas saat ini. Seiring kehidupan kita semakin terhubung dengan ranah digital, kebutuhan akan cara yang aman, berpusat pada pengguna, dan menjaga privasi untuk menegaskan identitas dan kualifikasi kita secara online menjadi semakin kritis. Metode tradisional mulai menunjukkan kelemahannya, dan permintaan akan solusi yang lebih tangguh sangat terasa.

Dalam artikel ini, kita akan membahas keadaan terkini API Kredensial Digital, sebuah perkembangan penting yang menjanjikan untuk membentuk kembali cara kita berinteraksi dengan informasi identitas di web. Kita akan mengeksplorasi mekanisme dasarnya, protokol yang didukungnya, adopsi browser saat ini, dan menawarkan rekomendasi bagi Relying Party maupun penerbit wallet yang sedang menavigasi lanskap yang berkembang pesat ini.

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

Di beberapa negara, solusi muncul terutama didorong oleh konsorsium bank awal yang mengembangkan layanan untuk memanfaatkan hubungan tepercaya yang ada untuk identifikasi online. Pemerintah juga turun tangan, menegakkan atau menyediakan wallet dan layanan identitas digital nasional. Namun, solusi-solusi ini sering kali terkotak-kotak, terbatas secara geografis, dan tidak dapat beroperasi secara universal.

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

Tantangan ini meningkat secara dramatis dengan munculnya deepfake, teknik peniruan berbasis AI yang canggih, dan serangan phishing yang semakin canggih. Teknologi ini dapat membuat bukti video, audio, dan dokumen yang sangat realistis namun sepenuhnya palsu, sehingga sangat sulit bagi sistem tradisional, 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 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 fungsinya.

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

1. Penerbit (Issuer): Entitas (misalnya, pemerintah, universitas, pemberi kerja) yang memiliki otoritas 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 dalam wallet digital. Pemegang mengontrol kapan dan informasi apa dari kredensial yang dibagikan.
3. Verifikator (atau Relying Party): Entitas (misalnya, situs web, layanan online) yang perlu memverifikasi informasi tertentu tentang pemegang untuk memberikan akses ke layanan atau sumber daya. Verifikator 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 perantara pengguna langsung, model ini menekankan persetujuan pengguna dan pengungkapan selektif (selective disclosure). Pemegang memutuskan potongan informasi mana yang akan dibagikan dari kredensial untuk transaksi tertentu, alih-alih 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 pribadi mereka, sering kali diamankan di dalam wallet digital mereka (yang dilindungi oleh perangkat keras perangkat), untuk membuktikan kendali atas kredensial dan untuk mengotorisasi presentasinya ke verifikator. Ini biasanya melibatkan verifikator yang menyajikan tantangan (challenge) yang ditandatangani oleh wallet pemegang menggunakan kunci pribadi yang terkait dengan kredensial tersebut. Verifikator kemudian dapat menggunakan kunci publik yang sesuai untuk mengonfirmasi tanda tangan, sehingga mengautentikasi presentasi tersebut.

Penjelasan ini bersifat netral protokol, karena prinsip inti penerbitan, penyimpanan, dan verifikasi melalui tantangan kriptografis adalah umum di berbagai teknologi dasar.

Artikel ini berkonsentrasi pada verifikasi kredensial digital dan prinsip pengungkapan selektif, yang memungkinkan pengguna 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 Kualifikasi (QES) dan kemampuan penandatanganan jarak jauh (seperti yang terlihat dalam solusi komprehensif seperti Wallet Identitas Digital UE untuk tanda tangan yang mengikat secara hukum), fokus di sini, khususnya untuk API Kredensial Digital, adalah pada asersi identitas dan verifikasi atribut untuk interaksi online.

Untuk memahami fungsi kredensial digital, ada baiknya memvisualisasikan model berlapis. Setiap lapisan menangani aspek ekosistem yang berbeda, mulai dari format data itu sendiri hingga cara penyajiannya kepada pengguna di browser web. Artikel ini terutama berfokus pada API Kredensial Digital, yang beroperasi pada lapisan presentasi.

Terminologi Inti:

• Kredensial digital: Kredensial apa pun yang dapat dibaca mesin (PDF dengan barcode, ISO mDL, W3C VC, SD-JWT, dll.). Kata "Digital" tidak menjamin adanya verifikasi kriptografis.
• Verifiable Credential (Kredensial yang Dapat Diverifikasi): Jenis kredensial digital, didefinisikan oleh Model Data W3C VC. Ini menambahkan bukti kerusakan (tamper-evidence) dan bukti kriptografis, dan selalu hidup di dunia tiga pihak: penerbit → pemegang → verifikator.
• Verifiable Credential API: Antarmuka layanan REST/HTTP untuk menerbitkan, menyimpan, menyajikan, dan memverifikasi VC antara sistem back-end (penerbit, wallet, verifikator).
• Digital Credentials API (DC API): API browser / sistem operasi (JavaScript + perpipaan native) yang memungkinkan situs web meminta wallet di perangkat pengguna untuk menyajikan kredensial digital apa pun yang didukung (VC, ISO mDoc, SD-JWT…) dengan cara yang menghormati privasi.

Anggaplah 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 ujung-ke-ujung (contoh: verifikasi usia online):

Diagram berikut mengilustrasikan bagaimana lapisan-lapisan ini bekerja sama dalam skenario dunia nyata.

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

Mengapa pemisahan ini ada:

• 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 VC API.
• Handshake 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 jaminan tinggi; W3C VC untuk klaim umum) di bawah DC API.

Poin-poin penting:

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

Setelah mengeksplorasi peserta dan arsitektur berlapis keseluruhan kredensial digital, artikel ini sekarang akan membahas lebih dalam tentang lapisan presentasi, khususnya berfokus pada API Kredensial Digital dan statusnya saat ini.

Sebagai komponen penting pada 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 wallet pengguna. Upaya ini terutama ditempatkan di dalam Kelompok Kerja Identitas Terfederasi W3C (FedID WG), setelah bermigrasi dari Kelompok Komunitas FedID pada April 2025. Draf spesifikasi resmi dapat ditemukan di sini: https://w3c-fedid.github.io/digital-credentials/.

Per Oktober 2025, API ini telah dikirimkan dalam versi stabil baik di Chrome 141 (30 Sept 2025) maupun Safari 26 (15 Sept 2025). Implementasi Chrome mendukung OpenID4VP dan ISO 18013-7 Annex C, sementara Safari secara eksklusif mendukung protokol org-iso-mdoc.

Penting (Pembaruan Maret 2026): Hubungan API dengan protokol telah berubah secara fundamental. Pada TPAC di November 2025, W3C FedID WG mencapai konsensus untuk menghapus registri protokol terbuka dan sebaliknya menetapkan secara permanen daftar protokol terbatas yang didukung langsung dalam spesifikasi: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (untuk presentasi), dan openid4vci-v1 (untuk penerbitan). Agen pengguna (browser) diharapkan menolak protokol yang tidak terdaftar. Hal ini menjadikan Kelompok Kerja sebagai penjaga gerbang de facto untuk penambahan protokol di masa mendatang — sebuah pertukaran yang disengaja untuk memungkinkan tinjauan keamanan dan privasi holistik terhadap segala sesuatu yang mengalir melalui API (lihat Draf Kerja saat ini).

Spesifikasi ini sekarang juga mencakup penerbitan kredensial melalui navigator.credentials.create(). Chrome 143 meluncurkan Origin Trial untuk ini, memungkinkan situs web memicu alur penyediaan wallet menggunakan OpenID4VCI. Namun, kerentanan pengikatan pemilihan wallet — di mana aplikasi wallet berbahaya dapat mencegat kode pra-otorisasi penerbitan — tetap menjadi masalah terbuka. Penerbit pemerintah telah mengindikasikan bahwa mereka tidak akan mengadopsi penerbitan yang dimediasi browser sampai masalah ini terselesaikan.

Chrome mendukung presentasi secara native di Android melalui sistem Credential Manager-nya dan juga mendukung API Kredensial Digital Lintas Perangkat di desktop melalui handoff QR yang didukung CTAP/BLE.

API ini memperluas API Manajemen Kredensial 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 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 bagaimana situs web mungkin memanggil API untuk meminta kredensial menggunakan OpenID4VP:

async function requestCredential() {
    // Periksa dukungan API Kredensial Digital
    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 agar ringkas
                    },
                },
            };
 
            // buat Abort Controller
            const controller = new AbortController();
 
            // Panggil API Kredensial Digital 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 agar ringkas
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // skenario fallback, ilustrasi saja
        alert("API Kredensial Digital tidak didukung di browser ini.");
    }
}

Contoh ini diambil dari sini.

API Kredensial Digital 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 agar buram (terenkripsi) bagi browser itu sendiri, dengan dekripsi dan interpretasi ditangani oleh relying party dan wallet/pemegang.

API Kredensial Digital awalnya dirancang agar sepenuhnya agnostik protokol, bertindak sebagai "pipa kosong" dengan registri terbuka untuk protokol apa pun yang ingin mendaftar. Namun, per Januari 2026, spesifikasi tersebut sekarang secara eksplisit menyebutkan protokol yang didukungnya — agen pengguna diharapkan menolak yang tidak terdaftar. Dua keluarga protokol utama yang saat ini ditetapkan secara permanen (hardcoded) dalam spesifikasi adalah: org.iso.mdoc (diturunkan 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 Elektroteknik Internasional (IEC). Standar dasarnya adalah ISO/IEC 18013-5, yang mendefinisikan aplikasi mDL, struktur data, dan protokol untuk presentasi langsung (jarak dekat) menggunakan teknologi seperti NFC, Bluetooth, atau kode QR. ISO/IEC 18013-7 memperluas ini untuk memungkinkan presentasi online/jarak jauh dari mDL. String protokol "org.iso.mdoc" didefinisikan secara khusus dalam ISO/IEC TS 18013-7 (Annex C) untuk digunakan dengan API seperti API Kredensial Digital.

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

• Kasus Penggunaan Umum: Terutama dokumen identitas yang diterbitkan pemerintah seperti SIM 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 Standarisasi: 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 bagi berbagai jenis kredensial, bukan hanya pemerintah. Pada awal 2025, OpenID4VP berada dalam tahap draf lanjutan (misalnya, draf 28 per April). OpenID4VCI juga semakin matang.
• Model Data: OpenID4VP/VCI dirancang agar agnostik terhadap format kredensial. Mereka dapat membawa W3C Verifiable Credentials (VC) dalam format JSON/JSON-LD atau JWT, mdoc, SD-JWT, dan format lainnya. Model interaksi melibatkan Permintaan Otorisasi dari Verifikator (RP) dan respons dari Wallet Pemegang yang berisi vp_token (Token Presentasi yang Dapat Diverifikasi). Pengungkapan selektif biasanya dikelola menggunakan bahasa kueri seperti Presentation Exchange (DIF PE) atau Bahasa Kueri Kredensial Digital (DCQL) yang lebih baru.
• Kasus Penggunaan Umum: Berbagai 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 keduanya tidak selalu eksklusif satu sama lain. OpenID4VP dapat, misalnya, digunakan untuk meminta dan mengangkut sebuah [org.iso.mdoc]. Pilihan sering kali bergantung pada kasus penggunaan spesifik, jenis kredensial, dan peserta ekosistem.

Wallet Identitas Digital Uni Eropa (EUDI) adalah inisiatif besar yang bertujuan untuk memberikan semua warga negara dan penduduk UE sebuah wallet digital yang aman untuk dokumen identitas dan atestasi. Arsitektur dan kerangka kerja referensi Wallet EUDI secara eksplisit berencana untuk mendukung mdoc (terutama untuk SIM Seluler) dan W3C Verifiable Credentials, memanfaatkan OpenID4VP dan OpenID4VCI untuk alur presentasi dan penerbitan. Implementasi referensi mencakup dukungan untuk OpenID4VP yang mentransfer mDoc dan OpenID4VCI untuk menerbitkan PID dan mDL dalam format mDoc dan SD-JWT-VC. Dukungan ganda oleh proyek berskala besar semacam ini menggarisbawahi pentingnya kedua keluarga protokol tersebut.

Pembaruan Maret 2026: Komitmen UE terhadap API Kredensial Digital menjadi lebih konkret. Architecture Reference Framework (ARF) Topik F EUDI sekarang secara kondisional mewajibkan Unit Wallet EUDI dan Relying Party untuk mendukung API DC untuk presentasi jarak jauh dan alur penerbitan atestasi. Kondisi tersebut mencakup API DC mencapai status Rekomendasi W3C dan memenuhi harapan seputar fungsionalitas, netralitas browser/OS, privasi, dan perlindungan penolakan layanan (denial-of-service). European Wallet Consortium (EWC) telah memasukkan kasus uji API DC ke dalam program pengujian kesesuaiannya, dan konsorsium NOBID menyelesaikan uji coba pembayaran menggunakan OpenID4VP — protokol yang sama yang sekarang dibawa oleh API DC.

Namun, arah ini bukan tanpa kritik, karena beberapa pengamat mencatat bahwa API Kredensial Digital, yang sangat dipengaruhi oleh perusahaan "Bigtech AS", mungkin menjadi sangat tergabung ke dalam spesifikasi akhir Wallet EUDI. Kekhawatiran telah diajukan tentang potensi pengaruh entitas non-UE pada bagian penting infrastruktur UE, seperti dibahas dalam forum komunitas seperti diskusi GitHub ini. Secara terpisah, keputusan untuk menetapkan referensi ISO 18013-7 secara permanen dalam spesifikasi telah memicu keberatan dari Ping Identity, dengan argumen bahwa merujuk secara normatif pada spesifikasi berbayar bertentangan dengan prinsip web terbuka — kekhawatiran yang dapat muncul sebagai keberatan formal ketika spesifikasi beralih ke Rekomendasi Kandidat.

Lanskap browser untuk API Kredensial Digital sekarang telah terbentuk, dengan Chrome 141 dan Safari 26 mengirimkan dukungan stabil pada September 2025. Ada perbedaan mencolok dalam pendekatan dan tingkat dukungan antar browser.

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

Deteksi Fitur:

if (typeof DigitalCredential !== "undefined") {
    // API Kredensial Digital didukung
}

Credential Manager Android secara native mendukung OpenID4VP untuk presentasi dan OpenID4VCI untuk penerbitan, memungkinkan aplikasi Android bertindak sebagai pemegang dan verifikator kredensial menggunakan standar ini. Google mencatat dukungan wallet yang terus tumbuh; Google Wallet adalah pengadopsi awal, dengan Samsung Wallet dan 1Password telah diumumkan.

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

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

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 SIM, yang disimpan di Apple Wallet atau di aplikasi penyedia dokumen pihak ketiga.

Poin-poin penting dari implementasi Apple:

• Hanya MDOC: API 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 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 mem-parsing dan memvalidasi permintaan di sandbox sebelum meneruskannya ke aplikasi wallet, 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 jarak dekat setelah handoff 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 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 pengguna.
    }
}

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

Mozilla awalnya menyatakan posisi standar negatif pada API Kredensial Digital. Kekhawatiran mereka, didokumentasikan secara rinci, komprehensif dan berakar pada misi mereka untuk melindungi privasi pengguna, agensi, dan memastikan web yang terbuka dan adil.

Kekhawatiran utama yang diajukan oleh Mozilla meliputi:

• 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 diterbitkan pemerintah, kasus penggunaan utama, mungkin tidak sejalan dengan pilihan presentasi identitas individu.
• Masalah Interoperabilitas: Kekhawatiran tentang proliferasi format kredensial yang mengarah pada ekosistem yang terfragmentasi daripada yang dapat beroperasi secara universal.
• Pengungkapan Selektif: Kekhawatiran bahwa manfaat privasi dari pengungkapan selektif dapat dirusak jika tidak diimplementasikan dengan jaminan ketidakterkaitan (unlinkability) yang kuat, atau jika pengguna tidak sepenuhnya memahami apa yang sedang dibagikan.
• Sentralisasi Kepercayaan dan Agensi Pengguna: Ketakutan bahwa API dapat menyebabkan peningkatan sentralisasi kepercayaan dan pengurangan agensi pengguna, melanggengkan ketidakseimbangan kekuatan sosial yang ada.

Sementara Dewan W3C menolak keberatan formal terkait kekhawatiran ini (untuk memungkinkan pekerjaan dilanjutkan di dalam W3C daripada tempat yang berpotensi kurang transparan), Dewan memang merekomendasikan agar Kelompok Kerja bekerja secara aktif untuk memitigasi potensi bahaya ini.

Pembaruan Maret 2026 — Implementasi sedang berjalan: Meskipun posisi negatif formal secara teknis tetap tidak berubah, Mozilla telah mulai mengimplementasikan secara aktif API Kredensial Digital. Pada Q1 2026, dukungan dasar API DC mendarat di Firefox 149 (di belakang flag preferensi), dilacak di bawah meta bug 2004828. Kode sumber ada di mozilla-central, termasuk DigitalCredential.cpp, binding WebIDL, dan perpipaan IPC. Pekerjaan pada permintaan izin desktop dan Android (bug 2010091, bug 2010093) sedang berlangsung.

Tiga insinyur Mozilla — John Schanck, Martin Thomson, dan Benjamin VanderSloot — adalah anggota aktif dari Kelompok Kerja FedID W3C, dan Schanck telah memberikan umpan balik substantif berdasarkan implementasi pada PR spesifikasi utama termasuk algoritma presentasi kredensial dan algoritma persiapan permintaan.

Ini adalah perkembangan yang signifikan: sementara Mozilla mempertahankan kekhawatirannya tentang potensi penyalahgunaan API, mereka jelas memilih untuk membentuk API dari dalam — baik melalui kerja spesifikasi maupun implementasi — daripada menyerahkan desainnya kepada vendor browser lain. Ini menandakan bahwa API Kredensial Digital kemungkinan berada di jalur menuju dukungan tiga browser, meskipun dengan Mozilla mendorong pagar pembatas privasi yang lebih kuat (termasuk log transparansi yang diusulkan untuk permintaan kredensial).

Tabel 1: Dukungan Browser untuk API Kredensial Digital & Protokol (Maret 2026)

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

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

Ini berarti merancang sistem yang dapat menangani kedua jalur protokol, seperti yang ditunjukkan di bawah ini.

Meskipun ini menambah kompleksitas, upaya untuk memaksakan 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 pragmatis, meskipun lebih intensif dalam pengembangan, adalah membangun fleksibilitas untuk menangani keduanya.

Relying Party harus sangat menyadari bahwa bahkan ketika meminta 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 mekanismenya sendiri untuk pengungkapan selektif, biasanya melibatkan penerbit yang membuat hash yang digarami (salted hash) dari elemen data individu. Wallet pemegang kemudian hanya mengungkapkan elemen yang diminta beserta garamnya (salt), memungkinkan verifikator untuk mengonfirmasinya terhadap hash tanpa melihat data lain. Permintaan untuk elemen tertentu terkait dengan 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 Bahasa Kueri Kredensial Digital (DCQL) yang lebih baru yang tertanam dalam presentation_definition permintaan. Ini memungkinkan RP untuk menentukan jenis kredensial dan klaim individu yang mereka butuhkan. Wallet kemudian menyusun Presentasi yang Dapat Diverifikasi 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 minimisasi data. Format dan struktur data yang diungkapkan yang dikembalikan oleh wallet juga mungkin berbeda, memerlukan logika parsing dan validasi yang berbeda di backend RP.

Bagi entitas yang ingin menerbitkan kredensial digital dan menyediakan aplikasi wallet bagi 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 API Kredensial Digital.

• Android: Secara umum menawarkan ekosistem yang lebih terbuka. Android Credential Manager menyertakan API Holder yang memungkinkan aplikasi native pihak ketiga mendaftar sebagai pemegang kredensial. Aplikasi pemegang terdaftar ini kemudian dapat berpartisipasi dalam alur presentasi kredensial yang dimediasi oleh sistem, menanggapi permintaan dari API Kredensial Digital (via Chrome) atau verifikator aplikasi native. Android juga secara eksplisit mendukung OpenID4VCI untuk penerbitan kredensial, memungkinkan pengguna 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 bisa 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 (entitlement) 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 "taman bertembok" (walled garden) Apple sudah mapan, dan implementasi kredensial digital mereka tidak terkecuali. Namun, WWDC25 mengklarifikasi 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 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 mdoc 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 "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 wallet yang terintegrasi penuh di iOS memerlukan pembuatan aplikasi native dan penggunaan kerangka kerja khusus Apple—bukan teknologi web seperti PWA—ada mekanisme yang jelas, meskipun dikontrol ketat, bagi aplikasi pihak ketiga untuk bertindak sebagai penyedia dokumen bersama Apple Wallet. Ini mengonfirmasi bahwa interaksi dengan API Kredensial Digital di Safari dikelola oleh OS, yang kemudian mengirimkan permintaan ke Apple Wallet atau aplikasi penyedia dokumen terdaftar dan resmi lainnya.

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 Sept 2025) dan Safari 26 (15 Sept 2025) mengirimkan dukungan presentasi yang stabil, dan Firefox 149 sekarang membawa kode implementasi dasar, API ini berada di jalur menuju cakupan tiga browser. Kami akan terus memperbarui artikel ini seiring perubahan lanskap.

Periode sejak Oktober 2025 telah didefinisikan oleh kematangan API dari pipa eksperimental menjadi standar yang diatur. Penghapusan registri protokol terbuka di TPAC (November 2025) adalah sinyal paling jelas: W3C FedID WG sekarang secara eksplisit menyebutkan dan mengatur protokol yang didukung API. Ini memungkinkan tinjauan keamanan dan privasi yang komprehensif tetapi juga menjadikan Kelompok Kerja sebagai penjaga gerbang — sebuah pertukaran yang disengaja yang tidak disetujui oleh semua peserta (terutama, keberatan paywall ISO dari Ping Identity tetap belum terselesaikan).

Sementara itu, API berkembang dari presentasi ke siklus hidup penuh: Origin Trial penerbitan Chrome 143 melalui navigator.credentials.create() memungkinkan situs web memicu penyediaan wallet. Tetapi kerentanan pengikatan pemilihan wallet — di mana aplikasi wallet berbahaya dapat mencegat kode penerbitan — menghalangi adopsi pemerintah terhadap fitur ini.

Di sisi regulasi, Topik F ARF UE secara kondisional mewajibkan dukungan API DC untuk semua wallet negara anggota EUDI, sambil menunggu spesifikasi mencapai Rekomendasi W3C. Adopsi dunia nyata semakin cepat: DMV California telah menambahkan dukungan API DC, dan rangkaian uji kesesuaian sedang dikembangkan oleh European Wallet Consortium.

Tantangan tetap ada. Realitas protokol ganda (dukungan multi-protokol Chrome versus fokus mdoc-only Safari) tetap ada bagi relying party. Pertanyaan tentang apakah browser harus mendukung semua protokol yang terdaftar atau hanya satu belum terselesaikan — terkait langsung dengan kendala platform Apple. Dan pertimbangan privasi tetap menjadi kesenjangan terbesar yang menghambat kemajuan menuju Rekomendasi Kandidat, dengan persyaratan normatif untuk kriteria inklusi protokol masih belum tertulis. Spesifikasi ini diperkirakan 1–2 tahun lagi dari Rekomendasi W3C.