Liên kết động với Passkeys: Xác nhận thanh toán an toàn (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

Trong loạt bài gồm bốn phần toàn diện của chúng tôi (phần 1, phần 2, phần 3 & phần 4) về PSD2, chúng tôi đã khám phá cách passkeys tích hợp với các biện pháp xác thực khách hàng mạnh (SCA) được giới thiệu bởi PSD2. Chúng tôi đã đặc biệt tập trung vào các yếu tố xác thực mà SCA yêu cầu để truy cập các ứng dụng ngân hàng. Các yêu cầu của SCA không chỉ áp dụng cho việc truy cập ứng dụng mà còn cho việc khởi tạo và ký các giao dịch thanh toán điện tử từ xa. Hơn nữa, các yêu cầu này đòi hỏi việc sử dụng một cơ chế được gọi là liên kết động. Trong bài viết này, chúng tôi sẽ giải thích về liên kết động và xem xét cách passkeys có thể được sử dụng hiệu quả để triển khai cơ chế này cả hiện tại và trong tương lai.

Liên kết động là một yêu cầu bảo mật theo chỉ thị PSD2 và phụ lục triển khai của nó là Tiêu chuẩn Kỹ thuật Quản lý (RTS). Khái niệm này được giới thiệu để tăng cường bảo mật cho các khoản thanh toán điện tử bằng cách đảm bảo rằng mỗi giao dịch được kết nối duy nhất với một số tiền cụ thể và một người thụ hưởng cụ thể bằng một mã xác thực. Sự liên kết này ngăn chặn bất kỳ sửa đổi nào đối với chi tiết giao dịch sau khi nó đã được người thanh toán xác thực, từ đó giảm nguy cơ gian lận. Các khoản thanh toán điện tử bao gồm chuyển khoản ngân hàng trong phần mềm ngân hàng trực tuyến cũng như các khoản thanh toán bằng thẻ tín dụng trên các trang web của nhà bán hàng.

Theo Chỉ thị PSD2 và RTS đi kèm, liên kết động được định nghĩa là một quy trình đảm bảo rằng "mã xác thực được tạo ra là dành riêng cho số tiền và người thụ hưởng đã được người thanh toán đồng ý khi khởi tạo giao dịch thanh toán điện tử" (Điều 97(2) của PSD2). Điều này có nghĩa là bất kỳ thay đổi nào trong chi tiết thanh toán sẽ làm mất hiệu lực của mã xác thực, đòi hỏi phải xác thực lại.

Liên kết động rất quan trọng trong PSD2, vì nó giải quyết trực tiếp các rủi ro bảo mật liên quan đến các giao dịch điện tử từ xa, vốn đặc biệt dễ bị tấn công bởi các loại gian lận khác nhau, chẳng hạn như tấn công xen giữa (man-in-the-middle).

Bằng cách bảo mật giao dịch theo cách này, liên kết động làm giảm đáng kể khả năng xảy ra các giao dịch trái phép.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Điều 5 của RTS mở rộng các yêu cầu đối với mã xác thực trong liên kết động. Các yêu cầu này bao gồm:

• Nhận thức của người thanh toán: Người thanh toán được biết về số tiền của giao dịch thanh toán và người thụ hưởng.

• Mã xác thực là duy nhất: Mã xác thực được tạo cho mỗi giao dịch phải là duy nhất và không thể tái sử dụng cho bất kỳ giao dịch nào khác.

• Mã xác thực là cụ thể: Các mã được tạo ra và mã được chấp nhận phải cụ thể cho số tiền của giao dịch và danh tính của người thụ hưởng như đã được người thanh toán xác nhận. Bất kỳ thay đổi nào về số tiền hoặc người thụ hưởng đều dẫn đến việc mã xác thực bị vô hiệu hóa.

• Truyền tải an toàn: Tính bảo mật, xác thực và toàn vẹn được duy trì cho số tiền của giao dịch và người thụ hưởng trong tất cả các giai đoạn của quá trình xác thực, bao gồm cả việc tạo, truyền và sử dụng mã xác thực.

Với các yêu cầu kỹ thuật này của liên kết động đã được đặt ra, trong phần tiếp theo, chúng ta sẽ xem passkeys có thể giúp ích như thế nào với tư cách là một công nghệ mới. Chúng ta sẽ khám phá tiềm năng của chúng trong việc hợp lý hóa và bảo mật các quy trình xác thực thanh toán, làm cho liên kết động không chỉ mạnh mẽ hơn mà còn thân thiện hơn với người dùng.

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.

Enterprises trust Corbado to protect their users and make logins more seamless with passkeys. Get your free passkey consultation now.

Get free consultation

Đầu tiên, hãy phân tích các lựa chọn khác nhau về cách passkeys có thể được sử dụng trong liên kết động.

Trong phương pháp này, chính passkey hoạt động như một xác nhận mật mã được sử dụng trực tiếp làm mã xác thực. Thử thách được đưa ra trong quá trình giao dịch được tạo ra để phản ánh cụ thể các chi tiết giao dịch, chẳng hạn như số tiền và người thụ hưởng, và được lưu trữ cùng với thông tin đó. Khi người dùng ủy quyền giao dịch bằng passkey của họ, một chữ ký duy nhất, an toàn về mặt mật mã sẽ được tạo ra, có thể được xác minh và lưu trữ cùng với giao dịch. Phản hồi này không chỉ đóng vai trò là một yếu tố xác thực mạnh mẽ mà còn liên kết trực tiếp sự chấp thuận với các chi tiết giao dịch cụ thể, tuân thủ nghiêm ngặt các yêu cầu của PSD2 về liên kết động.

Become part of our Passkeys Community for updates & support.

Join

Một cách tích hợp nâng cao hơn bao gồm việc mã hóa các chi tiết giao dịch bổ sung vào chính thử thách WebAuthn (về mặt kỹ thuật, điều này không bắt buộc bởi PSD2/RTS). Phương pháp này đề xuất kết hợp một hàm băm mật mã của người thụ hưởng và số tiền, cùng với dữ liệu ngẫu nhiên khác, vào thử thách. Bằng cách này, quy trình xác thực không chỉ xác minh danh tính của người dùng thông qua passkey mà còn xác nhận tính toàn vẹn của các chi tiết giao dịch bằng mật mã. Cách tiếp cận này cung cấp một lớp bảo mật bổ sung bằng cách đảm bảo rằng bất kỳ sự can thiệp nào vào số tiền hoặc chi tiết người thụ hưởng đều có thể bị phát hiện tại thời điểm thanh toán cuối cùng. Bằng chứng mật mã trở thành một phần không thể thay đổi của mã xác thực, tăng cường sự tin cậy và bảo mật trong môi trường giao dịch có rủi ro cao (thêm thông tin tại đây).

Chúng ta hãy phân tích những hạn chế và thách thức của hai lựa chọn này.

Một trong những hạn chế của việc sử dụng passkeys trong bối cảnh liên kết động, đặc biệt là để xác thực thanh toán, là thiếu tài liệu hoặc sự đảm bảo cụ thể rằng người thanh toán đã được thông báo chính xác về thông tin người thụ hưởng.

Trong khi passkeys cung cấp một phương thức an toàn để xác thực người dùng, chúng vốn không xác minh liệu tất cả các chi tiết giao dịch, đặc biệt là những chi tiết liên quan đến người thụ hưởng, đã được hiển thị chính xác cho người thanh toán hay chưa.

Vấn đề này không chỉ riêng với passkeys; đó là một thách thức chung trên các hệ thống thanh toán trực tuyến khác nhau. Việc đảm bảo người thanh toán nhận thức đầy đủ và đồng ý với tất cả các chi tiết giao dịch trước khi bắt đầu thanh toán là rất quan trọng để duy trì sự tin cậy và bảo mật.

Hạn chế đáng kể nhất của việc tích hợp passkeys vào liên kết động phát sinh từ sự phân biệt giữa đăng ký bên thứ nhất và bên thứ ba.

Bối cảnh thanh toán bên thứ nhất là gì?

✔️ Trong bối cảnh thanh toán Bên thứ nhất, người dùng tương tác trực tiếp với tổ chức phát hành / ngân hàng trên dịch vụ internet và tên miền của họ. Passkeys có thể được đăng ký và xác thực một cách liền mạch. Một ví dụ có thể là một ngân hàng đăng ký passkey trên trang web của riêng họ và sử dụng nó để ủy quyền khởi tạo thanh toán từ phần mềm ngân hàng trực tuyến của họ. Ở đây, passkeys hoạt động liền mạch. Ngân hàng có thể đảm bảo rằng passkey được sử dụng trong tên miền của mình, duy trì quyền kiểm soát môi trường thanh toán và bảo mật của giao dịch.

Vui lòng xem bài đăng trên blog của chúng tôi về việc triển khai passkey của Mastercard trong bối cảnh thanh toán bên thứ nhất.

Bối cảnh thanh toán bên thứ ba là gì?

Trong bối cảnh thanh toán Bên thứ ba, người dùng đang ở trên trang của nhà bán hàng trong quá trình thanh toán trên một tên miền khác (ví dụ: amazon.com) và muốn khởi tạo một giao dịch thẻ tín dụng:

• ✔️ Trường hợp 1 – Người dùng đã có passkey từ tổ chức phát hành / ngân hàng của họ: Nhà bán hàng hiển thị một iframe nơi việc xác thực bằng passkey có thể diễn ra. IFRAME được hiển thị bởi quy trình 3-D Secure 2 (3DSS/EMV 3DS) cơ bản đã có sẵn cho các giao dịch thẻ tín dụng cần hỗ trợ SCA và liên kết động.

• ❌ Trường hợp 2 – Người dùng chưa có passkey từ tổ chức phát hành / ngân hàng của họ: Một lần nữa, nhà bán hàng hiển thị iframe. Vì chưa có passkey nào, người dùng được xác thực bằng các yếu tố xác thực hiện có (ví dụ: SMS OTP hoặc ứng dụng ngân hàng gốc trên điện thoại thông minh của họ). Tại thời điểm này, sau khi xác thực thành công, đây sẽ là thời điểm lý tưởng để đăng ký passkey cho người dùng, nhưng điều này không được phép do các hạn chế của tiêu chuẩn WebAuthn. Việc đăng ký passkeys trong một iframe liên nguồn (cross-origin) không được phép (tên miền của trang chính và iframe cần phải giống hệt nhau). Việc đăng ký dần dần như trong ảnh chụp màn hình sau đây sẽ là không thể:

Việc đăng ký passkey trong iframe liên nguồn có được hỗ trợ trong tương lai không?

Trong khi passkeys cung cấp một giải pháp tốt cho liên kết động trong bối cảnh thanh toán bên thứ nhất trong một tên miền duy nhất, trong bối cảnh thanh toán bên thứ ba, chúng hiện không được hỗ trợ bởi WebAuthn Cấp 2. Tuy nhiên, tin tốt là hỗ trợ iframe liên nguồn đã được tích hợp vào đặc tả WebAuthn Cấp 3 đang diễn ra (sẽ được cung cấp rộng rãi vào cuối năm 2024). Tuy nhiên, các trình duyệt vẫn phải bắt kịp với đặc tả:

Tính đến hôm nay, có vẻ như đến năm 2024, việc hỗ trợ đăng ký passkeys liên nguồn (cross-origin) có thể trở thành hiện thực trên các trình duyệt lớn, điều này sẽ gỡ bỏ hạn chế kỹ thuật đáng kể nhất trong việc sử dụng passkeys cho thanh toán.

Đã có một số nỗ lực của các nhóm làm việc do Google khởi xướng tại W3C (ví dụ: BasicCard, PaymentHandler hoặc PaymentManifest) để cải thiện trải nghiệm thanh toán trên web. Cho đến nay, chưa có nỗ lực nào đạt được độ phủ thị trường và sử dụng đáng kể. Sự phức tạp trong quy trình thanh toán cho các giao dịch thương mại điện tử vẫn là một thách thức lớn với các quy định chống gian lận ngày càng tăng. Tiêu chuẩn Xác nhận thanh toán an toàn (Secure Payment Conformation) do Google & Stripe khởi xướng hiện là tiêu chuẩn hứa hẹn nhất được xây dựng dựa trên tiêu chuẩn WebAuthn.

Tiêu chuẩn Xác nhận thanh toán an toàn (SPC) giải quyết tất cả các yếu tố quan trọng của PSD2 SCA bao gồm yêu cầu liên kết động, và đồng thời cố gắng cải thiện trải nghiệm người dùng (UX).

• Cung cấp UX gốc của trình duyệt: SPC tận dụng trình duyệt để cung cấp trải nghiệm xác thực nhất quán và hợp lý trên các trang web của nhà bán hàng và các bên tin cậy khác nhau. Cách tiếp cận này nhằm tăng cường bảo mật giao dịch vượt ra ngoài những gì thường đạt được với nội dung được hiển thị trong iframe bằng cách có giao diện nhất quán và đảm bảo nhận thức của người thanh toán:

Ví dụ từ https://www.w3.org/press-releases/2023/spc-cr/

• Cung cấp Bằng chứng Mật mã: Tiêu chuẩn đảm bảo rằng bằng chứng mật mã về việc người dùng xác nhận chi tiết thanh toán được tạo ra và bao gồm trong xác nhận WebAuthn mà không cần mã hóa thông tin vào thử thách WebAuthn.

• Cho phép Đăng ký Bên thứ ba: Không giống như tiêu chuẩn WebAuthn Cấp 2, nơi việc đăng ký một trình xác thực phải diễn ra trong bối cảnh bên thứ nhất, SPC cho phép đăng ký passkeys trực tiếp từ một iframe liên nguồn. Khả năng này giải quyết các trường hợp sử dụng phổ biến trong hệ sinh thái thanh toán và tạo điều kiện tích hợp dễ dàng hơn cho các nhà bán hàng và bộ xử lý thanh toán. Như chúng ta đã thảo luận ở trên, chức năng này đã là một phần của phiên bản tiếp theo của tiêu chuẩn cơ bản và do đó có thể sẽ bị loại bỏ khỏi SPC trong tương lai.

• Xác thực thanh toán liên nguồn: SPC mở rộng tiện ích của WebAuthn bằng cách cho phép bất kỳ nguồn gốc nào tạo ra một xác nhận cho một giao dịch, ngay cả khi nó tận dụng thông tin xác thực từ một Bên tin cậy khác (mà không cần rời khỏi trang). Trong trường hợp này, thậm chí không cần một iframe từ nhà bán hàng / tổ chức phát hành. Tính năng này đặc biệt hữu ích trong các kịch bản có nhiều bên (nhà bán hàng + tổ chức phát hành / ngân hàng) tham gia vào quá trình xác thực và xác nhận sau đó có thể được chuyển đến Bên tin cậy ban đầu (nhà cung cấp tài khoản, ví dụ như một ngân hàng) để xác minh.

Ví dụ trên được lấy từ SPC Explainer và cho thấy khái niệm Xác thực thanh toán liên nguồn (Cross-Origin): Trong một quy trình thanh toán sử dụng SPC, người dùng vẫn ở trên trang web của nhà bán hàng (được tô màu xanh lam) trong suốt giao dịch. Trình duyệt web (màu xanh lá cây) duy trì việc hiển thị nguồn gốc của nhà bán hàng và cũng trình bày một hộp thoại được xác định trước, không thể tùy chỉnh với tất cả thông tin quan trọng cho liên kết động (số tiền + người thụ hưởng) để xác nhận giao dịch. Sau khi người dùng xác nhận, hệ điều hành (được mô tả bằng màu cam) xử lý việc xác thực sinh trắc học cần thiết để xác minh giao dịch.

Những mục tiêu này minh họa cam kết của SPC trong việc cải thiện cả bảo mật và trải nghiệm người dùng của thanh toán trực tuyến, nhằm mục đích đơn giản hóa các quy trình xác thực trong khi vẫn duy trì các tiêu chuẩn bảo mật cao trên toàn cảnh thanh toán kỹ thuật số.

Chúng ta hãy xem qua tất cả các luồng khả thi mà SPC sẽ cho phép và so sánh chúng với passkeys tiêu chuẩn, để chúng ta hiểu được những lợi ích.

Như chúng ta có thể thấy ở đây, sự khác biệt quan trọng nhất là việc đăng ký trên trang web của nhà bán hàng trong một iframe mà passkeys chưa hỗ trợ (xem thảo luận của chúng ta ở trên) và khả năng hoàn toàn mới của Xác thực liên nguồn (Cross-Origin). Chúng ta hãy xem xét từng cái một.

Đây là một ví dụ mô phỏng về việc đăng ký một SPC passkey trực tiếp trên trang của Mastercard. Như bạn có thể thấy ở đây, việc tạo passkey được đề xuất ngay sau khi hoàn thành xác thực qua SMS OTP trong trường hợp này.

Trong trường hợp này, giao tiếp sẽ trông giống như một quy trình đăng ký passkeys tiêu chuẩn vì điều này xảy ra hoàn toàn trong bối cảnh bên thứ nhất.

Lấy từ https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

SPC passkey này bây giờ có thể được sử dụng trên một trang web của nhà bán hàng để xác thực, trong một iframe trên trang của nhà bán hàng và cho Xác thực liên nguồn (xem bên dưới).

Như chúng ta đã thảo luận trước đây, quá trình đăng ký một SPC passkey trên trang web của nhà bán hàng thường sẽ xảy ra trong quá trình giao dịch thanh toán, trong bối cảnh của luồng 3-D Secure (3DS). Luồng này được thiết kế để tăng cường bảo mật cho các giao dịch thẻ tín dụng và thẻ ghi nợ trực tuyến bằng cách bao gồm một bước xác thực bổ sung để xác minh danh tính của chủ thẻ.

Trong một giao dịch thanh toán, khi luồng 3DS được khởi tạo, quá trình xác thực được thực hiện thông qua một iframe được lưu trữ trên trang web của nhà bán hàng (ví dụ: amazon.com) nhưng được kiểm soát bởi nhà cung cấp dịch vụ thanh toán hoặc ngân hàng phát hành (ví dụ: mastercard.com). Iframe này đóng vai trò là một môi trường an toàn để khách hàng xác thực danh tính của họ bằng các yếu tố xác thực hiện có.

Khi khách hàng xác thực thành công bằng các yếu tố thông thường này (ví dụ: SMS OTP hoặc ứng dụng ngân hàng), sẽ có cơ hội đăng ký một SPC passkey cho các giao dịch trong tương lai. Vì Tiêu chuẩn SPC cho phép tạo passkey liên nguồn từ bên trong iframe, điều này sẽ hoạt động. Việc đăng ký passkey này trong iframe thường sẽ liên quan đến việc khách hàng thực hiện một hành động tạo và liên kết passkey với thẻ tín dụng của họ, chẳng hạn như xác minh vân tay hoặc nhận dạng khuôn mặt trên một thiết bị tương thích. Hãy nhớ rằng iframe được kiểm soát bởi nhà cung cấp dịch vụ thanh toán (ví dụ: PayPal) hoặc ngân hàng phát hành (ví dụ: mastercard.com). Do đó, SPC passkey được tạo trực tiếp với tổ chức phát hành / ngân hàng chứ không phải nhà bán hàng. Luồng đơn giản hóa sẽ trông như thế này:

Lấy từ https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Tại https://spc-merchant.glitch.me/, Google đã thiết lập một ứng dụng demo có thể được truy cập qua Chrome trên Windows và Mac, minh họa cách thức hoạt động này từ bên trong một iframe:

Nó cũng cho phép thử nghiệm trực tiếp với trang web của ngân hàng được lưu trữ tại: https://spc-rp.glitch.me/reauth. Trong ví dụ này, không cần giao tiếp ngoài luồng với các API giữa nhà bán hàng và tổ chức phát hành / ngân hàng – mọi thứ đều được xử lý bởi trình duyệt. Việc xác thực bằng một passkey hiện có sẽ hoạt động theo cùng một cách từ bên trong iframe.

Trong ví dụ sau, chúng ta thấy Xác thực liên nguồn nơi người dùng đã đăng ký một SPC Passkey với Mastercard. Trang web của nhà bán hàng ví dụ (decorshop.com) có thể kích hoạt Xác thực liên nguồn. Sự khác biệt lớn và quan trọng là trang của nhà bán hàng / tổ chức phát hành không bao giờ hiển thị trong quá trình xác thực. Trình duyệt kết hợp với hệ điều hành trình bày UX thanh toán được xác định trước (do việc triển khai tiêu chuẩn SPC của trình duyệt cung cấp) và cửa sổ xác thực (tiêu chuẩn WebAuthn). Giao tiếp giữa nhà bán hàng và tổ chức phát hành / ngân hàng được xử lý ở chế độ nền.

Nguồn gốc từ (đã điều chỉnh một phần): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Nguồn gốc từ (đã điều chỉnh một phần): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Khi sử dụng Xác thực liên nguồn, nhà bán hàng giao tiếp với tổ chức phát hành / ngân hàng thông qua một số dạng API để trao đổi thông tin về các thông tin xác thực hiện có (#2 trong biểu đồ tuần tự ở trên). Nếu thông tin xác thực tồn tại và trình duyệt của người dùng hỗ trợ SPC, quá trình xác thực sẽ bắt đầu. Cuối cùng, xác nhận được trả về cho tổ chức phát hành / ngân hàng thông qua các giao thức hiện có như EMV 3DS, nơi xác nhận có thể được xác minh mật mã cuối cùng (#16).

Vì xác nhận cũng bao gồm thông tin về thông tin được hiển thị bởi trình duyệt, tất cả các yêu cầu về liên kết động đều được đáp ứng. Đây sẽ là một bước tiến lớn về mặt UX và cải thiện trải nghiệm thanh toán của khách hàng.

Tiêu chuẩn Xác nhận thanh toán an toàn (SPC) là một sự phát triển thú vị trong thế giới xác thực thanh toán trực tuyến, nhằm tăng cường bảo mật đồng thời hợp lý hóa trải nghiệm người dùng. Tính đến hôm nay, Google Chrome là trình duyệt lớn duy nhất hỗ trợ SPC ở một số dạng. Tuy nhiên, điều này không có gì đáng ngạc nhiên vì tiêu chuẩn này một phần do Google khởi xướng. Từ các trình duyệt lớn khác như Safari của Apple và Mozilla Firefox, có một sự thiếu cam kết đáng chú ý mà không có tín hiệu rõ ràng nào về kế hoạch hỗ trợ SPC của họ. Cụ thể, Apple đang thúc đẩy Tiêu chuẩn độc quyền của riêng mình là Apple Pay và dường như không quan tâm đến các tiêu chuẩn thanh toán khác.

Sự kết nối của SPC với WebAuthn đã làm cho quá trình phát triển trở nên khó khăn hơn. Điều này là do bất kỳ cải tiến hoặc sửa đổi nào trong tiêu chuẩn SPC đều cần được đánh giá cẩn thận để ngăn chặn sự dư thừa và đảm bảo chúng cung cấp những cải tiến thực sự so với các khả năng hiện có. Mục tiêu là tinh chỉnh SPC để phục vụ các nhu cầu cụ thể trong quy trình thanh toán mà WebAuthn chưa hoàn toàn bao phủ, chẳng hạn như tích hợp trực tiếp vào luồng thanh toán và cung cấp trải nghiệm xác thực thân thiện với người dùng hơn có thể hoạt động liền mạch trên các trang web của nhà bán hàng khác nhau.

Khi SPC tiếp tục phát triển, việc áp dụng nó trên các trình duyệt khác nhau sẽ rất quan trọng cho việc triển khai rộng rãi. Sự tham gia của các công ty lớn như Google cho thấy một hướng đi tích cực, nhưng sự hỗ trợ rộng rãi hơn sẽ là cần thiết để thiết lập SPC như một tiêu chuẩn trong ngành công nghiệp thanh toán trực tuyến.

Những thách thức được nêu ở trên, đặc biệt là về nhận thức của người thanh toán, đã thúc đẩy công việc đang diễn ra trong Nhóm làm việc WebAuthn về một cái gọi là tiện ích mở rộng xác nhận (trước đây gọi là “txAuthSimple”) trong Tiêu chuẩn WebAuthN. Mục đích của nó là cho phép trình xác thực hoặc trình duyệt/HĐH (trong một giao diện người dùng đặc quyền) hiển thị chi tiết giao dịch cho người dùng và đảm bảo rằng bên tin cậy nhận được bằng chứng mật mã rằng người dùng thực sự đã xác nhận những chi tiết này. Điều này giải quyết trực tiếp vấn đề “thiếu sự đảm bảo về nhận thức của người dùng” được mô tả trong phần 3.3.1.

Tương tự như cách Xác nhận thanh toán an toàn (SPC) cung cấp một hộp thoại chuyên dụng, do trình duyệt điều khiển, tiện ích mở rộng xác nhận giải quyết mối quan tâm “Những gì bạn thấy là những gì bạn ký” (WYSIWYS). Các mục tiêu chính của nó là:

• Hiển thị chi tiết giao dịch đáng tin cậy: Thay vì để nội dung web hiển thị số tiền và người thụ hưởng, tiện ích mở rộng tận dụng màn hình an toàn của thiết bị hoặc hộp thoại giao diện người dùng của trình duyệt dưới sự kiểm soát của HĐH.
• Bằng chứng mật mã: Trình xác thực (hoặc nền tảng máy khách) ký một bản ghi về văn bản chính xác được hiển thị. Bằng cách xác minh chữ ký này, bên tin cậy có thể xác nhận rằng người dùng đã được hiển thị các chi tiết chính xác.
• Phương án dự phòng nếu Trình xác thực không hỗ trợ hiển thị: Trong trường hợp trình xác thực phần cứng không thể hiển thị văn bản, trình duyệt có thể hiển thị nó và bao gồm nó trong [=dữ liệu máy khách=]. Đây là một sự đảm bảo yếu hơn nhưng cho phép khả năng tương thích rộng hơn.

Tiện ích mở rộng thêm một trường mới vào các cấu trúc tiện ích mở rộng WebAuthn hiện có. Các Bên tin cậy cung cấp một chuỗi văn bản đơn giản (với định dạng cơ bản tùy chọn) được gọi là confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Khi máy khách (trình duyệt) nhận được điều này, nó sẽ:

1. Nhắc người dùng bằng một hộp thoại xác nhận đặc biệt (để họ biết đây không chỉ là một lần đăng nhập cơ bản).
2. Chuyển cùng một chuỗi đó đến trình xác thực dưới dạng dữ liệu CBOR nếu trình xác thực hỗ trợ tiện ích mở rộng.
3. Trả về bất kỳ đầu ra nào của trình xác thực cho Bên tin cậy.

Nếu trình xác thực hỗ trợ hiển thị văn bản, nó phải hiển thị văn bản đó (ví dụ: trên màn hình riêng hoặc giao diện người dùng đáng tin cậy) trước khi hoàn thành xác minh người dùng. Sau đó, nó bao gồm cùng một chuỗi trong đầu ra đã ký của mình.

Ở phía Bên tin cậy, các bước xác minh đảm bảo rằng văn bản confirmation được trả về khớp với những gì đã được gửi. Nếu đầu ra của tiện ích mở rộng trình xác thực bị thiếu nhưng chính sách của Bên tin cậy cho phép một phương án dự phòng, Bên tin cậy có thể dựa vào giá trị confirmation từ dữ liệu máy khách—cho biết trình duyệt đã hiển thị văn bản thay vì trình xác thực.

Bằng cách nhúng người thụ hưởng và số tiền vào tiện ích mở rộng này, người dùng sẽ thấy chính xác những gì họ đang ủy quyền trên một màn hình đáng tin cậy. Chữ ký của người dùng bây giờ không chỉ phản ánh một thử thách đã được băm mà còn cả văn bản giao dịch chính xác. Điều này đặc biệt có giá trị đối với yêu cầu liên kết động của PSD2, vì:

• Bất kỳ sự không khớp hoặc sửa đổi nào của chi tiết giao dịch sau khi hiển thị đều làm mất hiệu lực của chữ ký.
• Bên tin cậy có thể chứng minh rằng người dùng đã được cung cấp các chi tiết giao dịch chính xác tại thời điểm ký, đáp ứng yêu cầu “nhận thức của người thanh toán” của PSD2 một cách mạnh mẽ hơn nhiều so với việc chỉ băm dữ liệu trong thử thách.

Trong khi tiện ích mở rộng xác nhận vẫn đang được thảo luận, nó đại diện cho một bước quan trọng hướng tới các luồng giao dịch an toàn và thân thiện với người dùng hơn. Bằng cách xây dựng nó trực tiếp vào đặc tả WebAuthn, nó cung cấp:

• Khả năng tương tác: Bất kỳ trình xác thực hoặc máy khách nào triển khai tiện ích mở rộng sẽ tuân theo cùng một định dạng được tiêu chuẩn hóa.
• Tính linh hoạt: Các Bên tin cậy có thể thực thi các chính sách mạnh mẽ hơn (yêu cầu hiển thị ở cấp độ trình xác thực) hoặc chấp nhận phương án dự phòng ở cấp độ trình duyệt nếu cần.
• Sự phù hợp với hệ sinh thái rộng lớn hơn: Nó phù hợp tốt với các quy định bắt buộc như PSD2, đặc biệt là về liên kết động mạnh mẽ.

Để biết thêm chi tiết kỹ thuật, bạn có thể xem cuộc thảo luận đang diễn ra: yêu cầu kéo GitHub #2020. Tóm lại, tiện ích mở rộng xác nhận cũng có thể lấp đầy khoảng trống lớn cuối cùng trong các luồng dựa trên passkey tiêu chuẩn: cung cấp bằng chứng mật mã về chính xác những gì người dùng đã thấy khi họ đồng ý, mặc dù ít cấu trúc hơn so với Xác nhận thanh toán an toàn. Nếu nó được các trình duyệt và nhà cung cấp trình xác thực chấp nhận, nó có thể trở thành một phương pháp được tiêu chuẩn hóa cao để cung cấp sự đảm bảo bảo mật WYSIWYS cần thiết theo liên kết động của PSD2—và hơn thế nữa.

Mặc dù SPC và tiện ích mở rộng xác nhận có chung mục tiêu là tăng cường liên kết động trong WebAuthn, chúng khác nhau về phạm vi và cách tiếp cận. Bảng dưới đây nêu bật một số khác biệt này:

Về bản chất, SPC cố gắng cung cấp một giải pháp thanh toán toàn diện* và cũng kết hợp liên kết động* như một phần của luồng của nó. Trong khi đó, tiện ích mở rộng xác nhận* giải quyết yêu cầu “những gì bạn thấy là những gì bạn ký” trong các thông điệp WebAuthn tiêu chuẩn mà không áp đặt một luồng thanh toán đầy đủ. Cả hai cách tiếp cận đều có thể tạo điều kiện cho việc tuân thủ PSD2, nhưng mỗi cách đều phụ thuộc vào sự hỗ trợ của trình duyệt và trình xác thực để mang lại lợi ích trong thế giới thực.

Do đó, khuyến nghị của chúng tôi dành cho các tổ chức phát hành, ngân hàng và tổ chức tài chính là phải đánh giá cẩn thận các trường hợp sử dụng cần được bao phủ và theo dõi sự phát triển của hệ sinh thái vì sự dễ dàng của passkeys sẽ gây áp lực đáng kể lên các giải pháp SCA & liên kết động hiện có để cải thiện UX của chúng. Khách hàng sẽ yêu cầu các giải pháp sinh trắc học trên web. Hiện tại, khuyến nghị hoạt động của chúng tôi là:

• ✔️ Passkeys cho các thanh toán được khởi tạo trên trang web của Tổ chức phát hành / Ngân hàng: Passkeys là một giải pháp rất tốt để các tổ chức phát hành / ngân hàng triển khai liên kết động trực tiếp vào trang web & ứng dụng của họ. Chúng có thể được kết hợp với các tùy chọn xác thực khác như thông báo đẩy, email / SMS OTP hoặc TOTP để tăng cường bảo mật hơn nữa cho các khoản thanh toán có rủi ro cao. Tất nhiên, các cân nhắc về việc tuân thủ SCA phải luôn là một phần của cuộc thảo luận này (xem thêm loạt bài 4 phần của chúng tôi về passkeys & SCA).

  Một giải pháp được đề xuất có thể được các tổ chức phát hành / ngân hàng tự triển khai vì passkeys dựa trên tiêu chuẩn mở WebAuthn. Tuy nhiên, điều này đòi hỏi kiến thức chuyên môn đáng kể, xử lý các trường hợp đặc biệt và liên tục cập nhật tất cả các quy định và phát triển kỹ thuật mới. Giải pháp thay thế là sử dụng nhà cung cấp xác thực của bên thứ ba. Ví dụ, Corbado Connect hỗ trợ liên kết động thông qua ký giao dịch, tận dụng các thử thách WebAuthn đã được điều chỉnh. Tất cả thông tin được ghi lại trong nhật ký kiểm toán. Điều này không chỉ hữu ích cho các tổ chức tài chính mà còn có thể được tận dụng cho tất cả các loại chữ ký (ví dụ: ký tài liệu, các hành động của người dùng có rủi ro cao). Tùy chọn, có thể sử dụng thêm SMS hoặc E-Mail OTP để cải thiện bảo mật hơn nữa.

• ❌ Passkeys cho các thanh toán trên trang của Nhà bán hàng: Việc triển khai passkeys cho các thanh toán trên trang của nhà bán hàng vẫn chưa thể thực hiện được. Các trường hợp sử dụng liên nguồn vẫn đang được phát triển nhưng có thể là một lựa chọn khả thi vào cuối năm 2024. Tuy nhiên, việc sử dụng passkeys để xác thực trên các trang của nhà bán hàng đã là một ý tưởng tuyệt vời ngay hôm nay và cũng có thể được sử dụng để bắt đầu thu thập passkeys mà sau này cũng có thể được sử dụng cho thanh toán.

• ❌ SPC Passkeys hoặc Tiện ích mở rộng xác nhận cho Liên kết động: Tiêu chuẩn SPC chưa đạt đến trạng thái hoàn thiện & hỗ trợ để được sử dụng trong môi trường sản xuất.

Nhìn chung, chúng tôi rất vui khi thấy các nhà bán hàng và ngân hàng đã bắt đầu tham gia vào tiêu chuẩn và bổ sung các yêu cầu cũng như sự hỗ trợ của họ cho hệ sinh thái. Nhìn về phía trước, các tổ chức tài chính và các nền tảng thương mại điện tử nên theo dõi chặt chẽ những tiến bộ công nghệ này và xem xét cách họ có thể tích hợp passkeys vào hệ thống của mình. Khi các quy định tiếp tục phát triển, điều quan trọng là phải đi trước đón đầu, đảm bảo rằng các quy trình xác thực thanh toán phù hợp với các tiêu chuẩn bảo mật mới nhất và cung cấp trải nghiệm người dùng an toàn, hiệu quả cho người tiêu dùng, giúp cải thiện tỷ lệ chuyển đổi & giảm bớt sự phức tạp.

Tại sao Passkeys lại quan trọng?

Passkeys cho Doanh nghiệp

Mật khẩu & lừa đảo trực tuyến (phishing) đặt doanh nghiệp vào tình thế rủi ro. Passkeys cung cấp giải pháp MFA duy nhất cân bằng giữa bảo mật và UX. Sách trắng của chúng tôi bao gồm việc triển khai và tác động kinh doanh.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Khi chúng ta xem xét passkeys cho liên kết động, rõ ràng là trong khi passkeys có thể giúp tuân thủ SCA & liên kết động, việc tích hợp kỹ thuật trong các dịch vụ của bên thứ ba với tiêu chuẩn WebAuthn, vốn ban đầu được thiết kế cho bối cảnh bên thứ nhất, lại đặt ra một số thách thức. Các tiêu chuẩn này đang dần phát triển để hỗ trợ tốt hơn các kịch bản của bên thứ ba, cho thấy một sự chuyển dịch hướng tới sự linh hoạt hơn trong ứng dụng của chúng. Xác nhận thanh toán an toàn (SPC) tìm cách thúc đẩy sự thích ứng này hơn nữa, nhằm mục đích tăng cường các quy trình xác thực thanh toán bằng cách kết hợp các tương tác thân thiện và liền mạch hơn trên các trang web của nhà bán hàng khác nhau.

Tuy nhiên, sự tiến bộ và chấp nhận rộng rãi hơn của tiêu chuẩn SPC hoặc Tiện ích mở rộng Xác nhận phụ thuộc rất nhiều vào việc áp dụng của các trình duyệt lớn—một quá trình đã diễn ra chậm chạp, với Google Chrome hiện là trình duyệt duy nhất hỗ trợ. Tốc độ áp dụng chậm này có thể cản trở đặc biệt là SPC vượt ra khỏi trạng thái hiện tại của nó trừ khi có nhiều trình duyệt hơn bắt đầu tích hợp nó. Sự phát triển liên tục và sức hút ngày càng tăng của passkeys cho thấy một hướng đi đầy hứa hẹn, nơi các hệ thống dựa trên các mô-đun bảo mật phần cứng (HSM) như secure enclaves, TEE và TPM cũng sẽ đóng một vai trò quan trọng cho các ứng dụng thanh toán vì các công nghệ này cung cấp bảo mật nâng cao có thể làm cho việc liên kết động các khoản thanh toán trở nên thiết thực và thoải mái hơn không chỉ cho các giao dịch được khởi tạo trên các trang web ngân hàng mà còn trên các nền tảng của nhà bán hàng bên thứ ba.

Tiềm năng của passkeys trong việc mở rộng tiện ích của chúng sang các quy trình thanh toán trực tuyến nêu bật một khía cạnh quan trọng trong việc bảo mật các giao dịch dựa trên web và làm cho Internet nói chung trở thành một nơi an toàn hơn.