API Thông tin xác thực kỹ thuật số (2025): Chrome & Safari (WWDC25)

Cập nhật lần cuối: 15 tháng 7, 2025 (sau sự kiện WWDC25)

Tổng quan nhanh về việc hỗ trợ Digital Credentials API trên các trình duyệt chính:

Thế giới thông tin xác thực kỹ thuật số đang phát triển nhanh chóng. Dưới đây là tổng quan về các mốc phát triển quan trọng và dự báo:

Thông tin xác thực kỹ thuật số (Digital credentials) đ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 số, nhu cầu về những cách 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à trình độ của mình trên mạng chưa bao giờ trở nên 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 trạng hiện tại của Digital Credentials API, một sự 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 nay, và đưa ra các khuyến nghị cho cả bên tin cậy (relying parties) và bên phát hành (issuer) đang điều hướng trong bối cảnh 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 việc 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à lừa đảo.

Ở 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 liên minh 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 dịch vụ và ví (wallet) định danh kỹ thuật 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 có khả năng tương tác phổ quát.

Giải pháp thay thế cho việc xác minh danh tính ở nhiều khu vực thường liên quan đến các quy trình phức tạp. Ví dụ, xác minh thực tế tại một 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ự gia tăng 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 do con người hoặc sai lệch, 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 (phishing) 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 do AI cung cấp cũng vô cùng khó khăn để phân biệt người dùng thật với kẻ lừa đảo. 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 bước 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 Biết khách hàng của bạn (KYC) mạnh mẽ. Bối cảnh mối đe dọa ngày càng leo thang này nhấn mạnh nhu cầu cấp thiết về các cơ chế xác minh và định danh trực tuyến an toàn hơn, có thể xác minh bằng mật mã.

Want to try digital credentials yourself in a demo?

Try Digital Credentials

Để hiểu cách thông tin xác thực kỹ thuật 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ốt lõi, khái niệm thông tin xác thực kỹ thuật 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 chỉ kỹ thuật số (digital credential) để chứng thực 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 chỉ từ bên phát hành (issuer) 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 chỉ đượ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 chỉ cho một giao dịch cụ thể, thay vì tiết lộ toàn bộ chứng chỉ.

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 (issuer) ký điện tử vào chứng chỉ, đảm bảo tính xác thực và toàn vẹn của nó. Người nắm giữ, đến lượt mình, sử dụng khóa riêng của họ, thường được bảo mật trong ví kỹ thuật số (wallet) 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 chỉ và ủy quyền trình bày 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í (wallet) của người nắm giữ sẽ ký bằng khóa riêng liên quan đến chứng chỉ. 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ý, qua đó xác thực việc trình bày.

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 thông tin xác thực kỹ thuật 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 thông tin xác thực kỹ thuật 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 kỹ thuật 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 Digital Credentials API, là về khẳng định (assertion) danh tính và xác minh thuộc tính cho các tương tác trực tuyến, không chủ yếu tập trung vào các chức năng ký rộng hơn này.

Để hiểu cách thông tin xác thực kỹ thuật số hoạt động, việc hình dung một mô hình phân lớp sẽ rất hữu ích. Mỗi lớp giải quyết một khía cạnh khác nhau của hệ sinh thái, từ định dạng dữ liệu đến cách nó được trình bày 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 Digital Credentials API, hoạt động ở lớp trình bày.

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

• Thông tin xác thực kỹ thuật số (Digital credential): Bất kỳ thông tin xác 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ã.
• Thông tin xác thực có thể xác minh (Verifiable Credential): Một loại thông tin xác thực kỹ thuật số, được định nghĩa bởi Mô hình dữ liệu W3C VC. Nó thêm 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 Thông tin xác 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 bày và xác minh các VC giữa các hệ thống back-end (bên phát hành, ví (wallet), bên xác minh).
• API Thông tin xác thực kỹ thuật 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 ví trên thiết bị của người dùng trình bày bất kỳ chứng chỉ kỹ thuật số (digital credential) nào được hỗ trợ (VC, ISO mDoc, SD-JWT …) một cách tôn trọng quyền riêng tư.

Hãy coi VC là một mô hình dữ liệu, VC API là một đặc tả back-end, và DC API là việc triển khai front-end để trình bày các thông tin xác 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 đều phụ thuộc vào định dạng của thông tin xác thực.

Luồng từ đầu đến cuối (ví dụ: xác minh tuổi trực tuyến):

1. Phát hành (VC API - bên phát hành ↔ ví): Sở Giao thông Vận tải của tiểu bang cấp một Thông tin xác thực có thể xác minh (Verifiable Credential) nói rằng "Người nắm giữ trên 18 tuổi".
2. Lưu trữ (Ứng dụng ví - HĐH): Thông tin xác thực nằm trong ví 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 - trang web → trình duyệt): Trang web của 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 bày (DC API chuyển đến ví → OpenID4VP (giao thức) → payload VC): Ví hiển thị giao diện người dùng yêu cầu sự đồng ý, người dùng chấp thuận, ví gửi lại một bản trình bày có thể xác minh (verifiable presentation).
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 (issuer); cấp quyền truy cập.

Lưu ý 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ó khả năng 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 các hệ thống back-end: Được giải quyết bởi VC API.
• Bắt tay giữa Ví ↔ Trang web 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 tuyên bố chung) bên dưới DC API.

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

1. "Thông tin xác thực kỹ thuật số (Digital credential)" là thuật ngữ bao trùm.
2. Thông tin xác thực có thể xác minh (Verifiable Credential) là một loại thông tin xác thực kỹ thuật số với khả năng xác minh bằng mật mã tích hợp.
3. VC API là hệ thống ống nước từ máy chủ đến máy chủ cho các hoạt động vòng đời trên VC.
4. Digital Credentials API là cầu nối giữa trình duyệt và ví, cuối cùng cho phép các thông tin xác thực đó chảy mượt mà 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 cho phép đị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 thông tin xác thực kỹ thuật số, bài viết này sẽ đi sâu hơn vào lớp trình bày, đặc biệt tập trung vào Digital Credentials API và tình trạng hiện tại của nó.

Là thành phần quan trọng ở lớp trình bày, Digital Credentials API là một tiêu chuẩn web hiện đang được phát triển để cung cấp một cách thức 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 kỹ thuật số từ ví (wallet) kỹ thuật số của người dùng. Nỗ lực này chủ yếu được đặt trong Nhóm làm việc về Đị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 năm 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 năm 2025, API này vẫn được mô tả là đang trải qua những thay đổi đáng kể. Điều này cho thấy giai đoạn phát triển tích cực của nó. Mặc dù vậy, tiềm năng của nó là rất lớn. Chrome là trình duyệt đầu tiên phát hành một phiên bản công khai, với Origin Trial, cho phép các nhà phát triển thử nghiệm các khả năng của nó. Chrome cũng 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à gần đây cũng đã công bố hỗ trợ sử dụng Digital Credentials API đa thiết bị (Cross-Device) trên máy tính để bàn.

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 thông tin xác thực kỹ thuật số thông qua navigator.credentials.get(). Theo tài liệu giải thích về Digital Credentials của W3C FedID WG (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 thông tin xác thực kỹ thuật số bằng cách gọi navigator.credentials.get() với các tham số cụ thể cho thông tin xác thực kỹ thuật số.

Đâ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 thông tin xác 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.

Digital Credentials API 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 các khả năng của hệ điều hành bên dưới để khám phá các ví và thông tin xác 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 thông tin xác thực và ủy quyền phát hành nó, 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 thông tin xác thực thực tế trong phản hồi được dự định là không rõ ràng (đượ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 (relying party) và ví/người nắm giữ (holder).

Digital Credentials API được thiết kế để không phụ thuộc vào giao thức, có nghĩa là nó có thể hỗ trợ các giao thức nền tảng khác nhau để trao đổi thông tin xác thực. Tuy nhiên, 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 để trình bày 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 bày mDL 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ư Digital Credentials API.

• 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) để đảm bảo tính 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 (issuer), 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 bày) 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 thông tin xác thực có thể xác minh. Đây là những tiêu chuẩn mở nhằm mục đích tương tác rộng rãi cho các loại thông tin xác 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 thông tin xác thực. Chúng có thể mang theo W3C Verifiable Credentials (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ừ Ví 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 (attestation) 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 (relying party) cần xác minh các tuyên bố từ các bên phát hành (issuer) 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 thông tin xác thực và các bên tham gia hệ sinh thái.

Ví định danh kỹ thuật 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ố (digital wallet) an toàn cho các tài liệu định danh và chứng thực (attestation). 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à W3C Verifiable Credentials, sử dụng OpenID4VP và OpenID4VCI cho các luồng trình bày và phát hành. Việc triển khai tham chiếu bao gồm hỗ trợ cho OpenID4VP chuyển mDocs và OpenID4VCI để phát hành PID và mDL ở đị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ó những lời chỉ trích, vì một số nhà quan sát lưu ý rằng Digital Credentials API, bị ảnh hưởng nhiều bởi các công ty "Bigtech của Mỹ", có thể được tích hợp sâu vào các đặc tả cuối cùng của Ví EUDI. Những 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 Digital Credentials API vẫn đang hình thành, với những khác biệt đáng chú ý trong cách tiếp cận và mức độ hỗ trợ.

Google Chrome, đặc biệt trên Android, đã là một trong những người sớm áp dụng và triển khai Digital Credentials API. Họ đã chạy các Origin Trial và tích hợp nó với Credential Manager gốc của Android. Việc triển khai của Chrome chủ yếu tận dụng OpenID4VP làm giao thức để yêu cầu thông tin xác thực thông qua lệnh gọi API navigator.credentials.get(). Mặc dù bản thân OpenID4VP không phụ thuộc vào định dạng và có thể mang theo org.iso.mdoc hoặc W3C Verifiable Credentials làm payload, sự nhấn mạnh thực tế từ Google dường như là vào luồng OpenID4VP như là cơ chế vận chuyển. Credential Manager của Android cũng hỗ trợ tự nhiên OpenID4VP để trình bày và OpenID4VCI để phát hành. Điều này cho phép các ứng dụng Android hoạt động như người nắm giữ và người xác minh thông tin xác thực bằng các tiêu chuẩn này.

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 Google bằng cách tập trung vào giao thức org.iso.mdoc. Để có 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. Tại hội nghị, Apple đã chính thức công bố hỗ trợ API trong Safari 26 (phát hành cùng với iOS 26 và các bản cập nhật hệ điều hành khác vào Mùa thu 2025), xác nhận rằng việc triển khai của họ chỉ hỗ trợ giao thức org.iso.mdoc để trình bày.

Đ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ỉ MDOC: API chỉ sử dụng 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 Digital Credentials API của Safari.
• Chỉ trình bày: API dùng để trình bày (xác minh) các thông tin xác 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 cử chỉ của người dùng và tận dụng cơ chế "yêu cầu một phần", trong đó 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 sandbox trước khi chuyển nó đến ứng dụng ví, tăng cường bảo mật.
• Có thể mở rộng cho ứng dụng: Ngoài Apple Wallet, các ứng dụng của bên thứ ba có thể hoạt động như các 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.

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 ISO mdoc để cung cấp một giải pháp tích hợp cao và an toàn, mặc dù kém 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 cực" về đề xuất Digital Credentials API hiện tại. Những lo 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 tâm 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ề thông tin xác thực kỹ thuật số trở nên phổ biến cho các tương tác thông thường.
• Loại trừ người dùng: Nguy cơ những cá nhân không thể hoặc chọn không sử dụng thông tin xác thực kỹ thuật số có thể bị loại khỏi các dịch vụ và cộng đồng trực tuyến. Thông tin xác 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 thông tin xác 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ó khả năng tương tác phổ quát.
• Tiết lộ có chọn lọc: Lo lắng rằng 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 triển khai 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 hiểu đầy đủ 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 bày thông tin xác 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 minh đượ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 tiếp tục 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 làm việ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 Digital Credentials API & Giao thức

Đố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 thông tin xác thực kỹ thuật 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.

Với việc Safari, với thị phần đáng kể, có khả năng ưu tiên các tương tác org.iso.mdoc trực tiếp thông qua Digital Credentials API, và Chrome/Android đang nhấn mạnh OpenID4VP (có thể mang theo mdocs hoặc các định dạng Verifiable Credential khác), 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 các hệ thống có thể:

1. Khởi tạo các yêu cầu thông tin xác thực qua API navigator.credentials.get(), có khả năng chỉ định các tham số giao thức khác nhau ("org.iso.mdoc" hoặc "openid4vp") 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 hoặc dưới dạng vp_token qua OpenID4VP, sau đó cần được phân tích để trích xuất thông tin xác thực cơ bản (bản thân 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, 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 trên iOS hoặc những người trên Android/Chrome, 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 giá trị băm có salt của các phần tử dữ liệu riêng lẻ. Ví 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 salt của chúng, cho phép bên xác minh xác nhận chúng so với các giá trị băm mà không thấy 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 Digital Credentials Query Language (DCQL) mới hơn đượ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 thông tin xác thực và các tuyên bố riêng lẻ mà họ cần. Ví sau đó xây dựng một Bản trình bày có thể xác minh (Verifiable Presentation) chỉ chứa thông tin được yêu cầu, nếu được hỗ trợ bởi định dạng thông tin xác thực và ví.

Các RP cần ánh xạ các yêu cầu dữ liệu cụ thể của họ với 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 triển khai và yêu cầu trong mỗi giao thức để đảm bảo rằng chỉ có dữ liệu cần thiết tối thiểu được yêu cầu và xử lý, qua đó tuân thủ các thực tiễn tốt nhất về quyền riêng tư và các 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ộ do ví trả về 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 thông tin xác thực kỹ thuật số và cung cấp các ứng dụng ví 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 bên phát hành (issuer) ví phải đối mặt với những bối cảnh khác biệt rõ rệt trên iOS và Android liên quan đến việc tạo ví, tích hợp hệ thống và tương tác với Digital Credentials API.

• Android: Thường cung cấp một hệ sinh thá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ữ thông tin xác 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 bày thông tin xác thực do hệ thống làm trung gian, phản hồi các yêu cầu từ Digital Credentials API (qua Chrome) hoặc các bên xác minh là ứng dụng gốc. Android cũng hỗ trợ rõ ràng OpenID4VCI để phát hành thông tin xác thực, cho phép người dùng chọn một ví của bên thứ ba tương thích để nhận thông tin xác 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 các khả năng nắm giữ thông tin xác 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 ví của bên thứ ba có thể tồn tại trên App Store, khả năng tích hợp sâu của chúng với tư cách là người nắm giữ thông tin xác thực cấp hệ thống cho các thông tin xác thực có độ đảm bảo cao (như mDL 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 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à quy trình xác minh của Apple. Đối với Digital Credentials API 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 bày 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 bao" (walled garden) của Apple đã được thiết lập rõ ràng, và việc triển khai thông tin xác thực kỹ thuật 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.

Trong khi Apple Wallet là nhà cung cấp chính, được tích hợp sẵn cho các thông tin xác thực như mDL 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 bày 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 mdoc 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 cấp chứng chỉ đáng tin cậy để ký yêu cầu.
2. Triển khai một App Extension: 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 một ví 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ư các nhà cung cấp tài liệu cùng với Apple Wallet. Điều này xác nhận rằng tương tác với Digital Credentials API 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 đã được đăng ký và ủy quyền.

Digital Credentials API đại diện cho một bước tiến đáng kể trong không gian định danh kỹ thuật 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ư hơn cho việc xác minh danh tính và trình bày thông tin xác thực. Khi hệ sinh thái phát triển, điều quan trọng là cả các bên tin cậy và các bên phát hành ví 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 thông tin xác thực, giao thức và các triển khai ví khác nhau là một công việc quan trọng. Việc giải quyết các mối quan tâm chính đáng được nêu ra bởi các tổ chức như Mozilla về quyền riêng tư, sự loại trừ và quyền tự quyết của người dùng là tối quan trọng để đảm bảo các công nghệ này phục vụ nhân loại. Sự phân mảnh hiện tại trong hỗ trợ trình duyệt và sự nhấn mạnh vào giao thức có nghĩa là các bên tin cậy và các bên phát hành ví phải điều hướng một bối cảnh phức tạp trong thời gian tới.