---
url: 'https://www.corbado.com/id/blog/kredensial-digital-passkey'
title: 'Kredensial Digital dan Passkey: Persamaan & Perbedaannya'
description: 'Pahami bagaimana passkey dan kredensial digital saling melengkapi untuk menciptakan identitas digital yang tepercaya dan tahan phishing.'
lang: 'id'
author: 'Vincent Delitz'
date: '2025-07-25T07:00:23.862Z'
lastModified: '2026-03-27T07:07:13.516Z'
keywords: 'kredensial digital vs. passkey'
category: 'Passkeys Strategy'
---

# Kredensial Digital dan Passkey: Persamaan & Perbedaannya

## Ringkasan Singkat: Passkey vs. Kredensial Digital

- 🔑 **Passkey: Untuk Login yang Aman.** Passkey membuktikan _siapa_ Anda (autentikasi)
  dan melawan [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) yang lebih baik dan pengalaman
  pengguna yang lebih lancar dibandingkan dengan kata sandi.
- 🎯 **Perbedaannya:** Passkey terutama untuk _mengakses_ layanan.
  [Kredensial Digital](https://www.corbado.com/id/blog/digital-credentials-api) untuk _memberikan informasi
  terverifikasi_ tentang diri Anda.

|              | **Passkey**                         | **Kredensial 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](https://www.corbado.com/glossary/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](https://www.corbado.com/id/blog/digital-credentials-api), 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.

### 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](https://www.corbado.com/glossary/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](https://www.corbado.com/id/blog/webauthn-pubkeycredparams-credentialpublickey). Di
sini, kunci privat, yang disimpan dengan aman di perangkat pengguna, menandatangani
tantangan dari [relying party](https://www.corbado.com/glossary/relying-party) (RP). Ini membuktikan bahwa
pengguna memiliki kunci tersebut tanpa menunjukkannya.

Kriptografi ini membuat passkey sangat sulit untuk
di-[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/credential-stuffing) setelah pelanggaran data. Lebih dari
sekadar [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android), passkey membuat proses
login menjadi jauh lebih baik: lebih cepat, sering kali hanya memerlukan pemindaian
biometrik (seperti [Face ID](https://www.corbado.com/faq/is-face-id-passkey) atau sidik jari), sehingga pengguna
tidak perlu mengingat atau mengetik kata sandi yang panjang. Perpaduan antara
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) yang lebih baik dan kemudahan
penggunaan ini telah membuatnya populer dengan cepat.

### 1.2 Kredensial Digital

Pada saat yang sama, [kredensial digital](https://www.corbado.com/id/blog/digital-credentials-api), yang sering
disimpan di [wallet](https://www.corbado.com/blog/digital-wallet-assurance)
[identitas digital](https://www.corbado.com/id/blog/digital-credentials-api), menjadi jauh lebih banyak
dibicarakan. EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide)
[Wallet](https://www.corbado.com/blog/digital-wallet-assurance) (EUDI [Wallet](https://www.corbado.com/blog/digital-wallet-assurance))
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](https://www.corbado.com/glossary/microcredentials) (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](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) 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](https://www.corbado.com/id/blog/digital-credentials-api) 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](https://www.corbado.com/glossary/step-up-authentication), dan migrasi
perangkat. Kita juga akan menyinggung bagaimana standar browser yang sedang berkembang
seperti [Digital Credentials API](https://www.corbado.com/blog/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:

| Fitur                                            | Passkey                                                                                | Kredensial Digital                                                                                                                                                                                                                            |
| :----------------------------------------------- | :------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tujuan Utama**                                 | Autentikasi (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 Inti**                               | Standar FIDO2                                                                          | W3C Verifiable Credentials, ISO mdocs (misalnya, 18013-5, 18013-7), OpenID4VC (OID4VP/OID4VCI)                                                                                                                                                |
| **Data yang Disampaikan**                        | Bukti kriptografis kepemilikan kunci (Assertion)                                       | Klaim/Atribut yang Ditandatangani (misalnya, Nama, Tanggal Lahir, Alamat, Kualifikasi, Usia di atas 18)                                                                                                                                       |
| **Interaksi Umum**                               | Login / Masuk / Autentikasi                                                            | Menyajikan 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](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)
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](https://www.w3.org/TR/webauthn-3/) ini
  mendefinisikan API [JavaScript](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) yang
  digunakan [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) untuk berinteraksi
  dengan [authenticator](https://www.corbado.com/glossary/authenticator) untuk mendaftarkan
  (navigator.credentials.create()) dan mengautentikasi (navigator.credentials.get())
  passkey. Ini bertindak sebagai jembatan antara
  [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql)
  [Relying Party](https://www.corbado.com/glossary/relying-party) dan browser atau sistem operasi pengguna.
  WebAuthn memperluas
  [Credential Management API](https://www.w3.org/TR/credential-management-1/) umum dari
  W3C.

- **[CTAP (Client to Authenticator Protocol)](https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html):**
  Didefinisikan oleh [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), [CTAP](https://www.corbado.com/id/glossary/ctap)
  menentukan bagaimana klien (browser atau OS) berkomunikasi dengan perangkat
  [authenticator](https://www.corbado.com/glossary/authenticator). Ini bisa berupa
  [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) yang terpasang di perangkat
  (menggunakan perangkat keras aman seperti TPM atau
  [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) atau
  [authenticator](https://www.corbado.com/glossary/authenticator) roaming seperti kunci keamanan USB atau bahkan
  ponsel yang bertindak sebagai authenticator untuk perangkat lain. CTAP2 adalah versi
  yang selaras dengan [FIDO2](https://www.corbado.com/glossary/fido2) dan passkey, mendukung berbagai
  transportasi seperti USB, NFC, dan Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/glossary/relying-party) (RP)
  terkadang perlu mengidentifikasi perangkat fisik spesifik yang digunakan selama
  [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) untuk penilaian risiko.
  Ide-ide awal, seperti ekstensi `devicePubKey` dan `supplementalPubKeys`, mencoba
  menyelesaikan ini tetapi kemudian ditinggalkan. Kelompok kerja sinyal kepercayaan
  [FIDO Alliance](https://www.corbado.com/glossary/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](https://www.corbado.com/faq/sca-psd2-importance) (SCA) internal.

![webauthentication layer](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/webauthentication_layer_5d44167576.png)

### 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](https://github.com/WICG/digital-credentials)
  yang bertujuan untuk memperluas API navigator.credentials.get() untuk memungkinkan
  [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) meminta
  [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) 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](https://www.corbado.com/glossary/oauth2), 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](https://www.corbado.com/glossary/verifiable-presentation) kembali ke Verifier.
- **OpenID for Verifiable Credential Issuance (OpenID4VCI):** Melengkapi
  [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), ini menstandardisasi bagaimana
  [Issuer](https://www.corbado.com/glossary/issuer) mengirimkan VC ke Wallet milik Holder, sekali lagi
  menggunakan mekanisme [OAuth 2.0](https://www.corbado.com/glossary/oauth2). 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](https://www.corbado.com/glossary/iso-18013-5) mendefinisikan struktur data
  [mDL](https://www.corbado.com/blog/mobile-drivers-license) inti dan presentasi offline (NFC, BLE), sementara
  [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) dan 23220 menentukan mekanisme presentasi online,
  termasuk API REST dan profil integrasi dengan [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)
  (Lampiran B dari 18013-7). Platform seperti [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)
  dan Apple Wallet memanfaatkan standar ISO ini.

![Layers digital credentials](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_new_94dff37b9e.png)

### 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-android) menyediakan Keystore yang didukung
  perangkat keras, sering diimplementasikan menggunakan prosesor aman khusus (StrongBox
  Keymaster), menawarkan perlindungan kuat untuk kunci kriptografis pada perangkat
  [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/secure-enclave), Keystore yang didukung perangkat keras
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/secure-enclave) Apple) untuk melindungi dengan kuat baik
kredensial autentikasi (passkey) maupun kredensial [atestasi](https://www.corbado.com/id/glossary/ctap) (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](https://www.corbado.com/id/blog/digital-credentials-api) 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](https://www.corbado.com/id/glossary/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**

| Skenario                         | Tujuan                                 | Peran Passkey                 | Peran VC                                                            | Toleransi Gesekan            | Pengikatan Perangkat? |
| :------------------------------- | :------------------------------------- | :---------------------------- | :------------------------------------------------------------------ | :--------------------------- | :-------------------- |
| **E-Commerce / Umum**            | Kecepatan & Keamanan Dasar             | ✅ Login Utama (2FA)          | tidak ada                                                           | 🟢 Rendah                    | ❌ Tidak              |
| **Jaminan Tinggi / MFA**         | Otentikasi Kuat & Pembuktian ID        | ✅ Login Utama (2FA)          | 🆔 KYC / Onboard / Pemulihan                                        | 🟡 Sedang                    | ❌ Tidak              |
| **Otentikasi Pembayaran**        | Konfirmasi 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 Eropa**      | Kepatuhan Peraturan                    | ✅ Faktor Inti SCA            | 🆔 KYC / Onboard / Pemulihan                                        | 🔴 Lebih Tinggi (Diwajibkan) | ✅ Ya                 |
| **Mandat Wallet EUDI Uni Eropa** | Kepatuhan & 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](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/assertion) identitas terverifikasi.
- **Kemungkinan Alur:**
- **Passkey sebagai 2FA/MFA Mandiri:** Passkey secara inheren memenuhi persyaratan
  [autentikasi dua faktor](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
  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](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik) 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](https://www.corbado.com/blog/passkeys-vs-2fa-security).
- **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](https://www.corbado.com/glossary/verifiable-credential) spesifik (misalnya, PID,
  kredensial ID nasional) dari wallet pengguna setelah
  [login passkey](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik).
- **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](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) 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](https://www.corbado.com/blog/passkeys-vs-2fa-security)/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](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang aman.

### 3.4 Skenario Pembayaran (Gesekan Rendah)

- **Tujuan:** Checkout atau inisiasi [pembayaran](https://www.corbado.com/passkeys-for-payment) yang efisien dan
  aman, meminimalkan gesekan pengguna.
- **Kemungkinan Alur:**
- **Autentikasi untuk Pembayaran:** Passkey ideal untuk mengautentikasi pengguna _ke_ akun
  [Penyedia Layanan Pembayaran](https://www.corbado.com/id/blog/passkey-penyedia-pembayaran-sdk-pihak-ketiga)
  (PSP) mereka (misalnya, [PayPal](https://www.corbado.com/blog/paypal-passkeys)) atau langsung di dalam alur
  checkout [merchant](https://www.corbado.com/glossary/merchant). Ini menggantikan kata sandi dan memberikan
  konfirmasi yang cepat dan aman untuk memulai [pembayaran](https://www.corbado.com/passkeys-for-payment).
- **Orientasi/KYC:** VC tetap penting selama fase _orientasi_ atau penyiapan akun dengan
  [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) atau
  [merchant](https://www.corbado.com/glossary/merchant), memberikan informasi identitas terverifikasi
  (pemeriksaan [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)/AML) yang diperlukan untuk
  mengaktifkan kemampuan [pembayaran](https://www.corbado.com/passkeys-for-payment) sejak awal.
- **Kekhawatiran Gesekan Transaksi:** Memperkenalkan langkah presentasi Verifiable
  Credential terpisah _selama_ alur otorisasi pembayaran inti (memerlukan interaksi dengan
  wallet [identitas digital](https://www.corbado.com/id/blog/digital-credentials-api)) 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](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) 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](https://www.corbado.com/passkeys-for-banking).
- **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](https://www.corbado.com/glossary/eidas) 2 (Pasal 5f) yang mewajibkan
  penerimaan EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/blog/webauthn-resident-key-discoverable-credentials-passkeys) 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](https://www.corbado.com/id/blog/psd2-passkeys) (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](https://www.corbado.com/blog/psd2-passkeys), AML, pendaftaran [telekomunikasi](https://www.corbado.com/passkeys-for-telecom))
  untuk memerlukan verifikasi identitas atau atribut spesifik, ia memulai langkah kedua.
  RP meminta presentasi (melalui [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)) dari Data
  Identifikasi Orang (PID) atau [Atestasi](https://www.corbado.com/id/glossary/ctap) 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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password). 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](https://www.corbado.com/faq/sca-psd2-importance)
(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](https://www.corbado.com/id/blog/psd2-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys).

[PayPal](https://www.corbado.com/blog/paypal-passkeys), misalnya, memungkinkan pengguna untuk menandai perangkat
sebagai "diingat" seperti yang dijelaskan di
[halaman bantuan](https://www.paypal.com/is/cshelp/article/what-are-the-payment-services-directives-strong-customer-authentication-and-remembered-device-help718)
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](https://www.corbado.com/id/blog/psd2-passkeys)."

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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/nist-passkeys)) menawarkan kenyamanan
paling besar dan peluang terbaik untuk adopsi, penting untuk aplikasi konsumen. Passkey
yang terikat perangkat (mungkin [AAL3](https://www.corbado.com/blog/nist-passkeys)) 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](https://www.corbado.com/passkeys-for-banking),
[asuransi](https://www.corbado.com/passkeys-for-insurance), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-use-google-pay)) 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](https://www.corbado.com/glossary/mdoc) Apple untuk interaksi browser versus
dukungan OpenID4VP yang lebih luas dari Android melalui Credential Manager-nya), bagaimana
wallet ini memfasilitasi [atestasi](https://www.corbado.com/id/glossary/ctap) 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](https://www.corbado.com/passkeys-for-payment).

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](https://www.corbado.com/glossary/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](https://www.corbado.com/id/blog/digital-credentials-api) 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](https://www.corbado.com/id/glossary/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](https://www.corbado.com/id/blog/digital-credentials-api) 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](https://www.corbado.com/blog/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](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) dan memberi pengguna lebih
banyak kontrol atas data mereka.