---
url: 'https://www.corbado.com/id/blog/biometrik-kesadaran-pembayar'
title: 'Biometrik & Kesadaran Pembayar dalam Penautan Dinamis'
description: 'Kesadaran pembayar biometrik di bawah penautan dinamis PSD2: bagaimana biometrik lokal + PKI dan passkeys memenuhi kepatuhan, dengan panduan EBA/RTS dan praktik terbaik.'
lang: 'id'
author: 'Vincent'
date: '2025-10-02T15:13:41.248Z'
lastModified: '2026-03-25T10:47:43.231Z'
keywords: 'biometrik kesadaran pembayar'
category: 'Passkeys Strategy'
---

# Biometrik & Kesadaran Pembayar dalam Penautan Dinamis

## Ringkasan Eksekutif: Biometrik & Kesadaran Pembayar dalam Penautan Dinamis

Pendekatan Corbado memadukan passkeys yang tahan [phishing](https://www.corbado.com/glossary/phishing) (SCA)
dengan tampilan yang dikontrol bank dan
[penautan dinamis](https://www.corbado.com/id/blog/penautan-dinamis-passkeys-spc) sisi server untuk memenuhi
[PSD2 RTS](https://www.corbado.com/faq/sca-rts-technical-standards) Pasal 5
(“apa‑yang‑Anda‑lihat‑adalah‑apa‑yang‑Anda‑tanda tangani”).

- **Implementasi inti (saat ini):** Kami menampilkan **jumlah dan penerima pembayaran**
  transaksi dalam UI yang dikontrol oleh Bison-Bank segera sebelum dan selama
  [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) passkey. Backend kami
  menghasilkan **tantangan satu kali** yang **terikat pada snapshot transaksi kanonis**
  (jumlah, penerima pembayaran, txnId). Respons hanya diterima jika cocok dengan snapshot
  tersebut; **setiap perubahan akan membatalkannya**.

- **Posisi regulator:** **Penautan dinamis tetap diwajibkan** untuk
  [pembayaran](https://www.corbado.com/passkeys-for-payment) jarak jauh bahkan dengan passkeys (PSD2 Pasal 97(2);
  RTS Pasal 5). RTS **tidak mewajibkan** “kode
  [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)”
  [penautan dinamis](https://www.corbado.com/id/blog/penautan-dinamis-passkeys-spc) dihitung di perangkat;
  pembuatan/validasi sisi server dapat diterima ketika **integritas tampilan**,
  **spesifisitas**, dan **pembatalan saat ada perubahan** ditegakkan (lihat juga EBA Q\&A
  2020_5366 tentang di mana kode dapat dihitung).

- **Keamanan & kemampuan audit:** Mengikat tanda tangan passkey yang **berbasis perangkat
  keras dan tahan phishing** ke data transaksi tertentu akan **mencegah perusakan dan
  penyampaian ulang**, serta menghasilkan **bukti persetujuan pembayar yang kuat dan tidak
  dapat disangkal**. Jika didukung, kami dapat secara opsional mengadopsi **Secure Payment
  Confirmation (SPC)** untuk menambahkan **bukti kriptografis dari detail yang
  ditampilkan** tanpa mengubah model backend.

> **Penjelasan:** Passkeys menghilangkan [phishing](https://www.corbado.com/glossary/phishing) lintas-asal (hanya
> berfungsi di situs/aplikasi tempat passkeys dibuat). **Penautan dinamis** memastikan
> bahwa **persis apa yang disetujui pembayar** (jumlah + penerima pembayaran) adalah apa
> yang dieksekusi oleh bank.

## 1. PSD2 SCA & penautan dinamis

- **SCA**: Dua elemen independen dari kategori yang berbeda
  (pengetahuan/kepemilikan/inherensi), dilindungi dari pengungkapan/replikasi dengan
  mitigasi yang sesuai (RTS Pasal 6–8). Independensi diperlukan (Pasal 9), termasuk
  pemisahan saat dieksekusi pada perangkat serbaguna (misalnya, perlindungan tingkat OS,
  perangkat keras aman).
- **Penautan dinamis (RTS Pasal 5)**:
    - (i) pembayar dibuat sadar akan jumlah dan penerima pembayaran selama
      [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)
    - (ii) kode autentikasi bersifat unik untuk jumlah/penerima pembayaran tersebut
    - (iii) setiap perubahan akan membatalkan kode tersebut
    - (iv) kerahasiaan/integritas jumlah, penerima pembayaran, dan kode dilindungi secara
      menyeluruh. Hal ini mewujudkan niat regulator
      “apa-yang-Anda-lihat-adalah-apa-yang-Anda-tanda-tangani”.
- **Implikasi**: Autentikasi pengguna yang kuat saja tidak cukup untuk
  [pembayaran](https://www.corbado.com/passkeys-for-payment). Persetujuan harus terikat pada data transaksi
  tertentu dengan bukti yang dapat diaudit tentang pengikatan dan tampilan kepada pembayar
  (RTS Pasal 5(1)(a–d)).

**Klarifikasi — phishing vs. otorisasi:** Passkeys terikat pada asal, sehingga domain
palsu tidak dapat menghasilkan tanda tangan yang valid. Namun, [PSD2](https://www.corbado.com/blog/psd2-passkeys)
masih mewajibkan **penautan dinamis** untuk [pembayaran](https://www.corbado.com/passkeys-for-payment) jarak jauh
untuk mengikat _otorisasi_ ke **jumlah dan penerima pembayaran yang tepat** untuk
**membatalkan setiap perubahan** dan untuk **melindungi integritas** dari apa yang
ditampilkan kepada pembayar (RTS Pasal 5(1)(a–d)).
[Penautan dinamis](https://www.corbado.com/id/blog/penautan-dinamis-passkeys-spc) mengatasi integritas otorisasi
(termasuk substitusi MITM/MITB/TPP), bukan hanya [phishing](https://www.corbado.com/glossary/phishing).

### 1.1 Latar belakang teori — teks hukum dan panduan

> [PSD2](https://www.corbado.com/blog/psd2-passkeys) Pasal 97(2): “Sehubungan dengan inisiasi transaksi
> [pembayaran](https://www.corbado.com/passkeys-for-payment) elektronik, Negara-negara Anggota harus memastikan
> bahwa pembayar memiliki akses ke prosedur
> [autentikasi pelanggan yang kuat](https://www.corbado.com/blog/psd2-sca-requirements) yang mencakup
> elemen-elemen yang secara dinamis menautkan transaksi ke jumlah tertentu dan penerima
> pembayaran tertentu.”
> [PSD2 Pasal 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> RTS Pasal 5: “Penyedia layanan [pembayaran](https://www.corbado.com/passkeys-for-payment) harus memastikan
> bahwa kode autentikasi yang dihasilkan spesifik untuk jumlah transaksi
> [pembayaran](https://www.corbado.com/passkeys-for-payment) dan penerima pembayaran yang disetujui oleh pembayar
> saat memulai transaksi; pembayar dibuat sadar akan jumlah transaksi pembayaran dan
> penerima pembayaran yang diberikan autentikasi; kode autentikasi yang diterima oleh
> [penyedia layanan pembayaran](https://www.corbado.com/id/blog/passkey-penyedia-pembayaran-sdk-pihak-ketiga)
> sesuai dengan jumlah asli transaksi pembayaran dan identitas penerima pembayaran yang
> disetujui oleh pembayar saat memulai transaksi; setiap perubahan pada jumlah atau
> penerima pembayaran akan mengakibatkan pembatalan kode autentikasi; kerahasiaan,
> keaslian, dan integritas jumlah serta penerima pembayaran dilindungi.”
> [RTS Pasal 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

Opini EBA 2019 (EBA‑Op‑2019‑06) memperkuat bahwa penautan dinamis mengikat autentikasi ke
jumlah dan penerima pembayaran, memerlukan independensi faktor, dan menerima kunci
kriptografis yang terikat perangkat sebagai kepemilikan di mana ada pengikatan perangkat
yang unik. Opini ini juga menekankan integritas dari apa yang ditampilkan kepada pembayar
selama autentikasi. [Opini EBA 2019](https://www.eba.europa.eu)

### 1.2 Sejarah penautan dinamis

![sejarah penautan dinamis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

Sebelum [PSD2](https://www.corbado.com/blog/psd2-passkeys), banyak bank mengandalkan OTP SMS atau daftar TAN
tercetak yang sering kali tidak menampilkan jumlah atau penerima pembayaran di samping
langkah persetujuan. Celah tersebut memudahkan penipu untuk mengelabui pelanggan agar
mengotorisasi transfer yang tidak diinginkan setelah kredensial dicuri. Penautan dinamis
diperkenalkan untuk menutup celah itu dengan memastikan pembayar mengetahui jumlah dan
penerima pembayaran yang tepat pada saat autentikasi dan dengan membuat kode autentikasi
spesifik untuk detail tersebut sehingga setiap perubahan akan membatalkannya (RTS Pasal
5(1)(a–d)). Di mana SMS menjadi bagian dari alur, [issuer](https://www.corbado.com/glossary/issuer) juga harus
memastikan kerahasiaan, keaslian, dan integritas jumlah/penerima pembayaran dan kode di
semua fase autentikasi (Q\&A 2018_4414; RTS Pasal 5(2)). Persetujuan dalam aplikasi saat
ini (misalnya, “Apakah Anda ingin mengotorisasi 100 USD ke John Smith melalui
[Face ID](https://www.corbado.com/faq/is-face-id-passkey)?”) mengimplementasikan prinsip “apa yang Anda lihat
adalah apa yang Anda tanda tangani” ini dengan cara yang ramah pelanggan.

### 1.3 Penautan dinamis saat ini: push aplikasi dan biometrik lokal

![notifikasi push penautan dinamis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

Saat ini, di perangkat seluler, dua pola mendominasi. Pertama, notifikasi push dapat
mengarahkan pelanggan (deep-link) ke dalam aplikasi untuk meninjau detail transaksi dan
menyetujuinya. Pengawas telah mengklarifikasi bahwa push dapat berfungsi sebagai bukti
elemen kepemilikan jika kontrol Pasal 7 diterapkan untuk mengurangi penggunaan yang tidak
sah dan mencegah replikasi, dan keseluruhan perjalanan mematuhi RTS; meskipun demikian,
risiko rekayasa sosial tetap ada dan harus diatasi dalam UX (Q\&A 2019_4984; RTS Pasal 7).

![biometrik lokal penautan dinamis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

Kedua, persetujuan menggunakan biometrik asli perangkat (dengan fallback PIN) melakukan
verifikasi pengguna secara lokal untuk membuka operasi kunci privat. Kunci privat berada
di lingkungan perangkat keras yang aman (Secure Enclave/TEE/TPM) dan menandatangani sebuah
tantangan. Ini sesuai dengan [SCA](https://www.corbado.com/id/blog/psd2-passkeys): inherensi (biometrik) ditambah
kepemilikan yang dibuktikan dengan pengikatan perangkat dan kunci kriptografis yang
terikat perangkat (EBA‑Op‑2019‑06, para. 25, 35–37). Untuk pembayaran jarak jauh, kode
harus ditautkan secara dinamis ke jumlah dan penerima pembayaran dan detail tersebut harus
ditampilkan kepada pembayar sebelum verifikasi pengguna (RTS Pasal 5). Jika kedua faktor
ada di satu perangkat, terapkan lingkungan eksekusi aman yang terpisah dan pemeriksaan
integritas sehingga kompromi pada satu faktor tidak membahayakan yang lain (RTS Pasal
9(2)–(3)).

### 1.4 Bagaimana biometrik lokal dengan PKI mengimplementasikan penautan dinamis

Di balik layar, [biometrik lokal](https://www.corbado.com/id/blog/passkey-vs-biometrik-lokal) tidak
“mengautentikasi ke bank” secara langsung. Sebaliknya, biometrik (atau fallback PIN)
melakukan verifikasi pengguna di perangkat dan mengontrol akses ke kunci privat yang tidak
dapat diekspor yang disimpan di modul
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) berbasis perangkat keras. Ketika
pembayar menyetujui, perangkat menggunakan kunci privat tersebut untuk menghasilkan tanda
tangan digital atas tantangan yang disediakan bank. Jika bank menurunkan atau mengaitkan
tantangan itu dengan snapshot kanonis dari transaksi (jumlah, penerima pembayaran,
pengidentifikasi), maka tanda tangan yang dihasilkan berfungsi sebagai kode autentikasi
yang spesifik untuk detail tersebut. Setiap perubahan akan membatalkan kode karena
snapshot yang tersimpan tidak lagi cocok, atau, dalam desain yang disempurnakan, karena
derivasi tantangan berubah. Bagian kesadaran pembayar tetap menjadi persyaratan UX:
tampilkan jumlah dan penerima pembayaran dalam tampilan yang dikontrol bank segera sebelum
verifikasi pengguna. Bersama-sama, ini memenuhi persyaratan RTS Pasal 5 tentang kesadaran,
spesifisitas/keunikan, dan pembatalan saat ada perubahan, sementara kontrol Pasal 7 dan
bukti pengikatan perangkat membuktikan elemen kepemilikan.

![biometrik penautan dinamis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Mengapa passkeys sesuai dengan SCA (terikat perangkat dan tersinkronisasi)

- **Kepemilikan (kunci terikat-perangkat & tersinkronisasi)**: Kunci privat passkey
  disimpan di perangkat keras yang aman
  (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM). Passkeys yang terikat-perangkat
  tidak dapat diekspor, sejalan dengan ekspektasi EBA untuk pengikatan perangkat yang unik
  (EBA‑Op‑2019‑06, para. 25, 35–37). Passkeys yang tersinkronisasi juga dapat membuktikan
  kepemilikan pada setiap autentikasi, asalkan pengikatan perangkat dan kontrol
  anti-replikasi efektif; regulator telah menekankan perlunya tautan yang andal antara
  elemen dan perangkat (EBA‑Op‑2019‑06; RTS Pasal 7).
- **Inherensi/pengetahuan (Verifikasi Pengguna)**: Verifikasi Pengguna melalui biometrik
  (inherensi) atau PIN perangkat (pengetahuan) mengaktifkan kunci secara lokal.
  Dikombinasikan dengan kepemilikan, ini adalah [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security)
  sejati dengan independensi faktor. Pelanggaran pada satu faktor tidak membahayakan yang
  lain.

## 3. Apakah Passkeys memenuhi persyaratan penautan dinamis?

Penautan dinamis adalah tentang **mengikat autentikasi ke transaksi**. Pertanyaan bagi
bank adalah: jika kami membiarkan pengguna menyetujui pembayaran melalui passkey (bukan,
katakanlah, OTP atau perangkat penandatangan), dapatkah kami menjamin bahwa persetujuan
ini spesifik untuk jumlah dan penerima pembayaran yang dimaksud, dan tidak dapat digunakan
kembali atau dimanipulasi?

Ada 2 opsi untuk mengimplementasikan penautan dinamis dengan passkeys:

- **Penautan sisi server (standar):** Hasilkan tantangan WebAuthn satu kali yang dikaitkan
  oleh backend dengan jumlah dan penerima pembayaran yang tepat. Pengguna melihat “€X ke
  Y” dalam tampilan yang dikontrol bank dan menyetujui dengan passkey. Respons hanya
  diterima untuk transaksi tersebut. Setiap perubahan akan membatalkannya.
- **Inklusi kriptografis (ditingkatkan):** Sematkan hash dari jumlah/penerima pembayaran
  ke dalam tantangan sehingga tanda tangan berkomitmen pada data transaksi. Ini tidak
  diwajibkan oleh RTS tetapi menambah jaminan bahwa bahkan pertukaran backend akan gagal
  verifikasi.

**Catatan kepatuhan eksplisit:** RTS **tidak** mewajibkan “kode autentikasi” penautan
dinamis dihitung di perangkat pembayar. Sebuah
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) dapat menghasilkan dan
memvalidasinya di **server** selama **jumlah/penerima pembayaran** dilindungi dan **setiap
perubahan** membatalkan kode (lihat EBA Q\&A 2020_5366 tentang lokasi/waktu kode). Itulah
pendekatan **penautan dinamis sisi server (standar)** kami.

Keduanya menghasilkan “kode autentikasi” yang unik dan tidak dapat digunakan kembali yang
spesifik untuk transaksi tersebut. Peringatan utamanya adalah **kesadaran pembayar**:
WebAuthn sendiri tidak membuktikan apa yang ditampilkan. Integritas tampilan harus berasal
dari UI yang dikontrol bank.

### 3.1 Pertimbangan Kesadaran Pembayar

Pasal 5 RTS mengharuskan pembayar untuk melihat jumlah dan penerima pembayaran selama
autentikasi. WebAuthn tidak membuktikan apa yang ditampilkan. Secara teori, jika aplikasi
atau OS disusupi, pengguna dapat disesatkan sementara autentikator tetap menandatangani.
Kita akan menganalisis di bawah ini secara detail bagaimana risiko ini terjadi dalam
kenyataan dan mengapa ini bukan risiko
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) nyata dan lebih merupakan masalah
interpretasi regulasi.

**Kontrol integritas tampilan yang kami terapkan:**

- Tampilan yang dikontrol bank merender **jumlah + penerima pembayaran**: kami
  **memblokir** pemanggilan passkey jika tampilan terhalang atau tidak fokus
- **Deteksi overlay/perusakan** di aplikasi/web: tidak ada prompt passkey dari iframes
  tersembunyi
- **Pembatasan integritas/atestasi perangkat**: tolak atau tingkatkan
  [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) pada sinyal perangkat yang
  di-root/jailbreak/disusupi
- **Persetujuan atomik** terhadap **snapshot** jumlah/penerima pembayaran yang dipegang
  server: tantangan baru diperlukan pada setiap perubahan parameter

**Tentang inklusi kriptografis:** Ekstensi “tampilan transaksi” WebAuthn (SPC) **tidak
didukung secara luas** saat ini. Garis dasar portabel kami adalah **pengikatan sisi
server**, diperkuat dengan menurunkan tantangan dari snapshot transaksi (misalnya,
H(jumlah ‖ penerima pembayaran ‖ txnId ‖ nonce)) sehingga tanda tangan **berkomitmen**
pada nilai-nilai tersebut.

### 3.2 Kesetaraan regulasi: biometrik lokal dengan PKI dan passkeys

Kedua pola menggunakan
[kriptografi kunci publik](https://www.corbado.com/id/blog/webauthn-pubkeycredparams-credentialpublickey) dengan
kunci perangkat yang tidak dapat diekspor, dan keduanya mengandalkan verifikasi pengguna
lokal untuk membuka operasi penandatanganan. Dalam keduanya, bank memastikan kesadaran
pembayar dengan menunjukkan jumlah dan penerima pembayaran dalam tampilan yang dikontrol
bank segera sebelum verifikasi pengguna, dan memastikan spesifisitas dengan mengikat kode
autentikasi ke detail tersebut — membatalkannya pada setiap perubahan (RTS Pasal
5(1)(a–d)). RTS bersifat netral teknologi dan tidak mengharuskan jumlah/penerima
pembayaran dirender di dalam modal biometrik OS; ia memerlukan tampilan kepada pembayar
dan pengikatan kode (RTS Pasal 5). Ketika kedua elemen [SCA](https://www.corbado.com/id/blog/psd2-passkeys)
dieksekusi pada satu perangkat, persyaratan integritas dan pemisahan Pasal 9 berlaku sama
(RTS Pasal 9(2)–(3)). Terakhir, lokasi komputasi penautan dinamis bersifat fleksibel:
dapat dilakukan di sisi server jika integritas dipertahankan dan setiap perubahan
membatalkan kode (Q\&A 2020_5366). Ini adalah kondisi yang sama di mana regulator sudah
menerima [biometrik lokal](https://www.corbado.com/id/blog/passkey-vs-biometrik-lokal) dengan PKI — oleh karena
itu, passkeys, yang diimplementasikan dengan kesadaran pembayar dan kontrol pengikatan
yang sama, harus diterima atas dasar yang setara.

### 3.3 Passkeys dan tujuan penautan dinamis

Jadi, apakah passkeys biasa menurut standar WebAuthn _memenuhi tujuan_ penautan dinamis?
**Sebagian:**

- **Serangan MITM/jaringan:** Ya. Pengikatan asal dan tanda tangan per-tantangan mencegah
  perusakan dan pemutaran ulang.
- **Integritas transaksi:** Ya. Asosiasi server atau hashing-tantangan memastikan hanya
  jumlah/penerima pembayaran asli yang akan terverifikasi.
- **Persetujuan pembayar:** Lebih sulit. Passkeys tidak memiliki tampilan tingkat
  autentikator. Penipuan UI pada perangkat yang disusupi bisa saja terjadi. Harus ada
  sesuatu yang dibangun di atasnya untuk menjamin persetujuan pembayar.

**Mengapa penautan dinamis masih diperlukan dengan passkeys**

- **Hukum:** PSD2 Pasal 97(2) dan RTS Pasal 5 mengamanatkan penautan dinamis untuk **semua
  inisiasi pembayaran jarak jauh**. Tidak ada pengecualian untuk metode tahan-phishing.
- **Keamanan:** Passkeys menghilangkan **phishing lintas-asal**, tetapi tidak dengan
  sendirinya **membuktikan apa yang ditampilkan** kepada pembayar. Penautan dinamis +
  kontrol integritas tampilan memastikan bahwa **jumlah/penerima pembayaran spesifik**
  yang dilihat pengguna adalah apa yang dieksekusi bank, dan bahwa **setiap perubahan
  membatalkan** persetujuan.

**Singkatnya, passkeys dapat memenuhi penautan dinamis** ketika terikat secara ketat pada
data transaksi dan dipasangkan dengan mekanisme tampilan yang dapat dipercaya. Tantangan
yang tersisa adalah membuktikan apa yang sebenarnya dilihat oleh pengguna.

## 4. Bagaimana Corbado mengimplementasikan penautan dinamis dengan passkeys

Corbado menawarkan solusi yang sesuai dengan penautan dinamis yang secara eksplisit
membahas pertimbangan persetujuan pembayar di atas.

### 4.1 Solusi menyeluruh: alur, teknologi, UX, dan kepatuhan

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

Alur proses:

- **Tampilan yang dikontrol bank** menunjukkan kepada pembayar jumlah dan penerima
  pembayaran yang tepat. Tidak ada prompt passkey yang ditampilkan kecuali tampilan ini
  terlihat.
- **Autentikasi:** klien memanggil WebAuthn dengan tantangan satu kali yang terikat untuk
  transaksi yang dikanonisasi. Autentikator melakukan verifikasi pengguna (biometrik atau
  PIN perangkat) dan menandatangani tantangan dan asal.
- **Verifikasi server:** backend memverifikasi hash ID RP dan asal, mencocokkan tantangan
  dengan transaksi yang disimpan, memeriksa UV/flag, memberlakukan penggunaan satu kali
  dan kedaluwarsa, dan membandingkan snapshot jumlah/penerima pembayaran yang disimpan.
- **Persetujuan dan audit:** hanya setelah itu transaksi disetujui secara atomik. Setiap
  ketidakcocokan/perubahan ditolak dan memerlukan autentikasi baru. Catatan audit yang
  tidak dapat diubah disimpan (ID kredensial, authenticatorData,
  [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), tanda tangan, tantangan, dan jumlah/penerima
  pembayaran yang dikanonisasi), secara opsional di-hash-chain untuk bukti perusakan.
- **Gerbang integritas perangkat:** Evaluasi integritas perangkat dan sinyal
  [atestasi](https://www.corbado.com/id/glossary/ctap): tolak atau tingkatkan keamanan jika perangkat
  di-root/jailbreak/disusupi.
- **Kanonisasi penerima pembayaran:** Tampilkan label yang ramah (misalnya, “ACME GmbH”),
  tetapi ikat dan verifikasi terhadap **pengidentifikasi penerima pembayaran kanonis**
  (misalnya, IBAN/BIC atau skema unik lainnya).

Detail teknis:

- **Backend:** buat objek transaksi dengan data yang dikanonisasi (misalnya, mata
  uang/desimal yang dinormalisasi; IBAN/penerima manfaat yang dikanonisasi). Hasilkan
  tantangan berumur pendek yang berkomitmen pada nilai-nilai ini (misalnya,
  H(jumlah||penerima pembayaran||txnId||nonce)); simpan dalam status tertunda; hanya
  ekspos ID buram ke klien.
- **Klien/autentikator:** render detail pembayar dalam tampilan yang dikontrol bank;
  panggil WebAuthn (ID RP = domain Bison) hanya ketika terlihat; memerlukan verifikasi
  pengguna; autentikator menandatangani tantangan + asal per
  [WebAuthn](https://www.w3.org/TR/webauthn-3/).
- **Verifikasi/finalisasi:** validasi tanda tangan, hash ID RP, asal/tipe, flag UV;
  anti-replay/kedaluwarsa; bandingkan snapshot jumlah/penerima pembayaran yang tidak dapat
  diubah; setujui secara atomik; simpan catatan audit.
- **Turunkan tantangan dari snapshot:**:
  `challenge = H(jumlah ‖ penerimaPembayaranKanonis ‖ txnId ‖ nonce)`

Kebijakan UX:

- Penekanan yang jelas pada jumlah/penerima pembayaran; kontrol konfirmasi/batal yang
  dapat diakses; batas waktu singkat; percobaan ulang yang baik selalu menggunakan
  tantangan baru; tanda terima segera (misalnya, “Anda menyetujui €X ke Y”). Blokir prompt
  passkey jika tampilan terhalang dan peringatkan jika parameter berubah sebelum
  penandatanganan.
- Deteksi overlay/konten yang terhalang: jangan pernah menunjukkan prompt passkey jika
  **tampilan transaksi tidak terlihat**. Tolak jika parameter berubah di tengah alur dan
  mulai ulang dengan **tantangan baru**.

**Catatan kepatuhan:** Desain menyeluruh ini memenuhi RTS Pasal 5: **kesadaran pembayar**
(tampilan yang dikontrol bank), **spesifisitas** dan **keunikan** (kode satu kali yang
terikat pada jumlah/penerima pembayaran), **pembatalan saat ada perubahan** (pemeriksaan
server yang ketat), dan **kerahasiaan/integritas** jumlah/penerima pembayaran dan kode di
semua fase (RTS Pasal 5(1)(a–d), 5(2); lihat juga Q\&A 2018_4414 untuk integritas SMS).
Independensi faktor (Pasal 7–9) dipertahankan melalui kepemilikan yang terikat perangkat
dan UV lokal (biometrik atau PIN) pada perangkat serbaguna dengan perlindungan yang sesuai
(RTS Pasal 9(2)–(3)).

_Catatan:_

- untuk alur web, Corbado secara opsional akan mengadopsi
  \[[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)]\([https://www.w3.org/TR/](https://www.w3.org/TR/)[payment](https://www.corbado.com/passkeys-for-payment)-request-secure-[payment](https://www.corbado.com/passkeys-for-payment)-confirmation/)
  jika/ketika Apple memberikan dukungan luas, menambahkan tampilan yang dimediasi oleh
  browser tepercaya yang secara kriptografis membuktikan jumlah dan penerima pembayaran.

## 5. Risiko sisa & kontrol kompensasi

**Kekhawatiran: Serangan phishing** **Respons:** Passkeys tahan phishing secara desain:
mereka terikat pada asal yang sah dan tidak melibatkan rahasia bersama, sehingga
kredensial tidak dapat dipanen di situs palsu, tidak seperti OTP. Penyerang yang mem-proxy
lalu lintas ke domain yang mirip tidak dapat memperoleh tanda tangan yang valid untuk asal
bank. Penautan dinamis berkontribusi lebih sedikit dalam vektor ini, tetapi tetap wajib
untuk memastikan setiap persetujuan unik untuk jumlah dan penerima pembayaran yang
dimaksud. Tindakan pelengkap (edukasi phishing, pemisahan yang jelas antara persetujuan
login vs pembayaran, penilaian anomali/risiko untuk konteks pembayaran yang tidak biasa)
semakin mengurangi paparan.

**Kekhawatiran: Rekayasa sosial / Penipuan Authorized Push Payment (APP)** **Respons:**
Tidak ada autentikator yang dapat sepenuhnya mencegah pengguna mengotorisasi pembayaran
dengan dalih palsu (misalnya, penipuan “rekening aman”). Penautan dinamis memastikan
pengguna secara eksplisit melihat penerima pembayaran dan jumlah serta memberikan bukti
persetujuan yang kuat, tetapi tidak dapat mengesampingkan pembayar yang yakin.
Kompensasinya mencakup peringatan kontekstual (penerima pembayaran baru, transfer besar
pertama), periode penenangan atau eksekusi yang ditunda untuk penerima pembayaran berisiko
tinggi, verifikasi penerima pembayaran yang lebih kuat, dan pemeriksaan peningkatan
(konfirmasi tambahan) pada sinyal risiko. Notifikasi pasca-pembayaran dan saluran sengketa
yang cepat membantu mendeteksi dan menahan kerugian. Kami menambahkan **peringatan
kontekstual** waktu nyata (misalnya, penerima pembayaran baru, transfer besar pertama),
**periode penenangan** untuk penerima pembayaran berisiko tinggi, **verifikasi penerima
pembayaran** yang lebih kuat, dan **notifikasi pasca-pembayaran** (“Anda menyetujui €X ke
Y”) untuk mempercepat deteksi dan respons.

**Kekhawatiran: Malware atau kompromi perangkat** **Respons:** Kunci privat **tidak dapat
diekspor** dan memerlukan **verifikasi pengguna lokal** untuk setiap tanda tangan,
sehingga [malware](https://www.corbado.com/glossary/malware) tidak bisa begitu saja mengekstrak kredensial.
Risiko realistis adalah **penipuan UI** pada OS yang sepenuhnya disusupi. Mitigasi dengan
UI yang aman/terverifikasi (misalnya, konfirmasi yang dilindungi), pemeriksaan integritas
perangkat/[atestasi](https://www.corbado.com/id/glossary/ctap) dan pemblokiran perangkat berisiko tinggi, dan
konfirmasi tepercaya seperti [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) atau ekstensi
konfirmasi bila tersedia. Jika indikator kompromi muncul (deteksi overlay,
root/jailbreak), gunakan verifikasi ulang di luar jalur atau tolak eksekusi. Tidak ada
metode konsumen yang sempurna pada perangkat yang sepenuhnya dikuasai, tetapi kontrol ini
mempersempit jendela secara dramatis.

**Kekhawatiran: Man‑in‑the‑browser / pembajakan sesi** **Respons:** Ekstensi berbahaya
atau skrip yang disuntikkan dapat memulai tindakan pada asal yang sah. Passkeys yang
terikat asal menghentikan phishing lintas situs. **Penautan dinamis** memastikan editan di
balik layar pada jumlah/penerima pembayaran **gagal**. Kami memperkuat saluran melalui
kontrol CSP/anti-perusakan dan dengan memerlukan **tantangan baru satu kali** untuk setiap
konfirmasi.

**Kekhawatiran: Ancaman orang dalam atau perusakan sisi server** **Respons:** Respons
autentikasi terikat secara unik pada jumlah/penerima pembayaran asli, sehingga setiap
substitusi sisi server gagal validasi. Pertahankan catatan tautan yang bukti perusakannya
terlihat dan tidak dapat diubah (tantangan, kredensial, tanda tangan, dan jumlah/penerima
pembayaran yang dikanonisasi) untuk audit/anti-penyangkalan. Terapkan pemisahan tugas dan
kontrol empat mata pada jalur pemrosesan pembayaran kritis untuk mengurangi risiko orang
dalam.

**Kekhawatiran: Perangkat dicuri / pencurian kredensial** **Respons:** Kepemilikan
perangkat saja tidak cukup: verifikasi pengguna (biometrik/PIN) diperlukan untuk setiap
tanda tangan, dengan batas laju dan penguncian tingkat OS. Setiap pembayaran memerlukan
tantangan baru yang spesifik transaksi; token sesi generik tidak dapat mengotorisasi
pembayaran sewenang-wenang. Tambahan seperti pencabutan perangkat jarak jauh, peningkatan
keamanan pada penggunaan perangkat baru, pemeriksaan geovelocity, dan notifikasi (“Anda
mengotorisasi €X ke Y”) semakin membatasi penyalahgunaan.

Secara keseluruhan: passkeys secara material mengurangi risiko phishing dan replay;
penautan dinamis tetap penting untuk menjamin integritas transaksi, mengikat persetujuan
ke jumlah/penerima pembayaran, dan memberikan bukti kuat persetujuan yang terinformasi di
seluruh skenario ancaman yang tersisa.

## 6. FAQ Kepatuhan

**Pertanyaan 1:** Bagaimana kita dapat membuktikan bahwa pengguna benar-benar melihat dan
menyetujui jumlah serta penerima pembayaran saat menggunakan passkey? **Respons:** Kami
memberlakukan **tampilan pembayar** dalam tampilan yang dikontrol bank dan mengikat
persetujuan ke **snapshot sisi server** dari jumlah/penerima pembayaran. Asersi passkey
(authenticatorData, [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), tanda tangan) diterima
**hanya** untuk tantangan yang diturunkan dari snapshot itu; **setiap perubahan**
memerlukan tantangan baru. **Audit tahan-rusak** kami menautkan asersi ke “€X ke
ID-Penerima Y” dan mencatat bahwa sistem kami tidak akan melanjutkan jika detailnya
berbeda. Jika didukung, **SPC** menambahkan **bukti kriptografis** bahwa pengguna
mengonfirmasi detail yang ditampilkan.

**Pertanyaan 1:** Bagaimana kita dapat membuktikan bahwa pengguna benar-benar melihat dan
menyetujui jumlah serta penerima pembayaran saat menggunakan passkey? **Respons:** Ini
pada dasarnya adalah pertanyaan **non-repudiation** (anti-penyangkalan). Di bawah PSD2,
penautan dinamis dimaksudkan untuk memastikan pengguna sadar akan apa yang mereka setujui.
Dengan passkey, bukti yang kami simpan adalah tanda tangan kriptografis (kode autentikasi)
dan data terkait (jumlah/penerima pembayaran mana yang terikat di server kami).
Berdasarkan kebijakan, kami menampilkan detail transaksi kepada pengguna di aplikasi atau
halaman web sebelum mereka melakukan autentikasi. Kami mencatat layar/tampilan tersebut
dan [autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) yang berhasil
berikutnya untuk transaksi spesifik tersebut. Jika terjadi sengketa, kami dapat
menunjukkan bahwa perangkat pengguna menghasilkan tanda tangan yang valid untuk tantangan
yang dikaitkan dengan (misalnya) “€100 ke ACME Corp.” dan bahwa sistem kami tidak akan
melanjutkan jika ada detail yang berbeda. Kepatuhan kami bergantung pada logging yang
aman: kami memastikan sistem kami tahan-rusak dalam menautkan respons passkey ke data
transaksi.

**Pertanyaan 2:** Bagaimana jika perangkat atau OS disusupi? Dapatkah
[malware](https://www.corbado.com/glossary/malware) memanipulasi transaksi atau proses passkey? **Respons:**
Kompromi perangkat adalah ancaman kritis dalam skenario [perbankan](https://www.corbado.com/passkeys-for-banking)
digital apa pun. Jika sistem operasi berbahaya, ia dapat mencoba menyesatkan pengguna atau
membajak proses. Namun, bahkan dalam kasus terburuk ini, **passkeys mempertahankan
beberapa perlindungan utama**. Kunci privat tidak dapat diekstraksi oleh
[malware](https://www.corbado.com/glossary/malware). Malware juga tidak dapat meniru pengguna ke bank, karena
tidak dapat menghasilkan tanda tangan
[passkey tanpa biometrik](https://www.corbado.com/id/faq/passkey-tanpa-biometrik)/PIN pengguna. Yang paling bisa
dilakukannya adalah mendorong pengguna untuk mengautentikasi sesuatu dengan dalih palsu.
Penautan dinamis membantu di sini dengan memerlukan pemeriksaan integritas: malware tidak
dapat secara diam-diam mengubah detail transaksi setelahnya – jika melakukannya, tanda
tangan tidak akan terverifikasi. Titik terlemahnya adalah **tampilan/UI**: Trojan yang
canggih mungkin mengubah apa yang dilihat pengguna (misalnya, menampilkan “ACME Corp”
sementara transaksi yang mendasarinya sebenarnya ditujukan ke penerima pembayaran lain).
Ini tidak sepele, terutama jika aplikasi bank menggunakan kerangka kerja UI yang aman,
tetapi bisa dibayangkan. Meskipun begitu, jika kami mendeteksi tanda-tanda kompromi
perangkat (perilaku tidak biasa, tanda tangan malware yang diketahui, dll.), kami akan
kembali ke verifikasi di luar jalur atau menolak transaksi. **Singkatnya:** Tidak ada
solusi yang 100% jika perangkat pengguna sepenuhnya dikuasai oleh penyerang. Passkeys +
penautan dinamis secara dramatis mengurangi permukaan serangan (penyerang tidak bisa
begitu saja mem-proxy kredensial atau mengubah data jaringan; mereka harus melakukan
penipuan pada pengguna secara waktu nyata). Jika OS disusupi, penautan dinamis setidaknya
memastikan setiap ketidakcocokan antara apa yang seharusnya dan apa yang disetujui akan
terdeteksi oleh backend kami.

**Pertanyaan 3:** Jika biometrik digunakan untuk membuka passkey, apakah itu dianggap satu
faktor atau dua? Apakah kita mematuhi aturan 2 faktor? **Respons:** Biometrik saja
**tidak** cukup untuk [SCA](https://www.corbado.com/id/blog/psd2-passkeys) – itu hanya satu faktor inherensi.
Namun, dalam implementasi passkey, biometrik _tidak sendirian_: kepemilikan perangkat
adalah faktor lainnya. Biometrik pengguna membuka kunci privat _yang tersimpan di
perangkat_. Kepemilikan dan inherensi adalah dua kategori yang berbeda. Ini analog dengan
bagaimana banyak aplikasi [perbankan](https://www.corbado.com/passkeys-for-banking) sudah memenuhi SCA: Anda
memiliki telepon (kepemilikan) _dan_ Anda menggunakan sidik jari atau wajah Anda untuk
membuka aplikasi (inherensi). EBA secara eksplisit telah mengakui kombinasi
pengikatan-perangkat plus biometrik sebagai SCA yang patuh. Skenario passkey adalah
kombinasi yang persis seperti itu. Jika pengguna memilih untuk menggunakan PIN alih-alih
biometrik untuk membuka passkey, maka itu adalah kepemilikan + pengetahuan, juga patuh.
Kami memberlakukan verifikasi pengguna pada semua operasi passkey (artinya pengguna harus
memberikan biometrik/PIN setiap kali), jadi tidak ada situasi di mana hanya memiliki
perangkat sudah cukup. Dengan demikian, setiap otorisasi pembayaran melalui passkey adalah
peristiwa _dua faktor_ di bawah definisi PSD2.

**Pertanyaan 4:** Bisakah penyerang menggunakan kembali
[autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) atau entah bagaimana
melewati penautan dinamis dengan memanipulasi data saat transit? **Respons:** Tidak. Di
sinilah passkeys dan penautan dinamis bekerja sama dengan kuat. Setiap autentikasi
WebAuthn menghasilkan **tanda tangan unik** yang terikat pada tantangan (yang kami
hasilkan per transaksi) dan dibatasi untuk domain kami. Penyerang tidak dapat memutar
ulang tanda tangan itu untuk transaksi yang berbeda. Tanda tangan itu sendiri
menggabungkan nonce tantangan dan hanya valid untuk apa yang awalnya dikeluarkan. Jika
penyerang mencegat komunikasi jaringan, mereka tidak dapat mengubah jumlah atau penerima
pembayaran tanpa membatalkan tanda tangan (karena tantangan atau konteks transaksi tidak
akan lagi cocok). Ini secara efektif adalah perlindungan MITM yang kita diskusikan. Juga,
tanda tangan passkey menyertakan data asal – mereka tidak akan terverifikasi jika tidak
dikirim ke asal situs web/aplikasi kami yang tepat, sehingga phishing atau pengalihan
tidak akan berfungsi. Singkatnya, setiap upaya manipulasi membatalkan kode autentikasi,
sesuai aturan penautan dinamis. Ini sebenarnya lebih aman daripada beberapa alur berbasis
OTP saat ini, di mana pengguna terkadang menyetujui kode generik dan ada risiko permintaan
telah dirusak. Dengan passkeys, kami secara kriptografis mengikat autentikasi pengguna ke
sesi/transaksi tertentu.

**Pertanyaan 5:** Apakah ada opini regulator yang diketahui tentang WebAuthn/passkeys
untuk SCA? Apakah kita yakin regulator akan menerima passkeys sebagai patuh? **Respons:**
Hingga saat ini, EBA belum secara eksplisit menerbitkan opini tentang WebAuthn atau
istilah “passkeys” dalam T\&J atau panduan mereka. Namun, berdasarkan prinsip-prinsip yang
telah mereka tetapkan, passkeys jelas cocok dengan metode yang dapat diterima. Opini EBA
2019 pada dasarnya mengantisipasi pendekatan seperti [FIDO2](https://www.corbado.com/glossary/fido2): untuk
kepemilikan, mereka secara eksplisit menyebutkan **“pertukaran kunci publik/privat” dengan
pengikatan perangkat yang tepat sebagai bukti kepemilikan**. Passkey WebAuthn persis
seperti itu – sepasang kunci publik/privat, dengan bagian privat terikat dengan aman ke
perangkat. Mereka juga memberikan persetujuan pada “tanda tangan yang dihasilkan oleh
perangkat” sebagai bukti kepemilikan yang valid. Jadi, meskipun mereka tidak menggunakan
istilah passkey, metodenya dicakup oleh contoh-contoh mereka. Kami juga telah mengamati
bahwa pemain pembayaran utama di Eropa bergerak maju dengan implementasi passkey (misalnya
[PayPal](https://www.corbado.com/blog/paypal-passkeys)) yang menunjukkan tingkat kepercayaan bahwa ini sesuai
dengan PSD2. Contoh ini menunjukkan bahwa passkeys diterima sebagai bagian dari alur SCA
yang patuh, asalkan penautan dinamis dan persyaratan keseluruhan dipenuhi.

**Pertanyaan 6:** Apakah kita masih memerlukan penautan dinamis jika passkeys
tahan-phishing? **Respons:** Ya. Passkeys menghilangkan **phishing lintas-asal**, tetapi
PSD2 masih mengamanatkan **penautan dinamis** untuk inisiasi pembayaran jarak jauh.
Penautan dinamis mengikat **jumlah dan penerima pembayaran spesifik** ke hasil SCA dan
**membatalkan setiap perubahan**, mengatasi integritas otorisasi di luar phishing
(misalnya, substitusi MITM/MITB/TPP).

## 7. Kesimpulan: kepatuhan penautan dinamis dan hasil yang lebih baik

Solusi Corbado sesuai dengan Penautan Dinamis dan PSD2. Tampilan pembayar pra-autentikasi,
tantangan satu kali yang terikat pada jumlah dan penerima pembayaran, verifikasi server
yang ketat, dan audit yang tidak dapat diubah secara bersama-sama memenuhi persyaratan RTS
Pasal 5 tentang kesadaran pembayar, keunikan/spesifisitas, pembatalan saat ada perubahan,
dan integritas/kerahasiaan. Independensi faktor dipertahankan melalui kepemilikan yang
terikat perangkat dan UV (biometrik atau PIN), sejalan dengan panduan EBA.

Dibandingkan dengan metode OTP/SMS saat ini, Corbado memberikan keamanan dan hasil
pengguna yang jauh lebih baik: ketahanan terhadap phishing dan replay, pencegahan
perusakan parameter secara diam-diam, bukti non-repudiation yang lebih kuat, dan
pengurangan gesekan melalui UV di perangkat. Risiko sisa (misalnya, rekayasa sosial,
perangkat yang disusupi) dimitigasi dengan kontrol konkret dan lebih sempit daripada
dengan metode lama. Untuk web, Corbado dapat mengadopsi
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) ketika dukungan platform (terutama Apple) sudah
luas, menambahkan bukti kriptografis tampilan tanpa mengubah postur kepatuhan inti.

Singkatnya, otorisasi transaksi berbasis passkey dari Corbado memenuhi aturan dan semangat
penautan dinamis PSD2 dan meningkatkan ketahanan terhadap penipuan dan kemampuan audit
dibandingkan dengan pendekatan lama, sambil mempertahankan jalur yang jelas untuk
peningkatan di masa depan (SPC) seiring dengan matangnya ekosistem.

Dalam praktiknya, passkeys memenuhi penautan dinamis ketika kita melakukan tiga hal: kita
menampilkan jumlah dan penerima pembayaran kepada pembayar sebelum verifikasi pengguna;
kita menghasilkan kode autentikasi yang spesifik untuk detail-detail tersebut; dan kita
membatalkan kode pada setiap perubahan (RTS Pasal 5(1)(a–d)). Ini mencerminkan
prinsip-prinsip yang sudah diterima regulator untuk
[biometrik lokal](https://www.corbado.com/id/blog/passkey-vs-biometrik-lokal), dengan kemudahan tambahan bahwa
passkeys bersifat asli OS dan berfungsi di seluruh saluran web dan aplikasi tanpa aplikasi
tambahan. Dikombinasikan dengan pengikatan asal, mereka tidak menampilkan permintaan palsu
— hanya prompt sah dari situs atau aplikasi asli yang muncul kepada pengguna.