--- url: 'https://www.corbado.com/id/blog/penautan-dinamis-passkeys-spc' title: 'Penautan Dinamis dengan Passkeys: Konfirmasi Pembayaran Aman (SPC)' description: 'Temukan bagaimana penautan dinamis, passkeys & Konfirmasi Pembayaran Aman (SPC) dapat meningkatkan pembayaran digital. Pelajari penggunaan passkeys untuk penautan dinamis.' lang: 'id' author: 'Vincent Delitz' date: '2025-07-15T13:23:06.144Z' lastModified: '2026-03-25T10:06:41.435Z' keywords: 'penautan dinamis, konfirmasi pembayaran aman, spc' category: 'Passkeys Strategy' --- # Penautan Dinamis dengan Passkeys: Konfirmasi Pembayaran Aman (SPC) ## 1. Pendahuluan Dalam seri empat bagian kami yang komprehensif (bagian 1, bagian 2, bagian 3 & bagian 4) tentang [PSD2](https://www.corbado.com/blog/psd2-passkeys), kami telah menjelajahi bagaimana passkeys terintegrasi dengan langkah-langkah **autentikasi pelanggan yang kuat (SCA)** yang diperkenalkan oleh [PSD2](https://www.corbado.com/blog/psd2-passkeys). Kami secara khusus berfokus pada elemen [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang disyaratkan oleh [SCA](https://www.corbado.com/id/blog/psd2-passkeys) untuk mengakses aplikasi perbankan. Persyaratan [SCA](https://www.corbado.com/id/blog/psd2-passkeys) tidak hanya berlaku untuk mengakses aplikasi tetapi juga untuk memulai dan menandatangani transaksi [pembayaran](https://www.corbado.com/passkeys-for-payment) elektronik dari jarak jauh. Selain itu, persyaratan ini memerlukan penggunaan mekanisme yang dikenal sebagai **penautan dinamis**. Dalam artikel ini, kami akan menjelaskan penautan dinamis dan mengkaji bagaimana passkeys dapat digunakan secara efektif untuk mengimplementasikan mekanisme ini, baik saat ini maupun di masa depan. ## 2. Apa Itu Penautan Dinamis dalam PSD2? **Penautan dinamis** adalah persyaratan [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) di bawah direktif [PSD2](https://www.corbado.com/blog/psd2-passkeys) dan adendum pelaksanaannya, Standar Teknis Regulasi (RTS). Konsep ini diperkenalkan untuk meningkatkan [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) [pembayaran](https://www.corbado.com/passkeys-for-payment) elektronik dengan memastikan bahwa setiap transaksi terhubung secara unik ke jumlah tertentu dan penerima pembayaran tertentu melalui kode [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password). Keterkaitan ini mencegah modifikasi detail transaksi setelah diautentikasi oleh pembayar, sehingga mengurangi risiko penipuan. [Pembayaran](https://www.corbado.com/passkeys-for-payment) elektronik mencakup transfer bank dalam perangkat lunak [perbankan](https://www.corbado.com/passkeys-for-banking) online, serta [pembayaran](https://www.corbado.com/passkeys-for-payment) kartu kredit di situs [merchant](https://www.corbado.com/glossary/merchant). ### 2.1 Definisi dan Pentingnya dalam PSD2 Menurut Direktif PSD2 dan RTS yang menyertainya, penautan dinamis didefinisikan sebagai proses yang memastikan bahwa "kode [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang dihasilkan spesifik untuk jumlah dan penerima pembayaran yang disetujui oleh pembayar saat memulai transaksi [pembayaran](https://www.corbado.com/passkeys-for-payment) elektronik" (Pasal 97(2) PSD2). Ini berarti bahwa setiap perubahan dalam detail [pembayaran](https://www.corbado.com/passkeys-for-payment) akan membatalkan kode autentikasi, sehingga memerlukan autentikasi ulang. Penautan dinamis sangat penting dalam PSD2, karena secara langsung mengatasi risiko [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) yang terkait dengan transaksi elektronik jarak jauh, yang sangat rentan terhadap berbagai jenis penipuan, seperti serangan man-in-the-middle. Dengan mengamankan transaksi dengan cara ini, penautan dinamis secara signifikan menurunkan kemungkinan transaksi yang tidak sah. ### 2.2 Persyaratan untuk Penautan Dinamis dalam Transaksi Keuangan Pasal 5 RTS memperluas persyaratan untuk kode autentikasi dalam penautan dinamis. Persyaratan ini meliputi: - **Kesadaran pembayar**: Pembayar dibuat sadar akan jumlah transaksi pembayaran dan penerima pembayarannya. - **Kode autentikasi unik:** Kode autentikasi yang dihasilkan untuk setiap transaksi harus unik dan tidak dapat digunakan kembali untuk transaksi lain. - **Kode autentikasi spesifik**: Kode yang dihasilkan dan kode yang diterima harus spesifik untuk jumlah transaksi dan identitas penerima pembayaran sebagaimana dikonfirmasi oleh pembayar. Setiap perubahan pada jumlah atau penerima pembayaran akan mengakibatkan pembatalan kode autentikasi. - **Transmisi aman**: Kerahasiaan, keaslian, dan integritas dijaga untuk jumlah transaksi dan penerima pembayaran di semua fase autentikasi, termasuk pembuatan, transmisi, dan penggunaan kode autentikasi. Dengan ditetapkannya persyaratan teknis penautan dinamis ini, di bagian berikutnya kita akan melihat bagaimana passkeys dapat membantu sebagai teknologi baru. Kita akan menjelajahi potensi mereka untuk menyederhanakan dan mengamankan proses autentikasi pembayaran, membuat penautan dinamis tidak hanya lebih kuat tetapi juga lebih ramah pengguna. ## 3. Bagaimana Passkeys Dapat Digunakan untuk Penautan Dinamis? Mari kita analisis terlebih dahulu berbagai opsi bagaimana passkeys dapat digunakan dalam penautan dinamis. ### 3.1 Opsi 1: Penggunaan Standar Passkeys dalam Penautan Dinamis Dalam pendekatan ini, passkey itu sendiri bertindak sebagai pernyataan kriptografis yang digunakan langsung sebagai kode autentikasi. Tantangan yang dikeluarkan selama proses transaksi dibuat untuk secara spesifik mencerminkan detail transaksi tertentu, seperti jumlah dan penerima pembayaran, dan disimpan bersama dengan informasi tersebut. Ketika pengguna mengotorisasi transaksi menggunakan passkey mereka, tanda tangan unik yang aman secara kriptografis akan dihasilkan yang dapat diverifikasi dan disimpan bersama dengan transaksi. Respons ini tidak hanya berfungsi sebagai faktor autentikasi yang kuat tetapi juga secara langsung mengikat persetujuan ke detail transaksi spesifik, dengan ketat mematuhi persyaratan PSD2 untuk penautan dinamis. ### 3.2 Opsi 2: Bukti Kriptografis yang Ditingkatkan melalui Tantangan WebAuthn Integrasi yang lebih canggih melibatkan pengkodean detail transaksi tambahan ke dalam tantangan WebAuthn itu sendiri (yang secara teknis tidak disyaratkan oleh PSD2/RTS). Metode ini menyarankan untuk memasukkan hash kriptografis dari penerima pembayaran dan jumlahnya, bersama dengan data acak lainnya, ke dalam tantangan. Dengan melakukan ini, proses autentikasi tidak hanya memverifikasi identitas pengguna melalui passkey tetapi juga secara kriptografis menegaskan integritas detail transaksi. Pendekatan ini menawarkan lapisan keamanan tambahan dengan memastikan bahwa setiap perusakan pada jumlah atau detail penerima pembayaran akan dapat dideteksi pada titik pembayaran akhir. Bukti kriptografis menjadi bagian yang tidak dapat diubah dari kode autentikasi, meningkatkan kepercayaan dan keamanan di lingkungan transaksi berisiko tinggi (info lebih lanjut [di sini](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)). ### 3.3 Keterbatasan dan Tantangan Opsi Passkey Standar Mari kita analisis keterbatasan dan tantangan dari kedua opsi ini. #### 3.3.1 Kesadaran Pembayar Tidak Dapat Dijamin Salah satu keterbatasan penggunaan passkeys dalam konteks penautan dinamis, terutama untuk autentikasi pembayaran, adalah kurangnya dokumentasi atau jaminan konkret bahwa pembayar telah diinformasikan secara akurat tentang informasi penerima pembayaran. Meskipun passkeys menyediakan metode yang aman untuk autentikasi pengguna, mereka tidak secara inheren memverifikasi apakah semua detail transaksi, terutama yang menyangkut penerima pembayaran, telah ditampilkan dengan benar kepada pembayar. Masalah ini tidak unik untuk passkeys; ini adalah tantangan umum di berbagai sistem pembayaran online. Memastikan bahwa pembayar sepenuhnya sadar dan menyetujui semua detail transaksi sebelum memulai pembayaran sangat penting untuk menjaga kepercayaan dan keamanan. #### 3.3.2 Kasus Penggunaan: Konteks Pembayaran Pihak Pertama vs. Pihak Ketiga Keterbatasan paling signifikan dalam mengintegrasikan passkeys ke dalam penautan dinamis muncul dalam perbedaan antara registrasi pihak pertama dan pihak ketiga. **Apa itu Konteks Pembayaran Pihak Pertama?** ✔️ Dalam konteks pembayaran Pihak Pertama, pengguna berinteraksi langsung dengan penerbit / bank di layanan internet dan domain mereka. Passkeys dapat didaftarkan dan diautentikasi dengan lancar. Contohnya bisa jadi bank yang mendaftarkan passkey di situs web mereka sendiri dan menggunakannya untuk mengotorisasi inisiasi pembayaran dari perangkat lunak [perbankan](https://www.corbado.com/passkeys-for-banking) online mereka. Di sini, passkeys bekerja dengan mulus. Bank dapat memastikan bahwa passkey digunakan dalam domainnya, menjaga kontrol atas lingkungan pembayaran dan keamanan transaksi. Silakan lihat postingan blog kami untuk implementasi [passkey Mastercard](https://www.corbado.com/id/blog/passkey-mastercard) dalam konteks pembayaran pihak pertama. **Apa itu Konteks Pembayaran Pihak Ketiga?** Dalam konteks pembayaran Pihak Ketiga, pengguna berada di halaman [merchant](https://www.corbado.com/glossary/merchant) dalam proses checkout di domain yang berbeda (misalnya amazon.com) dan ingin memulai transaksi kartu kredit: - ✔️ **Kasus 1 – Pengguna sudah memiliki passkey dari penerbit / bank mereka:** [Merchant](https://www.corbado.com/glossary/merchant) menampilkan [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) di mana autentikasi dengan passkey dapat terjadi. [IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) ditampilkan oleh proses [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS) yang sudah ada untuk transaksi kartu kredit yang perlu mendukung [SCA](https://www.corbado.com/id/blog/psd2-passkeys) dan penautan dinamis. - ❌ **Kasus 2 – Pengguna tidak memiliki passkey dari penerbit / bank mereka:** Sekali lagi, merchant menampilkan [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). Karena belum ada passkeys yang tersedia, pengguna diautentikasi oleh faktor autentikasi yang ada (misalnya SMS OTP atau aplikasi [perbankan](https://www.corbado.com/passkeys-for-banking) asli di ponsel cerdas mereka). Pada titik ini, setelah autentikasi berhasil, akan menjadi momen yang ideal untuk mendaftarkan passkey bagi pengguna, tetapi **ini tidak diizinkan karena batasan standar WebAuthn**. Pendaftaran passkeys dalam iframe lintas-asal tidak diizinkan (domain halaman utama dan iframe harus identik). Pendaftaran bertahap seperti pada tangkapan layar berikut tidak akan mungkin: ![dynamic-linking-passkeys-check-out-faster.png](https://www.corbado.com/website-assets/dynamic_linking_passkeys_check_out_faster_edb79b9e22.png) **Apakah pendaftaran passkey di iframe lintas-asal akan didukung di masa depan?** Walaupun passkeys menawarkan solusi yang baik untuk penautan dinamis dalam konteks pembayaran pihak pertama dalam satu domain, dalam konteks pembayaran pihak ketiga, saat ini mereka tidak didukung oleh WebAuthn Level 2. Namun, kabar baiknya adalah dukungan iframe lintas-asal sudah dimasukkan ke dalam spesifikasi [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) yang sedang berlangsung (yang akan tersedia secara umum pada akhir 2024). Namun, browser masih harus mengejar spesifikasi tersebut: | **Browser/Standar** | **Konteks Pihak Pertama** | **Konteks Pihak Ketiga** | | --------------------------------------------------------------------------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Mendaftarkan passkeys** **di iframe lintas-asal:** | | | | Diperlukan di WebAuthn Level 2 | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | ❌ | | Diperlukan di WebAuthn Level 3 | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | | Diimplementasikan di Chrome | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | | Diimplementasikan di Firefox | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | [Sinyal positif](https://github.com/mozilla/standards-positions/issues/964) untuk implementasi | | Diimplementasikan di [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Detail](https://issues.chromium.org/issues/40258856) | Menunggu sinyal untuk implementasi | | **Autentikasi menggunakan passkeys** **di iframe lintas-asal:** | | | | Diperlukan di WebAuthn Level 2 | ✔️ | ✔️ | | Diperlukan di WebAuthn Level 3 | ✔️ | ✔️ | | Diimplementasikan di Chrome | ✔️ | ✔️ | | Diimplementasikan di Firefox | ✔️ | ✔️ | | Diimplementasikan di Safari | ✔️ | ✔️ | Hingga hari ini, tampaknya pada tahun 2024, cakupan untuk pendaftaran passkeys lintas-asal bisa menjadi kenyataan di browser-browser utama, yang akan menghilangkan batasan teknis paling signifikan dalam menggunakan passkeys untuk pembayaran. ## 4. Opsi Masa Depan: Konfirmasi Pembayaran Aman (SPC) Ada beberapa upaya (misalnya BasicCard, PaymentHandler atau PaymentManifest) oleh kelompok kerja yang diprakarsai Google di W3C untuk meningkatkan pengalaman pembayaran di web. Hingga saat ini, belum ada yang mendapatkan cakupan pasar dan penggunaan yang signifikan. Gesekan dalam proses pembayaran untuk transaksi [ecommerce](https://www.corbado.com/passkeys-for-e-commerce) tetap menjadi tantangan besar dengan meningkatnya regulasi terhadap penipuan. Standar **Konfirmasi Pembayaran Aman** yang diprakarsai oleh Google & Stripe saat ini adalah standar yang paling menjanjikan yang dibangun di atas standar WebAuthn. ### 4.1 Apa Tujuan dari Standar SPC? Konfirmasi Pembayaran Aman (SPC) menangani semua elemen penting dari PSD2 SCA termasuk persyaratan penautan dinamis, dan pada saat yang sama mencoba meningkatkan pengalaman UX. - **Menawarkan UX Asli Browser**: [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) memanfaatkan browser untuk menyediakan pengalaman autentikasi yang konsisten dan efisien di berbagai situs merchant dan [pihak yang mengandalkan](https://www.corbado.com/id/glossary/relying-party). Pendekatan ini dimaksudkan untuk meningkatkan keamanan transaksi melebihi apa yang biasanya dicapai dengan konten yang dirender dalam iframe dengan memiliki tampilan yang konsisten dan menjamin kesadaran pembayar: ![Dynamic Linking Passkeys SPC Merchant](https://www.corbado.com/website-assets/dynamic_linking_passkeys_spc_merchant_8009b1ef5a.png)_Contoh dari [https://www.w3.org/press-releases/2023/spc-cr/](https://www.w3.org/press-releases/2023/spc-cr/)_ - **Menyediakan Bukti Kriptografis:** Standar ini memastikan bahwa bukti kriptografis dari konfirmasi pengguna atas detail pembayaran dihasilkan dan disertakan dalam pernyataan WebAuthn tanpa perlu mengkodekan informasi ke dalam tantangan WebAuthn. - **Mengizinkan Pendaftaran Pihak Ketiga:** Tidak seperti dalam standar WebAuthn Level 2, di mana pendaftaran [authenticator](https://www.corbado.com/glossary/authenticator) harus terjadi dalam konteks pihak pertama, [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) memungkinkan pendaftaran passkeys langsung dari iframe lintas-asal. Kemampuan ini menangani kasus penggunaan umum dalam ekosistem pembayaran dan memfasilitasi integrasi yang lebih mudah bagi merchant dan pemroses pembayaran. Seperti yang telah kita bahas di atas, fungsionalitas ini sudah menjadi bagian dari versi berikutnya dari standar yang mendasarinya dan oleh karena itu mungkin akan dihapus di masa depan dari [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc). - **Autentikasi Pembayaran Lintas-Asal:** SPC memperluas kegunaan WebAuthn dengan memungkinkan asal mana pun untuk menghasilkan pernyataan untuk suatu transaksi, bahkan jika itu memanfaatkan kredensial dari [Pihak yang Mengandalkan](https://www.corbado.com/id/glossary/relying-party) lain (tanpa perlu meninggalkan halaman). Dalam hal ini, bahkan iframe dari merchant / penerbit tidak diperlukan. Fitur ini sangat berguna dalam skenario di mana beberapa pihak (merchant + penerbit / bank) terlibat dalam proses autentikasi dan pernyataan kemudian dapat diangkut ke [Pihak yang Mengandalkan](https://www.corbado.com/id/glossary/relying-party) asli (penyedia akun, misalnya bank) untuk verifikasi. ![Cross Origin Authentication Payments](https://www.corbado.com/website-assets/cross_origin_authentication_payments_1fe18ec791.png) Contoh di atas diambil dari Penjelasan SPC dan menunjukkan konsep Autentikasi Pembayaran Lintas-Asal: Dalam proses pembayaran menggunakan SPC, pengguna tetap berada di situs merchant (disorot dengan warna biru) selama transaksi. Browser web (berwarna hijau) mempertahankan tampilan asal merchant dan juga menyajikan dialog yang telah ditentukan sebelumnya dan tidak dapat disesuaikan dengan semua informasi penting untuk penautan dinamis (jumlah + penerima pembayaran) untuk mengonfirmasi transaksi. Setelah konfirmasi pengguna, sistem operasi (digambarkan dengan warna oranye) menangani [autentikasi biometrik](https://www.corbado.com/id/faq/apa-itu-passkeys) yang diperlukan untuk memverifikasi transaksi. Tujuan-tujuan ini menggambarkan komitmen SPC untuk meningkatkan keamanan dan pengalaman pengguna pembayaran online, bertujuan untuk menyederhanakan proses autentikasi sambil mempertahankan standar keamanan yang tinggi di seluruh lanskap pembayaran digital. ### 4.2 Seperti Apa Alur Passkey SPC? Mari kita lihat semua kemungkinan alur yang diizinkan oleh SPC dan membandingkannya dengan passkeys standar, agar kita memahami manfaatnya. | | **Passkeys SPC** | **Passkeys** | | --------------------------------------------- | ---------------- | ------------ | | **Otentikasi/registrasi situs web Penerbit** | ✔️ | ✔️ | | **Registrasi situs web Merchant di iframe** | ✔️ | ❌/✔️ | | **Otentikasi situs web Merchant di iframe** | ✔️ | ✔️ | | **Otentikasi lintas-asal situs web Merchant** | ✔️ | ❌ | Seperti yang bisa kita lihat di sini, perbedaan paling penting adalah pendaftaran di situs web merchant dalam iframe yang belum didukung oleh passkeys (lihat diskusi kita di atas) dan kemungkinan baru yaitu Autentikasi Lintas-Asal. Mari kita bahas satu per satu. #### 4.2.1 Passkeys SPC: Daftar / Autentikasi Langsung di Situs Web Penerbit / Bank Berikut adalah contoh mock-up [pendaftaran passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) SPC langsung di halaman [Mastercard](https://www.corbado.com/blog/mastercard-passkeys). Seperti yang dapat Anda lihat di sini, [pembuatan passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) ditawarkan tepat setelah penyelesaian autentikasi melalui SMS OTP dalam kasus ini. ![SPC Passkeys Issuer Bank](https://www.corbado.com/website-assets/spc_passkeys_issuer_bank_3d68dd2043.png) Dalam kasus ini, komunikasi akan terlihat seperti proses pendaftaran passkeys standar karena ini terjadi sepenuhnya dalam konteks pihak pertama. ![SPC Passkeys Flow](https://www.corbado.com/website-assets/spc_passkeys_flow_1324c4d2d7.png)_Diambil dari [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ Passkey SPC ini sekarang dapat digunakan di situs merchant untuk autentikasi, dalam iframe di situs merchant, dan untuk Autentikasi Lintas-Asal (lihat di bawah). #### 4.2.2 Passkeys SPC: Daftar / Autentikasi di Situs Web Merchant Selama Pembayaran Seperti yang telah kita bahas sebelumnya, proses [pendaftaran passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) SPC di situs web merchant biasanya akan terjadi selama transaksi pembayaran, dalam konteks alur [3-D Secure](https://www.corbado.com/glossary/3d-secure) (3DS). Alur ini dirancang untuk meningkatkan keamanan transaksi kartu kredit dan debit online dengan melibatkan langkah autentikasi tambahan yang memverifikasi identitas pemegang kartu. Selama transaksi pembayaran, ketika alur 3DS dimulai, proses autentikasi difasilitasi melalui iframe yang di-host di situs merchant (misalnya amazon.com) tetapi dikendalikan oleh [penyedia layanan pembayaran](https://www.corbado.com/id/blog/passkey-penyedia-pembayaran-sdk-pihak-ketiga) atau bank penerbit (misalnya [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). Iframe ini berfungsi sebagai lingkungan yang aman bagi pelanggan untuk mengautentikasi identitas mereka menggunakan faktor autentikasi yang ada. Setelah pelanggan berhasil mengautentikasi diri mereka menggunakan faktor konvensional ini (misalnya SMS OTP atau aplikasi perbankan), ada kesempatan untuk mendaftarkan passkey SPC untuk transaksi di masa depan. **Karena Standar SPC memungkinkan pembuatan passkey lintas-asal dari dalam iframe, ini akan berhasil.** [Pendaftaran passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) ini di iframe biasanya akan melibatkan pelanggan melakukan tindakan yang menghasilkan dan mengikat passkey ke kartu kredit mereka, seperti memverifikasi sidik jari atau pengenalan wajah mereka pada perangkat yang kompatibel. Perlu diingat bahwa iframe dikendalikan oleh [penyedia layanan pembayaran](https://www.corbado.com/id/blog/passkey-penyedia-pembayaran-sdk-pihak-ketiga) (misalnya [PayPal](https://www.corbado.com/blog/paypal-passkeys)) atau bank penerbit (misalnya [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). Oleh karena itu, passkey SPC dibuat dengan penerbit / bank secara langsung dan bukan merchant. Alur yang disederhanakan akan terlihat seperti ini: ![SPC Passkeys Merchant Flow](https://www.corbado.com/website-assets/spc_passkeys_merchant_flow_267ffda65a.png)_Diambil dari [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ Di [https://spc-merchant.glitch.me/](https://spc-merchant.glitch.me/), Google telah menyiapkan aplikasi demo yang dapat diakses melalui Chrome di Windows dan Mac, yang mengilustrasikan bagaimana ini akan bekerja dari dalam iframe: ![SPC Passkey Demo App](https://www.corbado.com/website-assets/spc_passkey_demo_app_4458eb6295.png) Ini juga memungkinkan untuk bermain-main dengan situs bank secara langsung yang di-host di: [https://spc-rp.glitch.me/reauth](https://spc-rp.glitch.me/reauth). Dalam contoh ini, tidak ada komunikasi out-of-band dengan API antara merchant dan penerbit / bank yang diperlukan – semuanya ditangani oleh browser. Autentikasi menggunakan passkey yang ada akan bekerja dengan cara yang sama dari dalam iframe. #### 4.2.3 Passkeys SPC: Autentikasi Lintas-Asal Dalam contoh berikut, kita melihat Autentikasi Lintas-Asal di mana pengguna telah mendaftarkan Passkey SPC dengan Mastercard. Contoh situs merchant (decorshop.com) dapat memicu Autentikasi Lintas-Asal. **Perbedaan utama dan penting adalah bahwa halaman merchant / penerbit tidak pernah terlihat selama proses autentikasi**. Browser dalam kombinasi dengan sistem operasi menyajikan UX pembayaran yang telah ditentukan (disediakan oleh implementasi browser dari standar SPC) dan modal autentikasi (standar WebAuthn). Komunikasi antara merchant dan penerbit / bank ditangani di latar belakang. ![SPC Passkeys Cross-Origin Authentication](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_3cc4d40619.png)_Asli dari (disesuaikan sebagian): [https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf](https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf) (Mastercard)_ ![SPC Passkeys Cross-Origin Authentication Flow](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_flow_d6d05cdf6b.png)_Asli dari (disesuaikan sebagian): [https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams](https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams)_ Saat menggunakan Autentikasi Lintas-Asal, merchant berkomunikasi dengan penerbit / bank melalui beberapa bentuk API untuk bertukar informasi tentang kredensial yang ada (#2 dalam bagan urutan di atas). Jika kredensial ada dan browser pengguna mendukung SPC, autentikasi dimulai. Pada akhirnya, pernyataan dikembalikan kembali ke penerbit / bank melalui protokol yang ada seperti EMV 3DS, di mana pernyataan tersebut akhirnya dapat diverifikasi secara kriptografis pada akhirnya (#16). Karena pernyataan tersebut juga menyertakan informasi tentang informasi yang ditampilkan oleh browser, semua persyaratan untuk penautan dinamis terpenuhi. Ini akan menjadi langkah besar dalam hal peningkatan UX dan pengalaman pembayaran pelanggan. ### 4.3 Apa Status Standar Konfirmasi Pembayaran Aman? Standar Konfirmasi Pembayaran Aman (SPC) adalah perkembangan menarik di dunia autentikasi pembayaran online, yang bertujuan untuk meningkatkan keamanan sambil menyederhanakan pengalaman pengguna. Hingga hari ini, Google Chrome adalah satu-satunya browser utama yang mendukung SPC dalam beberapa bentuk. Namun, ini tidak mengherankan karena standar tersebut sebagian telah diprakarsai oleh Google. Dari browser utama lainnya seperti Safari Apple dan Mozilla Firefox, ada kekurangan komitmen yang nyata tanpa sinyal yang jelas tentang rencana mereka untuk mendukung SPC. Secara khusus, Apple mendorong Standar miliknya sendiri, **Apple Pay**, dan tampaknya tidak tertarik pada standar pembayaran lainnya. Koneksi SPC dengan WebAuthn telah membuat proses pengembangan menjadi lebih sulit. Ini karena setiap peningkatan atau modifikasi dalam standar SPC perlu dievaluasi dengan cermat untuk mencegah redundansi dan memastikan mereka memberikan peningkatan asli atas kemampuan yang ada. Tujuannya adalah untuk menyempurnakan SPC untuk melayani kebutuhan spesifik dalam proses pembayaran yang tidak sepenuhnya tercakup oleh WebAuthn, seperti integrasi langsung ke dalam alur checkout dan menyediakan pengalaman autentikasi yang lebih ramah pengguna yang dapat beroperasi dengan lancar di berbagai situs merchant. Seiring SPC terus berkembang, adopsinya di berbagai browser akan sangat penting untuk implementasi yang luas. Keterlibatan pemain besar seperti Google menunjukkan arah yang positif, tetapi dukungan yang lebih luas akan diperlukan untuk menetapkan SPC sebagai standar di seluruh industri pembayaran online. ## 5. Opsi Masa Depan 2: Ekstensi Konfirmasi Tantangan yang diuraikan di atas, terutama seputar **kesadaran pembayar**, telah mendorong pekerjaan yang sedang berlangsung di [Kelompok Kerja WebAuthn](https://github.com/w3c/webauthn/pull/2020) pada apa yang disebut **ekstensi konfirmasi** (sebelumnya dikenal sebagai “txAuthSimple”) dalam Standar WebAuthN. Tujuannya adalah untuk memungkinkan [authenticator](https://www.corbado.com/glossary/authenticator) atau browser/OS (dalam UI berprivilese) untuk menampilkan detail transaksi kepada pengguna dan memastikan bahwa pihak yang mengandalkan menerima bukti kriptografis bahwa pengguna benar-benar mengonfirmasi detail ini. Ini secara langsung mengatasi masalah “kurangnya jaminan kesadaran pengguna” yang dijelaskan di [bagian 3.3.1](#331-payer-awareness-cannot-be-assured). ### 5.1 Apa Tujuan dari Ekstensi Konfirmasi? Mirip dengan bagaimana Konfirmasi Pembayaran Aman (SPC) menyediakan dialog khusus yang digerakkan oleh browser, ekstensi konfirmasi menangani masalah “Apa yang Anda Lihat Adalah Apa yang Anda Tanda Tangani” (WYSIWYS). Tujuan utamanya adalah: - **Tampilan Detail Transaksi yang Tepercaya**: Daripada menyerahkannya pada konten web untuk menunjukkan jumlah dan penerima pembayaran, ekstensi ini memanfaatkan layar aman perangkat atau dialog UI browser di bawah kendali OS. - **Bukti Kriptografis**: [Authenticator](https://www.corbado.com/glossary/authenticator) (atau platform klien) menandatangani catatan teks persis yang ditampilkan. Dengan memverifikasi tanda tangan ini, pihak yang mengandalkan dapat mengonfirmasi bahwa pengguna telah ditunjukkan detail yang benar. - **Fallback jika Authenticator Tidak Mendukung Tampilan**: Dalam kasus di mana authenticator perangkat keras tidak dapat menampilkan teks, browser dapat menampilkannya dan menyertakannya dalam \[=data klien=]. Ini adalah jaminan yang lebih lemah tetapi memungkinkan kompatibilitas yang lebih luas. ### 5.2 Bagaimana Cara Kerja Ekstensi Konfirmasi? Ekstensi ini menambahkan bidang baru ke struktur ekstensi WebAuthn yang ada. Pihak yang Mengandalkan menyediakan string teks sederhana (dengan format dasar opsional) yang disebut `confirmation`: ```webidl partial dictionary AuthenticationExtensionsClientInputs { USVString confirmation; }; ``` Ketika klien (browser) menerima ini, ia: 1. **Meminta** pengguna dengan dialog konfirmasi khusus (sehingga mereka tahu ini lebih dari sekadar login dasar). 2. **Meneruskan** string yang sama ke authenticator sebagai data [CBOR](https://www.corbado.com/glossary/cbor) jika authenticator mendukung ekstensi tersebut. 3. **Mengembalikan** output authenticator apa pun ke Pihak yang Mengandalkan. Jika authenticator mendukung tampilan teks, ia **harus** menampilkan teks tersebut (misalnya, di layarnya sendiri atau UI tepercaya) sebelum menyelesaikan verifikasi pengguna. Kemudian ia menyertakan string yang sama dalam output yang ditandatanganinya. Di sisi Pihak yang Mengandalkan, langkah-langkah verifikasi memastikan bahwa teks `confirmation` yang dikembalikan **cocok** dengan apa yang dikirim. Jika output ekstensi authenticator hilang tetapi kebijakan Pihak yang Mengandalkan mengizinkan fallback, Pihak yang Mengandalkan dapat mengandalkan nilai `confirmation` dari data klien—menunjukkan bahwa browser menampilkan teks alih-alih authenticator. ### 5.3 Mengapa Ini Penting untuk Penautan Dinamis Dengan menyematkan **penerima pembayaran** dan **jumlah** ke dalam ekstensi ini, pengguna melihat dengan tepat apa yang mereka otorisasi pada tampilan tepercaya. Tanda tangan pengguna sekarang tidak hanya mencerminkan tantangan yang di-hash tetapi juga **teks transaksi yang persis**. Ini sangat berharga untuk persyaratan penautan dinamis PSD2, karena: - Setiap ketidakcocokan atau modifikasi detail transaksi setelah ditampilkan akan membatalkan tanda tangan. - Pihak yang Mengandalkan dapat membuktikan bahwa pengguna diberi detail transaksi yang benar pada saat penandatanganan, memenuhi persyaratan “kesadaran pembayar” PSD2 jauh lebih kuat daripada hanya melakukan hashing data dalam tantangan. ### 5.4 Status Saat Ini dari Ekstensi Konfirmasi Walaupun **ekstensi konfirmasi** masih dalam diskusi, ini merupakan langkah penting menuju alur transaksi yang lebih aman dan ramah pengguna. Dengan membangunnya langsung ke dalam spesifikasi WebAuthn, ia menawarkan: - **Interoperabilitas**: Setiap authenticator atau klien yang mengimplementasikan ekstensi akan mengikuti format standar yang sama. - **Fleksibilitas**: Pihak yang Mengandalkan dapat memberlakukan kebijakan yang lebih kuat (memerlukan tampilan tingkat authenticator) atau menerima fallback tingkat browser jika diperlukan. - **Penyelarasan Ekosistem yang Lebih Luas**: Ini selaras dengan mandat peraturan seperti PSD2, terutama seputar penautan dinamis yang kuat. Untuk detail teknis lebih lanjut, Anda dapat melihat diskusi yang sedang berlangsung: [Permintaan pull GitHub #2020](https://github.com/w3c/webauthn/pull/2020). Singkatnya, ekstensi konfirmasi juga dapat menutup celah besar terakhir dalam alur berbasis passkey standar: menyediakan **bukti kriptografis** tentang **apa** yang sebenarnya dilihat pengguna saat mereka memberikan persetujuan, meskipun kurang terstruktur dibandingkan dengan Konfirmasi Pembayaran Aman. Jika mendapatkan daya tarik di antara vendor browser dan authenticator, ini bisa menjadi metode yang sangat terstandarisasi untuk memberikan jaminan keamanan WYSIWYS yang diperlukan di bawah penautan dinamis PSD2—dan lebih dari itu. ### 5.5 Perbandingan: Bagaimana SPC dan Ekstensi Konfirmasi Berbeda Meskipun **SPC** dan **ekstensi konfirmasi** memiliki tujuan yang sama untuk memperkuat penautan dinamis di WebAuthn, keduanya berbeda dalam cakupan dan pendekatan. Tabel di bawah ini menyoroti beberapa perbedaan ini: | **Kriteria Perbandingan** | **SPC** | **Ekstensi Konfirmasi** | | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **Alur Pembayaran Terintegrasi**
_(Menangani checkout penuh, jumlah, penerima pembayaran, UI, dll.)_ | ✔️ Menyertakan dialog browser standar untuk pembayaran | ❌ Hanya berfokus pada menampilkan dan menandatangani string teks | | **Tampilan Transaksi Tepercaya**
_(Memastikan pengguna melihat penerima/jumlah yang benar)_ | ✔️ Alur berbasis browser memastikan UX yang konsisten | ✔️ Baik tampilan authenticator atau browser | | **Penanganan Fallback**
_(Jika authenticator memiliki kemampuan tampilan terbatas atau tidak ada)_ | ❌ Tidak dirancang khusus untuk jalur fallback | ✔️ Pihak yang Mengandalkan dapat menerima tampilan tingkat klien jika diperlukan | | **Cakupan di Luar Penautan Dinamis**
_(Tujuan lebih luas, mis. alur sekali klik, otentikasi lintas-asal)_ | ✔️ Dirancang untuk menyederhanakan seluruh proses checkout | ❌ Murni ekstensi untuk tantangan/respons WebAuthn standar | | **Kematangan & Adopsi Saat Ini**
_(Kesiapan lintas-browser)_ | Adopsi rendah di luar Chrome; jadwal tidak pasti | Sedang didiskusikan di [WebAuthn WG](https://github.com/w3c/webauthn/pull/2020) tetapi menjanjikan | Intinya, SPC mencoba menawarkan solusi pembayaran yang komprehensif\* dan juga menggabungkan penautan dinamis\* sebagai bagian dari alurnya. Sementara itu, ekstensi konfirmasi\* menangani persyaratan _“apa yang Anda lihat adalah apa yang Anda tanda tangani”_ _di dalam_ pesan WebAuthn standar tanpa memaksakan alur pembayaran penuh. Salah satu pendekatan dapat memfasilitasi kepatuhan PSD2, tetapi masing-masing bergantung pada dukungan **browser** dan **authenticator** untuk memberikan manfaat di dunia nyata. ## 6. Rekomendasi untuk Penerbit / Bank Rekomendasi kami untuk penerbit, bank, dan lembaga keuangan adalah untuk mengevaluasi dengan cermat kasus penggunaan mana yang perlu dicakup dan memantau perkembangan ekosistem karena kemudahan passkeys akan memberikan tekanan besar pada solusi SCA & penautan dinamis yang ada untuk meningkatkan UX mereka. Pelanggan akan menuntut solusi biometrik di web. Saat ini, rekomendasi operasional kami adalah: - ✔️ **[Passkeys untuk Pembayaran yang Dimulai di Situs Web Penerbit / Bank](https://issues.chromium.org/issues/40258856):** Passkeys adalah solusi yang sangat baik bagi penerbit / bank untuk mengimplementasikan penautan dinamis ke dalam situs web & aplikasi mereka secara langsung. Mereka dapat dikombinasikan dengan opsi autentikasi lain seperti notifikasi push, email / SMS OTP atau TOTP untuk lebih meningkatkan keamanan pembayaran berisiko tinggi. Tentu saja, pertimbangan mengenai kepatuhan SCA harus selalu menjadi bagian dari diskusi ini (lihat juga seri 4 bagian kami tentang passkeys & SCA). Solusi yang diusulkan dapat diimplementasikan oleh penerbit / bank sendiri karena passkeys didasarkan pada standar WebAuthn yang terbuka. Namun, ini membutuhkan pengetahuan yang substansial, penanganan kasus-kasus khusus, dan terus mengikuti semua peraturan baru dan perkembangan teknis. Alternatifnya adalah menggunakan penyedia autentikasi pihak ketiga. Misalnya, Corbado Connect mendukung penautan dinamis melalui penandatanganan transaksi, memanfaatkan tantangan WebAuthn yang disesuaikan. Semua informasi dicatat dalam log audit. Ini tidak hanya berguna untuk lembaga keuangan tetapi juga dapat dimanfaatkan untuk semua jenis tanda tangan (misalnya penandatanganan dokumen, tindakan pengguna berisiko tinggi). Secara opsional, SMS atau E-Mail OTP tambahan dapat digunakan untuk meningkatkan keamanan lebih lanjut. - ❌ **Passkeys untuk Pembayaran di Halaman Merchant:** Meluncurkan passkeys untuk pembayaran di halaman merchant belum memungkinkan. Kasus penggunaan lintas-asal masih dalam pengembangan tetapi mungkin menjadi pilihan yang layak pada akhir 2024. Namun, menggunakan passkeys untuk autentikasi di halaman merchant sudah merupakan ide bagus hari ini dan juga dapat digunakan untuk mulai mengumpulkan passkeys yang kemudian juga dapat digunakan untuk pembayaran di masa depan. - ❌ **Passkeys SPC atau Ekstensi Konfirmasi untuk Penautan Dinamis**: Standar SPC belum mencapai status & dukungan yang matang untuk digunakan di lingkungan produksi. Secara keseluruhan, kami senang melihat bahwa merchant dan bank telah mulai terlibat dengan standar dan menambahkan persyaratan serta dukungan mereka ke ekosistem. Ke depan, lembaga keuangan dan platform [e-commerce](https://www.corbado.com/passkeys-for-e-commerce) harus memantau kemajuan teknologi ini dengan cermat dan mempertimbangkan bagaimana mereka dapat mengintegrasikan passkeys ke dalam sistem mereka. Seiring peraturan terus berkembang, sangat penting untuk tetap terdepan, memastikan bahwa proses autentikasi pembayaran selaras dengan standar keamanan terbaru dan memberikan pengalaman pengguna yang aman dan efisien bagi konsumen yang meningkatkan konversi & mengurangi gesekan. ## 6. Kesimpulan Saat kami meninjau passkeys untuk penautan dinamis, terbukti bahwa meskipun passkeys dapat membantu mematuhi SCA & penautan dinamis, integrasi teknis dalam layanan pihak ketiga dengan standar WebAuthn, yang awalnya dirancang untuk konteks pihak pertama, menghadirkan beberapa tantangan. Standar-standar ini secara bertahap berkembang untuk mendukung skenario pihak ketiga dengan lebih baik, menunjukkan pergeseran menuju fleksibilitas yang lebih besar dalam penerapannya. Konfirmasi Pembayaran Aman (SPC) berupaya untuk melanjutkan adaptasi ini, bertujuan untuk meningkatkan proses autentikasi pembayaran dengan menggabungkan interaksi yang lebih ramah pengguna dan mulus di berbagai situs merchant. Namun, kemajuan dan penerimaan yang lebih luas dari standar SPC atau Ekstensi Konfirmasi sangat bergantung pada adopsinya oleh browser-browser utama—sebuah proses yang lambat, dengan Google Chrome saat ini menjadi satu-satunya pendukung. Tingkat adopsi yang lambat ini berpotensi menghambat terutama SPC untuk bergerak melampaui keadaannya saat ini kecuali lebih banyak browser mulai mengintegrasikannya. Pengembangan yang sedang berlangsung dan daya tarik passkeys yang meningkat menunjukkan arah yang menjanjikan di mana sistem yang mengandalkan modul keamanan perangkat keras (HSM) seperti secure enclaves, TEE, dan TPM juga akan memainkan peran penting untuk aplikasi pembayaran karena teknologi ini menawarkan keamanan yang ditingkatkan yang dapat membuat penautan dinamis pembayaran lebih praktis & nyaman tidak hanya untuk transaksi yang dimulai di situs perbankan tetapi juga di platform merchant pihak ketiga. Potensi passkeys untuk memperluas kegunaannya ke proses pembayaran online menyoroti aspek penting dalam mengamankan transaksi berbasis web dan membuat Internet secara umum menjadi tempat yang lebih aman.