---
url: 'https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan'
title: 'Sinh trắc học và Nhận thức của người thanh toán trong Liên kết động'
description: 'Nhận thức của người thanh toán qua sinh trắc học theo liên kết động PSD2: cách sinh trắc học cục bộ + PKI và passkey đáp ứng tuân thủ, với hướng dẫn và các phương pháp tốt nhất từ EBA/RTS.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2025-10-02T15:13:56.504Z'
lastModified: '2026-03-25T10:49:03.040Z'
keywords: 'sinh trắc học, nhận thức người thanh toán'
category: 'Passkeys Strategy'
---

# Sinh trắc học và Nhận thức của người thanh toán trong Liên kết động

## Tóm tắt dành cho nhà quản lý: Sinh trắc học & Nhận thức của người thanh toán trong Liên kết động

Phương pháp của Corbado kết hợp passkey chống [phishing](https://www.corbado.com/glossary/phishing) (SCA) với màn
hình hiển thị do ngân hàng kiểm soát và
[liên kết động](https://www.corbado.com/vi/blog/lien-ket-dong-passkeys-spc) phía máy chủ để đáp ứng Điều 5 của
[PSD2 RTS](https://www.corbado.com/faq/sca-rts-technical-standards) (“những-gì-bạn-thấy-là-những-gì-bạn-ký”).

- **Triển khai cốt lõi (hiện tại):** Chúng tôi hiển thị **số tiền và người thụ hưởng** của
  giao dịch trong giao diện người dùng (UI) do Bison‑Bank kiểm soát ngay trước và trong
  khi xác thực bằng passkey. Backend của chúng tôi tạo ra một **thử thách dùng một lần**
  được **ràng buộc với một bản ghi chính tắc của giao dịch** (số tiền, người thụ hưởng,
  txnId). Phản hồi chỉ được chấp nhận nếu khớp với bản ghi đó; **bất kỳ thay đổi nào cũng
  làm mất hiệu lực** của nó.

- **Quan điểm pháp lý:** **Liên kết động vẫn là yêu cầu bắt buộc** cho các
  [khoản thanh toán](https://www.corbado.com/passkeys-for-payment) từ xa ngay cả khi sử dụng passkey (PSD2 Điều
  97(2); RTS Điều 5). RTS **không yêu cầu** “mã xác thực” của
  [liên kết động](https://www.corbado.com/vi/blog/lien-ket-dong-passkeys-spc) phải được tính toán trên thiết bị;
  việc tạo/xác thực phía máy chủ là chấp nhận được khi **tính toàn vẹn của hiển thị**,
  **tính cụ thể** và **vô hiệu hóa khi có thay đổi** được thực thi (xem thêm EBA Q\&A
  2020_5366 về nơi mã có thể được tính toán).

- **Bảo mật & khả năng kiểm toán:** Ràng buộc một chữ ký passkey **dựa trên phần cứng,
  chống phishing** với dữ liệu giao dịch cụ thể sẽ **ngăn chặn việc giả mạo và chuyển
  tiếp**, và tạo ra **bằng chứng mạnh mẽ, không thể chối cãi** về sự đồng ý của người
  [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet). Khi được
  hỗ trợ, chúng tôi có thể tùy chọn áp dụng **Xác nhận Thanh toán An toàn (Secure Payment
  Confirmation - SPC)** để thêm **bằng chứng mã hóa về các chi tiết đã hiển thị** mà không
  thay đổi mô hình backend.

> **Làm rõ:** Passkey loại bỏ [phishing](https://www.corbado.com/glossary/phishing) chéo nguồn gốc (chúng chỉ
> hoạt động trên trang web/ứng dụng mà chúng được tạo ra). **Liên kết động** đảm bảo rằng
> **chính xác những gì người thanh toán đã phê duyệt** (số tiền + người thụ hưởng) là
> những gì ngân hàng thực hiện.

## 1. PSD2 SCA & liên kết động

- **SCA**: Hai yếu tố độc lập từ các loại riêng biệt (kiến thức/sở hữu/vốn có), được bảo
  vệ chống lại việc tiết lộ/sao chép với các biện pháp giảm thiểu phù hợp (RTS Điều 6–8).
  Yêu cầu tính độc lập (Điều 9), bao gồm cả việc tách biệt khi thực hiện trên các thiết bị
  đa năng (ví dụ: bảo vệ cấp hệ điều hành, phần cứng
  [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android)).
- **Liên kết động (RTS Điều 5)**:
    - (i) người
      [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet) được
      biết về số tiền và người thụ hưởng trong quá trình xác thực
    - (ii) mã xác thực là duy nhất cho số tiền/người thụ hưởng đó
    - (iii) bất kỳ thay đổi nào cũng làm mã không hợp lệ
    - (iv) tính [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android)/toàn vẹn của số tiền,
      người thụ hưởng và mã được bảo vệ từ đầu đến cuối. Điều này mang lại ý định pháp lý
      “những-gì-bạn-thấy-là-những-gì-bạn-ký”.
- **Hàm ý**: Chỉ xác thực người dùng mạnh là không đủ cho các
  [khoản thanh toán](https://www.corbado.com/passkeys-for-payment). Sự chấp thuận phải được ràng buộc với dữ liệu
  giao dịch cụ thể với bằng chứng có thể kiểm toán về sự ràng buộc và việc hiển thị cho
  người [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet) (RTS
  Điều 5(1)(a–d)).

**Làm rõ — phishing và ủy quyền:** Passkey được ràng buộc với nguồn gốc, vì vậy các tên
miền giả mạo không thể lấy được chữ ký hợp lệ. Tuy nhiên, [PSD2](https://www.corbado.com/blog/psd2-passkeys) vẫn
yêu cầu **liên kết động** cho các [khoản thanh toán](https://www.corbado.com/passkeys-for-payment) từ xa để ràng
buộc _sự ủy quyền_ với **số tiền và người thụ hưởng chính xác** nhằm **vô hiệu hóa bất kỳ
thay đổi nào** và để **bảo vệ tính toàn vẹn** của những gì được hiển thị cho người thanh
toán (RTS Điều 5(1)(a–d)). [Liên kết động](https://www.corbado.com/vi/blog/lien-ket-dong-passkeys-spc) giải quyết
tính toàn vẹn của việc ủy quyền (bao gồm cả việc thay thế MITM/MITB/TPP), chứ không chỉ
[phishing](https://www.corbado.com/glossary/phishing).

### 1.1 Nền tảng lý thuyết — văn bản pháp lý và hướng dẫn

> [PSD2](https://www.corbado.com/blog/psd2-passkeys) Điều 97(2): “Đối với việc khởi tạo các giao dịch thanh toán
> điện tử, các Quốc gia Thành viên phải đảm bảo rằng người thanh toán có quyền truy cập
> vào các thủ tục [xác thực khách hàng mạnh](https://www.corbado.com/blog/psd2-sca-requirements) bao gồm các yếu
> tố liên kết động giao dịch với một số tiền cụ thể và một người thụ hưởng cụ thể.”
> [PSD2 Điều 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> RTS Điều 5:
> “[Nhà cung cấp dịch vụ thanh toán](https://www.corbado.com/vi/blog/passkeys-cho-nha-cung-cap-thanh-toan-sdk-ben-thu-ba)
> phải đảm bảo rằng mã xác thực được tạo ra là cụ thể cho số tiền của giao dịch thanh toán
> và người thụ hưởng đã được người thanh toán đồng ý khi khởi tạo giao dịch; 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à việc xác thực
> được cấp; mã xác thực được
> [nhà cung cấp dịch vụ thanh toán](https://www.corbado.com/vi/blog/passkeys-cho-nha-cung-cap-thanh-toan-sdk-ben-thu-ba)
> chấp nhận tương ứng với số tiền ban đầu của giao dịch thanh toán và danh tính của người
> thụ hưởng đã được người thanh toán đồng ý khi khởi tạo giao dịch; bất kỳ thay đổi nào
> đối với số tiền hoặc người thụ hưởng sẽ dẫn đến việc mã xác thực bị vô hiệu hóa; tính
> [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android), xác thực và toàn vẹn của số tiền và
> của người thụ hưởng được bảo vệ.”
> [RTS Điều 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

Ý kiến của EBA năm 2019 (EBA‑Op‑2019‑06) củng cố rằng liên kết động ràng buộc việc xác
thực với số tiền và người thụ hưởng, yêu cầu sự độc lập của các yếu tố và chấp nhận các
khóa mã hóa ràng buộc với thiết bị là yếu tố sở hữu khi có sự ràng buộc thiết bị duy nhất.
Nó cũng nhấn mạnh tính toàn vẹn của những gì được hiển thị cho người thanh toán trong quá
trình xác thực. [Ý kiến của EBA 2019](https://www.eba.europa.eu)

### 1.2 Lịch sử của liên kết động

![lịch sử liên kết động](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

Trước khi có [PSD2](https://www.corbado.com/blog/psd2-passkeys), nhiều ngân hàng dựa vào OTP qua SMS hoặc danh
sách TAN được in ra giấy mà thường không hiển thị số tiền hoặc người thụ hưởng cùng với
bước phê duyệt. Lỗ hổng đó đã giúp kẻ gian dễ dàng lừa khách hàng ủy quyền cho các giao
dịch chuyển tiền không mong muốn một khi thông tin đăng nhập bị đánh cắp. Liên kết động
được giới thiệu để lấp đầy lỗ hổng đó bằng cách đảm bảo người thanh toán nhận biết được số
tiền và người thụ hưởng chính xác tại thời điểm xác thực và bằng cách làm cho mã xác thực
cụ thể cho các chi tiết đó để bất kỳ thay đổi nào cũng làm mất hiệu lực của nó (RTS Điều
5(1)(a–d)). Khi SMS là một phần của quy trình, các tổ chức phát hành cũng phải đảm bảo
tính bảo mật, xác thực và toàn vẹn của số tiền/người thụ hưởng và mã trong tất cả các giai
đoạn xác thực (Q\&A 2018_4414; RTS Điều 5(2)). Các phương thức phê duyệt trong ứng dụng
ngày nay (ví dụ: “Bạn có muốn ủy quyền 100 USD cho John Smith qua
[Face ID](https://www.corbado.com/faq/is-face-id-passkey) không?”) thực hiện nguyên tắc “những gì bạn thấy là
những gì bạn ký” này một cách thân thiện với khách hàng.

### 1.3 Liên kết động ngày nay: thông báo đẩy trên ứng dụng và sinh trắc học cục bộ

![thông báo đẩy liên kết động](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

Ngày nay, trên di động, có hai mô hình chiếm ưu thế. Đầu tiên, một thông báo đẩy có thể
liên kết sâu (deep-link) khách hàng vào ứng dụng để xem lại chi tiết giao dịch và phê
duyệt. Các cơ quan giám sát đã làm rõ rằng thông báo đẩy có thể dùng làm bằng chứng cho
yếu tố sở hữu nếu các biện pháp kiểm soát của Điều 7 được áp dụng để giảm thiểu việc sử
dụng trái phép và ngăn chặn sao chép, và toàn bộ hành trình tuân thủ RTS; tuy nhiên, rủi
ro tấn công phi kỹ thuật vẫn còn và cần được giải quyết trong UX (Q\&A 2019_4984; RTS Điều
7\).

![sinh trắc học cục bộ liên kết động](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

Thứ hai, việc phê duyệt sử dụng sinh trắc học gốc của thiết bị (với phương án dự phòng là
mã PIN) thực hiện xác minh người dùng cục bộ để mở khóa một hoạt động khóa riêng. Khóa
riêng nằm trong một môi trường phần cứng an toàn (Secure Enclave/TEE/TPM) và ký vào một
thử thách. Điều này tương ứng rõ ràng với [SCA](https://www.corbado.com/vi/blog/passkeys-va-psd2): yếu tố vốn có
(sinh trắc học) cộng với yếu tố sở hữu được chứng minh bằng việc ràng buộc thiết bị và một
khóa mã hóa ràng buộc với thiết bị (EBA‑Op‑2019‑06, đoạn 25, 35–37). Đối với các khoản
thanh toán từ xa, mã phải được liên kết động với số tiền và người thụ hưởng và các chi
tiết đó phải được hiển thị cho người thanh toán trước khi xác minh người dùng (RTS Điều
5\). Nếu cả hai yếu tố đều trên một thiết bị, hãy triển khai các môi trường thực thi an
toàn riêng biệt và kiểm tra tính toàn vẹn để việc xâm phạm một yếu tố không làm xâm phạm
yếu tố kia (RTS Điều 9(2)–(3)).

### 1.4 Cách sinh trắc học cục bộ với PKI thực hiện liên kết động

Về bản chất, sinh trắc học cục bộ không “xác thực với ngân hàng” một cách trực tiếp. Thay
vào đó, sinh trắc học (hoặc mã PIN dự phòng) thực hiện xác minh người dùng trên thiết bị
và kiểm soát quyền truy cập vào một khóa riêng không thể xuất được lưu trữ trong một
mô-đun bảo mật dựa trên phần cứng. Khi người thanh toán phê duyệt, thiết bị sử dụng khóa
riêng đó để tạo ra một chữ ký số trên một thử thách do ngân hàng cung cấp. Nếu ngân hàng
lấy hoặc liên kết thử thách đó với một bản ghi chính tắc của giao dịch (số tiền, người thụ
hưởng, mã định danh), thì chữ ký kết quả sẽ hoạt động như một mã xác thực cụ thể cho các
chi tiết đó. Bất kỳ thay đổi nào cũng sẽ làm mất hiệu lực của mã vì bản ghi được lưu trữ
không còn khớp nữa, hoặc, trong các thiết kế nâng cao, vì việc tạo thử thách thay đổi.
Phần nhận thức của người thanh toán vẫn là một yêu cầu về UX: hiển thị số tiền và người
thụ hưởng trong một giao diện do ngân hàng kiểm soát ngay trước khi xác minh người dùng.
Cùng với nhau, điều này thỏa mãn các yêu cầu của RTS Điều 5 về nhận thức, tính cụ thể/duy
nhất và vô hiệu hóa khi có thay đổi, trong khi các biện pháp kiểm soát của Điều 7 và bằng
chứng ràng buộc thiết bị chứng minh yếu tố sở hữu.

![sinh trắc học liên kết động](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Tại sao passkey tuân thủ SCA (ràng buộc với thiết bị và đồng bộ hóa)

- **Sở hữu (khóa ràng buộc với thiết bị & đồng bộ hóa)**: Khóa riêng của passkey được lưu
  trữ trong phần cứng bảo mật (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM).
  Passkey ràng buộc với thiết bị không thể xuất được, phù hợp với kỳ vọng của EBA về việc
  ràng buộc thiết bị duy nhất (EBA‑Op‑2019‑06, đoạn 25, 35–37). Passkey được đồng bộ hóa
  cũng có thể chứng minh yếu tố sở hữu trong mỗi lần xác thực, miễn là các biện pháp kiểm
  soát ràng buộc thiết bị và chống sao chép có hiệu quả; các cơ quan quản lý đã nhấn mạnh
  sự cần thiết của một liên kết đáng tin cậy giữa yếu tố và thiết bị (EBA‑Op‑2019‑06; RTS
  Điều 7).
- **Vốn có/Kiến thức (Xác minh Người dùng)**: Xác minh Người dùng thông qua sinh trắc học
  (vốn có) hoặc mã PIN của thiết bị (kiến thức) sẽ kích hoạt khóa cục bộ. Kết hợp với yếu
  tố sở hữu, đây là
  [xác thực hai yếu tố (2FA)](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
  thực sự với sự độc lập của các yếu tố. Việc vi phạm một yếu tố không làm ảnh hưởng đến
  yếu tố kia.

## 3. Passkey có đáp ứng các yêu cầu liên kết động không?

Liên kết động là về việc **ràng buộc việc xác thực với giao dịch**. Câu hỏi đối với một
ngân hàng là: nếu chúng ta cho phép người dùng phê duyệt một khoản thanh toán qua passkey
(thay vì, chẳng hạn, một OTP hoặc một thiết bị ký), liệu chúng ta có thể đảm bảo rằng sự
phê duyệt này là cụ thể cho số tiền và người thụ hưởng dự định, và không thể bị tái sử
dụng hoặc thao túng không?

Có 2 lựa chọn để triển khai liên kết động với passkey:

- **Liên kết phía máy chủ (tiêu chuẩn):** Tạo một thử thách WebAuthn dùng một lần mà
  backend liên kết với số tiền và người thụ hưởng chính xác. Người dùng thấy “€X cho Y”
  trong một giao diện do ngân hàng kiểm soát và phê duyệt bằng passkey. Phản hồi chỉ được
  chấp nhận cho giao dịch đó. Bất kỳ thay đổi nào cũng làm nó mất hiệu lực.
- **Bao hàm mã hóa (nâng cao):** Nhúng một hàm băm của số tiền/người thụ hưởng vào thử
  thách để chữ ký cam kết với dữ liệu giao dịch. Điều này không được RTS yêu cầu nhưng
  tăng thêm sự đảm bảo rằng ngay cả việc hoán đổi ở backend cũng sẽ thất bại khi xác minh.

**Lưu ý tuân thủ rõ ràng:** RTS **không** yêu cầu “mã xác thực” của liên kết động phải
được tính toán trên thiết bị của người thanh toán. Một
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) có thể tạo và xác thực nó trên
**máy chủ** miễn là **số tiền/người thụ hưởng** được bảo vệ và **bất kỳ thay đổi nào**
cũng làm mất hiệu lực của mã (xem EBA Q\&A 2020_5366 về vị trí/thời điểm của mã). Đó là
cách tiếp cận **liên kết động phía máy chủ (tiêu chuẩn)** của chúng tôi.

Cả hai cách đều tạo ra một “mã xác thực” duy nhất, không thể tái sử dụng, cụ thể cho giao
dịch. Lưu ý chính là **nhận thức của người thanh toán**: bản thân WebAuthn không chứng
minh được những gì đã được hiển thị. Tính toàn vẹn của việc hiển thị phải đến từ giao diện
người dùng do ngân hàng kiểm soát.

### 3.1 Cân nhắc về Nhận thức của Người thanh toán

RTS Điều 5 yêu cầu người thanh toán phải thấy số tiền và người thụ hưởng trong quá trình
xác thực. WebAuthn không [chứng thực](https://www.corbado.com/vi/glossary/attestation) những gì đã được hiển thị.
Về lý thuyết, nếu ứng dụng hoặc hệ điều hành bị xâm phạm, người dùng có thể bị đánh lừa
trong khi trình xác thực vẫn ký. Chúng ta sẽ phân tích chi tiết bên dưới về cách rủi ro
này diễn ra trong thực tế và tại sao nó không phải là một rủi ro bảo mật thực sự mà thiên
về vấn đề diễn giải quy định hơn.

**Các biện pháp kiểm soát tính toàn vẹn hiển thị mà chúng tôi thực thi:**

- Giao diện do ngân hàng kiểm soát hiển thị **số tiền + người thụ hưởng**: chúng tôi
  **chặn** việc gọi passkey nếu giao diện bị che khuất hoặc mất tiêu điểm
- **Phát hiện lớp phủ/giả mạo** trong ứng dụng/web: không có
  [lời nhắc passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) từ các
  [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) ẩn
- **Kiểm soát tính toàn vẹn/attestation của thiết bị**: từ chối hoặc yêu cầu xác thực tăng
  cường đối với các tín hiệu thiết bị đã bị root/jailbreak/xâm phạm
- **Phê duyệt nguyên tử** dựa trên một **bản ghi** số tiền/người thụ hưởng do máy chủ lưu
  giữ: một thử thách mới là bắt buộc khi có bất kỳ thay đổi tham số nào

**Về bao hàm mã hóa:** Các phần mở rộng “hiển thị giao dịch” của WebAuthn (SPC) **chưa
được hỗ trợ rộng rãi** ngày nay. Nền tảng di động của chúng tôi là **ràng buộc phía máy
chủ**, được củng cố bằng cách lấy thử thách từ bản ghi giao dịch (ví dụ: H(số tiền ‖ người
thụ hưởng ‖ txnId ‖ nonce)) để chữ ký **cam kết** với các giá trị đó.

### 3.2 Sự tương đương về mặt quy định: sinh trắc học cục bộ với PKI và passkey

Cả hai mô hình đều sử dụng mật mã khóa công khai với các khóa thiết bị không thể xuất, và
cả hai đều dựa vào việc xác minh người dùng cục bộ để mở khóa hoạt động ký. Trong cả hai
trường hợp, ngân hàng đảm bảo nhận thức của người thanh toán bằng cách hiển thị số tiền và
người thụ hưởng trong một giao diện do ngân hàng kiểm soát ngay trước khi xác minh người
dùng, và đảm bảo tính cụ thể bằng cách ràng buộc mã xác thực với các chi tiết đó — làm mất
hiệu lực của nó khi có bất kỳ thay đổi nào (RTS Điều 5(1)(a–d)). RTS không phụ thuộc vào
công nghệ và không yêu cầu số tiền/người thụ hưởng phải được hiển thị bên trong một cửa sổ
sinh trắc học của hệ điều hành; nó yêu cầu hiển thị cho người thanh toán và ràng buộc của
mã (RTS Điều 5). Khi cả hai yếu tố [SCA](https://www.corbado.com/vi/blog/passkeys-va-psd2) thực thi trên một
thiết bị, các yêu cầu về tính toàn vẹn và tách biệt của Điều 9 áp dụng như nhau (RTS Điều
9(2)–(3)). Cuối cùng, vị trí của việc tính toán liên kết động là linh hoạt: nó có thể được
thực hiện phía máy chủ nếu tính toàn vẹn được bảo toàn và bất kỳ thay đổi nào cũng làm mất
hiệu lực của mã (Q\&A 2020_5366). Đây là những điều kiện tương tự mà các cơ quan quản lý
đã chấp nhận cho sinh trắc học cục bộ với PKI — do đó, passkey, được triển khai với cùng
các biện pháp kiểm soát nhận thức của người thanh toán và ràng buộc, nên được chấp nhận
trên cơ sở tương đương.

### 3.3 Passkey và mục đích của liên kết động

Vậy, passkey thông thường theo tiêu chuẩn WebAuthn có _thực hiện được mục đích_ của liên
kết động không? **Một phần:**

- **Tấn công MITM/mạng:** Có. Ràng buộc nguồn gốc và chữ ký cho mỗi thử thách ngăn chặn
  việc giả mạo và phát lại.
- **Toàn vẹn giao dịch:** Có. Liên kết máy chủ hoặc băm thử thách đảm bảo chỉ có số
  tiền/người thụ hưởng ban đầu mới được xác minh.
- **Sự đồng thuận của người thanh toán:** Khó hơn. Passkey thiếu hiển thị ở cấp trình xác
  thực. Lừa đảo giao diện người dùng trên các thiết bị bị xâm phạm có thể xảy ra. Cần phải
  xây dựng thêm một lớp bảo vệ để đảm bảo sự đồng thuận của người thanh toán.

**Tại sao liên kết động vẫn cần thiết với passkey**

- **Pháp lý:** PSD2 Điều 97(2) và RTS Điều 5 bắt buộc liên kết động cho **tất cả các hoạt
  động khởi tạo thanh toán từ xa**. Không có ngoại lệ cho các phương pháp chống phishing.
- **Bảo mật:** Passkey loại bỏ **phishing chéo nguồn gốc**, nhưng bản thân chúng không
  **chứng minh được những gì đã được hiển thị** cho người thanh toán. Liên kết động + các
  biện pháp kiểm soát tính toàn vẹn hiển thị đảm bảo rằng **số tiền/người thụ hưởng cụ
  thể** mà người dùng đã thấy là những gì ngân hàng thực hiện, và **bất kỳ thay đổi nào
  cũng làm mất hiệu lực** của sự phê duyệt.

**Tóm lại, passkey có thể thỏa mãn liên kết động** khi được ràng buộc chặt chẽ với dữ liệu
giao dịch và kết hợp với các cơ chế hiển thị đáng tin cậy. Thách thức còn lại là chứng
minh những gì người dùng đã thực sự nhìn thấy.

## 4. Corbado thực hiện liên kết động với passkey như thế nào

Corbado cung cấp một giải pháp tuân thủ liên kết động giải quyết rõ ràng các cân nhắc về
sự đồng thuận của người thanh toán ở trên.

### 4.1 Giải pháp từ đầu đến cuối: luồng, công nghệ, UX và tuân thủ

Quy trình:

- **Hiển thị do ngân hàng kiểm soát** cho người thanh toán thấy số tiền và người thụ hưởng
  chính xác. Không có [lời nhắc passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) nào được
  hiển thị trừ khi giao diện này hiển thị.
- **Xác thực:** client gọi WebAuthn với một thử thách ràng buộc, dùng một lần cho giao
  dịch đã được chuẩn hóa. Trình xác thực thực hiện xác minh người dùng (sinh trắc học hoặc
  mã PIN của thiết bị) và ký trên thử thách và nguồn gốc.
- **Xác minh phía máy chủ:** backend xác minh hàm băm RP ID và nguồn gốc, khớp thử thách
  với giao dịch được lưu trữ, kiểm tra cờ UV/flags, thực thi sử dụng một lần và hết hạn,
  và so sánh bản ghi số tiền/người thụ hưởng đã lưu.
- **Phê duyệt và kiểm toán:** chỉ sau đó giao dịch mới được phê duyệt một cách nguyên tử.
  Bất kỳ sự không khớp/thay đổi nào đều bị từ chối và yêu cầu một lần xác thực mới. Một
  bản ghi kiểm toán không thể thay đổi được lưu lại (ID thông tin xác thực,
  authenticatorData, [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), chữ ký, thử thách, và số
  tiền/người thụ hưởng đã được chuẩn hóa), tùy chọn được băm chuỗi để làm bằng chứng chống
  giả mạo.
- **Cổng kiểm tra tính toàn vẹn thiết bị:** Đánh giá tính toàn vẹn của thiết bị và tín
  hiệu [attestation](https://www.corbado.com/glossary/attestation): từ chối hoặc yêu cầu xác thực tăng cường nếu
  thiết bị bị root/jailbreak/xâm phạm.
- **Chuẩn hóa người thụ hưởng:** Hiển thị một nhãn thân thiện (ví dụ: “ACME GmbH”), nhưng
  ràng buộc và xác minh dựa trên một **mã định danh người thụ hưởng chính tắc** (ví dụ:
  IBAN/BIC hoặc một lược đồ duy nhất khác).

Chi tiết kỹ thuật:

- **Backend:** tạo một đối tượng giao dịch với dữ liệu đã được chuẩn hóa (ví dụ: tiền
  tệ/số thập phân được chuẩn hóa; IBAN/người thụ hưởng được chuẩn hóa). Tạo một thử thách
  có thời hạn ngắn cam kết với các giá trị này (ví dụ: H(số tiền||người thụ
  hưởng||txnId||nonce)); lưu trữ đang chờ xử lý; chỉ tiết lộ ID không rõ ràng cho client.
- **Client/trình xác thực:** hiển thị chi tiết người thanh toán trong một giao diện do
  ngân hàng kiểm soát; gọi WebAuthn (RP ID = tên miền Bison) chỉ khi hiển thị; yêu cầu xác
  minh người dùng; trình xác thực ký thử thách + nguồn gốc theo
  [WebAuthn](https://www.w3.org/TR/webauthn-3/).
- **Xác minh/hoàn tất:** xác thực chữ ký, hàm băm RP ID, nguồn gốc/loại, cờ UV; chống phát
  lại/hết hạn; so sánh bản ghi số tiền/người thụ hưởng không thể thay đổi; phê duyệt một
  cách nguyên tử; lưu lại bản ghi kiểm toán.
- **Lấy thử thách từ bản ghi:**: `challenge = H(amount ‖ canonicalPayee ‖ txnId ‖ nonce)`

Chính sách UX:

- Nhấn mạnh rõ ràng về số tiền/người thụ hưởng; các nút điều khiển xác nhận/hủy dễ tiếp
  cận; thời gian chờ ngắn; thử lại một cách nhẹ nhàng luôn sử dụng một thử thách mới; biên
  nhận ngay lập tức (ví dụ: “Bạn đã phê duyệt €X cho Y”). Chặn
  [lời nhắc passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) nếu màn hình hiển thị bị che
  khuất và cảnh báo nếu các tham số thay đổi trước khi ký.
- Phát hiện lớp phủ/nội dung bị che khuất: không bao giờ hiển thị lời nhắc passkey nếu
  **giao diện giao dịch không hiển thị**. Từ chối nếu các tham số thay đổi giữa chừng và
  bắt đầu lại với một **thử thách mới**.

**Lưu ý tuân thủ:** Thiết kế từ đầu đến cuối này đáp ứng RTS Điều 5: **nhận thức của người
thanh toán** (hiển thị do ngân hàng kiểm soát), **tính cụ thể** và **duy nhất** (mã dùng
một lần ràng buộc với số tiền/người thụ hưởng), **vô hiệu hóa khi có thay đổi** (kiểm tra
nghiêm ngặt phía máy chủ), và **tính bảo mật/toàn vẹn** của số tiền/người thụ hưởng và mã
trong tất cả các giai đoạn (RTS Điều 5(1)(a–d), 5(2); xem thêm Q\&A 2018_4414 về tính toàn
vẹn của SMS). Tính độc lập của các yếu tố (Điều 7–9) được bảo toàn thông qua yếu tố sở hữu
ràng buộc với thiết bị và xác minh người dùng cục bộ trên các thiết bị đa năng với các
biện pháp bảo vệ phù hợp (RTS Điều 9(2)–(3)).

_Lưu ý:_\* đối với các luồng web, Corbado sẽ tùy chọn áp dụng
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) nếu/khi Apple cung cấp
hỗ trợ rộng rãi, bổ sung một màn hình hiển thị đáng tin cậy do trình duyệt trung gian
[chứng thực](https://www.corbado.com/vi/glossary/attestation) bằng mã hóa số tiền và người thụ hưởng.

## 5. Các rủi ro còn lại & biện pháp kiểm soát bù trừ

**Mối quan ngại: Tấn công phishing** **Phản hồi:** Passkey có khả năng chống phishing theo
thiết kế: chúng được ràng buộc với nguồn gốc hợp pháp và không liên quan đến bí mật được
chia sẻ, vì vậy thông tin xác thực không thể bị thu thập trên một trang web giả mạo, không
giống như OTP. Kẻ tấn công làm proxy lưu lượng truy cập đến một tên miền trông giống hệt
không thể có được chữ ký hợp lệ cho nguồn gốc của ngân hàng. Liên kết động đóng góp ít hơn
trong vector này, nhưng vẫn là bắt buộc để đảm bảo mọi sự phê duyệt là duy nhất cho số
tiền và người thụ hưởng dự định. Các biện pháp bổ sung (giáo dục về phishing, tách biệt rõ
ràng giữa đăng nhập và phê duyệt thanh toán, chấm điểm rủi ro/bất thường cho các bối cảnh
thanh toán bất thường) giúp giảm thiểu rủi ro hơn nữa.

**Mối quan ngại: Tấn công phi kỹ thuật / Lừa đảo Ủy quyền Đẩy Thanh toán (APP)** **Phản
hồi:** Không có trình xác thực nào có thể ngăn chặn hoàn toàn việc người dùng ủy quyền một
khoản thanh toán dưới chiêu bài giả mạo (ví dụ: lừa đảo “tài khoản an toàn”). Liên kết
động đảm bảo người dùng thấy rõ người thụ hưởng và số tiền và cung cấp bằng chứng mạnh mẽ
về sự đồng ý, nhưng nó không thể thay đổi quyết định của một người thanh toán đã bị thuyết
phục. Các biện pháp bù trừ bao gồm cảnh báo theo ngữ cảnh (người thụ hưởng mới, chuyển
khoản lớn lần đầu), thời gian chờ hoặc thực hiện chậm đối với những người thụ hưởng có rủi
ro cao, xác minh người thụ hưởng mạnh hơn, và kiểm tra tăng cường (xác nhận thêm) khi có
tín hiệu rủi ro. Thông báo sau thanh toán và các kênh tranh chấp nhanh chóng giúp phát
hiện và ngăn chặn thiệt hại. Chúng tôi thêm các **cảnh báo theo ngữ cảnh** thời gian thực
(ví dụ: người thụ hưởng mới, chuyển khoản lớn lần đầu), **thời gian chờ** cho người thụ
hưởng rủi ro cao, **xác minh người thụ hưởng** mạnh hơn và **thông báo sau thanh toán**
(“Bạn đã phê duyệt €X cho Y”) để tăng tốc độ phát hiện và phản ứng.

**Mối quan ngại: Malware hoặc thiết bị bị xâm phạm** **Phản hồi:** Khóa riêng là **không
thể xuất** và yêu cầu **xác minh người dùng cục bộ** cho mỗi chữ ký, vì vậy
[malware](https://www.corbado.com/glossary/malware) không thể đơn giản lấy cắp thông tin xác thực. Rủi ro thực tế
là **lừa đảo giao diện người dùng** trên một hệ điều hành bị xâm phạm hoàn toàn. Giảm
thiểu bằng giao diện người dùng an toàn/đã xác minh (ví dụ: xác nhận được bảo vệ), kiểm
tra tính toàn vẹn thiết bị/[attestation](https://www.corbado.com/glossary/attestation) và chặn các thiết bị có
rủi ro cao, và các xác nhận đáng tin cậy như [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
hoặc một phần mở rộng xác nhận khi có sẵn. Nếu các chỉ số xâm phạm xuất hiện (phát hiện
lớp phủ, root/jailbreak), hãy sử dụng xác minh lại ngoài băng tần hoặc từ chối thực hiện.
Không có phương pháp nào dành cho người tiêu dùng là hoàn hảo trên một thiết bị bị chiếm
quyền hoàn toàn, nhưng những biện pháp kiểm soát này thu hẹp đáng kể cửa sổ tấn công.

**Mối quan ngại: Man‑in‑the‑browser / chiếm đoạt phiên** **Phản hồi:** Các phần mở rộng
độc hại hoặc các tập lệnh được tiêm vào có thể khởi tạo hành động trên nguồn gốc hợp pháp.
Passkey ràng buộc với nguồn gốc ngăn chặn phishing chéo trang. **Liên kết động** đảm bảo
các chỉnh sửa ngầm đối với số tiền/người thụ hưởng sẽ **thất bại**. Chúng tôi tăng cường
bảo mật kênh thông qua các biện pháp kiểm soát CSP/chống giả mạo và bằng cách yêu cầu một
**thử thách mới, dùng một lần** cho mỗi lần xác nhận.

**Mối quan ngại: Mối đe dọa nội bộ hoặc giả mạo phía máy chủ** **Phản hồi:** Phản hồi xác
thực được liên kết duy nhất với số tiền/người thụ hưởng ban đầu, vì vậy bất kỳ sự thay thế
nào phía máy chủ đều không qua được xác thực. Duy trì các bản ghi liên kết không thể thay
đổi, có bằng chứng chống giả mạo (thử thách, thông tin xác thực, chữ ký, và số tiền/người
thụ hưởng đã được chuẩn hóa) để kiểm toán/không thể chối cãi. Áp dụng phân chia nhiệm vụ
và các biện pháp kiểm soát bốn mắt đối với các quy trình xử lý thanh toán quan trọng để
giảm rủi ro nội bộ.

**Mối quan ngại: Thiết bị bị đánh cắp / trộm cắp thông tin xác thực** **Phản hồi:** Chỉ sở
hữu thiết bị là không đủ: cần có xác minh người dùng (sinh trắc học/PIN) cho mỗi chữ ký,
với giới hạn tốc độ và khóa ở cấp hệ điều hành. Mỗi thanh toán yêu cầu một thử thách mới,
dành riêng cho giao dịch; các token phiên chung không thể ủy quyền cho các khoản thanh
toán tùy ý. Các biện pháp bổ sung như thu hồi thiết bị từ xa, xác thực tăng cường khi sử
dụng thiết bị mới, kiểm tra vận tốc địa lý, và thông báo (“Bạn đã ủy quyền €X cho Y”) càng
hạn chế việc lạm dụng.

Tổng thể: passkey giảm đáng kể rủi ro phishing và phát lại; liên kết động vẫn cần thiết để
đảm bảo tính toàn vẹn của giao dịch, ràng buộc sự phê duyệt với số tiền/người thụ hưởng,
và cung cấp bằng chứng mạnh mẽ về sự đồng ý có hiểu biết trong các kịch bản mối đe dọa còn
lại.

## 6. Câu hỏi thường gặp về Tuân thủ

**Câu hỏi 1:** Làm thế nào chúng ta có thể chứng minh rằng người dùng thực sự đã thấy và
đồng ý với số tiền và người thụ hưởng khi sử dụng passkey? **Phản hồi:** Về cơ bản đây là
câu hỏi về **tính không thể chối cãi**. Theo PSD2, liên kết động nhằm đảm bảo người dùng
nhận thức được những gì họ đang phê duyệt. Với passkey, bằng chứng chúng tôi lưu giữ là
chữ ký mã hóa (mã xác thực) và dữ liệu liên quan (nó được gắn với số tiền/người thụ hưởng
nào trên máy chủ của chúng tôi). Theo chính sách, chúng tôi hiển thị chi tiết giao dịch
cho người dùng trong ứng dụng hoặc trang web trước khi họ xác thực. Chúng tôi ghi lại màn
hình/giao diện đó và việc [xác thực passkey](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) thành công sau
đó cho giao dịch cụ thể đó. Trong trường hợp có tranh chấp, chúng tôi có thể chỉ ra rằng
thiết bị của người dùng đã tạo ra một chữ ký hợp lệ cho một thử thách được liên kết với
(ví dụ) “€100 cho ACME Corp.” và hệ thống của chúng tôi sẽ không tiếp tục nếu có bất kỳ
chi tiết nào khác biệt. Việc tuân thủ của chúng tôi dựa vào việc ghi nhật ký an toàn:
chúng tôi đảm bảo hệ thống của mình chống giả mạo trong việc liên kết phản hồi passkey với
dữ liệu giao dịch.

**Câu hỏi 2:** Điều gì sẽ xảy ra nếu thiết bị hoặc hệ điều hành bị xâm phạm?
[Malware](https://www.corbado.com/glossary/malware) có thể thao túng giao dịch hoặc quy trình passkey không?
**Phản hồi:** Việc xâm phạm thiết bị là một mối đe dọa nghiêm trọng trong bất kỳ kịch bản
[ngân hàng](https://www.corbado.com/passkeys-for-banking) số nào. Nếu hệ điều hành độc hại, nó có thể cố gắng
đánh lừa người dùng hoặc chiếm quyền các quy trình. Tuy nhiên, ngay cả trong trường hợp
xấu nhất này, **passkey vẫn duy trì một số biện pháp bảo vệ chính**. Khóa riêng không thể
bị trích xuất bởi [malware](https://www.corbado.com/glossary/malware). Malware cũng không thể mạo danh người dùng
với ngân hàng, vì nó không thể tạo ra chữ ký passkey mà không có sinh trắc học/PIN của
người dùng. Điều tồi tệ nhất nó có thể làm là thúc đẩy người dùng xác thực một thứ gì đó
dưới chiêu bài giả mạo. Liên kết động giúp ở đây bằng cách yêu cầu kiểm tra tính toàn vẹn:
malware không thể âm thầm thay đổi chi tiết giao dịch sau đó – nếu nó làm vậy, chữ ký sẽ
không được xác minh. Điểm yếu nhất là **hiển thị/giao diện người dùng**: một Trojan tinh
vi có thể thay đổi những gì người dùng thấy (ví dụ: hiển thị “ACME Corp” trong khi giao
dịch ngầm thực sự đang đi đến một người thụ hưởng khác). Điều này không hề đơn giản, đặc
biệt nếu ứng dụng ngân hàng sử dụng các framework UI an toàn, nhưng nó có thể xảy ra. Dù
vậy, nếu chúng tôi phát hiện dấu hiệu xâm phạm thiết bị (hành vi bất thường, chữ ký
malware đã biết, v.v.), chúng tôi sẽ chuyển sang xác minh ngoài băng tần hoặc từ chối giao
dịch. **Tóm lại:** Không có giải pháp nào là 100% nếu thiết bị của người dùng bị kẻ tấn
công chiếm quyền hoàn toàn. Passkey + liên kết động giảm đáng kể bề mặt tấn công (kẻ tấn
công không thể chỉ làm proxy thông tin xác thực hoặc thay đổi dữ liệu mạng; họ sẽ phải
thực hiện một màn lừa đảo người dùng trong thời gian thực). Nếu hệ điều hành bị xâm phạm,
liên kết động ít nhất đảm bảo bất kỳ sự không khớp nào giữa những gì nên có và những gì
được phê duyệt sẽ bị backend của chúng tôi phát hiện.

**Câu hỏi 3:** Nếu sinh trắc học được sử dụng để mở khóa passkey, đó được coi là một yếu
tố hay hai yếu tố? Chúng ta có tuân thủ quy tắc 2 yếu tố không? **Phản hồi:** Một mình
sinh trắc học **không** đủ cho [SCA](https://www.corbado.com/vi/blog/passkeys-va-psd2) – nó chỉ là một yếu tố vốn
có. Tuy nhiên, trong một triển khai passkey, sinh trắc học _không đơn độc_: yếu tố sở hữu
thiết bị là yếu tố còn lại. Sinh trắc học của người dùng mở khóa khóa riêng _được lưu trữ
trên thiết bị_. Sở hữu và vốn có là hai loại riêng biệt. Điều này tương tự như cách nhiều
ứng dụng [ngân hàng](https://www.corbado.com/passkeys-for-banking) đã thỏa mãn SCA: bạn có điện thoại (sở hữu)
_và_ bạn sử dụng vân tay hoặc khuôn mặt để mở khóa ứng dụng (vốn có). EBA đã công nhận rõ
ràng sự kết hợp giữa ràng buộc thiết bị cộng với sinh trắc học là SCA tuân thủ. Kịch bản
passkey chính xác là sự kết hợp đó. Nếu người dùng chọn sử dụng mã PIN thay vì sinh trắc
học để mở khóa passkey, thì đó là sở hữu + kiến thức, cũng tuân thủ. Chúng tôi thực thi
xác minh người dùng trên tất cả các hoạt động passkey (nghĩa là người dùng phải cung cấp
sinh trắc học/PIN mỗi lần), vì vậy không có tình huống nào mà chỉ cần có thiết bị là đủ.
Do đó, mỗi lần ủy quyền thanh toán qua passkey là một sự kiện _hai yếu tố_ theo định nghĩa
của PSD2.

**Câu hỏi 4:** Kẻ tấn công có thể tái sử dụng một lần
[xác thực passkey](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) hoặc bằng cách nào đó bỏ qua liên kết
động bằng cách thao túng dữ liệu đang truyền không? **Phản hồi:** Không. Đây là nơi
passkey và liên kết động hoạt động cùng nhau một cách mạnh mẽ. Mỗi lần xác thực WebAuthn
tạo ra một **chữ ký duy nhất** được gắn với thử thách (mà chúng tôi tạo cho mỗi giao dịch)
và được giới hạn trong phạm vi tên miền của chúng tôi. Kẻ tấn công không thể phát lại chữ
ký đó cho một giao dịch khác. Bản thân chữ ký kết hợp nonce của thử thách và chỉ hợp lệ
cho những gì nó được cấp ban đầu. Nếu một kẻ tấn công chặn được giao tiếp mạng, họ không
thể thay đổi số tiền hoặc người thụ hưởng mà không làm mất hiệu lực của chữ ký (vì thử
thách hoặc bối cảnh giao dịch sẽ không còn khớp nữa). Đây chính là biện pháp bảo vệ MITM
mà chúng tôi đã thảo luận. Ngoài ra, chữ ký passkey bao gồm dữ liệu nguồn gốc – chúng sẽ
không được xác minh nếu không được gửi đến chính xác nguồn gốc trang web/ứng dụng của
chúng tôi, vì vậy phishing hoặc chuyển hướng sẽ không hoạt động. Tóm lại, bất kỳ nỗ lực
thao túng nào cũng làm mất hiệu lực của mã xác thực, theo các quy tắc liên kết động. Điều
này thực sự an toàn hơn một số quy trình dựa trên OTP hiện tại, nơi người dùng đôi khi phê
duyệt một mã chung và có nguy cơ yêu cầu đã bị giả mạo. Với passkey, chúng tôi ràng buộc
mã hóa việc xác thực người dùng với phiên/giao dịch cụ thể.

**Câu hỏi 5:** Có bất kỳ ý kiến pháp lý nào đã biết về WebAuthn/passkey cho SCA không?
Chúng ta có chắc chắn các cơ quan quản lý sẽ chấp nhận passkey là tuân thủ không? **Phản
hồi:** Cho đến nay, EBA chưa công bố ý kiến rõ ràng về WebAuthn hoặc thuật ngữ “passkey”
trong các Hỏi & Đáp hoặc [hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) của họ.
Tuy nhiên, dựa trên các nguyên tắc họ đã đặt ra, passkey rõ ràng phù hợp với các phương
pháp được chấp nhận. Ý kiến năm 2019 của EBA về cơ bản đã dự đoán trước các phương pháp
tương tự [FIDO2](https://www.corbado.com/glossary/fido2): đối với yếu tố sở hữu, họ đã đề cập rõ ràng đến **“trao
đổi khóa công khai/riêng tư” với việc ràng buộc thiết bị phù hợp làm bằng chứng sở hữu**.
Một passkey WebAuthn chính xác là như vậy – một cặp khóa công khai/riêng tư, với nửa riêng
tư được ràng buộc an toàn với thiết bị. Họ cũng đã công nhận “chữ ký được tạo bởi một
thiết bị” là một bằng chứng sở hữu hợp lệ. Vì vậy, mặc dù họ không sử dụng thuật ngữ
passkey, phương pháp này đã được bao gồm trong các ví dụ của họ. Chúng tôi cũng đã quan
sát thấy rằng các công ty thanh toán lớn ở châu Âu đang tiến tới triển khai passkey (ví
dụ: [PayPal](https://www.corbado.com/blog/paypal-passkeys)), điều này cho thấy một mức độ tự tin rằng đây là
[tuân thủ PSD2](https://www.corbado.com/vi/blog/passkeys-va-psd2). Ví dụ này chứng tỏ rằng passkey đang được chấp
nhận như một phần của các quy trình SCA tuân thủ, miễn là liên kết động và các yêu cầu
tổng thể được đáp ứng.

**Câu hỏi 6:** Chúng ta có vẫn cần liên kết động nếu passkey đã chống được phishing không?
**Phản hồi:** Có. Passkey loại bỏ **phishing chéo nguồn gốc**, nhưng PSD2 vẫn bắt buộc
**liên kết động** cho việc khởi tạo thanh toán từ xa. Liên kết động ràng buộc **số tiền và
người thụ hưởng cụ thể** với kết quả SCA và **làm mất hiệu lực bất kỳ thay đổi nào**, giải
quyết tính toàn vẹn của việc ủy quyền ngoài phishing (ví dụ: thay thế MITM/MITB/TPP).

## 7. Kết luận: tuân thủ liên kết động và kết quả cải thiện

Giải pháp của Corbado tuân thủ Liên kết động và PSD2. Việc hiển thị cho người thanh toán
trước khi xác thực, thử thách dùng một lần ràng buộc với số tiền và người thụ hưởng, xác
minh nghiêm ngặt phía máy chủ, và kiểm toán không thể thay đổi cùng nhau thỏa mãn các yêu
cầu của RTS Điều 5 về nhận thức của người thanh toán, tính duy nhất/cụ thể, vô hiệu hóa
khi có thay đổi, và tính toàn vẹn/bảo mật. Tính độc lập của các yếu tố được bảo toàn thông
qua yếu tố sở hữu ràng buộc với thiết bị và UV (sinh trắc học hoặc PIN), phù hợp với hướng
dẫn của EBA.

So với các phương pháp OTP/SMS ngày nay, Corbado mang lại kết quả bảo mật và trải nghiệm
người dùng tốt hơn đáng kể: khả năng chống lại phishing và phát lại, ngăn chặn việc giả
mạo tham số một cách âm thầm, bằng chứng không thể chối cãi mạnh mẽ hơn, và giảm ma sát
thông qua UV trên thiết bị. Các rủi ro còn lại (ví dụ: tấn công phi kỹ thuật, thiết bị bị
xâm phạm) được giảm thiểu bằng các biện pháp kiểm soát cụ thể và hẹp hơn so với các phương
pháp cũ. Đối với web, Corbado có thể áp dụng [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) khi
nền tảng hỗ trợ (đáng chú ý là Apple) được phổ biến rộng rãi, bổ sung bằng chứng mã hóa về
việc hiển thị mà không thay đổi tư thế tuân thủ cốt lõi.

Tóm lại, việc ủy quyền giao dịch dựa trên passkey của Corbado đáp ứng cả tinh thần và văn
bản của liên kết động PSD2 và cải thiện khả năng chống gian lận và khả năng kiểm toán so
với các phương pháp cũ, đồng thời duy trì một lộ trình rõ ràng cho các cải tiến trong
tương lai (SPC) khi hệ sinh thái trưởng thành.

Trong thực tế, passkey thỏa mãn liên kết động khi chúng ta làm ba điều: chúng ta hiển thị
số tiền và người thụ hưởng cho người thanh toán trước khi xác minh người dùng; chúng ta
tạo ra một mã xác thực cụ thể cho các chi tiết chính xác đó; và chúng ta làm mất hiệu lực
của mã khi có bất kỳ thay đổi nào (RTS Điều 5(1)(a–d)). Điều này phản ánh các nguyên tắc
mà các cơ quan quản lý đã chấp nhận cho sinh trắc học cục bộ, với sự tiện lợi bổ sung là
passkey là gốc của hệ điều hành và hoạt động trên cả kênh web và ứng dụng mà không cần một
ứng dụng bổ sung. Kết hợp với ràng buộc nguồn gốc, chúng không hiển thị các yêu cầu giả
mạo — chỉ các lời nhắc hợp pháp từ trang web hoặc ứng dụng gốc mới xuất hiện cho người
dùng.