--- url: 'https://www.corbado.com/id/blog/digital-credentials-api' title: 'API Kredensial Digital (2026): Dukungan Langsung di Chrome & Safari' description: 'Pelajari tentang API Kredensial Digital, dukungan fiturnya saat ini di Chrome & Safari, dan ikuti pembaruan mendatang dengan panduan lengkap kami.' lang: 'id' author: 'Vincent Delitz' date: '2025-07-25T07:00:44.997Z' lastModified: '2026-03-27T07:07:14.062Z' keywords: 'api kredensial digital, dc api, kredensial digital, openid4vp, iso mdoc, identitas digital' category: 'Engineering' --- # API Kredensial Digital (2026): Dukungan Langsung di Chrome & Safari ### API Kredensial Digital: Gambaran Dukungan Browser (Maret 2026) _Terakhir diperbarui: 26 Maret 2026_ Berikut adalah gambaran cepat mengenai dukungan API Kredensial Digital di browser-browser utama: | Browser | Status Dukungan (Maret 2026) | Rilis Stabil / Prospek | | :-------------- | :----------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Google Chrome | ✅ **Tersedia (Stabil)** — agnostik protokol (OpenID4VP **dan** ISO 18013-7 Annex C) | **Chrome 141** ([Stabil sejak **30 Sept 2025**](https://developer.chrome.com/blog/digital-credentials-api-shipped)); lintas perangkat desktop via CTAP/BLE. [Lihat §6.1](#61-google-chrome-shipped) | | Apple Safari | ✅ **Tersedia (Stabil)** — **khusus mdoc** via `org-iso-mdoc` | **Safari 26** ([dirilis **15 Sept 2025**](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/)); mendukung Wallet & aplikasi penyedia dokumen terdaftar. [Lihat §6.2](#62-apple-safari-mdoc-focus) | | Mozilla Firefox | 🔧 **Dalam Pengembangan** — dasar kode mendarat di Firefox 149 | [Posisi standar negatif](https://github.com/mozilla/standards-positions/issues/1003) formal tidak berubah, tetapi [implementasi aktif sedang berjalan](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [Lihat §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | Microsoft Edge | ✅ **Tersedia (Stabil)** — berbasis Chromium, mengikuti Chrome 141 | **Edge 141** (Stabil awal Okt 2025); mewarisi kemampuan Chromium 141. | ## Linimasa: Bagaimana Status Kredensial Digital? Dunia kredensial digital bergerak sangat cepat. Berikut adalah ringkasan perkembangan utama dan proyeksinya: | **Ikon** | **Tanggal / Periode** | **Peristiwa** | **Deskripsi & Sumber** | | :------- | :-------------------------- | :----------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🚀🤖 | 20 Agustus 2024 | Origin Trial API Kredensial Digital Android | [Chrome 128 meluncurkan Origin Trial untuk API Kredensial Digital di Android](https://developer.chrome.com/release-notes/128), memungkinkan permintaan melalui sistem IdentityCredential CredMan Android. | | 🚀🍏 | 27 Feb 2025 | Safari Technology Preview 214 | WebKit (termasuk dalam [Safari Technology Preview 214](https://www.webkit.org/blog/16512/release-notes-for-safari-technology-preview-214/)) menambahkan Feature Flag API Kredensial Digital. ([Pull Request](https://github.com/WebKit/WebKit/pull/40008), [Perbandingan](https://github.com/WebKit/WebKit/compare/c968abdda41af3ad0abbf5c5c2c1fe0d5bb1c016...837aec74d9c8ea88f094c9de12a0a3c936735634)) | | 🚀🤖 | 4 Maret 2025 | Origin Trial Desktop Chrome 134 | [Chrome 134 meluncurkan Origin Trial Desktop untuk API Kredensial Digital](https://developer.chrome.com/origintrials/#/view_trial/3981410680008146945), memungkinkan komunikasi aman dengan wallet ponsel Android. (Sumber: Catatan Rilis Chrome 134) | | 🚀🍏 | 31 Mar 2025 | Rilis Safari 18.4 | [Fitur WebKit di Safari 18.4](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) membuat bagian dari API Kredensial Digital dapat diuji melalui Feature Flag. Perubahan yang sedang berlangsung dilacak [di sini](https://bugs.webkit.org/buglist.cgi?quicksearch=Digital%20Credentials). | | 💡 | April 2025 | W3C FedID WG Mengambil Alih | Pengembangan API Kredensial Digital secara formal pindah ke [Kelompok Kerja Identitas Terfederasi W3C](https://github.com/w3c-fedid/digital-credentials). | | 🚀🤖 | 30 April 2025 | Pengumuman OT Lintas Perangkat Chrome | Chrome mengumumkan [Origin Trial untuk API Kredensial Digital Lintas Perangkat](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) mulai di Chrome 136, memungkinkan Chrome desktop menyajikan kredensial secara aman dari perangkat Android. | | ⚠️🤖 | 2 Mei 2025 | Perubahan API Chrome yang Memutus Kompatibilitas | Chrome menguraikan perubahan yang memutus kompatibilitas (breaking changes) untuk versi API di Chrome 136 & 138 (misalnya, format permintaan, API `navigator.credentials.create()` ditambahkan di bawah flag). | | 🚀🍏 | 10 Juni 2025 | WWDC25: Apple Mengonfirmasi Dukungan API | Apple secara resmi mengumumkan dukungan API Kredensial Digital di Safari pada WWDC25, mengonfirmasi fokus pada protokol `org.iso.mdoc` untuk menyajikan dokumen identitas. Fitur ini tersedia di Safari 26 Beta dengan iOS 26. (Sumber: [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/)) | | 🧭 | 15 Sept 2025 | Rilis Safari 26 | [Safari/iOS 26 merilis API Kredensial Digital](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) dengan **`org-iso-mdoc`** (mdoc Annex C). | | 🚀🤖 | 30 Sept 2025 | Chrome 141 Stabil | [API Kredensial Digital dirilis **stabil** di Chrome 141](https://developer.chrome.com/blog/digital-credentials-api-shipped) (Android + lintas perangkat desktop). | | 📣 | 3 Okt 2025 | Blog Peluncuran | [Chrome](https://developer.chrome.com/blog/digital-credentials-api-shipped) dan [WebKit](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) mempublikasikan postingan peluncuran; Chrome menekankan dukungan **agnostik protokol** (OpenID4VP **dan** ISO 18013-7 Annex C); WebKit merinci model **khusus mdoc** Safari dan alur lintas perangkat CTAP. | | ⚙️ | 14 Nov 2025 | TPAC: Registri Protokol Dihapus | W3C FedID WG [mencapai konsensus](https://github.com/w3c-fedid/digital-credentials/issues/396) untuk menghapus registri protokol terbuka dan **secara permanen menetapkan protokol yang didukung** (OpenID4VP, OpenID4VCI, ISO 18013-7 Annex C) langsung dalam spesifikasi. Diimplementasikan dalam [PR #401](https://github.com/w3c-fedid/digital-credentials/pull/401) (digabungkan 28 Jan 2026). [Lihat §5](#5-underlying-protocols) | | 🦊 | _Q1 2026_ | Firefox Memulai Implementasi API DC | Mozilla mendaratkan [dukungan dasar API DC](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) di **Firefox 149**, meskipun [posisi standar negatifnya](https://github.com/mozilla/standards-positions/issues/1003) tidak berubah. [Kode sumber implementasi](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) di mozilla-central. [Lihat §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | 🇺🇸 | 27 Feb 2026 | DMV California Menambahkan API DC | DMV California menambahkan dukungan API DC pada platform [OpenCred](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) di v10.0.0, menjadi salah satu pengadopsi awal dari pemerintah untuk presentasi kredensial yang dimediasi browser. | | 🚀🤖 | _Q1 2026_ | Origin Trial Penerbitan Chrome 143 | Chrome meluncurkan [Origin Trial untuk **penerbitan** kredensial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()` dengan OpenID4VCI, memperluas API di luar presentasi. [Lihat §4](#4-how-does-the-digital-credentials-api-work) | | 🇪🇺📅 | _Akhir 2026 (Diantisipasi)_ | Ketersediaan Wallet EUDI | Negara Anggota UE diproyeksikan untuk menyediakan Wallet EUDI sesuai [eIDAS 2.0](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng). [Topik F ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) UE secara kondisional mewajibkan dukungan API DC untuk semua wallet negara anggota. [Lihat §5.4](#54-eu-digital-identity-wallet-support) | **Apa yang Berubah Sejak Oktober 2025?** - **Pergeseran tata kelola protokol**: W3C FedID WG [menghapus registri protokol terbuka](https://github.com/w3c-fedid/digital-credentials/issues/396) di TPAC (Nov 2025) dan sekarang [menetapkan protokol yang didukung secara permanen (hardcode)](https://github.com/w3c-fedid/digital-credentials/pull/401) langsung dalam spesifikasi: [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), OpenID4VCI, dan [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) Annex C. API ini bukan lagi sekadar "pipa kosong". - **Penerbitan telah tiba**: Chrome 143 meluncurkan [Origin Trial untuk penerbitan kredensial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) melalui `navigator.credentials.create()`, memperluas API di luar fungsi presentasi saja. - **Firefox mengimplementasikan**: Meskipun [posisi standar negatif](https://github.com/mozilla/standards-positions/issues/1003) tidak berubah, Mozilla [mendaratkan kode dasar API DC](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) di Firefox 149 dengan pengerjaan UX yang sedang berlangsung. - **Mandat kondisional UE**: [Architecture Reference Framework (Topik F)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) EUDI sekarang secara kondisional mewajibkan dukungan API DC untuk semua wallet negara anggota. - **Adopsi dunia nyata**: [DMV California](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) menambahkan dukungan API DC ke platform OpenCred mereka (Feb 2026). ## Key Facts - **Chrome 141** dan **Safari 26** telah merilis dukungan API Kredensial Digital yang stabil pada September 2025; Firefox 149 membawa kode implementasi dasar pada Q1 2026. - **Safari 26** hanya mendukung `org-iso-mdoc`; Chrome 141 mendukung OpenID4VP dan ISO 18013-7 Annex C, mengharuskan relying party untuk membangun backend protokol ganda. - **W3C FedID WG** menghapus registri protokol terbuka di TPAC (November 2025), secara permanen menetapkan OpenID4VP, OpenID4VCI, dan ISO 18013-7 Annex C langsung dalam spesifikasi. - **EUDI ARF Topik F** secara kondisional mewajibkan dukungan API DC untuk semua wallet negara anggota, bergantung pada spesifikasi yang mencapai status Rekomendasi W3C. - Meskipun memiliki **posisi standar negatif** secara formal, Mozilla mendaratkan kode API DC dasar di Firefox 149 pada Q1 2026, menandakan kemungkinan cakupan tiga browser di masa depan. ## 1. Pengantar: API Kredensial Digital 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](https://www.corbado.com/glossary/relying-party) maupun [penerbit](https://www.corbado.com/glossary/issuer) [wallet](https://www.corbado.com/blog/digital-wallet-assurance) yang sedang menavigasi lanskap yang berkembang pesat ini. ## 2. Identitas Digital & Verifikasi 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](https://www.corbado.com/passkeys-for-public-sector) juga turun tangan, menegakkan atau menyediakan [wallet](https://www.corbado.com/blog/digital-wallet-assurance) dan layanan [identitas digital](https://www.corbado.com/id/blog/iso-18013-7-mdl-kyc-onboarding-bank) nasional. Namun, solusi-solusi ini sering kali terkotak-kotak, terbatas secara geografis, dan tidak dapat beroperasi secara universal. Metode cadangan untuk [verifikasi identitas](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/glossary/phishing) yang [semakin canggih](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). 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](https://www.corbado.com/id/blog/verifikasi-identitas-digital) 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](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). Lanskap ancaman yang meningkat ini menggarisbawahi kebutuhan mendesak akan mekanisme identitas dan verifikasi online yang lebih aman dan dapat diverifikasi secara kriptografis. ## 3. Bagaimana Cara Kerja Kredensial Digital? Memahami cara kerja kredensial digital melibatkan melihat para pemain kunci yang terlibat dan berbagai lapisan teknologi yang memungkinkan fungsinya. ### 3.1. Model Tiga Pihak (Three-Party Model) Pada intinya, konsep kredensial digital, terutama dalam konteks API web baru, berkisar pada model tiga pihak: 1. **Penerbit (Issuer)**: Entitas (misalnya, [pemerintah](https://www.corbado.com/passkeys-for-public-sector), 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](https://www.corbado.com/glossary/issuer) dan menyimpannya dalam [wallet digital](https://www.corbado.com/blog/digital-wallet-assurance). Pemegang mengontrol kapan dan informasi apa dari kredensial yang dibagikan. 3. **Verifikator** (atau [Relying Party](https://www.corbado.com/glossary/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](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/three_party_model_5eedaec078.png) 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](https://www.corbado.com/id/glossary/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](https://www.corbado.com/glossary/issuer) menandatangani kredensial secara digital, memastikan keaslian dan integritasnya. Pemegang, pada gilirannya, menggunakan kunci pribadi mereka, sering kali diamankan di dalam [wallet digital](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/blog/digital-wallet-assurance) [Identitas Digital](https://www.corbado.com/id/blog/iso-18013-7-mdl-kyc-onboarding-bank) UE untuk tanda tangan yang mengikat secara hukum), fokus di sini, khususnya untuk API Kredensial Digital, adalah pada [asersi](https://www.corbado.com/glossary/assertion) identitas dan verifikasi atribut untuk interaksi online. ### 3.2. Lapisan Kredensial Digital 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. ![Lapisan kredensial digital](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_26eaf37952.png) **Terminologi Inti:** - **Kredensial digital:** Kredensial apa pun yang dapat dibaca mesin (PDF dengan barcode, ISO [mDL](https://www.corbado.com/blog/mobile-drivers-license), 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](https://www.corbado.com/glossary/issuer) → pemegang → verifikator. - **[Verifiable Credential API](https://w3c-ccg.github.io/vc-api/):** Antarmuka layanan REST/HTTP untuk menerbitkan, menyimpan, menyajikan, dan memverifikasi VC antara sistem back-end (penerbit, [wallet](https://www.corbado.com/blog/digital-wallet-assurance), verifikator). - **[Digital Credentials API (DC API)](https://github.com/w3c-fedid/digital-credentials):** 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/open-id-4-vp), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql), 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. ## 4. Bagaimana Cara Kerja API Kredensial Digital? 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](https://www.corbado.com/id/blog/iso-18013-7-mdl-kyc-onboarding-bank) dari [wallet](https://www.corbado.com/blog/digital-wallet-assurance) 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/](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](https://www.corbado.com/glossary/open-id-4-vp) dan [ISO 18013-7](https://www.corbado.com/glossary/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](https://github.com/w3c-fedid/digital-credentials/issues/396) untuk **menghapus registri protokol terbuka** dan sebaliknya [menetapkan secara permanen daftar protokol terbatas yang didukung](https://github.com/w3c-fedid/digital-credentials/pull/401) 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](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) dan privasi holistik terhadap segala sesuatu yang mengalir melalui API (lihat [Draf Kerja saat ini](https://www.w3.org/TR/digital-credentials/)). Spesifikasi ini sekarang juga mencakup **penerbitan kredensial** melalui `navigator.credentials.create()`. Chrome 143 meluncurkan [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) untuk ini, memungkinkan situs web memicu alur penyediaan wallet menggunakan OpenID4VCI. Namun, [kerentanan pengikatan pemilihan wallet](https://github.com/w3c-fedid/digital-credentials/issues/382) — 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) melalui [sistem Credential Manager](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html)-nya dan juga mendukung [API Kredensial Digital Lintas Perangkat](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) di desktop melalui handoff QR yang didukung [CTAP](https://www.corbado.com/id/glossary/ctap)/BLE. API ini memperluas [API Manajemen Kredensial](https://www.w3.org/TR/credential-management-1/) 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](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: ```javascript 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](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md). 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Browser dan OS kemudian dapat menyajikan antarmuka pengguna yang konsisten untuk memilih kredensial dan mengotorisasi pelepasannya, meningkatkan [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) dan privasi dengan memastikan persetujuan pengguna dan mencegah situs web mengakses [data](https://w3c-fedid.github.io/digital-credentials/) 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](https://www.corbado.com/glossary/relying-party) dan wallet/[pemegang](https://w3c-fedid.github.io/digital-credentials/). ## 5. Protokol yang Mendasari 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](https://github.com/w3c-fedid/digital-credentials/pull/401) 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](https://www.corbado.com/glossary/iso-18013-5) dan ekstensinya [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) "Annex C") dan spesifikasi OpenID Foundation yaitu OpenID for Verifiable Presentations (OpenID4VP) dan OpenID for [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) Issuance (OpenID4VCI). ### 5.1. org.iso.mdoc - **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](https://www.iso.org/standard/69084.html), yang mendefinisikan aplikasi [mDL](https://www.corbado.com/blog/mobile-drivers-license), struktur data, dan protokol untuk presentasi langsung (jarak dekat) menggunakan teknologi seperti NFC, Bluetooth, atau kode [QR](https://sphericalcowconsulting.com/2024/01/03/verifiable-credentials-and-mdocs-a-tale-of-two-protocols/). [ISO/IEC 18013-7](https://www.iso.org/standard/82772.html) memperluas ini untuk memungkinkan presentasi online/jarak jauh dari [mDL](https://www.corbado.com/blog/mobile-drivers-license). 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](https://www.corbado.com/glossary/mdoc) memiliki struktur data yang didefinisikan secara ketat berdasarkan [CBOR](https://www.corbado.com/glossary/cbor) (Concise Binary Object Representation) untuk kekompakan dan efisiensi. Ini menetapkan namespace dan elemen data untuk atribut SIM umum dan mendukung fitur [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) kriptografis yang kuat, termasuk otentikasi penerbit, pengikatan perangkat (device binding), otentikasi pemegang (melalui potret), enkripsi sesi, dan [pengungkapan selektif](https://www.corbado.com/id/glossary/pengungkapan-selektif). - **Kasus Penggunaan Umum**: Terutama dokumen identitas yang diterbitkan [pemerintah](https://www.corbado.com/passkeys-for-public-sector) 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](https://www.corbado.com/passkeys-for-public-sector), [verifikasi identitas](https://www.corbado.com/blog/digital-identity-guide) jarak jauh untuk [pembukaan rekening](https://www.corbado.com/blog/digital-identity-verification) bank). ### 5.2. OpenID4VP dan OpenID4VCI - **Asal dan Standarisasi**: OpenID4VP (untuk presentasi) dan [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) (untuk penerbitan) adalah spesifikasi yang dikembangkan oleh OpenID Foundation. Mereka memperluas [OAuth 2.0](https://www.corbado.com/glossary/oauth2) untuk mendukung pertukaran [kredensial yang dapat diverifikasi](https://www.corbado.com/glossary/microcredentials). 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](https://www.corbado.com/glossary/openid4vci) juga semakin matang. - **Model Data**: OpenID4VP/VCI dirancang agar agnostik terhadap format kredensial. Mereka dapat membawa W3C [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (VC) dalam format JSON/[JSON-LD](https://www.corbado.com/glossary/json-ld) atau JWT, [mdoc](https://www.corbado.com/glossary/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](https://www.corbado.com/id/glossary/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](https://www.corbado.com/blog/digital-identity-guide), memberikan bukti kualifikasi (misalnya, ijazah pendidikan, sertifikasi profesional), [atestasi](https://www.corbado.com/id/glossary/ctap) keanggotaan, dan banyak lagi. Mereka sangat cocok untuk interaksi online di mana [relying party](https://www.corbado.com/glossary/relying-party) perlu memverifikasi klaim dari berbagai [penerbit](https://www.corbado.com/glossary/issuer). ### 5.3. Perbandingan org.iso.mdoc dan OpenID4VP/VCI | Fitur | org.iso.mdoc (ISO 18013-5/7) | OpenID4VP / OpenID4VCI | | :------------------------ | :-------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | | **Badan Standarisasi** | ISO/IEC | OpenID Foundation | | **Fokus Utama** | SIM Seluler (mDL) & ID resmi | Pertukaran kredensial yang dapat diverifikasi secara umum (jenis apa pun) | | **Format Data** | Berbasis CBOR, elemen data didefinisikan secara ketat | Agnostik; umumnya [W3C VC](https://www.w3.org/TR/vc-data-model-2.0/) (JSON/JWT), mdoc, SD-JWT | | **Transportasi** | Didefinisikan untuk jarak dekat (NFC, BLE, QR) & online (18013-7) | Terutama berbasis OAuth 2.0 untuk online; dapat dimulai via QR, deep link | | **Pengungkapan Selektif** | Bawaan melalui klaim hash yang digarami (salted) | Melalui bahasa kueri seperti Presentation Exchange atau DCQL | | **Kematangan** | ISO 18013-5: Standar Terbit. ISO 18013-7: TS Terbit. Seri ISO 23220 (mDoc umum): Dalam pengembangan | OpenID4VP: Draf Lanjutan (mis., draf 28, April 2025). OpenID4VCI: Draf Lanjutan | | **Penerbit Umum** | Lembaga pemerintah (Samsat, dll.) | Pemerintah, lembaga pendidikan, pemberi kerja, entitas mana pun | | **Biaya Standar** | Berbayar | Gratis / Terbuka | 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. ### 5.4. Dukungan Wallet Identitas Digital UE Wallet Identitas Digital Uni Eropa (EUDI) adalah inisiatif besar yang bertujuan untuk memberikan semua warga negara dan penduduk UE sebuah [wallet digital](https://www.corbado.com/blog/digital-wallet-assurance) yang aman untuk dokumen identitas dan [atestasi](https://www.corbado.com/id/glossary/ctap). Arsitektur dan kerangka kerja referensi Wallet EUDI secara eksplisit berencana untuk mendukung mdoc (terutama untuk SIM Seluler) dan W3C [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials), memanfaatkan OpenID4VP dan [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) untuk alur presentasi dan penerbitan. Implementasi referensi mencakup dukungan untuk OpenID4VP yang mentransfer [mDoc](https://www.corbado.com/glossary/mdoc) dan OpenID4VCI untuk menerbitkan PID dan [mDL](https://www.corbado.com/blog/mobile-drivers-license) dalam [format](https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md) mDoc dan SD-JWT-VC. Dukungan ganda oleh proyek [berskala besar](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) EUDI sekarang **secara kondisional mewajibkan** Unit Wallet EUDI dan Relying Party untuk mendukung API DC untuk presentasi jarak jauh dan alur penerbitan [atestasi](https://www.corbado.com/id/glossary/ctap). 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)](https://eudiwalletconsortium.org/) telah memasukkan kasus uji API DC ke dalam program pengujian kesesuaiannya, dan [konsorsium NOBID](https://www.nobidconsortium.com/) 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Secara terpisah, keputusan untuk [menetapkan referensi ISO 18013-7 secara permanen](https://github.com/w3c-fedid/digital-credentials/pull/401) dalam spesifikasi telah memicu [keberatan dari Ping Identity](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228), 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. ## 6. Browser Mana yang Mendukung API Kredensial Digital? 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. ### 6.1. Google Chrome: Dirilis di 141; Agnostik Protokol 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:** ```javascript if (typeof DigitalCredential !== "undefined") { // API Kredensial Digital didukung } ``` Credential Manager [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) secara native mendukung OpenID4VP untuk presentasi dan OpenID4VCI untuk [penerbitan](https://www.androidcentral.com/apps-software/android-os/google-enhances-digital-credentials-access-with-androids-open-standards-support), memungkinkan aplikasi [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) bertindak sebagai pemegang dan verifikator kredensial menggunakan [standar](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html) ini. Google mencatat dukungan wallet yang terus tumbuh; **Google Wallet** adalah pengadopsi awal, dengan **Samsung Wallet** dan **1Password** telah diumumkan. ### 6.2. Apple Safari: Dirilis di 26; Khusus mdoc (`org-iso-mdoc`) 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: > Bukti dari pelacak bug WebKit dan kontribusi standar menyarankan bahwa Safari akan > memilih untuk **memfokuskan dukungan pada `org.iso.mdoc`** secara langsung, daripada > memprioritaskan OpenID4VP sebagai lapisan transportasi untuk semua jenis kredensial. Hal > ini kemungkinan didorong oleh keraguan teknis tentang kompleksitas OpenID4VP dalam > konteks browser dan investasi mendalam Apple dalam membentuk standar ISO mdoc agar > selaras dengan model keamanan platform mereka. Seperti yang kami antisipasi dengan benar, [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) 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](https://www.corbado.com/blog/wwdc25-passkeys-os26) [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/). 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](https://www.corbado.com/id/glossary/ctap) untuk jarak dekat setelah handoff [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi); respons JS tetap terenkripsi/buram bagi browser. Apple memberikan contoh kode yang jelas tentang bagaimana relying party akan menggunakan API: ```javascript 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. ### 6.3. Mozilla Firefox: Dari Siklus Negatif ke Implementasi Aktif Mozilla awalnya menyatakan **posisi standar negatif** pada API Kredensial Digital. Kekhawatiran mereka, [didokumentasikan secara rinci](https://github.com/mozilla/standards-positions/issues/1003), komprehensif dan berakar pada misi mereka untuk melindungi [privasi pengguna](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys), 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](https://www.w3.org/2025/02/council-report-fedid-dig-cred.html) 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](https://github.com/mozilla/standards-positions/issues/1003), Mozilla telah mulai **mengimplementasikan secara aktif** API Kredensial Digital. Pada Q1 2026, [dukungan dasar API DC](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) mendarat di **Firefox 149** (di belakang flag preferensi), dilacak di bawah [meta bug 2004828](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [Kode sumber](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) ada di mozilla-central, termasuk `DigitalCredential.cpp`, binding WebIDL, dan perpipaan IPC. Pekerjaan pada permintaan izin desktop dan Android ([bug 2010091](https://bugzilla.mozilla.org/show_bug.cgi?id=2010091), [bug 2010093](https://bugzilla.mozilla.org/show_bug.cgi?id=2010093)) sedang berlangsung. Tiga insinyur Mozilla — John Schanck, Martin Thomson, dan Benjamin VanderSloot — adalah [anggota aktif](https://www.w3.org/groups/wg/fedid/participants/) dari Kelompok Kerja FedID W3C, dan Schanck telah memberikan umpan balik substantif berdasarkan implementasi pada PR spesifikasi utama termasuk [algoritma presentasi kredensial](https://github.com/w3c-fedid/digital-credentials/pull/419) dan [algoritma persiapan permintaan](https://github.com/w3c-fedid/digital-credentials/pull/420). 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](https://github.com/w3c-fedid/digital-credentials/issues/472) yang diusulkan untuk permintaan kredensial). ### 6.4. Tabel Ikhtisar **Tabel 1: Dukungan Browser untuk API Kredensial Digital & Protokol (Maret 2026)** | Fitur / Browser | Google Chrome (Android & Desktop) | Apple Safari (iOS & macOS) | Mozilla Firefox | | :------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------- | | **API Kredensial Digital (`navigator.credentials.get`)** | ✅ **Stabil** (141) | ✅ **Stabil** (26) | 🔧 **Dalam Pengembangan** ([Firefox 149](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), via pref flag) | | **org.iso.mdoc via API** | ✅ **Ya** (via ISO 18013-7 Annex C di bawah API DC) | ✅ **Ya** (**hanya**; `protocol: "org-iso-mdoc"`) | 🔧 TBD (macOS mungkin menggunakan API OS; awalnya khusus mdoc) | | **OpenID4VP via API** | ✅ **Ya** | ❌ **Tidak** (Implementasi Safari hanya mdoc) | 🔧 TBD | | **Penerbitan via API Web (OpenID4VCI)** | 🔧 [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) (Chrome 143) via `credentials.create()` | ❌ API Browser bukan untuk penerbitan (hanya alur aplikasi native) | ❌ N/A | | **Alur lintas perangkat** | ✅ Desktop↔Seluler via handoff QR CTAP/BLE (buram bagi browser) | ✅ Handoff Mac/iPad ke iPhone; non-Apple via QR + CTAP di iPhone | ❌ N/A | ## 7. Rekomendasi untuk Relying Party Bagi organisasi (Relying Party atau RP) yang bermaksud meminta dan memverifikasi kredensial digital dari pengguna, lanskap saat ini memerlukan perencanaan strategis yang cermat. ### 7.1. Strategi: Bersiap untuk Dunia Protokol Ganda 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) atau mereka yang menggunakan Chrome/[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), tergantung pada jalur yang dipilih. Pendekatan pragmatis, meskipun lebih intensif dalam pengembangan, adalah membangun fleksibilitas untuk menangani keduanya. ### 7.2. Memahami Perbedaan Pengungkapan Informasi 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](https://www.corbado.com/glossary/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 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. ## 8. Rekomendasi untuk Penerbit Wallet Bagi entitas yang ingin menerbitkan kredensial digital dan menyediakan aplikasi wallet bagi pemegang, lingkungan sistem operasi memainkan peran penting. ### 8.1. Pertimbangan Platform: iOS vs. Android [Penerbit](https://www.corbado.com/glossary/issuer) wallet menghadapi lanskap yang sangat berbeda di [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) dan Android mengenai pembuatan wallet, integrasi sistem, dan interaksi dengan API Kredensial Digital. ![Kredensial Digital Android](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_digital_credential_cfe8d92b1e.png) - **Android**: Secara umum menawarkan ekosistem yang lebih terbuka. Android Credential Manager menyertakan API Holder yang memungkinkan [aplikasi native](https://www.corbado.com/id/blog/passkey-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](https://www.corbado.com/id/blog/passkey-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. ![Kredensial Digital Apple](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/apple_digital_credential_f763cdaeb9.png) - **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](https://www.corbado.com/blog/mobile-drivers-license) 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](https://support.apple.com/en-us/118260) 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. ### 8.2. Walled Garden Apple untuk Pembuatan Wallet Pendekatan "taman bertembok" (walled garden) Apple sudah mapan, dan implementasi kredensial digital mereka tidak terkecuali. Namun, [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) 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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/id/blog/passkey-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. ## 9. Kesimpulan: Dari Dirilis Menjadi Diatur 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](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), 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](https://github.com/w3c-fedid/digital-credentials/issues/396) 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](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228) dari Ping Identity tetap belum terselesaikan). Sementara itu, API **berkembang dari presentasi ke siklus hidup penuh**: [Origin Trial penerbitan](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) Chrome 143 melalui `navigator.credentials.create()` memungkinkan situs web memicu penyediaan wallet. Tetapi [kerentanan pengikatan pemilihan wallet](https://github.com/w3c-fedid/digital-credentials/issues/382) — di mana aplikasi wallet berbahaya dapat mencegat kode penerbitan — menghalangi adopsi pemerintah terhadap fitur ini. Di sisi regulasi, [Topik F ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) 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](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) telah menambahkan dukungan API DC, dan rangkaian uji kesesuaian sedang dikembangkan oleh [European Wallet Consortium](https://eudiwalletconsortium.org/). 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](https://github.com/w3c-fedid/digital-credentials/issues/439) belum terselesaikan — terkait langsung dengan kendala platform Apple. Dan pertimbangan privasi tetap menjadi [kesenjangan terbesar](https://github.com/w3c-fedid/digital-credentials/issues/255) 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.