Penautan Dinamis dengan Passkeys: Konfirmasi Pembayaran Aman (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

Dalam seri empat bagian kami yang komprehensif (bagian 1, bagian 2, bagian 3 & bagian 4) tentang PSD2, kami telah menjelajahi bagaimana passkeys terintegrasi dengan langkah-langkah autentikasi pelanggan yang kuat (SCA) yang diperkenalkan oleh PSD2. Kami secara khusus berfokus pada elemen autentikasi yang disyaratkan oleh SCA untuk mengakses aplikasi perbankan. Persyaratan SCA tidak hanya berlaku untuk mengakses aplikasi tetapi juga untuk memulai dan menandatangani transaksi pembayaran 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.

Penautan dinamis adalah persyaratan keamanan di bawah direktif PSD2 dan adendum pelaksanaannya, Standar Teknis Regulasi (RTS). Konsep ini diperkenalkan untuk meningkatkan keamanan pembayaran elektronik dengan memastikan bahwa setiap transaksi terhubung secara unik ke jumlah tertentu dan penerima pembayaran tertentu melalui kode autentikasi. Keterkaitan ini mencegah modifikasi detail transaksi setelah diautentikasi oleh pembayar, sehingga mengurangi risiko penipuan. Pembayaran elektronik mencakup transfer bank dalam perangkat lunak perbankan online, serta pembayaran kartu kredit di situs merchant.

Menurut Direktif PSD2 dan RTS yang menyertainya, penautan dinamis didefinisikan sebagai proses yang memastikan bahwa "kode autentikasi yang dihasilkan spesifik untuk jumlah dan penerima pembayaran yang disetujui oleh pembayar saat memulai transaksi pembayaran elektronik" (Pasal 97(2) PSD2). Ini berarti bahwa setiap perubahan dalam detail pembayaran akan membatalkan kode autentikasi, sehingga memerlukan autentikasi ulang.

Penautan dinamis sangat penting dalam PSD2, karena secara langsung mengatasi risiko keamanan 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.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Perusahaan mempercayai Corbado untuk melindungi pengguna mereka dan membuat proses login lebih lancar dengan passkeys. Dapatkan konsultasi passkey gratis Anda sekarang.

Dapatkan konsultasi gratis

Mari kita analisis terlebih dahulu berbagai opsi bagaimana passkeys dapat digunakan 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.

Become part of our Passkeys Community for updates & support.

Join

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).

Mari kita analisis keterbatasan dan tantangan dari kedua opsi ini.

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.

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 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 dalam konteks pembayaran pihak pertama.

Apa itu Konteks Pembayaran Pihak Ketiga?

Dalam konteks pembayaran Pihak Ketiga, pengguna berada di halaman 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 menampilkan iframe di mana autentikasi dengan passkey dapat terjadi. IFRAME ditampilkan oleh proses 3-D Secure 2 (3DSS/EMV 3DS) yang sudah ada untuk transaksi kartu kredit yang perlu mendukung SCA dan penautan dinamis.

• ❌ Kasus 2 – Pengguna tidak memiliki passkey dari penerbit / bank mereka: Sekali lagi, merchant menampilkan iframe. Karena belum ada passkeys yang tersedia, pengguna diautentikasi oleh faktor autentikasi yang ada (misalnya SMS OTP atau aplikasi perbankan 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:

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 yang sedang berlangsung (yang akan tersedia secara umum pada akhir 2024). Namun, browser masih harus mengejar spesifikasi tersebut:

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.

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 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.

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 memanfaatkan browser untuk menyediakan pengalaman autentikasi yang konsisten dan efisien di berbagai situs merchant dan pihak yang mengandalkan. 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:

Contoh dari 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 harus terjadi dalam konteks pihak pertama, 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.

• 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 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 asli (penyedia akun, misalnya bank) untuk verifikasi.

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 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.

Mari kita lihat semua kemungkinan alur yang diizinkan oleh SPC dan membandingkannya dengan passkeys standar, agar kita memahami manfaatnya.

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.

Berikut adalah contoh mock-up pendaftaran passkey SPC langsung di halaman Mastercard. Seperti yang dapat Anda lihat di sini, pembuatan passkey ditawarkan tepat setelah penyelesaian autentikasi melalui SMS OTP dalam kasus ini.

Dalam kasus ini, komunikasi akan terlihat seperti proses pendaftaran passkeys standar karena ini terjadi sepenuhnya dalam konteks pihak pertama.

Diambil dari 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).

Seperti yang telah kita bahas sebelumnya, proses pendaftaran passkey SPC di situs web merchant biasanya akan terjadi selama transaksi pembayaran, dalam konteks alur 3-D 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 atau bank penerbit (misalnya mastercard.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 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 (misalnya PayPal) atau bank penerbit (misalnya mastercard.com). Oleh karena itu, passkey SPC dibuat dengan penerbit / bank secara langsung dan bukan merchant. Alur yang disederhanakan akan terlihat seperti ini:

Diambil dari https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Di 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:

Ini juga memungkinkan untuk bermain-main dengan situs bank secara langsung yang di-host di: 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.

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.

Asli dari (disesuaikan sebagian): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Asli dari (disesuaikan sebagian): 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.

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.

Tantangan yang diuraikan di atas, terutama seputar kesadaran pembayar, telah mendorong pekerjaan yang sedang berlangsung di Kelompok Kerja WebAuthn pada apa yang disebut ekstensi konfirmasi (sebelumnya dikenal sebagai “txAuthSimple”) dalam Standar WebAuthN. Tujuannya adalah untuk memungkinkan 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.

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 (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.

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:

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 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.

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.

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. 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.

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:

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.

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: 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 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.

Mengapa Passkeys penting?

Passkeys untuk Perusahaan

Kata sandi & phishing menempatkan perusahaan dalam risiko. Passkeys menawarkan satu-satunya solusi MFA yang menyeimbangkan keamanan dan UX. Whitepaper kami mencakup implementasi dan dampak bisnis.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

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.