API Chứng thực Số (2025): Chrome & Safari đã chính thức hỗ trợ

Cập nhật lần cuối: 30 tháng 10, 2025

Dưới đây là tổng quan nhanh về việc hỗ trợ API Chứng thực Số trên các trình duyệt lớn:

Thế giới chứng thực số đang phát triển rất nhanh. Dưới đây là tổng hợp các cột mốc quan trọng và dự báo:

Want to experience digital credentials in action?

Try Digital Credentials

Có gì thay đổi từ tháng 7, 2025?

• Đã phát hành: Chrome 141 (30/09/2025) & Safari 26 (15/09/2025).
• Chrome: Không phụ thuộc giao thức (OpenID4VP và ISO 18013-7 Phụ lục C), hỗ trợ đa thiết bị trên desktop qua CTAP.
• Safari: Chỉ hỗ trợ mdoc (org-iso-mdoc), luồng đa thiết bị qua CTAP.
• Cấu trúc API: navigator.credentials.get(); cách đặt tên requests/data; phát hiện tính năng DigitalCredential.

Chứng thực số đang là một chủ đề nóng trong lĩnh vực định danh hiện nay. Khi cuộc sống của chúng ta ngày càng kết nối với thế giới kỹ thuật số, nhu cầu về các phương thức an toàn, lấy người dùng làm trung tâm và bảo vệ quyền riêng tư để khẳng định danh tính và bằng cấp trực tuyến chưa bao giờ quan trọng hơn thế. Các phương pháp truyền thống đang cho thấy sự lỗi thời, và nhu cầu về các giải pháp mạnh mẽ hơn là rất rõ rệt.

Trong bài viết này, chúng ta sẽ thảo luận về tình hình hiện tại của API Chứng thực Số, một bước phát triển quan trọng hứa hẹn sẽ định hình lại cách chúng ta tương tác với thông tin định danh trên web. Chúng ta sẽ khám phá các cơ chế nền tảng, các giao thức mà nó hỗ trợ, tình hình áp dụng trên các trình duyệt hiện tại, và đưa ra các khuyến nghị cho cả bên tin cậy và bên phát hành wallet khi điều hướng trong bối cảnh đang phát triển nhanh chóng này.

Việc chứng minh danh tính một cách đáng tin cậy và an toàn đã là một thách thức dai dẳng trong kiến trúc của web trong nhiều năm. Mặc dù internet đã tạo điều kiện cho sự kết nối và trao đổi thông tin chưa từng có, nó cũng mở ra những con đường mới cho việc mạo danh và gian lận.

Ở một số quốc gia, các giải pháp đã xuất hiện, chủ yếu được thúc đẩy bởi các hiệp hội ngân hàng thời kỳ đầu đã phát triển các dịch vụ để tận dụng các mối quan hệ tin cậy hiện có cho việc định danh trực tuyến. Chính phủ cũng đã vào cuộc, thực thi hoặc cung cấp các ví và dịch vụ định danh số quốc gia. Tuy nhiên, các giải pháp này thường bị cô lập, giới hạn về mặt địa lý và không thể tương tác phổ biến.

Giải pháp thay thế cho xác minh danh tính ở nhiều khu vực theo truyền thống liên quan đến các quy trình có độ phức tạp cao. Ví dụ, xác minh thực tế tại bưu điện gây ra sự chậm trễ và bất tiện đáng kể. Cuộc gọi video kết hợp với việc tải lên tài liệu đã trở thành một giải pháp thay thế kỹ thuật số hơn, theo sau là sự trỗi dậy gần đây của việc quét tài liệu tự động và kiểm tra sự sống (liveness checks). Mặc dù có những tiến bộ, các phương pháp này có những nhược điểm đáng kể. Chúng có thể tốn thời gian, dễ bị lỗi hoặc thiên vị của con người, và thường xuyên bị phát hiện là dễ bị tấn công bởi các kỹ thuật giả mạo tinh vi.

Thách thức đang leo thang một cách đáng kể với sự ra đời của deepfake, các kỹ thuật mạo danh tiên tiến do AI điều khiển, và các cuộc tấn công lừa đảo ngày càng tinh vi. Những công nghệ này có thể tạo ra các bằng chứng video, âm thanh và tài liệu rất thực tế nhưng hoàn toàn bịa đặt, khiến cho các hệ thống truyền thống, và ngay cả các công cụ xác minh dựa trên AI, cũng vô cùng khó khăn để phân biệt người dùng thật với kẻ gian lận. Khả năng tạo ra danh tính tổng hợp hoặc thao túng dữ liệu sinh trắc học để vượt qua các khâu kiểm tra là một mối đe dọa nghiêm trọng, đặc biệt đối với các tổ chức tài chính và bất kỳ dịch vụ nào yêu cầu các quy trình Nhận biết Khách hàng (KYC) mạnh mẽ. Bối cảnh mối đe dọa ngày càng gia tăng này nhấn mạnh nhu cầu cấp thiết về các cơ chế định danh và xác minh trực tuyến an toàn hơn, có thể xác minh bằng mật mã.

Want to experience digital credentials in action?

Try Digital Credentials

Để hiểu cách chứng thực số hoạt động, chúng ta cần xem xét các bên tham gia chính và các lớp công nghệ khác nhau cho phép chúng hoạt động.

Về cơ bản, khái niệm về chứng thực số, đặc biệt trong bối cảnh của các API web mới, xoay quanh một mô hình ba bên:

1. Bên phát hành (Issuer): Một thực thể (ví dụ: chính phủ, trường đại học, nhà tuyển dụng) có thẩm quyền đối với một số thông tin nhất định về một chủ thể và có thể cấp một chứng thực số chứng nhận thông tin đó.
2. Người nắm giữ (Holder): Chủ thể của thông tin (tức là người dùng) nhận chứng thực từ bên phát hành và lưu trữ nó trong một ví kỹ thuật số (digital wallet). Người nắm giữ kiểm soát thời điểm và thông tin nào từ chứng thực được chia sẻ.
3. Bên xác minh (Verifier) (hoặc Bên tin cậy (Relying Party)): Một thực thể (ví dụ: một trang web, một dịch vụ trực tuyến) cần xác minh một số thông tin nhất định về người nắm giữ để cấp quyền truy cập vào một dịch vụ hoặc tài nguyên. Bên xác minh yêu cầu thông tin cần thiết từ người nắm giữ.

Mô hình ba bên này rất quan trọng vì nó nhằm mục đích đặt người dùng (người nắm giữ) vào quyền kiểm soát dữ liệu của chính họ. Không giống như các hệ thống định danh truyền thống nơi dữ liệu có thể được lưu trữ tập trung hoặc chia sẻ giữa các bên mà không có sự trung gian trực tiếp của người dùng, mô hình này nhấn mạnh sự đồng ý của người dùng và việc tiết lộ có chọn lọc. Người nắm giữ quyết định chia sẻ những mẩu thông tin nào từ một chứng thực cho một giao dịch cụ thể, thay vì tiết lộ toàn bộ chứng thực.

Một khía cạnh cơ bản của các hệ thống này là sự tham gia của các cặp khóa mật mã. Bên phát hành ký số vào chứng thực, đảm bảo tính xác thực và toàn vẹn của nó. Người nắm giữ, lần lượt, sử dụng khóa riêng của họ, thường được bảo mật trong ví kỹ thuật số của họ (được bảo vệ bởi phần cứng thiết bị), để chứng minh quyền kiểm soát đối với chứng thực và để ủy quyền trình diện nó cho một bên xác minh. Điều này thường liên quan đến việc bên xác minh đưa ra một thử thách (một mẩu dữ liệu ngẫu nhiên) mà ví của người nắm giữ sẽ ký bằng khóa riêng liên quan đến chứng thực. Bên xác minh sau đó có thể sử dụng khóa công khai tương ứng để xác nhận chữ ký, do đó xác thực việc trình diện.

Giải thích này không phụ thuộc vào giao thức cụ thể, vì các nguyên tắc cốt lõi về phát hành, nắm giữ và xác minh thông qua các thử thách mật mã là chung cho các công nghệ nền tảng khác nhau.

Bài viết này tập trung vào việc xác minh chứng thực số và nguyên tắc tiết lộ có chọn lọc, cho phép người dùng chứng minh các thuộc tính cụ thể (ví dụ: "Tôi trên 18 tuổi," "Tôi có giấy phép lái xe hợp lệ") mà không cần tiết lộ toàn bộ tài liệu gốc. Mặc dù các hệ thống nền tảng cho chứng thực số có thể hỗ trợ các tính năng như Chữ ký Điện tử Đủ điều kiện (QES) và khả năng ký từ xa (như thấy trong các giải pháp toàn diện như Ví Định danh Số của EU cho các chữ ký có giá trị pháp lý), trọng tâm ở đây, đặc biệt đối với API Chứng thực Số, là về khẳng định danh tính và xác minh thuộc tính cho các tương tác trực tuyến, chứ không phải chủ yếu về các chức năng ký rộng hơn này.

Để hiểu cách chứng thực số hoạt động, sẽ hữu ích nếu hình dung một mô hình phân lớp. Mỗi lớp giải quyết một khía cạnh khác nhau của hệ sinh thái, từ chính định dạng dữ liệu đến cách nó được trình diện cho người dùng trong trình duyệt web. Bài viết này chủ yếu tập trung vào API Chứng thực Số, hoạt động ở lớp trình diện.

Thuật ngữ cốt lõi:

• Chứng thực số (Digital credential): Bất kỳ chứng thực nào có thể đọc được bằng máy (PDF có mã vạch, ISO mDL, W3C VC, SD-JWT, v.v.). "Kỹ thuật số" không nói lên điều gì về khả năng xác minh bằng mật mã.
• Chứng thực có thể xác minh (Verifiable Credential): Một loại chứng thực số, được định nghĩa bởi Mô hình Dữ liệu W3C VC. Nó bổ sung bằng chứng chống giả mạo và bằng chứng mật mã, và nó luôn tồn tại trong một thế giới ba bên: bên phát hành → người nắm giữ → bên xác minh.
• API Chứng thực có thể xác minh (Verifiable Credential API): Một giao diện dịch vụ REST/HTTP để phát hành, lưu trữ, trình diện và xác minh VC giữa các hệ thống back-end (bên phát hành, wallets, bên xác minh).
• API Chứng thực Số (Digital Credentials API - DC API): Một API của trình duyệt / hệ điều hành (JavaScript + các thành phần gốc) cho phép một trang web yêu cầu wallet phía thiết bị của người dùng trình diện bất kỳ chứng thực số nào được hỗ trợ (VC, ISO mDoc, SD-JWT…) theo cách tôn trọng quyền riêng tư.

Hãy nghĩ về VCs như một mô hình dữ liệu, VC API như một đặc tả back-end, và DC API là việc triển khai front-end để trình diện các chứng thực cho Web. Mọi thứ trên lớp 1 (Lớp mô hình dữ liệu) đều không phụ thuộc vào định dạng; mọi thứ bên dưới phụ thuộc vào định dạng của chứng thực.

Luồng end-to-end (ví dụ: xác minh tuổi trực tuyến):

1. Phát hành (VC API - bên phát hành ↔ wallet): Sở GTVT tiểu bang cấp một Chứng thực có thể xác minh nói rằng "Người nắm giữ trên 18 tuổi".
2. Lưu trữ (Ứng dụng Wallet - HĐH): Chứng thực nằm trong wallet của người dùng cùng với bằng chứng mật mã của nó.
3. Yêu cầu (navigator.credentials.get() qua DC API - website → trình duyệt): Trang web cửa hàng bia yêu cầu: "Cho tôi xem bằng chứng người dùng ≥18 tuổi."
4. Trình diện (DC API chuyển đến wallet → OpenID4VP (giao thức) → payload VC): Wallet hiển thị giao diện người dùng yêu cầu sự đồng ý, người dùng chấp thuận, wallet gửi lại một trình diện có thể xác minh.
5. Xác minh (VC API - back-end của cửa hàng bia): Back-end của trang web xác minh chữ ký và DID/khóa công khai của bên phát hành; cấp quyền truy cập.

Hãy chú ý cách dữ liệu là một VC, phương tiện truyền tải trên Web là DC API, giao thức trao đổi bên dưới là OpenID4VP, và việc kiểm tra phía máy chủ sử dụng VC API.

Tại sao lại có sự phân chia này:

• Mô hình dữ liệu có thể tương tác (bằng chứng mật mã, tiết lộ có chọn lọc): Được giải quyết bởi Mô hình Dữ liệu VC (& các định dạng khác).
• Các điểm cuối REST tiêu chuẩn cho hệ thống back-end: Được giải quyết bởi VC API.
• Bắt tay giữa Wallet ↔ Trang web mà vẫn bảo vệ quyền riêng tư: Được giải quyết bởi DC API.
• Các mức độ tin cậy / loại tài liệu khác nhau (ID chính phủ so với chứng chỉ khóa học): Được giải quyết bằng cách sử dụng định dạng phù hợp (ISO mDoc cho ID có độ đảm bảo cao; W3C VC cho các xác nhận chung) bên dưới DC API.

Những điểm chính cần nhớ:

1. "Chứng thực số" là thuật ngữ bao trùm.
2. Chứng thực có thể xác minh là một loại chứng thực số có khả năng xác minh bằng mật mã tích hợp sẵn.
3. VC API là các thành phần server-to-server cho các hoạt động vòng đời của VC.
4. API Chứng thực Số là cầu nối giữa trình duyệt và wallet, cuối cùng cho phép các chứng thực đó luân chuyển trơn tru vào các ứng dụng Web, bất kể chúng ở định dạng cụ thể nào.
5. Ba phần này bổ sung cho nhau, không cạnh tranh—chúng nằm ở các lớp khác nhau của cùng một ngăn xếp và cùng nhau tạo nên một hệ thống định danh an toàn, lấy người dùng làm trung tâm trên Web mở.

Sau khi đã khám phá các bên tham gia và kiến trúc phân lớp tổng thể của chứng thực số, bài viết này bây giờ sẽ đi sâu hơn vào lớp trình diện, đặc biệt tập trung vào API Chứng thực Số và tình hình hiện tại của nó.

Là thành phần quan trọng ở lớp trình diện, API Chứng thực Số là một tiêu chuẩn web đang được phát triển để cung cấp một cách an toàn và được tiêu chuẩn hóa cho các trang web yêu cầu và nhận thông tin định danh số từ các wallet kỹ thuật số của người dùng. Nỗ lực này chủ yếu được thực hiện trong Nhóm Công tác Định danh Liên kết của W3C (FedID WG), sau khi chuyển từ Nhóm Cộng đồng FedID vào tháng 4, 2025. Bản dự thảo đặc tả chính thức có thể được tìm thấy tại đây: https://w3c-fedid.github.io/digital-credentials/.

Tính đến tháng 10 năm 2025, API này đã được phát hành trong các phiên bản ổn định của cả Chrome 141 (30/09/2025) và Safari 26 (15/09/2025). Việc triển khai của Chrome không phụ thuộc vào giao thức, hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C, trong khi Safari chỉ hỗ trợ độc quyền giao thức org-iso-mdoc. Chrome hỗ trợ điều này một cách tự nhiên trên Android thông qua hệ thống Credential Manager và cũng hỗ trợ API Chứng thực Số Đa thiết bị trên máy tính để bàn thông qua cơ chế chuyển giao QR được hỗ trợ bởi CTAP/BLE.

API này mở rộng API Quản lý Thông tin xác thực (Credential Management API) hiện có bằng cách cho phép yêu cầu chứng thực số thông qua navigator.credentials.get(). Theo W3C FedID WG Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), API đã quay trở lại sử dụng giao diện đã được thiết lập này thay vì navigator.identity được đề xuất trước đây. Một trang web yêu cầu một chứng thực số bằng cách gọi navigator.credentials.get() với các tham số cụ thể cho chứng thực số.

Dưới đây là một ví dụ minh họa về cách một trang web có thể gọi API để yêu cầu một chứng thực bằng OpenID4VP:

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Ví dụ này được lấy từ đây.

API Chứng thực Số về cơ bản hoạt động như một lớp bao bọc hoặc trung gian an toàn. Nó cho phép trình duyệt làm trung gian cho yêu cầu thông tin định danh, tận dụng khả năng của hệ điều hành nền tảng để khám phá các wallet và chứng thực có sẵn phù hợp với yêu cầu. Trình duyệt và hệ điều hành sau đó có thể trình bày một giao diện người dùng nhất quán để chọn chứng thực và ủy quyền phát hành, tăng cường bảo mật và quyền riêng tư bằng cách đảm bảo sự đồng ý của người dùng và ngăn chặn các trang web truy cập âm thầm vào dữ liệu nhạy cảm. Dữ liệu chứng thực thực tế trong phản hồi được dự định là không thể đọc được (được mã hóa) đối với chính trình duyệt, với việc giải mã và diễn giải được xử lý bởi bên tin cậy và wallet/người nắm giữ.

API Chứng thực Số được thiết kế để không phụ thuộc vào giao thức, có nghĩa là nó có thể hỗ trợ nhiều giao thức nền tảng khác nhau để trao đổi chứng thực. Tuy nhiên, có hai họ giao thức chính là trung tâm của các triển khai và thảo luận hiện tại: org.iso.mdoc (bắt nguồn từ ISO 18013-5 và phần mở rộng của nó ISO 18013-7 "Phụ lục C") và các đặc tả OpenID for Verifiable Presentations (OpenID4VP) và OpenID for Verifiable Credential Issuance (OpenID4VCI) của OpenID Foundation.

• Nguồn gốc và Tiêu chuẩn hóa: org.iso.mdoc đề cập đến định dạng dữ liệu và mô hình tương tác cho các tài liệu di động, chủ yếu là Giấy phép Lái xe Di động (mDLs), được tiêu chuẩn hóa bởi Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) và Ủy ban Kỹ thuật Điện Quốc tế (IEC). Tiêu chuẩn nền tảng là ISO/IEC 18013-5, định nghĩa ứng dụng mDL, cấu trúc dữ liệu và các giao thức cho việc trình diện trực tiếp (gần) bằng các công nghệ như NFC, Bluetooth hoặc mã QR. ISO/IEC 18013-7 mở rộng điều này để cho phép trình diện mDLs trực tuyến/từ xa. Chuỗi giao thức "org.iso.mdoc" được định nghĩa cụ thể trong ISO/IEC TS 18013-7 (Phụ lục C) để sử dụng với các API như API Chứng thực Số.

• Mô hình Dữ liệu: mdocs có cấu trúc dữ liệu được định nghĩa nghiêm ngặt dựa trên CBOR (Concise Binary Object Representation) cho sự nhỏ gọn và hiệu quả. Nó chỉ định các không gian tên và các phần tử dữ liệu cho các thuộc tính giấy phép lái xe phổ biến và hỗ trợ các tính năng bảo mật mật mã mạnh, bao gồm xác thực bên phát hành, liên kết thiết bị, xác thực người nắm giữ (qua ảnh chân dung), mã hóa phiên và tiết lộ có chọn lọc.

• Các trường hợp sử dụng điển hình: Chủ yếu là các tài liệu định danh do chính phủ cấp như giấy phép lái xe và thẻ căn cước quốc gia. Nó được thiết kế cho các kịch bản có độ đảm bảo cao, cả trực tiếp (ví dụ: kiểm tra giao thông, xác minh tuổi đối với hàng hóa bị hạn chế) và trực tuyến (ví dụ: truy cập các dịch vụ của chính phủ, xác minh danh tính từ xa để mở tài khoản ngân hàng).

• Nguồn gốc và Tiêu chuẩn hóa: OpenID4VP (để trình diện) và OpenID4VCI (để phát hành) là các đặc tả được phát triển bởi OpenID Foundation. Chúng mở rộng OAuth 2.0 để hỗ trợ việc trao đổi chứng thực có thể xác minh. Đây là các tiêu chuẩn mở nhằm mục đích tương tác rộng rãi cho nhiều loại chứng thực khác nhau, không chỉ của chính phủ. Tính đến đầu năm 2025, OpenID4VP đang ở giai đoạn dự thảo nâng cao (ví dụ: dự thảo 28 vào tháng 4). OpenID4VCI cũng đang hoàn thiện.
• Mô hình Dữ liệu: OpenID4VP/VCI được thiết kế để không phụ thuộc vào định dạng chứng thực. Chúng có thể mang Chứng thực có thể xác minh của W3C (VCs) ở định dạng JSON/JSON-LD hoặc JWT, mdocs, SD-JWTs, và các định dạng khác. Mô hình tương tác bao gồm một Yêu cầu Ủy quyền từ Bên xác minh (RP) và một phản hồi từ Wallet của Người nắm giữ chứa một vp_token (Verifiable Presentation Token). Việc tiết lộ có chọn lọc thường được quản lý bằng các ngôn ngữ truy vấn như Presentation Exchange (DIF PE) hoặc Digital Credentials Query Language (DCQL) mới hơn.
• Các trường hợp sử dụng điển hình: Phạm vi ứng dụng rộng rãi, bao gồm xác minh danh tính, cung cấp bằng chứng về trình độ (ví dụ: bằng tốt nghiệp, chứng chỉ chuyên môn), chứng thực tư cách thành viên, và nhiều hơn nữa. Chúng rất phù hợp cho các tương tác trực tuyến nơi một bên tin cậy cần xác minh các tuyên bố từ các bên phát hành khác nhau.

Điều quan trọng là phải nhận ra rằng chúng không phải lúc nào cũng loại trừ lẫn nhau. Ví dụ, OpenID4VP có thể được sử dụng để yêu cầu và vận chuyển một [org.iso.mdoc]. Sự lựa chọn thường phụ thuộc vào trường hợp sử dụng cụ thể, loại chứng thực và các bên tham gia trong hệ sinh thái.

Ví Định danh Số của Liên minh Châu Âu (EUDI) là một sáng kiến lớn nhằm cung cấp cho tất cả công dân và cư dân EU một ví kỹ thuật số an toàn cho các tài liệu định danh và chứng thực. Kiến trúc và khung tham chiếu của Ví EUDI có kế hoạch rõ ràng để hỗ trợ cả mdoc (đặc biệt cho Giấy phép Lái xe Di động) và Chứng thực có thể xác minh của W3C, sử dụng OpenID4VP và OpenID4VCI cho các luồng trình diện và phát hành. Việc triển khai tham chiếu bao gồm hỗ trợ OpenID4VP truyền mDocs và OpenID4VCI để phát hành PID và mDLs ở các định dạng mDoc và SD-JWT-VC formats. Sự hỗ trợ kép này của một dự án quy mô lớn như vậy nhấn mạnh tầm quan trọng của cả hai họ giao thức. Tuy nhiên, hướng đi này không phải không có chỉ trích, vì một số nhà quan sát lưu ý rằng API Chứng thực Số, bị ảnh hưởng nhiều bởi các công ty "Bigtech của Mỹ", có thể trở thành một phần sâu sắc trong các đặc tả cuối cùng của Ví EUDI. Các mối lo ngại đã được nêu ra về ảnh hưởng tiềm tàng của các thực thể ngoài EU đối với một phần quan trọng của cơ sở hạ tầng EU, như đã được thảo luận trong các diễn đàn cộng đồng như cuộc thảo luận trên GitHub này.

Bối cảnh trình duyệt cho API Chứng thực Số hiện đã định hình, với Chrome 141 và Safari 26 đã phát hành hỗ trợ ổn định vào tháng 9 năm 2025. Có những khác biệt đáng chú ý trong cách tiếp cận và mức độ hỗ trợ giữa các trình duyệt.

Chrome đã phát hành API Chứng thực Số trong Chrome 141 (30/09/2025). Việc triển khai của Chrome không phụ thuộc vào giao thức: tương thích với OpenID4VP và ISO 18013-7 Phụ lục C (mdoc trực tuyến). Desktop hỗ trợ trình diện đa thiết bị từ các wallet di động thông qua một kênh được hỗ trợ bởi CTAP/BLE (chuyển giao QR), với phản hồi không thể đọc được đối với trình duyệt. Cấu trúc API đã chuyển sang navigator.credentials.get(); các tham số được đổi tên: providers → requests, request → data.

Phát hiện tính năng:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Credential Manager của Android hỗ trợ tự nhiên OpenID4VP để trình diện và OpenID4VCI để phát hành, cho phép các ứng dụng Android hoạt động như những người nắm giữ và xác minh chứng thực bằng các tiêu chuẩn này. Google ghi nhận sự hỗ trợ ngày càng tăng từ các wallet; Google Wallet là một trong những người tiên phong, với Samsung Wallet và 1Password đã được công bố.

Trong các phiên bản trước của bài viết này, chúng tôi đã dự đoán rằng cách tiếp cận của Apple sẽ khác với của Google bằng cách tập trung vào giao thức org.iso.mdoc. Để cung cấp bối cảnh lịch sử, lý do của chúng tôi như sau:

Như chúng tôi đã dự đoán chính xác, WWDC25 đã xác nhận chiến lược này. Safari 26 (iOS/iPadOS/macOS) đã được phát hành vào ngày 15/09/2025 với hỗ trợ API Chứng thực Số, xác nhận rằng việc triển khai của họ chỉ hỗ trợ độc quyền giao thức org-iso-mdoc (có gạch nối) để trình diện.

Điều này đã được trình bày chi tiết trong phiên WWDC25 Xác minh tài liệu định danh trên web. API cho phép các trang web yêu cầu thông tin có thể xác minh từ các tài liệu định danh, chẳng hạn như giấy phép lái xe, được lưu trữ trong Apple Wallet hoặc trong các ứng dụng cung cấp tài liệu của bên thứ ba.

Những điểm chính từ việc triển khai của Apple:

• Chỉ hỗ trợ MDOC: API chỉ sử dụng độc quyền chuỗi giao thức "org-iso-mdoc", dựa trên tiêu chuẩn ISO/IEC 18013-7 Phụ lục C. Không có hỗ trợ cho OpenID4VP trong việc triển khai API Chứng thực Số của Safari.
• Chỉ Trình diện: API dùng để trình diện (xác minh) các chứng thực hiện có. Việc phát hành vào Apple Wallet hoặc các ứng dụng khác vẫn là một quy trình riêng biệt, không qua trình duyệt.
• Lấy người dùng làm trung tâm & An toàn: Luồng được khởi tạo bởi một hành động của người dùng và tận dụng cơ chế "yêu cầu một phần", nơi hệ điều hành trước tiên phân tích và xác thực yêu cầu trong một môi trường sandbox trước khi chuyển nó đến ứng dụng wallet, tăng cường bảo mật.
• Có thể mở rộng cho các ứng dụng: Ngoài Apple Wallet, các ứng dụng của bên thứ ba có thể hoạt động như những nhà cung cấp tài liệu bằng cách triển khai framework IdentityDocumentServices mới và một phần mở rộng ứng dụng.
• Hỗ trợ đa thiết bị: Trình diện đa thiết bị từ các nền tảng không phải của Apple sử dụng CTAP để xác định vị trí gần sau khi chuyển giao bằng mã QR; phản hồi JS vẫn được mã hóa/không thể đọc được đối với trình duyệt.

Apple đã cung cấp một ví dụ mã rõ ràng về cách một bên tin cậy sẽ sử dụng API:

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Sự xác nhận này củng cố các chiến lược khác nhau trên thị trường trình duyệt. Trong khi Chrome xây dựng trên lớp vận chuyển OpenID4VP linh hoạt, Apple đang tận dụng sự đầu tư sâu của mình vào hệ sinh thái mdoc của ISO để cung cấp một giải pháp tích hợp cao và an toàn, mặc dù ít linh hoạt hơn, được thiết kế riêng cho các tài liệu định danh chính thức.

Mozilla đã chính thức bày tỏ quan điểm tiêu chuẩn tiêu cực về API Chứng thực Số ở dạng hiện tại. Các mối quan ngại của họ rất toàn diện và bắt nguồn từ sứ mệnh bảo vệ quyền riêng tư của người dùng, quyền tự quyết và đảm bảo một web mở, công bằng.

Các mối quan ngại chính được Mozilla nêu ra bao gồm:

• Rủi ro về quyền riêng tư: Tiềm năng tăng cường chia sẻ dữ liệu cá nhân và giảm tính ẩn danh trực tuyến nếu các yêu cầu về chứng thực số trở nên phổ biến cho các tương tác không quan trọng.
• Loại trừ người dùng: Rủi ro rằng những cá nhân không thể hoặc chọn không sử dụng chứng thực số có thể bị loại khỏi các dịch vụ và cộng đồng trực tuyến. Chứng thực do chính phủ cấp, một trường hợp sử dụng chính, có thể không phù hợp với lựa chọn trình bày danh tính của một cá nhân.
• Vấn đề tương tác: Lo ngại về sự gia tăng của các định dạng chứng thực dẫn đến một hệ sinh thái bị phân mảnh thay vì một hệ sinh thái có thể tương tác phổ biến.
• Tiết lộ có chọn lọc: Lo lắng rằng các lợi ích về quyền riêng tư của việc tiết lộ có chọn lọc có thể bị suy yếu nếu không được thực hiện với các đảm bảo về tính không thể liên kết mạnh mẽ, hoặc nếu người dùng không hoàn toàn hiểu những gì đang được chia sẻ.
• Tập trung hóa niềm tin và quyền tự quyết của người dùng: Lo ngại rằng API có thể dẫn đến việc tăng cường tập trung hóa niềm tin và giảm quyền tự quyết của người dùng, duy trì sự mất cân bằng quyền lực xã hội hiện có.

Mozilla thừa nhận rằng một API như vậy có thể mang lại tiện ích so với các phương pháp đặc thù hiện có để trình diện chứng thực nhưng nhấn mạnh rằng các tính năng nền tảng web mới phải chứng tỏ được rằng chúng làm cho web tốt hơn về tổng thể và ưu tiên lợi ích của người dùng. Mặc dù một Hội đồng W3C đã bác bỏ một phản đối chính thức liên quan đến những lo ngại này (để cho phép công việc được tiến hành trong W3C thay vì các địa điểm có thể kém minh bạch hơn), Hội đồng đã khuyến nghị rằng Nhóm Công tác tích cực làm việc để giảm thiểu những tác hại tiềm tàng này.

Bảng 1: Hỗ trợ của Trình duyệt cho API & Giao thức Chứng thực Số (Tháng 10, 2025)

Đối với các tổ chức (Bên tin cậy hoặc RP) có ý định yêu cầu và xác minh chứng thực số từ người dùng, bối cảnh hiện tại đòi hỏi phải lập kế hoạch chiến lược cẩn thận.

Do Safari (phát hành 15/09/2025) chỉ hỗ trợ độc quyền các tương tác org-iso-mdoc trực tiếp (ISO 18013-7 Phụ lục C) thông qua API Chứng thực Số, và Chrome (phát hành 30/09/2025) không phụ thuộc vào giao thức hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C (mdoc), các RP muốn có phạm vi tiếp cận rộng nhất có thể nên chuẩn bị để hỗ trợ các tương tác dựa trên cả hai cách tiếp cận.

Điều này có nghĩa là kiến trúc hệ thống có thể:

1. Khởi tạo các yêu cầu chứng thực qua API navigator.credentials.get(), chỉ định các tham số giao thức khác nhau ("org-iso-mdoc" cho Safari hoặc "openid4vp" cho các luồng Chrome/OID4VP) dựa trên việc phát hiện trình duyệt hoặc khả năng của user agent.
2. Xử lý các phản hồi có thể đến trực tiếp ở định dạng mdoc (ISO 18013-7 Phụ lục C) hoặc dưới dạng vp_token qua OpenID4VP, sau đó cần được phân tích để trích xuất chứng thực cơ bản (có thể là một mdoc hoặc một định dạng VC khác).

Mặc dù điều này làm tăng thêm sự phức tạp, nhưng việc cố gắng buộc tất cả người dùng đi theo một con đường giao thức duy nhất có khả năng sẽ loại trừ một phần đáng kể người dùng, hoặc là những người dùng trên iOS hoặc những người dùng trên Chrome/Android, tùy thuộc vào con đường được chọn. Một cách tiếp cận thực dụng, mặc dù tốn nhiều công sức phát triển hơn, là xây dựng sự linh hoạt để xử lý cả hai.

Các Bên tin cậy phải nhận thức rõ rằng ngay cả khi yêu cầu cùng một mẩu thông tin logic (ví dụ: "người dùng có trên 21 tuổi không?"), cách điều này được định nghĩa trong một yêu cầu và cách nó được trả về trong một phản hồi có thể khác nhau đáng kể giữa một truy vấn mdoc trực tiếp và một truy vấn OpenID4VP (có thể sử dụng Presentation Exchange hoặc DCQL).

• Tiết lộ có chọn lọc của mdoc: org.iso.mdoc có các cơ chế riêng để tiết lộ có chọn lọc, thường liên quan đến việc bên phát hành tạo ra các hàm băm có muối (salted hashes) của từng phần tử dữ liệu. Wallet của người nắm giữ sau đó chỉ tiết lộ các phần tử được yêu cầu cùng với muối của chúng, cho phép bên xác minh xác nhận chúng so với các hàm băm mà không thấy các dữ liệu khác. Yêu cầu cho các phần tử cụ thể được gắn với các không gian tên và định danh phần tử dữ liệu được xác định trước trong tiêu chuẩn mdoc.
• Tiết lộ có chọn lọc của OpenID4VP: OpenID4VP thường sử dụng một ngôn ngữ truy vấn như Presentation Exchange (DIF PE) hoặc ngôn ngữ mới hơn là Digital Credentials Query Language (DCQL) được nhúng trong presentation_definition của yêu cầu. Điều này cho phép các RP chỉ định các loại chứng thực và các tuyên bố cá nhân mà họ cần. Wallet sau đó xây dựng một Trình diện có thể xác minh chỉ chứa thông tin được yêu cầu, nếu được hỗ trợ bởi định dạng chứng thực và wallet.

Các RP cần ánh xạ các yêu cầu dữ liệu cụ thể của họ vào các cấu trúc giao thức khác nhau này. Điều quan trọng là phải hiểu các sắc thái về cách tiết lộ có chọn lọc được thực hiện và yêu cầu trong mỗi giao thức để đảm bảo rằng chỉ có dữ liệu tối thiểu cần thiết được yêu cầu và xử lý, do đó tuân thủ các thực tiễn tốt nhất về quyền riêng tư và nguyên tắc tối thiểu hóa dữ liệu. Định dạng và cấu trúc của dữ liệu được tiết lộ trả về bởi wallet cũng có thể khác nhau, đòi hỏi logic phân tích và xác thực riêng biệt trên backend của RP.

Đối với các thực thể muốn phát hành chứng thực số và cung cấp các ứng dụng wallet cho người nắm giữ, môi trường hệ điều hành đóng một vai trò quan trọng.

Các nhà phát hành wallet phải đối mặt với các bối cảnh khác biệt rõ rệt trên iOS và Android liên quan đến việc tạo wallet, tích hợp hệ thống và tương tác với API Chứng thực Số.

• Android: Nhìn chung cung cấp một hệ sinh thái cởi mở hơn. Android Credential Manager bao gồm một Holder API cho phép các ứng dụng gốc của bên thứ ba đăng ký làm người nắm giữ chứng thực. Các ứng dụng nắm giữ đã đăng ký này sau đó có thể tham gia vào các luồng trình diện chứng thực do hệ thống làm trung gian, phản hồi các yêu cầu từ API Chứng thực Số (qua Chrome) hoặc các bên xác minh ứng dụng gốc. Android cũng hỗ trợ rõ ràng OpenID4VCI để phát hành chứng thực, cho phép người dùng chọn một wallet của bên thứ ba tương thích để nhận các chứng thực mới được cấp. Mặc dù các ứng dụng gốc là trọng tâm chính cho khả năng nắm giữ chứng thực đầy đủ, hệ thống được thiết kế để có sự tham gia rộng rãi hơn.

• iOS: Apple duy trì sự kiểm soát chặt chẽ hơn đối với hệ sinh thái của mình. Mặc dù các ứng dụng wallet của bên thứ ba có thể tồn tại trên App Store, khả năng của chúng để tích hợp sâu như những người nắm giữ chứng thực cấp hệ thống cho các chứng thực có độ đảm bảo cao (như mDLs dành cho Apple Wallet) thường phải tuân theo các quy trình và quyền cụ thể của Apple. Ví dụ, việc thêm một ID vào Apple Wallet là một luồng được kiểm soát liên quan đến các cơ quan cấp phát của tiểu bang và xác minh của Apple. Đối với API Chứng thực Số trong Safari, các tương tác có khả năng sẽ được quản lý chặt chẽ, với trọng tâm chính là org.iso.mdoc được trình diện từ các nguồn được ủy quyền, cụ thể là chính Apple Wallet và các ứng dụng cung cấp tài liệu của bên thứ ba đã đăng ký.

Cách tiếp cận "khu vườn có tường rào" của Apple đã được thiết lập rõ ràng, và việc triển khai chứng thực số của họ cũng không ngoại lệ. Tuy nhiên, WWDC25 đã làm rõ con đường cho sự tham gia của bên thứ ba.

Mặc dù Apple Wallet là nhà cung cấp chính, tích hợp sẵn cho các chứng thực như mDLs của tiểu bang, Apple đã giới thiệu framework IdentityDocumentServices cho các ứng dụng iOS gốc. Điều này cho phép các nhà phát triển bên thứ ba xây dựng các ứng dụng có thể cung cấp và trình diện các tài liệu định danh của riêng họ.

Để tham gia vào luồng web, một ứng dụng gốc phải:

1. Đăng ký Tài liệu: Sử dụng IdentityDocumentProviderRegistrationStore để đăng ký các mdocs mà ứng dụng quản lý với hệ điều hành. Việc đăng ký này bao gồm loại tài liệu và các cơ quan chứng thực đáng tin cậy để ký yêu cầu.
2. Triển khai Phần mở rộng Ứng dụng: Thêm một "Identity Document Provider" UI App Extension vào dự án. Phần mở rộng này chịu trách nhiệm hiển thị giao diện người dùng ủy quyền cho người dùng khi ứng dụng được chọn trong một luồng xác minh dựa trên web.

Điều này có nghĩa là trong khi việc tạo ra một wallet tích hợp đầy đủ trên iOS đòi hỏi phải xây dựng một ứng dụng gốc và sử dụng các framework cụ thể của Apple—chứ không phải các công nghệ web như PWA—có một cơ chế rõ ràng, mặc dù được kiểm soát chặt chẽ, để các ứng dụng của bên thứ ba hoạt động như những nhà cung cấp tài liệu bên cạnh Apple Wallet. Điều này xác nhận rằng tương tác với API Chứng thực Số trong Safari được quản lý bởi hệ điều hành, sau đó sẽ chuyển các yêu cầu đến Apple Wallet hoặc bất kỳ ứng dụng cung cấp tài liệu nào khác đã đăng ký và được ủy quyền.

API Chứng thực Số đại diện cho một bước tiến đáng kể trong không gian định danh số, cung cấp một cách tiếp cận an toàn hơn, lấy người dùng làm trung tâm và bảo vệ quyền riêng tư để xác minh danh tính và trình diện chứng thực. Với Chrome 141 (30/09/2025) và Safari 26 (15/09/2025) hiện đã phát hành hỗ trợ ổn định, API đã chuyển từ giai đoạn thử nghiệm sang sẵn sàng cho sản xuất. Khi hệ sinh thái tiếp tục phát triển, điều quan trọng là cả bên tin cậy và nhà phát hành wallet phải thích ứng và nắm bắt tiềm năng của công nghệ mới này. Chúng tôi sẽ tiếp tục cập nhật bài viết này khi bối cảnh thay đổi.

Tuy nhiên, những thách thức vẫn còn đó. Việc đạt được khả năng tương tác toàn cầu thực sự giữa các định dạng chứng thực, giao thức và triển khai wallet khác nhau là một nhiệm vụ quan trọng. Việc giải quyết các mối quan ngại xác đáng do các tổ chức như Mozilla nêu ra liên quan đến quyền riêng tư, sự loại trừ và quyền tự quyết của người dùng là điều tối quan trọng để đảm bảo những công nghệ này phục vụ nhân loại. Các cách tiếp cận khác nhau—triển khai không phụ thuộc giao thức của Chrome so với việc tập trung chỉ vào mdoc của Safari—có nghĩa là các bên tin cậy và nhà phát hành wallet phải điều hướng một bối cảnh đa giao thức trong tương lai gần.