Get your free and exclusive 80-page Banking Passkey Report
Blog-Post-Header-Image

Kredensial Digital dan Passkey: Persamaan & Perbedaannya

Pahami bagaimana passkey dan kredensial digital saling melengkapi untuk menciptakan identitas digital yang tepercaya dan tahan phishing.

Vincent Delitz

Vincent

Created: July 25, 2025

Updated: July 25, 2025


See the original blog version in English here.

Ringkasan Singkat: Passkey vs. Kredensial Digital#

  • 🔑 Passkey: Untuk Login yang Aman. Passkey membuktikan siapa Anda (autentikasi) dan melawan phishing secara efektif.
  • 📄 Kredensial Digital: Untuk Bukti yang Dapat Diverifikasi. Kredensial ini membuktikan fakta tentang Anda (atestasi, misalnya, ID, keahlian), dan Anda mengontrol apa yang dibagikan.
  • 🤝 Persamaannya: Keduanya menggunakan kriptografi yang kuat untuk keamanan yang lebih baik dan pengalaman pengguna yang lebih lancar dibandingkan dengan kata sandi.
  • 🎯 Perbedaannya: Passkey terutama untuk mengakses layanan. Kredensial Digital untuk memberikan informasi terverifikasi tentang diri Anda.
PasskeyKredensial Digital
Tindakan👤 Login ke situs/aplikasi📜 Menunjukkan info terverifikasi (ID, keahlian)
Phishing✅ Kuat (Kunci spesifik situs)⚠️ Bervariasi (Presentasi adalah kuncinya)
Status👍 Diadopsi Luas & Terstandardisasi💡 Baru Muncul & Berkembang

1. Pendahuluan#

Lanskap digital berubah dengan cepat. Perubahan ini tidak hanya terjadi karena kata sandi tradisional dan rahasia bersama terus gagal, tetapi juga karena serangan seperti phishing dan deepfake yang didukung AI menjadi jauh lebih baik dan sulit dikenali. Ancaman canggih ini dapat menipu bahkan pengguna yang berhati-hati dan membuat cara lama untuk memeriksa identitas menjadi tidak dapat diandalkan. Ini jelas menunjukkan bahwa bukti kriptografis digital adalah satu-satunya cara yang benar-benar aman untuk mengonfirmasi identitas seseorang. Dalam situasi sulit ini, kita sangat membutuhkan cara yang lebih aman, ramah pengguna, dan dapat diverifikasi secara kriptografis untuk berinteraksi secara online. Kebutuhan ini telah membuat dua teknologi utama menjadi penting: passkey, yang sudah banyak digunakan, dan kredensial digital, yang baru saja dimulai. Teknologi ini tidak bergantung pada klaim yang diperiksa manusia—yang semakin mudah dipalsukan—tetapi sebaliknya menggunakan bukti kriptografis yang dapat diverifikasi mesin untuk membangun kepercayaan yang nyata.

DigitalCredentialsDemo Icon

Want to try digital credentials yourself in a demo?

Try Digital Credentials

1.1 Mengapa passkey meledak pada 2023-24#

Penggunaan passkey melonjak pesat selama 2023-2025, berkat dukungan kuat dari perusahaan besar seperti Apple, Google, dan Microsoft, ditambah FIDO Alliance. Berdasarkan standar W3C WebAuthn yang solid, passkey adalah perubahan mendasar dari rahasia bersama yang lemah. Alih-alih kata sandi, passkey menggunakan kriptografi kunci publik. Di sini, kunci privat, yang disimpan dengan aman di perangkat pengguna, menandatangani tantangan dari relying party (RP). Ini membuktikan bahwa pengguna memiliki kunci tersebut tanpa menunjukkannya.

Kriptografi ini membuat passkey sangat sulit untuk di-phishing—sebuah keunggulan besar, karena serangan phishing menjadi semakin canggih, terkadang menggunakan deepfake agar terlihat lebih nyata. Karena passkey terikat pada situs web atau aplikasi spesifik tempat ia dibuat, pengguna tidak dapat secara tidak sengaja menggunakannya di situs palsu. Ini adalah masalah umum dengan metode login lama yang rentan terhadap trik canggih semacam itu. Passkey juga menghentikan penggunaan ulang kata sandi dan bahaya credential stuffing setelah pelanggaran data. Lebih dari sekadar keamanan, passkey membuat proses login menjadi jauh lebih baik: lebih cepat, sering kali hanya memerlukan pemindaian biometrik (seperti Face ID atau sidik jari), sehingga pengguna tidak perlu mengingat atau mengetik kata sandi yang panjang. Perpaduan antara keamanan yang lebih baik dan kemudahan penggunaan ini telah membuatnya populer dengan cepat.

1.2 Kredensial Digital#

Pada saat yang sama, kredensial digital, yang sering disimpan di wallet identitas digital, menjadi jauh lebih banyak dibicarakan. EU Digital Identity Wallet (EUDI Wallet) adalah contoh yang baik dari tren ini.

Tidak seperti passkey, yang terutama untuk autentikasi (membuktikan siapa Anda dengan menunjukkan Anda mengontrol kunci privat), kredensial digital (berdasarkan standar seperti W3C Verifiable Credentials (VCs) atau ISO mdocs) adalah tentang atestasi yang dapat diverifikasi secara kriptografis (membuktikan apa yang benar tentang Anda dengan klaim yang ditandatangani secara digital). Kemampuan untuk memverifikasi klaim ini dengan kuat sangat penting, terutama sekarang karena deepfake dapat membuat pemalsuan bukti tradisional yang meyakinkan. Tanpa pemeriksaan kriptografis, bahkan para ahli pun sulit membedakan mana yang asli. Kredensial ini memungkinkan orang untuk membawa dan menunjukkan info terverifikasi secara digital—seperti nama, tanggal lahir, surat izin mengemudi, pendidikan, atau sertifikat pekerjaan—dengan cara yang aman secara kriptografis, menghormati privasi (dengan membiarkan pengguna hanya berbagi apa yang diperlukan), dan dapat diperiksa oleh mesin.

Munculnya kedua teknologi ini bukanlah suatu kebetulan. Ini menunjukkan pergeseran yang lebih luas di industri dari sistem identitas terpusat berbasis kata sandi ke model yang lebih terdesentralisasi dan berfokus pada pengguna yang dibangun di atas kepercayaan kriptografis. Kata sandi adalah titik lemah yang diketahui dalam keamanan online. Cara lama berbagi detail identitas sering kali kikuk, tidak aman, atau berbagi terlalu banyak data, yang merugikan privasi pengguna. Passkey memperbaiki kelemahan autentikasi secara langsung. Kredensial digital menangani pembagian atribut secara aman dan dengan kontrol pengguna. Keduanya menggunakan kriptografi serupa dan semakin bergantung pada integrasi platform dan perangkat keras yang aman, menunjukkan upaya bersama untuk membuat sistem identitas digital kita menjadi jauh lebih baik.

1.3 Pertanyaan inti: Bagaimana kedua teknologi ini bertemu dalam alur di dunia nyata?#

Sementara passkey menangani "login" dan kredensial digital menangani "pembuktian atribut," keduanya menggunakan dasar-dasar kriptografi yang serupa dan memainkan peran yang saling melengkapi dalam membangun interaksi digital yang tepercaya. Ini adalah sesuatu yang sangat kita butuhkan, karena ancaman saat ini seperti phishing yang canggih dan deepfake membuat cara-cara lama yang non-kriptografis untuk memeriksa identitas menjadi tidak aman. Ini membawa kita ke pertanyaan utama: Bagaimana passkey dan kredensial digital terhubung, dan bagaimana mereka dapat bekerja sama dalam situasi pengguna sehari-hari?

Artikel ini mengeksplorasi sinergi ini. Kita akan memeriksa perbedaan dan kesamaan mereka, protokol yang memungkinkannya, ketergantungan bersama mereka pada perangkat keras yang aman, dan bagaimana mereka dapat saling terkait dalam skenario seperti orientasi pengguna, login dengan step-up authentication, dan migrasi perangkat. Kita juga akan menyinggung bagaimana standar browser yang sedang berkembang seperti Digital Credentials API bertujuan untuk menjembatani dunia ini. Tulisan ini secara khusus berfokus pada interaksi antara teknologi-teknologi ini, melengkapi eksplorasi teknis yang lebih mendalam tentang Digital Credentials API yang sudah tersedia.

2. Passkey & Kredensial Digital dalam Satu Gambar#

Untuk memahami bagaimana passkey dan kredensial digital dapat bekerja sama, penting untuk terlebih dahulu memahami karakteristik masing-masing dan lapisan teknologi yang menopangnya.

2.1 Tabel perbandingan — tujuan, primitif kripto, UX#

Tabel berikut memberikan perbandingan tingkat tinggi:

FiturPasskeyKredensial Digital
Tujuan UtamaAutentikasi (Membuktikan siapa Anda dengan menunjukkan kontrol atas kunci privat)Atestasi/Otorisasi (Membuktikan apa yang benar tentang Anda melalui klaim yang ditandatangani; juga dapat digunakan untuk autentikasi)
Teknologi IntiStandar FIDO2W3C Verifiable Credentials, ISO mdocs (misalnya, 18013-5, 18013-7), OpenID4VC (OID4VP/OID4VCI)
Data yang DisampaikanBukti kriptografis kepemilikan kunci (Assertion)Klaim/Atribut yang Ditandatangani (misalnya, Nama, Tanggal Lahir, Alamat, Kualifikasi, Usia di atas 18)
Interaksi UmumLogin / Masuk / AutentikasiMenyajikan Bukti / Berbagi Data (misalnya, verifikasi usia, pemeriksaan KYC, menunjukkan lisensi, membuktikan kualifikasi)
Kriptografi Kunci🔑 Pasangan Kunci Asimetris: Kunci privat menandatangani tantangan autentikasi.🔑 Pasangan Kunci Asimetris: Kunci privat Issuer menandatangani VC; Kunci privat Holder menandatangani presentasi.
Tujuan Pengalaman Pengguna✅ Login cepat, sering, dan minim gesekan✅ Berbagi data yang aman, selektif, dan berbasis persetujuan
Pengikatan Perangkat❌ sebagian besar disinkronkan (dalam proses)✅ Dikontrol oleh Issuer (kunci sensitif terikat perangkat)
Ketahanan Phishing✅ Tinggi (Kredensial yang terikat pada origin mencegah penggunaan di situs palsu)❌ Bervariasi (Alur presentasi sangat penting; data VC itu sendiri dapat diverifikasi tetapi konteks presentasi dapat di-phishing jika tidak hati-hati. Desain protokol (misalnya, pengikatan origin di API) bertujuan untuk mengurangi ini).
Jangkar Kepercayaan / Sumber Kebenaran✅ Pengikatan identitas RP ke kunci publik selama pendaftaran; Keamanan Authenticator.✅ Otoritas & tanda tangan kriptografis Issuer; Infrastruktur kunci publik Issuer.
Kematangan Standardisasi / Interoperabilitas✅ Tinggi (WebAuthn/CTAP2 diadopsi dengan baik)❌ Campuran (Model data VC stabil; Protokol Presentasi/Penerbitan/API berkembang, ada fragmentasi)
Kemampuan Offline❌ Tidak ada✅ Ya (Dirancang untuk presentasi offline, misalnya, mDL melalui NFC/BLE)
Mekanisme Pencabutan✅ RP menghapus catatan kunci publik; Pengguna menghapus dari authenticator.✅ Issuer menerbitkan status (misalnya, daftar status); Verifier memeriksa status; Holder menghapus VC.
Gesekan Pendaftaran✅ Rendah (Sering terintegrasi ke dalam login/pendaftaran)❌ Tinggi (Pengaturan wallet terpisah)
Tingkat Adopsi (Mei 2025)✅ 95 %+❌ < 1 %

Perbandingan ini menyoroti bahwa meskipun keduanya memanfaatkan kriptografi untuk kepercayaan, fungsi utama dan pola penggunaan tipikal mereka berbeda secara signifikan. Passkey dioptimalkan untuk autentikasi yang sering dan aman, sementara kredensial digital unggul dalam menyediakan atribut yang dapat diverifikasi dengan persetujuan pengguna.

2.2 Lapisan WebAuthn (CTAP 2 dan Sinyal Kepercayaan Tingkat Lanjut)#

Passkey diwujudkan melalui interaksi beberapa standar utama:

  • WebAuthn (Web Authentication): Standar W3C ini mendefinisikan API JavaScript yang digunakan aplikasi web untuk berinteraksi dengan authenticator untuk mendaftarkan (navigator.credentials.create()) dan mengautentikasi (navigator.credentials.get()) passkey. Ini bertindak sebagai jembatan antara aplikasi web Relying Party dan browser atau sistem operasi pengguna. WebAuthn memperluas Credential Management API umum dari W3C.

  • CTAP (Client to Authenticator Protocol): Didefinisikan oleh FIDO Alliance, CTAP menentukan bagaimana klien (browser atau OS) berkomunikasi dengan perangkat authenticator. Ini bisa berupa platform authenticator yang terpasang di perangkat (menggunakan perangkat keras aman seperti TPM atau Secure Enclave) atau authenticator roaming seperti kunci keamanan USB atau bahkan ponsel yang bertindak sebagai authenticator untuk perangkat lain. CTAP2 adalah versi yang selaras dengan FIDO2 dan passkey, mendukung berbagai transportasi seperti USB, NFC, dan Bluetooth Low Energy (BLE).

  • Sinyal Kepercayaan Tingkat Lanjut & Pengikatan Perangkat (Pertimbangan untuk Passkey yang Disinkronkan): Seiring berkembangnya passkey menjadi dapat disinkronkan antar perangkat ("kredensial multi-perangkat"), Relying Party (RP) terkadang perlu mengidentifikasi perangkat fisik spesifik yang digunakan selama autentikasi untuk penilaian risiko. Ide-ide awal, seperti ekstensi devicePubKey dan supplementalPubKeys, mencoba menyelesaikan ini tetapi kemudian ditinggalkan. Kelompok kerja sinyal kepercayaan FIDO Alliance sekarang sedang mengembangkan penggantinya. Ide utamanya di sini adalah bahwa authenticator dengan passkey yang disinkronkan juga dapat membuat dan menggunakan pasangan kunci kedua yang terikat pada perangkat. Selama autentikasi, authenticator kemudian dapat memberikan tanda tangan dari kunci utama yang disinkronkan dan kunci kedua yang terikat perangkat ini. Ini akan memungkinkan RP mengenali perangkat tepercaya tertentu. Ini bisa berarti lebih sedikit gesekan (misalnya, melewatkan tantangan tambahan) bahkan jika passkey utama disinkronkan di banyak perangkat, semua tanpa kehilangan manfaat utama dari passkey yang disinkronkan: kegunaan di seluruh perangkat. Meskipun belum ada standar final untuk ini, fitur semacam itu akan memenuhi kebutuhan utama bagi RP yang memerlukan jaminan tinggi, memungkinkan mereka untuk lebih baik mengenali penggunaan perangkat baru atau memenuhi aturan Strong Customer Authentication (SCA) internal.

2.3 Lapisan Kredensial Digital (OpenID 4 VP/VCI, ISO 18013-7)#

Demikian pula, ekosistem kredensial digital bergantung pada serangkaian protokol dan API yang sedang berkembang untuk berfungsi:

  • API Kredensial Digital: Ini adalah upaya spesifikasi W3C yang sedang berkembang yang bertujuan untuk memperluas API navigator.credentials.get() untuk memungkinkan aplikasi web meminta Verifiable Credentials dari wallet digital pengguna dengan cara yang terstandardisasi. Ini melayani tujuan yang sama dengan WebAuthn tetapi berfokus pada VC, bukan passkey.
  • OpenID for Verifiable Presentations (OpenID4VP): Ini mendefinisikan protokol, yang dibangun di atas OAuth 2.0, tentang bagaimana Verifier (RP yang meminta kredensial) dapat meminta VC dari Wallet milik Holder. Elemen kunci termasuk presentation_definition (menentukan kredensial dan klaim yang diperlukan), Wallet yang bertindak sebagai server otorisasi, dan vp_token yang membawa Verifiable Presentation kembali ke Verifier.
  • OpenID for Verifiable Credential Issuance (OpenID4VCI): Melengkapi OpenID4VP, ini menstandardisasi bagaimana Issuer mengirimkan VC ke Wallet milik Holder, sekali lagi menggunakan mekanisme OAuth 2.0. Ini melibatkan konsep seperti Penawaran Kredensial, alur kode pra-otorisasi atau otorisasi, dan titik akhir kredensial khusus.
  • Standar ISO (misalnya, ISO/IEC 18013-7, ISO/IEC 23220): Standar internasional ini sangat signifikan untuk surat izin mengemudi seluler (mDL) dan jenis dokumen seluler lainnya (mdoc). ISO 18013-5 mendefinisikan struktur data mDL inti dan presentasi offline (NFC, BLE), sementara ISO 18013-7 dan 23220 menentukan mekanisme presentasi online, termasuk API REST dan profil integrasi dengan OpenID4VP (Lampiran B dari 18013-7). Platform seperti Google Wallet dan Apple Wallet memanfaatkan standar ISO ini.

2.4 Blok bangunan bersama (kunci publik/privat, Secure Enclave, StrongBox)#

Meskipun tujuan dan protokolnya berbeda, passkey dan kredensial digital berbagi blok bangunan fundamental:

  • Kriptografi Asimetris: Keduanya sangat bergantung pada pasangan kunci publik-privat. Passkey menggunakan kunci privat untuk membuktikan kepemilikan selama autentikasi. Kredensial digital menggunakan kunci privat issuer untuk menandatangani kredensial, memastikan keaslian dan integritasnya, dan pemegang mungkin menggunakan kunci privat mereka untuk menandatangani presentasi yang berisi kredensial tersebut.
  • Perangkat Keras Aman: Melindungi kunci privat adalah yang terpenting. Kedua teknologi ini sangat diuntungkan dari komponen perangkat keras aman yang terintegrasi ke dalam perangkat modern:
  • TPM (Trusted Platform Module): Chip khusus yang sering ditemukan di laptop dan desktop, menyediakan pembuatan kunci yang aman, penyimpanan, dan operasi kriptografis. Ini biasa digunakan oleh authenticator platform seperti Windows Hello.
  • Secure Enclave: Manajer kunci berbasis perangkat keras Apple, terisolasi dari prosesor utama di iPhone, iPad, dan Mac, digunakan untuk melindungi data sensitif termasuk kunci privat passkey.
  • Sistem Keystore Android / StrongBox Keymaster: Android menyediakan Keystore yang didukung perangkat keras, sering diimplementasikan menggunakan prosesor aman khusus (StrongBox Keymaster), menawarkan perlindungan kuat untuk kunci kriptografis pada perangkat Android. Meskipun beberapa manajer kata sandi menggunakan nama "Strongbox", elemen perangkat keras aman yang mendasarinya yang disediakan oleh OS adalah pendukung utamanya.

Penggunaan elemen perangkat keras aman yang sama (TPM, Secure Enclave, Keystore yang didukung perangkat keras Android) untuk operasi passkey dan berpotensi untuk mengamankan kunci privat di dalam wallet digital menciptakan sinergi yang signifikan. Platform tidak memerlukan chip aman terpisah untuk setiap fungsi. Sebaliknya, mereka dapat menggunakan satu basis perangkat keras yang kuat dan API sistem operasi terkait (seperti yang untuk Keystore Android atau Secure Enclave Apple) untuk melindungi dengan kuat baik kredensial autentikasi (passkey) maupun kredensial atestasi (VC). Ini membuat pengembangan lebih mudah, meningkatkan konsistensi keamanan, dan memanfaatkan investasi platform yang ada dengan baik.

Selanjutnya, Credential Management API browser (navigator.credentials) adalah lapisan pengorganisasian utama. Pertama kali diperluas oleh WebAuthn untuk passkey, sekarang sedang diperluas lebih lanjut oleh API Kredensial Digital untuk VC. Ini menunjuk ke rencana yang jelas: memberi RP satu cara utama untuk meminta kredensial yang berbeda, dan memberi pengguna cara yang akrab untuk memilihnya (seperti melalui manajer kredensial Android atau manajer kata sandi bawaan browser). Ini akan menyembunyikan detail teknis yang kompleks dari protokol seperti CTAP, OID4VP, dan ISO, membuat segalanya lebih mudah bagi pengembang dan pengguna.

3. Pandangan Relying Party: Mengintegrasikan Passkey & Kredensial Digital#

Dari perspektif Relying Party (RP), memahami cara mengintegrasikan dan memanfaatkan passkey dan kredensial digital secara efektif sangat penting untuk meningkatkan keamanan, meningkatkan pengalaman pengguna, dan memenuhi persyaratan peraturan. Bagian ini menganalisis bagaimana RP dapat menerapkan teknologi ini di berbagai skenario dan ekosistem umum.

3.1 Perbandingan Skenario Ekosistem#

Strategi integrasi yang optimal untuk passkey dan kredensial digital sangat bervariasi berdasarkan kasus penggunaan spesifik dan profil risiko serta persyaratan terkait. Tabel berikut memberikan perbandingan tingkat tinggi di berbagai skenario umum:

Perbandingan Skenario Ekosistem

SkenarioTujuanPeran PasskeyPeran VCToleransi GesekanPengikatan Perangkat?
E-Commerce / UmumKecepatan & Keamanan Dasar✅ Login Utama (2FA)tidak ada🟢 Rendah❌ Tidak
Jaminan Tinggi / MFAOtentikasi Kuat & Pembuktian ID✅ Login Utama (2FA)🆔 KYC / Onboard / Pemulihan🟡 Sedang❌ Tidak
Otentikasi PembayaranKonfirmasi Pembayaran Cepat & Aman✅ Login Utama (2FA)🆔 KYC / Onboard / Pemulihan🟢 Sangat Rendah❌ Tidak
Perbankan (Non-SCA)Keamanan Tinggi / Pengurangan Penipuan✅ Login Utama (2FA)🆔 KYC / Onboard / Pemulihan🟡 Sedang❓ Opsional
Kepatuhan SCA Uni EropaKepatuhan Peraturan✅ Faktor Inti SCA🆔 KYC / Onboard / Pemulihan🔴 Lebih Tinggi (Diwajibkan)✅ Ya
Mandat Wallet EUDI Uni EropaKepatuhan & Privasi Peraturan✅ Kunci Pseudonim (WebAuthn)🆔 PID (Data ID Orang) / Atribut Berkualifikasi (Sesuai Permintaan)🟡 Sedang✅ Ya (Atestasi WSCD)

Legenda:

  • Peran VC 🆔: Menjelaskan peran selama interaksi utama, mengakui VC sering digunakan untuk orientasi awal/KYC di berbagai skenario.
  • Pengikatan Perangkat? 🔗: Mengacu pada kebutuhan akan pengikatan perangkat eksplisit di luar pengikatan origin passkey standar, terutama relevan untuk passkey yang disinkronkan.
  • Mandat Wallet EUDI Uni Eropa*: Skenario ini mencerminkan persyaratan di bawah peraturan eIDAS 2 yang akan datang, diharapkan berlaku ~36 bulan setelah tindakan implementasi akhir mulai berlaku (kemungkinan akhir 2020-an).

Perbandingan ini memberikan gambaran singkat; bagian berikut membahas secara spesifik setiap skenario dari perspektif integrasi RP.

3.2 Skenario Faktor Tunggal (misalnya, E-Commerce, Layanan Umum)#

  • Tujuan: Akses cepat, minim gesekan dengan keamanan dasar yang baik.
  • Kemungkinan Alur:
  • Autentikasi Utama: Passkey akan mendominasi. Ketahanan phishing dan UX yang mulus (seringkali hanya biometrik/PIN) membuatnya ideal untuk menggantikan kata sandi dalam skenario login yang sering.
  • Peran Kredensial Digital: Minimal untuk login inti. VC mungkin digunakan secara opsional setelah login untuk tindakan spesifik seperti verifikasi usia (misalnya, membeli barang terbatas), personalisasi berdasarkan atribut terverifikasi (misalnya, status loyalitas), atau penyelesaian profil yang dipercepat selama pendaftaran awal.
  • Interaksi: Passkey menangani login inti; VC dicadangkan untuk interaksi opsional berbasis atribut.

3.3 Skenario Autentikasi Multi-Faktor (MFA) & Verifikasi Identitas (misalnya, Pemerintah, Asuransi, Dana)#

  • Tujuan: Login dengan jaminan tinggi dan, jika perlu, assertion identitas terverifikasi.
  • Kemungkinan Alur:
  • Passkey sebagai 2FA/MFA Mandiri: Passkey secara inheren memenuhi persyaratan autentikasi dua faktor ketika verifikasi pengguna (PIN/biometrik) terjadi selama seremoni login. Mereka menggabungkan:
  • Kepemilikan: Bukti kontrol atas kunci privat.
  • Pengetahuan/Inherensi: Verifikasi pengguna melalui PIN atau biometrik. Ini membuat login passkey itu sendiri menjadi metode MFA yang kuat dan tahan phishing, cukup untuk banyak skenario jaminan tinggi tanpa memerlukan langkah kedua terpisah hanya untuk mencapai 2FA.
  • Step-Up untuk Verifikasi Identitas (Sekali Pakai): Kebutuhan utama untuk langkah tambahan dengan Kredensial Digital muncul ketika layanan harus secara eksplisit memverifikasi identitas di luar hanya mengautentikasi pengguna yang kembali. Pemeriksaan kriptografis yang kuat semacam ini sangat penting ketika deepfake dapat secara meyakinkan memalsukan ID visual atau berbasis dokumen. Hanya bukti kriptografis digital dari sumber tepercaya yang dapat dengan andal mengonfirmasi suatu atribut. Ini mungkin diperlukan:
  • Selama orientasi awal.
  • Untuk tindakan berisiko tinggi tertentu yang memerlukan atribut identitas yang dikonfirmasi. Dalam kasus ini, RP meminta presentasi Verifiable Credential spesifik (misalnya, PID, kredensial ID nasional) dari wallet pengguna setelah login passkey.
  • Identitas untuk Pemulihan: Setelah identitas pengguna diverifikasi dengan kuat (misalnya, melalui step-up presentasi VC), informasi identitas terverifikasi ini berpotensi dapat dimanfaatkan dalam alur pemulihan akun yang aman. Misalnya, jika pengguna kehilangan semua authenticator passkey mereka, menyajikan kredensial identitas jaminan tinggi dapat menjadi bagian dari proses untuk mendapatkan kembali akses dan mendaftarkan passkey baru.
  • Interaksi: Passkey menyediakan 2FA/MFA mandiri yang kuat untuk autentikasi. VC digunakan secara strategis untuk verifikasi identitas eksplisit bila diperlukan, dan identitas terverifikasi ini juga dapat mendukung mekanisme pemulihan akun yang aman.

3.4 Skenario Pembayaran (Gesekan Rendah)#

  • Tujuan: Checkout atau inisiasi pembayaran yang efisien dan aman, meminimalkan gesekan pengguna.
  • Kemungkinan Alur:
  • Autentikasi untuk Pembayaran: Passkey ideal untuk mengautentikasi pengguna ke akun Penyedia Layanan Pembayaran (PSP) mereka (misalnya, PayPal) atau langsung di dalam alur checkout merchant. Ini menggantikan kata sandi dan memberikan konfirmasi yang cepat dan aman untuk memulai pembayaran.
  • Orientasi/KYC: VC tetap penting selama fase orientasi atau penyiapan akun dengan PSP atau merchant, memberikan informasi identitas terverifikasi (pemeriksaan KYC/AML) yang diperlukan untuk mengaktifkan kemampuan pembayaran sejak awal.
  • Kekhawatiran Gesekan Transaksi: Memperkenalkan langkah presentasi Verifiable Credential terpisah selama alur otorisasi pembayaran inti (memerlukan interaksi dengan wallet identitas digital) akan menambah gesekan yang signifikan dibandingkan dengan langkah konfirmasi passkey yang mulus. Gangguan pada pengalaman pengguna ini kemungkinan akan merugikan tingkat konversi dan oleh karena itu tidak cocok untuk skenario pembayaran gesekan rendah yang khas.
  • Interaksi: Passkey mengamankan autentikasi untuk tindakan pembayaran itu sendiri. VC menangani pembuktian identitas/KYC yang diperlukan, sering kali sekali pakai, untuk membuat akun pembayaran, tetapi dijauhkan dari langkah konfirmasi pembayaran yang kritis dan sensitif terhadap gesekan. (Topik kompleks penggunaan kredensial digital secara langsung sebagai instrumen pembayaran, termasuk bagaimana berbagai jenis wallet dan API browser yang sedang berkembang dapat mengaktifkan atau berinteraksi dengan VC khusus pembayaran tersebut, dieksplorasi secara rinci dalam artikel pelengkap kami yang akan datang: Kredensial Digital dan Pembayaran.

3.5 Skenario Lembaga Keuangan (Di Luar SCA)#

  • Tujuan: Mengamankan akses perbankan dengan pengurangan penipuan yang signifikan, terutama yang terkait dengan phishing, dengan meningkatkan dari metode autentikasi lama.
  • Kemungkinan Alur:
  • Mengganti MFA Lama: Banyak lembaga keuangan saat ini mengandalkan kata sandi yang dikombinasikan dengan faktor kedua yang dapat di-phishing seperti OTP SMS. Passkey menawarkan alternatif yang jauh lebih unggul, memberikan autentikasi kuat yang secara inheren tahan terhadap phishing dalam satu gerakan pengguna.
  • Login Utama dengan Passkey: Mengadopsi passkey untuk login utama segera meningkatkan keamanan karena ketahanannya terhadap phishing. Sifat kriptografis passkey mengurangi vektor serangan paling umum yang mengganggu kredensial tradisional.
  • Step-Up Berbasis Risiko - Pertimbangan Hati-hati Sinyal Perangkat: Untuk operasi berisiko lebih tinggi (misalnya, transfer besar, mengubah detail kontak), lembaga keuangan dapat mempertimbangkan verifikasi step-up. Meskipun sinyal pengikatan perangkat yang terkait dengan passkey adalah sebuah pilihan, kebutuhannya harus dievaluasi dengan cermat. Ketahanan phishing dari autentikasi passkey utama itu sendiri sangat mengurangi banyak risiko.
  • Keamanan Berbasis Hasil & Pengurangan Penipuan: Pengurangan signifikan risiko phishing yang dicapai oleh passkey adalah faktor kritis. Pendekatan keamanan berbasis hasil, yang berfokus pada kekuatan dan ketahanan phishing dari metode autentikasi, dapat menyebabkan pengurangan penipuan yang substansial. Bobot faktor tahan phishing seperti passkey jauh lebih tinggi daripada menambahkan lebih banyak faktor yang dapat di-phishing. Ini harus menjadi pusat strategi lembaga keuangan saat bermigrasi dari metode lama.
  • VC untuk Orientasi/Pembuktian Identitas: Seperti dalam skenario lain, VC tetap penting untuk KYC/AML awal yang kuat dan untuk memperbarui atribut identitas pelanggan secara aman menggunakan informasi terverifikasi, membangun fondasi tepercaya untuk hubungan perbankan.
  • Interaksi: Passkey berfungsi sebagai metode autentikasi utama yang kuat dan tahan phishing, secara drastis mengurangi risiko penipuan dari sistem lama. Sinyal perangkat untuk step-up adalah pilihan taktis. Kekuatan inheren passkey harus menginformasikan postur keamanan berbasis risiko, berpotensi mengurangi ketergantungan berlebihan pada faktor tambahan yang kurang tahan phishing. VC memberikan jaminan identitas dasar.

3.6 Skenario Mandat Wallet EUDI Uni Eropa (Persyaratan Masa Depan)#

  • Tujuan: Mematuhi peraturan eIDAS 2 (Pasal 5f) yang mewajibkan penerimaan EU Digital Identity Wallet oleh Relying Party tertentu (badan publik, entitas swasta besar di sektor yang diatur, VLOP), memungkinkan login pseudonim yang menjaga privasi dan verifikasi identitas/atribut jaminan tinggi bila diwajibkan secara hukum.
  • Kemungkinan Alur:
  • Login Pseudonim (Default): Pengguna memulai login. RP meminta autentikasi melalui EUDI Wallet. Wallet menggunakan "kunci pseudonim" bawaannya—sebuah resident key WebAuthn yang terikat perangkat keras dan terlingkup RP yang disimpan di elemen aman bersertifikat perangkat (WSCD)—untuk mengautentikasi pengguna. Ini memberikan autentikasi yang kuat dan sesuai SCA (kepemilikan + verifikasi pengguna) sambil menjaga identitas sipil pengguna tetap pseudonim secara default.
  • Step-Up untuk Identitas/Atribut (Diwajibkan Secara Hukum): Jika dan hanya jika RP memiliki dasar hukum spesifik di bawah hukum Uni atau nasional (misalnya, PSD2, AML, pendaftaran telekomunikasi) untuk memerlukan verifikasi identitas atau atribut spesifik, ia memulai langkah kedua. RP meminta presentasi (melalui OpenID4VP) dari Data Identifikasi Orang (PID) atau Atestasi Atribut Berkualifikasi (QAA) yang diperlukan dari wallet. Pengguna harus secara eksplisit menyetujui untuk membagikan data teridentifikasi ini.
  • Autentikasi Wallet & RP: Alur ini melibatkan autentikasi timbal balik. RP mengautentikasi dirinya ke wallet (berdasarkan pendaftaran resminya), dan wallet membuktikan keasliannya dan validitas kredensial ke RP, memanfaatkan perangkat keras aman (WSCD) dan infrastruktur sertifikasi terkait.
  • Interaksi: EUDI Wallet bertindak sebagai authenticator terpadu. Passkey WebAuthn terintegrasinya (kunci pseudonim) menangani login standar, menawarkan autentikasi yang kuat dan menjaga privasi. Kemampuan VC wallet dipanggil secara selektif untuk pengungkapan identitas atau atribut yang eksplisit dan diamanatkan secara hukum, memastikan minimisasi data secara default.

4. Pertimbangan Strategis untuk RP#

Menavigasi lanskap yang berkembang ini membutuhkan perencanaan strategis. Berikut adalah pertimbangan utama untuk Relying Party (RP)

4.1 Terus kumpulkan passkey#

Bagi RP, tindakan utama hari ini adalah mengaktifkan dan mendorong penggunaan passkey untuk autentikasi. Passkey sudah terstandardisasi, didukung luas oleh platform, dan menawarkan manfaat besar dan langsung dalam keamanan (ketahanan phishing) dan pengalaman pengguna (login lebih cepat dan mudah). Ini berarti lebih sedikit ketergantungan pada kata sandi dan metode MFA yang tidak aman seperti OTP SMS. Ini juga dapat menurunkan biaya dukungan dari reset kata sandi dan pemulihan akun. Menargetkan penggunaan passkey yang luas akan membangun dasar yang modern dan aman untuk autentikasi pengguna. Meskipun adopsi mungkin lambat pada awalnya, mengedukasi pengguna tentang manfaatnya sebelumnya dan membuat pendaftaran menjadi mudah dapat membantu mereka memulai.

4.2 Mengatasi Kesenjangan Kepatuhan SCA: Contoh PayPal#

Sementara passkey itu sendiri menawarkan langkah signifikan menuju autentikasi yang kuat dan dapat memenuhi persyaratan Strong Customer Authentication (SCA), beberapa organisasi mungkin memiliki kerangka kerja kepatuhan internal dengan interpretasi yang lebih ketat atau kekhawatiran spesifik, terutama mengenai passkey yang disinkronkan. Untuk Relying Party (RP) yang menghadapi skenario di mana departemen kepatuhan mencari jaminan lebih lanjut, ada baiknya mengetahui bahwa tindakan tambahan dapat melengkapi penerapan passkey. Ini dapat membantu mengatasi kesenjangan SCA yang dirasakan atau memenuhi persyaratan internal yang lebih tinggi tersebut. Salah satu strategi umum adalah memanfaatkan sinyal kepercayaan perangkat, sebuah pendekatan yang diambil oleh layanan seperti PayPal.

PayPal, misalnya, memungkinkan pengguna untuk menandai perangkat sebagai "diingat" seperti yang dijelaskan di halaman bantuan mereka:

"Perangkat yang diingat adalah browser web atau seluler pribadi, atau perangkat seluler yang digunakan untuk masuk ke akun PayPal Anda yang kami ingat setelah kami berhasil mengonfirmasi identitas Anda. Ini membuatnya lebih mudah untuk login, membayar, dan melakukan tindakan lain dengan akun PayPal Anda karena perangkat berfungsi sebagai salah satu dari dua faktor yang diperlukan untuk SCA."

Ini berarti bahwa jika pengguna login dengan kata sandi mereka (sesuatu yang mereka tahu) dari perangkat yang diingat (sesuatu yang mereka miliki), PayPal dapat menganggap ini cukup untuk SCA dalam banyak kasus. Namun, mereka juga menyatakan, "Mungkin ada saat-saat di mana kami masih meminta Anda untuk verifikasi lain untuk memastikan akun Anda aman." Ini bisa melibatkan pengiriman kode sandi sekali pakai melalui SMS atau meminta konfirmasi melalui aplikasi PayPal.

Pendekatan ini memungkinkan pengalaman pengguna yang lebih lancar di perangkat tepercaya sambil tetap menyediakan mekanisme untuk step-up authentication ketika risiko lebih tinggi atau peraturan menuntutnya. RP dapat mempertimbangkan model serupa, di mana kombinasi autentikasi utama (seperti passkey) dan kepercayaan perangkat (berpotensi dikelola di luar mekanisme langsung WebAuthn jika diperlukan) dapat membantu menjembatani kesenjangan kepatuhan SCA. Namun, untuk pendekatan yang lebih terintegrasi dan terstandardisasi terhadap sinyal kepercayaan khusus perangkat dalam kerangka kerja WebAuthn itu sendiri, perhatian beralih ke perkembangan yang sedang berlangsung di bidang itu.

4.3 Pantau Penerus Ekstensi WebAuthn yang Dihentikan untuk Pengikatan Perangkat yang Lebih Kuat#

Mengenai pendekatan terintegrasi WebAuthn untuk kepercayaan perangkat yang lebih kuat, RP di lingkungan keamanan tinggi harus memahami sejarah dan arah masa depan. Proposal ekstensi WebAuthn di masa lalu, seperti devicePubKey dan supplementalPubKeys, bertujuan untuk menyediakan sinyal kepercayaan khusus perangkat ini. Ini adalah upaya untuk mengatasi pertimbangan keamanan dari passkey yang disinkronkan, yang, meskipun menawarkan kegunaan penting untuk adopsi massal, memperkenalkan profil risiko yang berbeda (misalnya, ketergantungan pada pemulihan akun cloud) dibandingkan dengan kunci yang terikat perangkat. Ide di balik ekstensi semacam itu adalah untuk memungkinkan RP mendapatkan lapisan jaminan ekstra dengan memeriksa tanda tangan dari kunci yang secara khusus terikat pada perangkat fisik yang digunakan, bahkan ketika passkey utama itu sendiri disinkronkan.

Meskipun ekstensi spesifik ini (devicePubKey dan supplementalPubKeys) telah dihentikan, tantangan untuk mendapatkan sinyal pengikatan perangkat yang lebih kuat untuk passkey yang disinkronkan tetap ada. Oleh karena itu, RP harus memantau pengembangan dan standardisasi solusi lanjutan di bidang ini. Solusi semacam itu dapat membantu RP menilai risiko dengan lebih baik (misalnya, membedakan login dari perangkat yang dikenal dan tepercaya dari yang baru disinkronkan) tanpa memaksa semua pengguna untuk menggunakan passkey yang terikat perangkat yang kurang nyaman. Konteks ini menyajikan RP dengan pilihan yang lebih kompleks daripada sekadar "disinkronkan vs. terikat perangkat." Passkey yang disinkronkan (biasanya sesuai AAL2) menawarkan kenyamanan paling besar dan peluang terbaik untuk adopsi, penting untuk aplikasi konsumen. Passkey yang terikat perangkat (mungkin AAL3) memberikan jaminan tertinggi tetapi bisa lebih sulit digunakan. Tujuan dari ekstensi yang dihentikan adalah untuk menemukan jalan tengah—meningkatkan keamanan untuk kunci yang disinkronkan dengan menambahkan kembali sinyal kepercayaan khusus perangkat. Ini dapat membantu mengurangi beberapa risiko jika sinkronisasi cloud disusupi, tanpa kehilangan semua kenyamanan sinkronisasi. Oleh karena itu, RP harus mencari solusi lanjutan yang bertujuan untuk melakukan ini. Strategi terbaik akan bergantung pada toleransi risiko spesifik RP, basis pengguna, dan seberapa matang standar baru yang muncul.

4.4 Kredensial Digital: Pertimbangan RP untuk Pengikatan Perangkat dan Transisi Wallet#

Di luar mekanisme spesifik dalam WebAuthn untuk kepercayaan perangkat, beberapa Relying Party (RP)—terutama di sektor seperti perbankan, asuransi, dan layanan pembayaran—mulai mengevaluasi kredensial digital (Verifiable Credentials, atau VC) sebagai komponen pelengkap, atau bahkan langkah selanjutnya, dalam strategi identitas dan keamanan mereka.

Faktor signifikan yang mendorong minat ini adalah pengikatan perangkat yang kuat yang sering dikaitkan dengan kredensial digital, terutama ketika dikelola dalam wallet identitas digital yang aman. Wallet ini dapat memanfaatkan keamanan yang didukung perangkat keras (seperti Secure Enclave atau TPM) untuk melindungi kredensial dan kunci privat yang digunakan untuk menyajikannya. Issuer dan penyedia wallet juga dapat memberlakukan kebijakan yang membuat kredensial bernilai tinggi tertentu secara inheren terikat perangkat, menawarkan tingkat kontrol yang menarik untuk skenario jaminan tinggi.

Sangat penting untuk menyadari bahwa meskipun kemampuan pengikatan perangkat yang ditingkatkan ini adalah fitur yang menarik bagi RP ini, tujuan utama kredensial digital (atestasi atribut dan klaim) berbeda dari passkey (autentikasi pengguna). Passkey mengonfirmasi siapa pengguna itu, sementara kredensial digital mengonfirmasi apa yang benar tentang pengguna. Meskipun ada perbedaan mendasar dalam tujuan ini, karakteristik keamanan yang kuat dari VC yang disimpan di wallet menjadikannya area pertimbangan aktif bagi RP yang ingin melapisi jaminan tambahan. Ini secara alami mengarahkan diskusi ke arah penyedia wallet identitas digital ini dan ekosistem yang memungkinkan penerbitan, penyimpanan, dan presentasi kredensial semacam itu.

5. Menyajikan Kredensial Digital melalui Wallet untuk Atestasi Identitas#

Sementara passkey menawarkan autentikasi langsung, kredensial digital (VC) dikelola dan disajikan kepada Relying Party melalui wallet identitas digital. Wallet ini, baik solusi platform asli (seperti Apple Wallet, Google Wallet) atau aplikasi pihak ketiga (seperti EUDI Wallet), sedang berkembang untuk menggunakan standar browser yang muncul seperti API Kredensial Digital untuk verifikasi identitas online yang lebih lancar (misalnya, pemeriksaan usia, berbagi atribut ID digital).

Mekanisme terperinci dari berbagai jenis wallet, strategi platform spesifik untuk integrasi VC (termasuk fokus mDoc Apple untuk interaksi browser versus dukungan OpenID4VP yang lebih luas dari Android melalui Credential Manager-nya), bagaimana wallet ini memfasilitasi atestasi atribut, dan pertimbangan yang sepenuhnya terpisah untuk fungsionalitas pembayaran apa pun adalah topik yang kompleks. Ini dieksplorasi secara mendalam dalam artikel pelengkap kami yang akan datang: Kredensial Digital dan Pembayaran.

Artikel saat ini mempertahankan fokusnya pada interaksi mendasar antara passkey untuk autentikasi dan peran umum kredensial digital untuk membuktikan atribut.

6. Kesimpulan#

Passkey dan kredensial digital, meskipun berbeda dalam tujuan utamanya, mewakili dua pilar masa depan identitas digital yang modern, lebih aman, dan berfokus pada pengguna. Memahami bagaimana keduanya berhubungan dan dapat saling mendukung adalah kunci untuk membangun gelombang layanan online berikutnya.

6.1 Poin tindakan:#

Berdasarkan keadaan saat ini dan lintasan teknologi ini, dua tindakan utama menonjol untuk Relying Party:

  • Terapkan passkey di mana saja hari ini: Standarnya sudah matang, dukungan platform tersebar luas, dan manfaatnya dibandingkan kata sandi jelas dan substansial. Jadikan passkey sebagai target default untuk autentikasi pengguna untuk meningkatkan keamanan dan kegunaan dengan segera.
  • Tambahkan step-up wallet jika AML/KYC penting: Untuk proses yang memerlukan jaminan lebih tinggi atau atribut terverifikasi spesifik—seperti memenuhi peraturan Anti-Money Laundering (AML) / Know Your Customer (KYC), melakukan verifikasi usia yang andal, atau mengonfirmasi kualifikasi profesional—integrasikan alur presentasi Verifiable Credential untuk mendapatkan atribut yang dapat diverifikasi secara kriptografis, yang sangat diperlukan untuk mempercayai identitas dan klaim di era pemalsuan digital dan deepfake yang canggih. Gunakan API Kredensial Digital jika memungkinkan, tetapi terapkan fallback QR/deep link yang kuat untuk memastikan jangkauan lintas platform hingga API stabil. Ini memberikan jaminan tinggi yang ditargetkan tanpa membebani setiap login.

6.2 Prospek jangka panjang — transfer antar-perangkat dan API browser yang terkonsolidasi#

Ke depan, kita dapat mengharapkan lebih banyak konvergensi dan perbaikan:

  • Portabilitas Kredensial yang Ditingkatkan: Metode transfer antar-perangkat kemungkinan akan menjadi lebih baik. Ini mungkin melampaui autentikasi lintas perangkat CTAP 2.2 untuk passkey untuk menyertakan cara yang lebih lancar untuk memindahkan VC antar wallet, meskipun standardisasi di sini belum sejauh itu.
  • API Browser yang Terkonsolidasi: API Kredensial Digital kemungkinan akan matang dan didukung secara lebih konsisten di seluruh browser. Ini akan menawarkan RP cara yang lebih standar untuk meminta passkey dan VC melalui navigator.credentials.
  • Pengalaman Pengguna yang Terpadu: Pada akhirnya, pengguna seharusnya melihat lebih sedikit perbedaan teknis antara mengautentikasi dengan passkey dan menyajikan atribut dengan VC. Manajer kredensial platform dan wallet kemungkinan akan mengelola interaksi ini dengan lancar di belakang layar. Mereka akan menggunakan alat kriptografi bersama dan perangkat keras yang aman, memungkinkan pengguna untuk hanya menyetujui permintaan dengan prompt biometrik atau PIN yang akrab, tidak peduli apakah passkey atau VC yang digunakan. Selanjutnya, konsep seperti Continuous Passive Authentication (CPA), yang terus-menerus memverifikasi pengguna di latar belakang menggunakan biometrik perilaku dan sinyal lainnya, dapat lebih meningkatkan keamanan yang mulus ini, berpotensi bekerja bersama authenticator aktif seperti passkey.

Mencapai masa depan yang terintegrasi ini akan membutuhkan lebih banyak pekerjaan pada standar, bagaimana platform mendukungnya, dan bagaimana aplikasi menggunakannya. Dengan menggunakan passkey sekarang dan dengan bijaksana menambahkan kredensial digital, organisasi dapat siap untuk pergeseran ini ke dunia digital yang tanpa kata sandi dan memberi pengguna lebih banyak kontrol atas data mereka.

Learn more about our enterprise-grade passkey solution.

Learn more

Share this article


LinkedInTwitterFacebook

Enjoyed this read?

🤝 Join our Passkeys Community

Share passkeys implementation tips and get support to free the world from passwords.

🚀 Subscribe to Substack

Get the latest news, strategies, and insights about passkeys sent straight to your inbox.

Related Articles