Thông tin xác thực kỹ thuật số và Passkey: Điểm tương đồng & khác biệt

• 🔑 Passkey: Dùng để đăng nhập an toàn. Chúng chứng minh bạn là ai (xác thực) và chống lừa đảo (phishing) hiệu quả.
• 📄 Thông tin xác thực kỹ thuật số: Dùng để cung cấp bằng chứng có thể xác minh. Chúng chứng minh các sự thật về bạn (chứng thực, ví dụ: ID, kỹ năng của bạn), và bạn có quyền kiểm soát những gì được chia sẻ.
• 🤝 Điểm tương đồng: Cả hai đều sử dụng mật mã hóa mạnh để bảo mật tốt hơn và mang lại trải nghiệm người dùng mượt mà hơn so với mật khẩu.
• 🎯 Điểm khác biệt: Passkey chủ yếu dùng để truy cập dịch vụ. Thông tin xác thực kỹ thuật số dùng để cung cấp thông tin đã được xác minh về bản thân bạn.

Bối cảnh kỹ thuật số đang thay đổi nhanh chóng. Sự thay đổi này không chỉ xảy ra do mật khẩu truyền thống và các bí mật được chia sẻ liên tục thất bại, mà còn vì các cuộc tấn công như lừa đảo (phishing) và deepfake do AI tạo ra ngày càng tinh vi và khó phát hiện hơn. Những mối đe dọa tiên tiến này có thể đánh lừa ngay cả những người dùng cẩn thận và làm cho các phương pháp kiểm tra danh tính cũ trở nên không đáng tin cậy. Điều này cho thấy rõ rằng bằng chứng mật mã hóa kỹ thuật số là cách duy nhất thực sự an toàn để xác nhận danh tính của một người. Trong tình hình khó khăn này, chúng ta cần khẩn cấp các phương thức tương tác trực tuyến an toàn hơn, thân thiện với người dùng hơn và có thể xác minh bằng mật mã hóa. Nhu cầu này đã làm cho hai công nghệ chính trở nên quan trọng: passkey, vốn đã được sử dụng rộng rãi, và thông tin xác thực kỹ thuật số, vốn chỉ mới bắt đầu. Các công nghệ này không dựa vào những tuyên bố do con người kiểm tra – vốn ngày càng dễ bị làm giả – mà thay vào đó sử dụng bằng chứng mật mã hóa có thể kiểm tra bằng máy để xây dựng lòng tin thực sự.

Passkey đã có một bước nhảy vọt trong việc sử dụng trong giai đoạn 2023-2025, nhờ sự hỗ trợ mạnh mẽ từ các công ty lớn như Apple, Google, và Microsoft, cùng với Liên minh FIDO. Dựa trên tiêu chuẩn WebAuthn vững chắc của W3C, passkey là một thay đổi cơ bản so với các bí mật được chia sẻ yếu kém. Thay vì mật khẩu, chúng sử dụng mật mã hóa khóa công khai. Ở đây, một khóa riêng tư, được lưu trữ an toàn trên thiết bị của người dùng, sẽ ký các thử thách từ bên tin cậy (RP). Điều này chứng minh người dùng sở hữu khóa mà không cần tiết lộ chính khóa đó.

Cơ chế mật mã hóa này làm cho passkey rất khó bị lừa đảo (phishing)—một lợi thế lớn, vì các cuộc tấn công phishing ngày càng tinh vi, đôi khi sử dụng deepfake để trông thật hơn. Vì một passkey được liên kết với trang web hoặc ứng dụng cụ thể mà nó được tạo ra, người dùng không thể vô tình sử dụng nó trên các trang web giả mạo. Đây là một vấn đề phổ biến với các phương thức đăng nhập cũ, vốn dễ bị tấn công bởi các thủ đoạn tinh vi như vậy. Passkey cũng ngăn chặn việc tái sử dụng mật khẩu và các nguy cơ từ tấn công nhồi thông tin xác thực (credential stuffing) sau các vụ rò rỉ dữ liệu. Không chỉ về bảo mật, passkey còn cải thiện đáng kể trải nghiệm đăng nhập: nhanh hơn, thường chỉ cần quét sinh trắc học (như Face ID hoặc vân tay), vì vậy người dùng không cần phải nhớ hoặc nhập mật khẩu dài. Sự kết hợp giữa bảo mật tốt hơn và dễ sử dụng đã giúp chúng nhanh chóng trở nên phổ biến.

Đồng thời, thông tin xác thực kỹ thuật số, thường được lưu trong ví danh tính kỹ thuật số, đã được nhắc đến nhiều hơn. Ví Danh tính Kỹ thuật số của EU (Ví EUDI) là một ví dụ điển hình cho xu hướng này.

Không giống như passkey, chủ yếu dùng để xác thực (chứng minh bạn là ai bằng cách cho thấy bạn kiểm soát một khóa riêng tư), thông tin xác thực kỹ thuật số (dựa trên các tiêu chuẩn như Thông tin xác thực có thể xác minh (VC) của W3C hoặc mdocs của ISO) là về chứng thực có thể xác minh bằng mật mã hóa (chứng minh điều gì là đúng về bạn bằng các tuyên bố được ký kỹ thuật số). Khả năng xác minh mạnh mẽ các tuyên bố này là rất quan trọng, đặc biệt là khi deepfake có thể tạo ra các bản giả mạo thuyết phục của các bằng chứng truyền thống. Nếu không có kiểm tra bằng mật mã hóa, ngay cả các chuyên gia cũng khó phân biệt được thật giả. Chúng cho phép mọi người mang và xuất trình thông tin đã được xác minh một cách kỹ thuật số – như tên, ngày sinh, bằng lái xe, bằng cấp học vấn, hoặc chứng chỉ công việc – theo cách an toàn về mặt mật mã hóa, tôn trọng quyền riêng tư (bằng cách cho phép người dùng chỉ chia sẻ những gì cần thiết), và có thể được kiểm tra bằng máy.

Sự trỗi dậy của cả hai công nghệ này không phải là ngẫu nhiên. Nó cho thấy một sự dịch chuyển rộng lớn hơn trong ngành công nghiệp từ các hệ thống danh tính tập trung, dựa trên mật khẩu sang một mô hình phi tập trung, lấy người dùng làm trung tâm và được xây dựng trên sự tin cậy mật mã hóa. Mật khẩu là một điểm yếu đã được biết đến trong bảo mật trực tuyến. Các cách chia sẻ chi tiết danh tính cũ thường rườm rà, không an toàn, hoặc chia sẻ quá nhiều dữ liệu, gây hại cho quyền riêng tư của người dùng. Passkey khắc phục trực tiếp điểm yếu trong xác thực. Thông tin xác thực kỹ thuật số giải quyết việc chia sẻ thuộc tính một cách an toàn và có sự kiểm soát của người dùng. Cả hai đều sử dụng mật mã hóa tương tự và ngày càng phụ thuộc vào việc tích hợp nền tảng và phần cứng bảo mật, cho thấy một nỗ lực chung nhằm cải thiện đáng kể hệ thống danh tính kỹ thuật số của chúng ta.

Mặc dù passkey xử lý việc "đăng nhập" và thông tin xác thực kỹ thuật số xử lý việc "chứng minh thuộc tính", chúng sử dụng các nguyên tắc mật mã hóa cơ bản tương tự và đóng vai trò bổ sung cho nhau trong việc thiết lập các tương tác kỹ thuật số đáng tin cậy. Đây là điều chúng ta thực sự cần, vì các mối đe dọa hiện tại như lừa đảo (phishing) tinh vi và deepfake làm cho các phương pháp kiểm tra danh tính cũ, không dùng mật mã hóa trở nên không an toàn. Điều này đưa chúng ta đến câu hỏi chính: Passkey và thông tin xác thực kỹ thuật số kết nối với nhau như thế nào, và chúng có thể hoạt động cùng nhau trong các tình huống sử dụng hàng ngày ra sao?

Bài viết này khám phá sự phối hợp này. Chúng ta sẽ xem xét sự khác biệt và tương đồng của chúng, các giao thức cho phép chúng hoạt động, sự phụ thuộc chung vào phần cứng bảo mật, và cách chúng có thể kết hợp với nhau trong các kịch bản như giới thiệu người dùng mới (onboarding), đăng nhập với xác thực nâng cao (step-up authentication), và di chuyển thiết bị. Chúng ta cũng sẽ đề cập đến cách các tiêu chuẩn trình duyệt mới nổi như API Thông tin xác thực kỹ thuật số (Digital Credentials API) nhằm mục đích kết nối hai thế giới này. Bài viết này tập trung đặc biệt vào sự tương tác giữa các công nghệ này, bổ sung cho bài khám phá kỹ thuật sâu hơn về API Thông tin xác thực kỹ thuật số đã có sẵn.

Để hiểu cách passkey và thông tin xác thực kỹ thuật số có thể hoạt động cùng nhau, trước tiên cần nắm bắt các đặc điểm riêng biệt của chúng và các lớp công nghệ nền tảng.

Bảng sau đây cung cấp một so sánh ở cấp độ cao:

So sánh này nhấn mạnh rằng mặc dù cả hai đều tận dụng mật mã hóa để tạo dựng lòng tin, các chức năng chính và các mẫu sử dụng điển hình của chúng lại khác nhau đáng kể. Passkey được tối ưu hóa cho việc xác thực thường xuyên, an toàn, trong khi thông tin xác thực kỹ thuật số vượt trội trong việc cung cấp các thuộc tính có thể xác minh với sự đồng ý của người dùng.

Passkey được hiện thực hóa thông qua sự tương tác của một số tiêu chuẩn chính:

• WebAuthn (Web Authentication): Tiêu chuẩn W3C này định nghĩa API JavaScript mà các ứng dụng web sử dụng để tương tác với trình xác thực để đăng ký (navigator.credentials.create()) và xác thực (navigator.credentials.get()) passkey. Nó hoạt động như cầu nối giữa ứng dụng web của Bên tin cậy và trình duyệt hoặc hệ điều hành của người dùng. WebAuthn mở rộng API Quản lý thông tin xác thực (Credential Management API) chung của W3C.

• CTAP (Client to Authenticator Protocol): Được định nghĩa bởi Liên minh FIDO, CTAP chỉ định cách client (trình duyệt hoặc HĐH) giao tiếp với thiết bị trình xác thực. Đây có thể là một trình xác thực nền tảng được tích hợp sẵn trong thiết bị (sử dụng phần cứng bảo mật như TPM hoặc Secure Enclave) hoặc một trình xác thực di động như khóa bảo mật USB hoặc thậm chí là một chiếc điện thoại hoạt động như một trình xác thực cho một thiết bị khác. CTAP2 là phiên bản tương thích với FIDO2 và passkey, hỗ trợ nhiều phương thức truyền tải như USB, NFC và Bluetooth Low Energy (BLE).

• Tín hiệu tin cậy nâng cao & Liên kết thiết bị (Những lưu ý đối với Passkey được đồng bộ hóa): Khi passkey phát triển để có thể đồng bộ hóa trên các thiết bị ("thông tin xác thực đa thiết bị"), các Bên tin cậy (RP) đôi khi cần xác định thiết bị vật lý cụ thể được sử dụng trong quá trình xác thực để đánh giá rủi ro. Các ý tưởng ban đầu, như tiện ích mở rộng devicePubKey và supplementalPubKeys, đã cố gắng giải quyết vấn đề này nhưng sau đó đã bị loại bỏ. Nhóm làm việc về tín hiệu tin cậy của Liên minh FIDO hiện đang phát triển các giải pháp thay thế. Ý tưởng chính ở đây là một trình xác thực với một passkey được đồng bộ hóa cũng có thể tạo và sử dụng một cặp khóa thứ hai được gắn với thiết bị. Trong quá trình xác thực, trình xác thực sau đó có thể cung cấp chữ ký từ cả khóa chính được đồng bộ hóa và khóa thứ hai gắn với thiết bị này. Điều này sẽ cho phép các RP nhận ra một thiết bị đáng tin cậy cụ thể. Điều này có thể có nghĩa là ít trở ngại hơn (ví dụ: bỏ qua các thử thách bổ sung) ngay cả khi passkey chính được đồng bộ hóa trên nhiều thiết bị, mà không làm mất đi lợi ích chính của passkey được đồng bộ hóa: khả năng sử dụng trên các thiết bị. Mặc dù chưa có tiêu chuẩn cuối cùng cho việc này, một tính năng như vậy sẽ đáp ứng nhu cầu chính của các RP yêu cầu mức độ đảm bảo cao, cho phép họ phát hiện tốt hơn việc sử dụng thiết bị mới hoặc đáp ứng các quy tắc Xác thực khách hàng mạnh (SCA) nội bộ.

Tương tự, hệ sinh thái thông tin xác thực kỹ thuật số dựa vào một tập hợp các giao thức và API mới nổi để hoạt động:

• API Thông tin xác thực kỹ thuật số: Đây là một nỗ lực đặc tả mới nổi của W3C nhằm mở rộng API navigator.credentials.get() để cho phép các ứng dụng web yêu cầu Thông tin xác thực có thể xác minh từ ví kỹ thuật số của người dùng một cách chuẩn hóa. Nó phục vụ một mục đích tương tự như WebAuthn nhưng tập trung vào VC thay vì passkey.
• OpenID for Verifiable Presentations (OpenID4VP): Giao thức này, được xây dựng trên OAuth 2.0, định nghĩa cách một Bên xác minh (RP yêu cầu thông tin xác thực) có thể yêu cầu VC từ Ví của Người giữ. Các yếu tố chính bao gồm presentation_definition (chỉ định các thông tin xác thực và tuyên bố bắt buộc), Ví hoạt động như một máy chủ ủy quyền, và vp_token mang Bản trình bày có thể xác minh trở lại Bên xác minh.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): Bổ sung cho OpenID4VP, tiêu chuẩn này chuẩn hóa cách một Bên phát hành cung cấp VC cho Ví của Người giữ, một lần nữa sử dụng các cơ chế OAuth 2.0. Nó bao gồm các khái niệm như Credential Offers, các luồng được ủy quyền trước hoặc luồng mã ủy quyền, và các điểm cuối thông tin xác thực chuyên dụng.
• Tiêu chuẩn ISO (ví dụ: ISO/IEC 18013-7, ISO/IEC 23220): Các tiêu chuẩn quốc tế này đặc biệt quan trọng đối với giấy phép lái xe di động (mDL) và các loại tài liệu di động khác (mdoc). ISO 18013-5 định nghĩa cấu trúc dữ liệu mDL cốt lõi và trình bày ngoại tuyến (NFC, BLE), trong khi ISO 18013-7 và 23220 chỉ định các cơ chế trình bày trực tuyến, bao gồm các API REST và các hồ sơ tích hợp với OpenID4VP (Phụ lục B của 18013-7). Các nền tảng như Google Wallet và Apple Wallet tận dụng các tiêu chuẩn ISO này.

Mặc dù có các mục đích và giao thức khác nhau, passkey và thông tin xác thực kỹ thuật số chia sẻ các khối xây dựng cơ bản:

• Mật mã hóa bất đối xứng: Cả hai đều phụ thuộc nhiều vào các cặp khóa công khai-riêng tư. Passkey sử dụng khóa riêng tư để chứng minh quyền sở hữu trong quá trình xác thực. Thông tin xác thực kỹ thuật số sử dụng khóa riêng tư của bên phát hành để ký thông tin xác thực, đảm bảo tính xác thực và toàn vẹn của nó, và người giữ có thể sử dụng khóa riêng tư của họ để ký một bản trình bày chứa thông tin xác thực.
• Phần cứng bảo mật: Bảo vệ các khóa riêng tư là tối quan trọng. Cả hai công nghệ đều được hưởng lợi rất nhiều từ các thành phần phần cứng bảo mật được tích hợp vào các thiết bị hiện đại:
  • TPM (Trusted Platform Module): Một con chip chuyên dụng thường thấy trong máy tính xách tay và máy tính để bàn, cung cấp khả năng tạo khóa, lưu trữ và các hoạt động mật mã an toàn. Nó thường được sử dụng bởi các trình xác thực nền tảng như Windows Hello.
  • Secure Enclave: Trình quản lý khóa dựa trên phần cứng của Apple, được cách ly khỏi bộ xử lý chính trên iPhone, iPad và Mac, được sử dụng để bảo vệ dữ liệu nhạy cảm bao gồm cả khóa riêng tư của passkey.
  • Hệ thống Android Keystore / StrongBox Keymaster: Android cung cấp một Keystore được hỗ trợ bởi phần cứng, thường được triển khai bằng một bộ xử lý bảo mật chuyên dụng (StrongBox Keymaster), cung cấp sự bảo vệ mạnh mẽ cho các khóa mật mã trên các thiết bị Android. Mặc dù một số trình quản lý mật khẩu sử dụng tên "Strongbox", thành phần phần cứng bảo mật cơ bản do HĐH cung cấp mới là yếu tố hỗ trợ chính ở đây.

Việc sử dụng cùng các thành phần phần cứng bảo mật (TPM, Secure Enclave, Keystore được hỗ trợ phần cứng của Android) cho cả hoạt động passkey và có khả năng bảo vệ các khóa riêng tư trong ví kỹ thuật số tạo ra sự phối hợp đáng kể. Các nền tảng không cần các chip bảo mật riêng biệt cho mỗi chức năng. Thay vào đó, họ có thể sử dụng một nền tảng phần cứng mạnh mẽ duy nhất và các API hệ điều hành liên quan (như các API cho Keystore của Android hoặc Secure Enclave của Apple) để bảo vệ mạnh mẽ cả thông tin xác thực (passkey) và thông tin chứng thực (VC). Điều này giúp việc phát triển dễ dàng hơn, cải thiện tính nhất quán về bảo mật và tận dụng tốt các khoản đầu tư nền tảng hiện có.

Hơn nữa, API Quản lý thông tin xác thực của trình duyệt (navigator.credentials) là một lớp tổ chức chính. Lần đầu tiên được WebAuthn mở rộng cho passkey, giờ đây nó đang được API Thông tin xác thực kỹ thuật số mở rộng thêm cho VC. Điều này cho thấy một kế hoạch rõ ràng: cung cấp cho các RP một cách chính để yêu cầu các loại thông tin xác thực khác nhau, và cung cấp cho người dùng một cách quen thuộc để chọn chúng (như thông qua trình quản lý thông tin xác thực của Android hoặc các trình quản lý mật khẩu tích hợp trong trình duyệt). Điều này sẽ che giấu các chi tiết kỹ thuật phức tạp của các giao thức như CTAP, OID4VP và ISO, giúp mọi thứ dễ dàng hơn cho các nhà phát triển và người dùng.

Từ góc độ của Bên tin cậy (RP), việc hiểu cách tích hợp và tận dụng passkey và thông tin xác thực kỹ thuật số một cách hiệu quả là rất quan trọng để tăng cường bảo mật, cải thiện trải nghiệm người dùng và đáp ứng các yêu cầu quy định. Phần này phân tích cách các RP có thể triển khai các công nghệ này trong các kịch bản và hệ sinh thái phổ biến khác nhau.

Chiến lược tích hợp tối ưu cho passkey và thông tin xác thực kỹ thuật số thay đổi đáng kể dựa trên trường hợp sử dụng cụ thể và hồ sơ rủi ro cũng như các yêu cầu liên quan. Bảng sau đây cung cấp một so sánh cấp cao giữa các kịch bản phổ biến:

So sánh các kịch bản hệ sinh thái

Chú thích:

• Vai trò của VC 🆔: Mô tả vai trò trong tương tác chính, thừa nhận rằng VC thường được sử dụng để giới thiệu ban đầu/KYC trong các kịch bản.
• Cần liên kết thiết bị? 🔗: Đề cập đến nhu cầu liên kết thiết bị rõ ràng ngoài liên kết nguồn gốc passkey tiêu chuẩn, đặc biệt liên quan đến passkey được đồng bộ hóa.
• Yêu cầu bắt buộc về Ví EUDI của EU*: Kịch bản này phản ánh các yêu cầu theo quy định eIDAS 2 sắp tới, dự kiến sẽ áp dụng sau khoảng 36 tháng kể từ khi các văn bản thực thi cuối cùng có hiệu lực (có thể là cuối những năm 2020).

So sánh này cung cấp một cái nhìn tổng quan nhanh; các phần sau sẽ đi sâu vào chi tiết của từng kịch bản từ góc độ tích hợp của RP.

• Mục tiêu: Truy cập nhanh, ít trở ngại với bảo mật cơ bản tốt.
• Luồng có khả năng xảy ra:
  • Xác thực chính: Passkey sẽ chiếm ưu thế. Khả năng chống lừa đảo (phishing) và UX liền mạch (thường chỉ cần sinh trắc học/PIN) của chúng làm cho chúng trở nên lý tưởng để thay thế mật khẩu trong các kịch bản đăng nhập thường xuyên.
  • Vai trò của thông tin xác thực kỹ thuật số: Tối thiểu cho việc đăng nhập cốt lõi. VC có thể được sử dụng tùy chọn sau khi đăng nhập cho các hành động cụ thể như xác minh tuổi (ví dụ: mua hàng hóa bị hạn chế), cá nhân hóa dựa trên các thuộc tính đã được xác minh (ví dụ: trạng thái khách hàng thân thiết), hoặc hoàn thành hồ sơ nhanh chóng trong quá trình đăng ký ban đầu.
• Tương tác: Passkey xử lý việc đăng nhập cốt lõi; VC được dành riêng cho các tương tác tùy chọn, dựa trên thuộc tính.

• Mục tiêu: Đăng nhập đảm bảo cao và, khi cần thiết, khẳng định danh tính đã được xác minh.
• Luồng có khả năng xảy ra:
  • Passkey là 2FA/MFA độc lập: Passkey vốn đã đáp ứng các yêu cầu xác thực hai yếu tố khi xác minh người dùng (PIN/sinh trắc học) xảy ra trong quá trình đăng nhập. Chúng kết hợp:
    • Sở hữu: Bằng chứng về quyền kiểm soát khóa riêng tư.
    • Kiến thức/Vốn có: Xác minh người dùng qua PIN hoặc sinh trắc học. Điều này làm cho việc đăng nhập bằng passkey trở thành một phương thức MFA mạnh mẽ, chống lừa đảo, đủ cho nhiều kịch bản yêu cầu đảm bảo cao mà không cần một bước thứ hai riêng biệt chỉ để đạt được 2FA.
  • Nâng cao để xác minh danh tính (Một lần): Nhu cầu chính về một bước bổ sung với Thông tin xác thực kỹ thuật số xuất hiện khi dịch vụ phải xác minh danh tính một cách rõ ràng ngoài việc chỉ xác thực một người dùng quay trở lại. Loại kiểm tra mật mã mạnh mẽ này rất quan trọng khi deepfake có thể giả mạo ID bằng hình ảnh hoặc tài liệu một cách thuyết phục. Chỉ có bằng chứng mật mã kỹ thuật số từ một nguồn đáng tin cậy mới có thể xác nhận một thuộc tính một cách đáng tin cậy. Điều này có thể cần thiết:
    • Trong quá trình giới thiệu ban đầu.
    • Đối với các hành động có rủi ro cao cụ thể yêu cầu các thuộc tính danh tính đã được xác nhận. Trong những trường hợp này, RP yêu cầu một bản trình bày Thông tin xác thực có thể xác minh cụ thể (ví dụ: PID, thông tin xác thực ID quốc gia) từ ví của người dùng sau khi đăng nhập bằng passkey.
  • Danh tính để khôi phục: Một khi danh tính của người dùng đã được xác minh mạnh mẽ (ví dụ: qua bước nâng cao trình bày VC), thông tin danh tính đã được xác minh này có thể được tận dụng trong các luồng khôi phục tài khoản an toàn. Ví dụ, nếu người dùng mất tất cả các trình xác thực passkey của họ, việc trình bày một thông tin xác thực danh tính đảm bảo cao có thể là một phần của quy trình để lấy lại quyền truy cập và đăng ký passkey mới.
• Tương tác: Passkey cung cấp 2FA/MFA mạnh mẽ, độc lập để xác thực. VC được sử dụng một cách chiến lược để xác minh danh tính rõ ràng khi được yêu cầu, và danh tính đã được xác minh này cũng có thể hỗ trợ các cơ chế khôi phục tài khoản an toàn.

• Mục tiêu: Thanh toán hoặc khởi tạo thanh toán hợp lý, an toàn, giảm thiểu trở ngại cho người dùng.
• Luồng có khả năng xảy ra:
  • Xác thực để thanh toán: Passkey là lý tưởng để xác thực người dùng với tài khoản Nhà cung cấp dịch vụ thanh toán (PSP) của họ (ví dụ: PayPal) hoặc trực tiếp trong luồng thanh toán của nhà bán hàng. Điều này thay thế mật khẩu và cung cấp một xác nhận nhanh chóng, an toàn để khởi tạo thanh toán.
  • Giới thiệu/KYC: VC vẫn rất quan trọng trong giai đoạn giới thiệu hoặc thiết lập tài khoản với PSP hoặc nhà bán hàng, cung cấp thông tin danh tính đã được xác minh (kiểm tra KYC/AML) cần thiết để kích hoạt khả năng thanh toán ngay từ đầu.
  • Lo ngại về trở ngại trong giao dịch: Việc giới thiệu một bước trình bày Thông tin xác thực có thể xác minh riêng biệt trong luồng ủy quyền thanh toán cốt lõi (yêu cầu tương tác với ví danh tính kỹ thuật số) sẽ thêm vào đáng kể trở ngại so với một bước xác nhận passkey liền mạch. Sự gián đoạn này đối với trải nghiệm người dùng có khả năng gây hại cho tỷ lệ chuyển đổi và do đó không phù hợp với các kịch bản thanh toán ít trở ngại điển hình.
• Tương tác: Passkey bảo vệ việc xác thực cho chính hành động thanh toán. VC xử lý việc chứng minh danh tính/KYC cần thiết, thường là một lần, để thiết lập tài khoản thanh toán, nhưng được giữ ngoài bước xác nhận thanh toán quan trọng, nhạy cảm với trở ngại. (Chủ đề phức tạp về việc sử dụng thông tin xác thực kỹ thuật số trực tiếp làm công cụ thanh toán, bao gồm cách các loại ví khác nhau và các API trình duyệt mới nổi có thể kích hoạt hoặc tương tác với các VC dành riêng cho thanh toán như vậy, được khám phá chi tiết trong bài viết bổ sung sắp tới của chúng tôi: Thông tin xác thực kỹ thuật số và Thanh toán.

• Mục tiêu: Truy cập ngân hàng an toàn với việc giảm đáng kể gian lận, đặc biệt là liên quan đến lừa đảo (phishing), bằng cách nâng cấp từ các phương thức xác thực cũ.
• Luồng có khả năng xảy ra:
  • Thay thế MFA cũ: Nhiều tổ chức tài chính hiện đang dựa vào mật khẩu kết hợp với các yếu tố thứ hai dễ bị lừa đảo như SMS OTP. Passkey cung cấp một giải pháp thay thế vượt trội hơn hẳn, cung cấp xác thực mạnh mẽ vốn có khả năng chống lừa đảo trong một cử chỉ duy nhất của người dùng.
  • Đăng nhập chính bằng Passkey: Việc áp dụng passkey để đăng nhập chính ngay lập tức tăng cường bảo mật do khả năng chống lừa đảo của chúng. Bản chất mật mã của passkey giảm thiểu các vectơ tấn công phổ biến nhất gây hại cho các thông tin xác thực truyền thống.
  • Nâng cao dựa trên rủi ro - Cân nhắc cẩn thận các tín hiệu thiết bị: Đối với các hoạt động có rủi ro cao hơn (ví dụ: chuyển khoản lớn, thay đổi chi tiết liên lạc), các tổ chức tài chính có thể xem xét xác minh nâng cao. Mặc dù các tín hiệu liên kết thiết bị liên quan đến passkey là một lựa chọn, sự cần thiết của chúng nên được đánh giá cẩn thận. Khả năng chống lừa đảo của chính việc xác thực passkey chính đã giảm thiểu đáng kể nhiều rủi ro.
  • Bảo mật dựa trên kết quả & Giảm thiểu gian lận: Việc giảm đáng kể rủi ro lừa đảo đạt được nhờ passkey là một yếu tố quan trọng. Một cách tiếp cận bảo mật dựa trên kết quả, tập trung vào sức mạnh và khả năng chống lừa đảo của phương thức xác thực, có thể dẫn đến giảm gian lận đáng kể. Trọng số của một yếu tố chống lừa đảo như passkey cao hơn đáng kể so với việc thêm nhiều yếu tố dễ bị lừa đảo hơn. Điều này phải là trung tâm trong chiến lược của một tổ chức tài chính khi chuyển đổi từ các phương pháp cũ.
  • VC cho việc giới thiệu/chứng minh danh tính: Như trong các kịch bản khác, VC vẫn cần thiết cho việc KYC/AML ban đầu mạnh mẽ và để cập nhật an toàn các thuộc tính danh tính khách hàng bằng thông tin đã được xác minh, thiết lập một nền tảng đáng tin cậy cho mối quan hệ ngân hàng.
• Tương tác: Passkey đóng vai trò là một phương thức xác thực chính mạnh mẽ, chống lừa đảo, giảm đáng kể rủi ro gian lận từ các hệ thống cũ. Tín hiệu thiết bị để nâng cao là một lựa chọn chiến thuật. Sức mạnh vốn có của passkey nên định hướng một tư thế bảo mật dựa trên rủi ro, có khả năng giảm sự phụ thuộc quá mức vào các yếu tố bổ sung, ít có khả năng chống lừa đảo hơn. VC cung cấp sự đảm bảo danh tính nền tảng.

• Mục tiêu: Tuân thủ các quy định eIDAS 2 (Điều 5f) yêu cầu các Bên tin cậy cụ thể (cơ quan công quyền, các tổ chức tư nhân lớn trong các lĩnh vực được quản lý, VLOP) chấp nhận Ví Danh tính Kỹ thuật số của EU, cho phép cả đăng nhập bằng định danh giả bảo vệ quyền riêng tư và xác minh danh tính/thuộc tính đảm bảo cao khi có yêu cầu pháp lý.
• Luồng có khả năng xảy ra:
  • Đăng nhập bằng định danh giả (Mặc định): Người dùng bắt đầu đăng nhập. RP yêu cầu xác thực qua Ví EUDI. Ví sử dụng "khóa định danh giả" tích hợp sẵn – một khóa thường trú WebAuthn được liên kết với phần cứng, có phạm vi RP và được lưu trữ trong phần tử bảo mật được chứng nhận của thiết bị (WSCD) – để xác thực người dùng. Điều này cung cấp xác thực mạnh mẽ, tuân thủ SCA (sở hữu + xác minh người dùng) trong khi vẫn giữ danh tính dân sự của người dùng ở dạng định danh giả theo mặc định.
  • Nâng cao để xác minh danh tính/thuộc tính (Yêu cầu pháp lý): Chỉ khi RP có cơ sở pháp lý cụ thể theo luật của Liên minh hoặc quốc gia (ví dụ: PSD2, AML, đăng ký viễn thông) để yêu cầu xác minh danh tính hoặc các thuộc tính cụ thể, nó mới bắt đầu một bước thứ hai. RP yêu cầu một bản trình bày (qua OpenID4VP) của Dữ liệu Nhận dạng Cá nhân (PID) hoặc Chứng thực Thuộc tính Đủ điều kiện (QAA) cần thiết từ ví. Người dùng phải đồng ý rõ ràng để chia sẻ dữ liệu nhận dạng này.
  • Xác thực Ví & RP: Luồng này bao gồm xác thực lẫn nhau. RP tự xác thực với ví (dựa trên đăng ký chính thức của nó), và ví chứng thực tính xác thực của nó và tính hợp lệ của thông tin xác thực cho RP, tận dụng phần cứng bảo mật (WSCD) và cơ sở hạ tầng chứng nhận liên quan.
• Tương tác: Ví EUDI hoạt động như một trình xác thực hợp nhất. Passkey WebAuthn tích hợp của nó (khóa định danh giả) xử lý việc đăng nhập tiêu chuẩn, cung cấp xác thực mạnh mẽ, bảo vệ quyền riêng tư. Khả năng VC của ví được gọi một cách có chọn lọc để tiết lộ danh tính hoặc thuộc tính rõ ràng, theo yêu cầu của pháp luật, đảm bảo giảm thiểu dữ liệu theo mặc định.

Việc điều hướng trong bối cảnh đang phát triển này đòi hỏi phải có kế hoạch chiến lược. Dưới đây là những cân nhắc chính cho các Bên tin cậy (RP)

Đối với các RP, hành động chính hiện nay nên là kích hoạt và khuyến khích sử dụng passkey để xác thực. Passkey đã được chuẩn hóa, được các nền tảng hỗ trợ rộng rãi và mang lại những lợi ích lớn, tức thì về bảo mật (chống lừa đảo) và trải nghiệm người dùng (đăng nhập nhanh hơn, dễ dàng hơn). Điều này có nghĩa là ít phụ thuộc hơn vào mật khẩu và các phương thức MFA không an toàn như SMS OTP. Nó cũng có thể giảm chi phí hỗ trợ từ việc đặt lại mật khẩu và khôi phục tài khoản. Hướng tới việc sử dụng passkey rộng rãi sẽ thiết lập một nền tảng hiện đại, an toàn cho việc xác thực người dùng. Mặc dù việc áp dụng ban đầu có thể chậm, việc giáo dục người dùng về lợi ích trước và làm cho việc đăng ký dễ dàng có thể giúp họ bắt đầu.

Mặc dù bản thân passkey đã là một bước tiến đáng kể hướng tới xác thực mạnh mẽ và có thể đáp ứng các yêu cầu Xác thực khách hàng mạnh (SCA), một số tổ chức có thể có các khuôn khổ tuân thủ nội bộ với những diễn giải thậm chí còn nghiêm ngặt hơn hoặc các mối quan tâm cụ thể, đặc biệt là về passkey được đồng bộ hóa. Đối với các Bên tin cậy (RP) đối mặt với các kịch bản như vậy, nơi các bộ phận tuân thủ tìm kiếm thêm sự đảm bảo, việc biết rằng các biện pháp bổ sung có thể bổ sung cho việc triển khai passkey là rất hữu ích. Những biện pháp này có thể giúp giải quyết các lỗ hổng SCA được nhận thấy hoặc đáp ứng các yêu cầu nội bộ cao hơn đó. Một chiến lược phổ biến là tận dụng các tín hiệu tin cậy của thiết bị, một cách tiếp cận được các dịch vụ như PayPal thực hiện.

PayPal, chẳng hạn, cho phép người dùng đánh dấu một thiết bị là "đã ghi nhớ" như được mô tả trên trang trợ giúp của họ:

Điều này có nghĩa là nếu người dùng đăng nhập bằng mật khẩu của họ (thứ họ biết) từ một thiết bị đã ghi nhớ (thứ họ có), PayPal có thể coi điều này là đủ cho SCA trong nhiều trường hợp. Tuy nhiên, họ cũng tuyên bố, "Có thể có những trường hợp chúng tôi vẫn yêu cầu bạn xác minh thêm để đảm bảo tài khoản của bạn được an toàn." Điều này có thể bao gồm việc gửi mã một lần qua SMS hoặc yêu cầu xác nhận qua ứng dụng PayPal.

Cách tiếp cận này cho phép trải nghiệm người dùng mượt mà hơn trên các thiết bị đáng tin cậy trong khi vẫn cung cấp các cơ chế cho xác thực nâng cao khi rủi ro cao hơn hoặc quy định yêu cầu. Các RP có thể xem xét các mô hình tương tự, nơi sự kết hợp giữa xác thực chính (như passkey) và sự tin cậy của thiết bị (có thể được quản lý bên ngoài các cơ chế trực tiếp của WebAuthn nếu cần) có thể giúp thu hẹp các lỗ hổng tuân thủ SCA. Tuy nhiên, để có một cách tiếp cận tích hợp và chuẩn hóa hơn đối với các tín hiệu tin cậy dành riêng cho thiết bị trong chính khuôn khổ WebAuthn, sự chú ý đang hướng về các phát triển đang diễn ra trong lĩnh vực đó.

Đối với các phương pháp tích hợp WebAuthn như vậy để tăng cường độ tin cậy của thiết bị, các RP trong môi trường bảo mật cao nên hiểu rõ lịch sử và định hướng tương lai. Các đề xuất tiện ích mở rộng WebAuthn trước đây, như devicePubKey và supplementalPubKeys, nhằm cung cấp các tín hiệu tin cậy dành riêng cho thiết bị này. Đây là những nỗ lực để giải quyết các cân nhắc về bảo mật của passkey được đồng bộ hóa, vốn mang lại khả năng sử dụng quan trọng cho việc áp dụng hàng loạt, nhưng lại giới thiệu các hồ sơ rủi ro khác nhau (ví dụ: phụ thuộc vào việc khôi phục tài khoản đám mây) so với các khóa gắn với thiết bị. Ý tưởng đằng sau các tiện ích mở rộng như vậy là cho phép các RP có thêm một lớp đảm bảo bằng cách kiểm tra chữ ký từ một khóa được liên kết cụ thể với thiết bị vật lý đang được sử dụng, ngay cả khi chính passkey chính được đồng bộ hóa.

Mặc dù các tiện ích mở rộng cụ thể này (devicePubKey và supplementalPubKeys) đã bị ngừng, thách thức trong việc có được các tín hiệu liên kết thiết bị mạnh hơn cho passkey được đồng bộ hóa vẫn còn đó. Do đó, các RP nên theo dõi sự phát triển và chuẩn hóa của các giải pháp kế thừa trong lĩnh vực này. Các giải pháp như vậy có thể giúp các RP đánh giá rủi ro tốt hơn (ví dụ: phân biệt một lần đăng nhập từ một thiết bị đã biết, đáng tin cậy với một thiết bị mới được đồng bộ hóa) mà không buộc tất cả người dùng phải sử dụng các passkey gắn với thiết bị kém tiện lợi hơn. Bối cảnh này đặt ra cho các RP một lựa chọn phức tạp hơn là chỉ "đồng bộ hóa so với gắn với thiết bị." Passkey được đồng bộ hóa (thường tuân thủ AAL2) mang lại sự tiện lợi nhất và cơ hội áp dụng tốt nhất, rất quan trọng cho các ứng dụng tiêu dùng. Passkey gắn với thiết bị (có thể là AAL3) mang lại sự đảm bảo cao nhất nhưng có thể khó sử dụng hơn. Mục tiêu của các tiện ích mở rộng đã ngừng là tìm ra một con đường trung gian—cải thiện bảo mật cho các khóa được đồng bộ hóa bằng cách thêm lại một tín hiệu tin cậy dành riêng cho thiết bị. Điều này có thể giúp giảm một số rủi ro nếu việc đồng bộ hóa đám mây bị xâm phạm, mà không làm mất đi tất cả sự tiện lợi của việc đồng bộ hóa. Do đó, các RP nên tìm kiếm các giải pháp kế thừa nhằm mục đích này. Chiến lược tốt nhất sẽ phụ thuộc vào khả năng chấp nhận rủi ro cụ thể của RP, cơ sở người dùng và mức độ trưởng thành của bất kỳ tiêu chuẩn mới nào.

Ngoài các cơ chế cụ thể trong WebAuthn để tin cậy thiết bị, một số Bên tin cậy (RP)—đặc biệt là những bên trong các lĩnh vực như ngân hàng, bảo hiểm và dịch vụ thanh toán—đang bắt đầu đánh giá thông tin xác thực kỹ thuật số (Verifiable Credentials, hay VC) như một thành phần bổ sung, hoặc thậm chí là bước tiếp theo, trong chiến lược nhận dạng và bảo mật của họ.

Một yếu tố quan trọng thúc đẩy sự quan tâm này là sự liên kết thiết bị mạnh mẽ thường đi kèm với thông tin xác thực kỹ thuật số, đặc biệt khi được quản lý trong các ví danh tính kỹ thuật số an toàn. Những chiếc ví này có thể tận dụng bảo mật dựa trên phần cứng (như Secure Enclaves hoặc TPM) để bảo vệ thông tin xác thực và các khóa riêng tư được sử dụng để trình bày chúng. Các bên phát hành và nhà cung cấp ví cũng có thể thực thi các chính sách làm cho một số thông tin xác thực có giá trị cao trở nên gắn liền với thiết bị, mang lại một mức độ kiểm soát hấp dẫn cho các kịch bản yêu cầu đảm bảo cao.

Điều quan trọng là phải nhận ra rằng mặc dù khả năng liên kết thiết bị nâng cao này là một tính năng hấp dẫn đối với các RP này, mục đích chính của thông tin xác thực kỹ thuật số (chứng thực các thuộc tính và tuyên bố) khác với mục đích của passkey (xác thực người dùng). Passkey xác nhận người dùng là ai, trong khi thông tin xác thực kỹ thuật số xác nhận điều gì là đúng về người dùng. Mặc dù có sự khác biệt cơ bản về mục đích này, các đặc tính bảo mật mạnh mẽ của VC được giữ trong ví khiến chúng trở thành một lĩnh vực được các RP tích cực xem xét nhằm bổ sung thêm các lớp đảm bảo. Điều này tự nhiên dẫn cuộc thảo luận đến các nhà cung cấp những chiếc ví danh tính kỹ thuật số này và hệ sinh thái cho phép phát hành, lưu trữ và trình bày các thông tin xác thực như vậy.

Trong khi passkey cung cấp xác thực trực tiếp, thông tin xác thực kỹ thuật số (VC) được quản lý và trình bày cho các Bên tin cậy thông qua ví danh tính kỹ thuật số. Những chiếc ví này, dù là giải pháp nền tảng gốc (như Apple Wallet, Google Wallet) hay các ứng dụng của bên thứ ba (chẳng hạn như Ví EUDI), đang phát triển để sử dụng các tiêu chuẩn trình duyệt mới nổi như API Thông tin xác thực kỹ thuật số để xác minh danh tính trực tuyến mượt mà hơn (ví dụ: kiểm tra tuổi, chia sẻ các thuộc tính ID kỹ thuật số).

Cơ chế chi tiết của các loại ví khác nhau, các chiến lược nền tảng cụ thể để tích hợp VC (bao gồm việc Apple tập trung vào mDoc cho các tương tác trình duyệt so với sự hỗ trợ OpenID4VP rộng hơn của Android thông qua Trình quản lý thông tin xác thực của nó), cách những chiếc ví này tạo điều kiện cho việc chứng thực thuộc tính, và các cân nhắc hoàn toàn riêng biệt cho bất kỳ chức năng thanh toán nào là những chủ đề phức tạp. Những vấn đề này được khám phá sâu trong bài viết bổ sung sắp tới của chúng tôi: Thông tin xác thực kỹ thuật số và Thanh toán.

Bài viết hiện tại này vẫn tập trung vào sự tương tác nền tảng giữa passkey để xác thực và vai trò chung của thông tin xác thực kỹ thuật số để chứng thực các thuộc tính.

Passkey và thông tin xác thực kỹ thuật số, mặc dù khác nhau về mục đích chính, đại diện cho hai trụ cột của một tương lai danh tính kỹ thuật số hiện đại, an toàn hơn và lấy người dùng làm trung tâm. Hiểu cách chúng liên quan và có thể hỗ trợ lẫn nhau là chìa khóa để xây dựng làn sóng dịch vụ trực tuyến tiếp theo.

Dựa trên tình hình hiện tại và quỹ đạo của các công nghệ này, hai hành động chính nổi bật cho các Bên tin cậy:

• Triển khai passkey ở mọi nơi ngay hôm nay: Các tiêu chuẩn đã trưởng thành, sự hỗ trợ của nền tảng đã rộng rãi, và những lợi ích so với mật khẩu là rõ ràng và đáng kể. Hãy biến passkey thành mục tiêu mặc định cho việc xác thực người dùng để tăng cường bảo mật và khả năng sử dụng ngay lập tức.
• Thêm bước xác thực nâng cao qua ví ở những nơi cần tuân thủ AML/KYC: Đối với các quy trình yêu cầu đảm bảo cao hơn hoặc các thuộc tính đã được xác minh cụ thể – chẳng hạn như đáp ứng các quy định Chống rửa tiền (AML) / Nhận biết khách hàng (KYC), thực hiện xác minh tuổi đáng tin cậy, hoặc xác nhận trình độ chuyên môn – hãy tích hợp các luồng trình bày Thông tin xác thực có thể xác minh để có được các thuộc tính có thể xác minh bằng mật mã, vốn không thể thiếu để tin tưởng vào danh tính và các tuyên bố trong thời đại của các giả mạo kỹ thuật số và deepfake tinh vi. Sử dụng API Thông tin xác thực kỹ thuật số khi khả thi, nhưng triển khai các phương án dự phòng QR/liên kết sâu mạnh mẽ để đảm bảo phạm vi tiếp cận đa nền tảng cho đến khi API ổn định. Điều này cung cấp sự đảm bảo cao có mục tiêu mà không gây gánh nặng cho mỗi lần đăng nhập.

Nhìn về phía trước, chúng ta có thể mong đợi nhiều sự hội tụ và cải tiến hơn:

• Cải thiện khả năng di chuyển thông tin xác thực: Các phương pháp chuyển giao từ thiết bị này sang thiết bị khác có khả năng sẽ tốt hơn. Điều này có thể vượt ra ngoài xác thực chéo thiết bị CTAP 2.2 cho passkey để bao gồm các cách mượt mà hơn để di chuyển VC giữa các ví, mặc dù việc chuẩn hóa ở đây chưa tiến xa bằng.
• Hợp nhất các API trình duyệt: API Thông tin xác thực kỹ thuật số có thể sẽ trưởng thành và được hỗ trợ nhất quán hơn trên các trình duyệt. Điều này sẽ cung cấp cho các RP một cách chuẩn hóa hơn để yêu cầu cả passkey và VC thông qua navigator.credentials.
• Trải nghiệm người dùng hợp nhất: Cuối cùng, người dùng sẽ thấy ít sự khác biệt kỹ thuật hơn giữa việc xác thực bằng passkey và trình bày các thuộc tính bằng VC. Các trình quản lý thông tin xác thực và ví của nền tảng có khả năng sẽ quản lý các tương tác này một cách trơn tru ở hậu trường. Họ sẽ sử dụng các công cụ mật mã và phần cứng bảo mật được chia sẻ, cho phép người dùng chỉ cần phê duyệt các yêu cầu bằng các lời nhắc sinh trắc học hoặc PIN quen thuộc, bất kể là passkey hay VC được sử dụng. Hơn nữa, các khái niệm như Xác thực thụ động liên tục (CPA), liên tục xác minh người dùng ở chế độ nền bằng sinh trắc học hành vi và các tín hiệu khác, có thể nâng cao hơn nữa tính bảo mật liền mạch này, có khả năng hoạt động cùng với các trình xác thực chủ động như passkey.

Để đạt được tương lai tích hợp này sẽ cần nhiều nỗ lực hơn về tiêu chuẩn, cách các nền tảng hỗ trợ chúng và cách các ứng dụng sử dụng chúng. Bằng cách sử dụng passkey ngay bây giờ và thêm thông tin xác thực kỹ thuật số một cách chu đáo, các tổ chức có thể sẵn sàng cho sự thay đổi này sang một thế giới kỹ thuật số không mật khẩu và trao cho người dùng nhiều quyền kiểm soát hơn đối với dữ liệu của họ.