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

Cập nhật lần cuối: 26 tháng 3, 2026

Dưới đây là tổng quan nhanh về khả năng hỗ trợ Digital Credentials API (API Chứng thực Số) trên các trình duyệt chính:

Thế giới chứng thực số đang chuyển động rất nhanh. Dưới đây là tóm tắt các sự kiện quan trọng và dự báo:

Want to experience digital credentials in action?

Try Digital Credentials

Điều gì đã thay đổi kể từ tháng 10/2025?

• Thay đổi quản trị giao thức: W3C FedID WG đã loại bỏ sổ đăng ký giao thức mở tại TPAC (tháng 11/2025) và hiện quy định cứng các giao thức được hỗ trợ trực tiếp trong đặc tả: OpenID4VP, OpenID4VCI, và ISO 18013-7 Phụ lục C. API này không còn là một "ống dẫn đơn thuần" nữa.
• Tính năng phát hành đã đến: Chrome 143 đã ra mắt Origin Trial cho phát hành chứng thực thông qua navigator.credentials.create(), mở rộng khả năng của API ngoài việc chỉ trình bày.
• Firefox đang triển khai: Mặc dù lập trường tiêu chuẩn phủ định không thay đổi, Mozilla đã đưa mã DC API cơ bản vào Firefox 149 với công việc UX đang diễn ra.
• Yêu cầu có điều kiện từ EU: Khung Tham chiếu Kiến trúc EUDI (Chủ đề F) hiện yêu cầu có điều kiện về hỗ trợ DC API cho tất cả ví của các quốc gia thành viên.
• Áp dụng thực tế: DMV California đã thêm hỗ trợ DC API vào nền tảng OpenCred của họ (tháng 2/2026).

Chứng thực số (digital credentials) hiện đang là một chủ đề nóng trong không gian định danh. Khi cuộc sống của chúng ta ngày càng gắn liền 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ờ cấp thiết hơn thế. Các phương pháp truyền thống đang dần 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àng.

Trong bài viết này, chúng ta sẽ thảo luận về trạng thái hiện tại của Digital Credentials API, một bước phát triển quan trọng hứa hẹn đị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ơ chế hoạt động, các giao thức được hỗ trợ, tình hình áp dụng trên trình duyệt hiện nay và đưa ra các khuyến nghị cho cả các bên dựa vào (relying parties) lẫn bên phát hành ví đang điều hướng trong bối cảnh thay đổi 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 sự giả mạo 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 liên minh ngân hàng ban đầu phát triển dịch vụ để tận dụng các mối quan hệ tin cậy hiện có cho việc nhận diện trực tuyến. Chính phủ cũng tham gia, thực thi hoặc cung cấp các ví và dịch vụ đị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ề địa lý và không tương thích phổ quát.

Giải pháp thay thế cho xác minh danh tính ở nhiều khu vực theo truyền thống thường liên quan đến các quy trình có độ ma sát cao. Ví dụ, xác minh vật lý 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 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 thực thể sống (liveness checks). Bất chấp những tiến bộ, các phương pháp này vẫn có những hạn chế đáng kể. Chúng có thể tốn thời gian, dễ mắc lỗi do con người hoặc thiên kiến, và thường xuyên bị lộ là dễ bị tổn thương trước sự giả mạo tinh vi.

Thách thức đang leo thang mạnh mẽ với sự ra đời của deepfakes, các kỹ thuật giả mạo do AI điều khiển tiên tiế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 video, âm thanh và bằng chứng tài liệu giả mạo rất giống thật, khiến các hệ thống truyền thống, và thậm chí cả các công cụ xác minh hỗ trợ bởi AI, vô cùng khó khăn để phân biệt người dùng thật với kẻ gian lận. Tiềm 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 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 quy trình Know Your Customer (KYC) mạnh mẽ. Bối cảnh đe dọa 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 experience digital credentials in action?

Try Digital Credentials

Để hiểu cách thức hoạt động của chứng thực số, 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ức năng của chúng.

Về cốt lõi, khái niệm chứng thực số, đặc biệt trong bối cảnh các API web mới, xoay quanh 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 về một số thông tin nhất định về một chủ thể và có thể phát hành chứng thực số xác nhận thông tin đó.
2. Chủ sở hữu (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 ví kỹ thuật số. Chủ sở hữu kiểm soát khi nào và thông tin gì từ chứng thực được chia sẻ.
3. Bên xác minh (Verifier) (hoặc Relying Party): Một thực thể (ví dụ: trang web, dịch vụ trực tuyến) cần xác minh một số thông tin nhất định về chủ sở hữu để cấp quyền truy cập vào 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ừ chủ sở hữu.

Mô hình ba bên này quan trọng vì nó nhằm mục đích đặt người dùng (chủ sở hữu) vào quyền kiểm soát dữ liệu của chính họ. Khác với 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 thuận của người dùng và tiết lộ có chọn lọc. Chủ sở hữu quyết định chia sẻ những phần thông tin nào 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ó. Đổi lại, chủ sở hữu sử dụng khóa riêng của họ, thường được bảo mật trong ví kỹ thuật số (đượ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 bày nó cho bên xác minh. Việc này thường liên quan đến việc bên xác minh đưa ra một thách thức (một đoạn dữ liệu ngẫu nhiên) mà ví của chủ sở hữu ký bằng khóa riêng liên kết với chứng thực. Sau đó, bên xác minh 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 bày.

Giải thích này là trung lập về giao thức, 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ách thức 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ó bằng 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 cơ bản 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 Kỹ thuật số EU cho các chữ ký ràng buộc 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, 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ố vận hành, sẽ hữu ích khi 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ừ đị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:

• Digital credential (Chứng thực số): 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.). "Digital" (Số) không nói lên điều gì về khả năng xác minh bằng mật mã.
• Verifiable Credential (Chứng thực có thể xác minh): 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à luôn tồn tại trong thế giới ba bên: bên phát hành → chủ sở hữu → bên 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 VC giữa các hệ thống back-end (bên phát hành, ví, bên xác minh).
• Digital Credentials API (DC API): Một API trình duyệt / hệ điều hành (JavaScript + cơ chế native) 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 thực số được hỗ trợ nào (VC, ISO mDoc, SD-JWT...) theo cách tôn trọng quyền riêng tư.

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

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

Sơ đồ sau minh họa cách các lớp này làm việc cùng nhau trong một kịch bản thực tế.

Lưu ý rằng dữ liệu là một VC, phương thức 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 có sự phân chia này:

• Mô hình dữ liệu tương thích (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 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ủ vs chứng chỉ khóa học): Được giải quyết bằng cách sử dụng đúng định dạng (ISO mDoc cho ID đảm bảo cao; W3C VC cho các xác nhận chung) bên dưới DC API.

Điểm chính cần nhớ:

1. "Digital credential" (Chứng thực số) là thuật ngữ bao trùm.
2. Verifiable Credential là một loại chứng thực số có tích hợp khả năng xác minh bằng mật mã.
3. VC API là cơ chế kết nối máy chủ-tới-máy chủ cho các hoạt động vòng đời của VC.
4. Digital Credentials API là cầu nối trình duyệt-tới-ví giúp các chứng thực đó lưu thông mượt mà vào các ứng dụng Web, bất kể định dạng cụ thể của chúng là gì.
5. Ba mảnh ghép 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 (stack) 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 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 bày, cụ thể tập trung vào Digital Credentials API và trạng thái hiện tại của nó.

Là thành phần quan trọng tại 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 an toàn và 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ừ các ví của người dùng. Nỗ lực này chủ yếu nằm trong Nhóm làm việc Định danh Liên kết của W3C (FedID WG), đã 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 tháng 10 năm 2025, API đã được phát hành trong các phiên bản ổn định của cả Chrome 141 (30/9/2025) và Safari 26 (15/9/2025). Triển khai của Chrome hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C, trong khi Safari chỉ hỗ trợ duy nhất giao thức org-iso-mdoc.

Quan trọng (Cập nhật tháng 3/2026): Mối quan hệ của API với các giao thức đã thay đổi căn bản. Tại TPAC vào tháng 11/2025, W3C FedID WG đã đạt được sự đồng thuận để loại bỏ sổ đăng ký giao thức mở và thay vào đó quy định cứng một danh sách hữu hạn các giao thức được hỗ trợ trực tiếp trong đặc tả: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (để trình bày), và openid4vci-v1 (để phát hành). Các user agent (trình duyệt) được mong đợi sẽ từ chối các giao thức không có trong danh sách. Điều này biến Nhóm làm việc thành "người gác cổng" thực tế cho các bổ sung giao thức trong tương lai — một sự đánh đổi có chủ ý để cho phép đánh giá bảo mật và quyền riêng tư toàn diện cho mọi thứ lưu thông qua API (xem Dự thảo làm việc hiện tại).

Đặc tả hiện cũng bao gồm phát hành chứng thực thông qua navigator.credentials.create(). Chrome 143 đã ra mắt Origin Trial cho tính năng này, cho phép các trang web kích hoạt luồng cấp phép ví sử dụng OpenID4VCI. Tuy nhiên, một lỗ hổng ràng buộc lựa chọn ví — nơi một ứng dụng ví độc hại có thể chặn các mã ủy quyền trước khi phát hành — vẫn là một mối lo ngại mở. Các bên phát hành chính phủ đã chỉ ra rằng họ sẽ không áp dụng phát hành qua trung gian trình duyệt cho đến khi vấn đề này được giải quyết.

Chrome hỗ trợ trình bày native trên Android thông qua hệ thống Credential Manager và cũng hỗ trợ Digital Credentials API Đa thiết bị trên máy tính thông qua kênh CTAP/BLE (quét mã QR), với phản hồi được mã hóa/ẩn danh đối với trình duyệt.

API mở rộng 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 Bản giải thích Digital Credentials của W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), API đã quay lại sử dụng giao diện đã được thiết lập này thay vì navigator.identity được đề xuất trước đó. Một trang web yêu cầu 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 sử dụng OpenID4VP:

async function requestCredential() {
    // Kiểm tra hỗ trợ Digital Credentials API
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Các tham số này thường được lấy từ backend.
            // Được định nghĩa tĩnh ở đây cho mục đích minh họa khả năng mở rộng giao thức.
            const oid4vp = {
                protocol: "oid4vp", // Một ví dụ về yêu cầu OpenID4VP tới các ví. // Dựa trên https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // Yêu cầu Presentation Exchange, lược bỏ cho ngắn gọn
                    },
                },
            };
 
            // tạo một Abort Controller
            const controller = new AbortController();
 
            // Gọi Digital Credentials API sử dụng yêu cầu trình bày từ backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Gửi phản hồi đã mã hóa tới backend để giải mã và xác minh
            // Lược bỏ cho ngắn gọn
        } catch (error) {
            console.error("Lỗi:", error);
        }
    } else {
        // kịch bản dự phòng, chỉ mang tính minh họa
        alert("Digital Credentials API không được hỗ trợ trên trình duyệt này.");
    }
}

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

Digital Credentials API về cơ bản hoạt động như một lớp vỏ bảo mật hoặc trung gian. Nó cho phép trình duyệt điều phối yêu cầu thông tin định danh, tận dụng khả năng của hệ điều hành bên dưới để khám phá các ví và chứng thực có sẵn khớ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 nó, tăng cường bảo mật và quyền riêng tư bằng cách đảm bảo sự đồng thuận của người dùng và ngăn chặn các trang web truy cập ngầ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 thiết kế để trở nên mờ (đượ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 relying party và ví/chủ sở hữu.

Digital Credentials API ban đầu được thiết kế để hoàn toàn không phụ thuộc vào giao thức, hoạt động như một "ống dẫn đơn thuần" với một sổ đăng ký mở cho bất kỳ giao thức nào đăng ký. Tuy nhiên, kể từ tháng 1/2026, đặc tả hiện nêu tên rõ ràng các giao thức mà nó hỗ trợ — các user agent được mong đợi sẽ từ chối các giao thức không có trong danh sách. Hai họ giao thức chính hiện được quy định cứng trong đặc tả là: org.iso.mdoc (bắt nguồn từ ISO 18013-5 và phần mở rộng 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 tài liệu di động, chủ yếu là Giấy phép Lái xe Di động (mDL), đượ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 bày trực tiếp (gần) sử dụ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 chặt chẽ dựa trên CBOR (Concise Binary Object Representation) cho sự nhỏ gọn và hiệu quả. Nó chỉ định các namespace và 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 mẽ, bao gồm xác thực bên phát hành, ràng buộc thiết bị, xác thực chủ sở hữu (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ư bằng lái xe và căn cước công dân. Nó được thiết kế cho các kịch bản đảm bảo cao, cả trực tiếp (ví dụ: dừng xe kiểm tra giao thông, xác minh tuổi mua hàng hạn chế) và trực tuyến (ví dụ: truy cập dịch vụ 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 (cho trình bày) và OpenID4VCI (cho 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 thích rộng rãi cho nhiều loại chứng thực khác nhau, không chỉ 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 các Chứng thực có thể xác minh của W3C (VC) ở đị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 Chủ sở hữu chứa một vp_token (Token Trình bày Có thể xác minh). 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 Ngôn ngữ Truy vấn Chứng thực Số (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, bao gồm xác minh danh tính, cung cấp bằng chứng về trình độ (ví dụ: bằng cấp giáo dục, chứng chỉ chuyên môn), chứng nhận 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 relying party cần xác minh các tuyên bố từ nhiều 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 hệ sinh thái.

Ví Định danh Kỹ thuật số 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à W3C Verifiable Credentials, sử dụng OpenID4VP và OpenID4VCI cho các luồng trình bày và phát hành. Triển khai tham chiếu bao gồm hỗ trợ OpenID4VP chuyển giao mDoc và OpenID4VCI để phát hành PID và mDL ở các định dạng mDoc và SD-JWT-VC. Sự hỗ trợ kép này bởi 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.

Cập nhật tháng 3/2026: Cam kết của EU đối với Digital Credentials API đã trở nên cụ thể hơn. Chủ đề F trong Khung Tham chiếu Kiến trúc (ARF) của EUDI hiện yêu cầu có điều kiện rằng các Đơn vị Ví EUDI và Relying Party phải hỗ trợ DC API cho các luồng trình bày từ xa và phát hành chứng thực. Các điều kiện bao gồm việc DC API đạt trạng thái Khuyến nghị của W3C và đáp ứng các kỳ vọng về chức năng, tính trung lập của trình duyệt/hệ điều hành, quyền riêng tư và bảo vệ chống từ chối dịch vụ. Hiệp hội Ví Châu Âu (EWC) đã đưa các trường hợp kiểm thử DC API vào chương trình kiểm tra sự tuân thủ của mình, và liên minh NOBID đã hoàn thành các thí điểm thanh toán sử dụng OpenID4VP — cùng giao thức mà DC API hiện đang vận chuyển.

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 Digital Credentials API, chịu ảnh hưởng nặng nề bởi các công ty "Bigtech 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 lo ngại đã được nêu ra về ảnh hưởng tiềm tàng của các thực thể không thuộc EU đối với một phần quan trọng của cơ sở hạ tầng EU, như đã thảo luận trong các diễn đàn cộng đồng như cuộc thảo luận GitHub này. Riêng biệt, quyết định mã hóa cứng tham chiếu ISO 18013-7 trong đặc tả đã dẫn đến sự phản đối từ Ping Identity, lập luận rằng việc tham chiếu quy chuẩn đến một đặc tả phải trả phí xung đột với các nguyên tắc web mở — một mối lo ngại có thể nổi lên như một sự phản đối chính thức khi đặc tả chuyển sang giai đoạn Khuyến nghị Ứng viên (Candidate Recommendation).

Bối cảnh trình duyệt cho Digital Credentials API hiện đã hình thành, với Chrome 141 và Safari 26 phát hành hỗ trợ ổn định vào tháng 9/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 Digital Credentials API trong Chrome 141 (30/9/2025). Triển khai của Chrome là đa giao thức (protocol-agnostic): tương thích với OpenID4VP và ISO 18013-7 Phụ lục C (mdoc online). Máy tính để bàn hỗ trợ trình bày đa thiết bị (cross-device) từ ví di động thông qua kênh CTAP/BLE (quét mã QR), với phản hồi mờ (opaque) đối với trình duyệt. Hình dạng 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 được hỗ trợ
}

Hệ thống Credential Manager của Android hỗ trợ native OpenID4VP cho trình bày và OpenID4VCI cho phát hành, cho phép các ứng dụng Android hoạt động như người nắm giữ chứng thực (holder) và người xác minh (verifier) sử dụng các tiêu chuẩn này. Google ghi nhận sự hỗ trợ ngày càng tăng của ví; Google Wallet là người áp dụng sớm, 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 biệt so 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 là 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) đã phát hành vào ngày 15/9/2025 với hỗ trợ Digital Credentials API, xác nhận rằng triển khai của họ độc quyền hỗ trợ giao thức org-iso-mdoc (có gạch nối) để trình bày.

Điều này đã được trình bày chi tiết trong phiên Xác minh tài liệu định danh trên web tại WWDC25. 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ư bằng lái xe, được lưu trữ trong Apple Wallet hoặc trong các ứng dụng nhà cung cấp tài liệu bên thứ ba.

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

• Chỉ MDOC: API 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 triển khai Digital Credentials API của Safari.
• Chỉ Trình bày: API dành cho việc trình bày (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 & Bảo mật: Luồng được khởi tạo bởi 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 sandbox trước khi chuyển nó đến ứng dụng ví, tăng cường bảo mật.
• Mở rộng cho Ứng dụng: Ngoài Apple Wallet, các ứng dụng bên thứ ba có thể hoạt động như 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 (app extension).
• Hỗ trợ Đa thiết bị: Trình bày đa thiết bị từ các nền tảng không phải Apple sử dụng CTAP cho khoảng cách gần sau khi quét mã QR; phản hồi JS vẫn được mã hóa/mờ đối với trình duyệt.

Apple đã cung cấp một ví dụ mã rõ ràng về cách một relying party sẽ sử dụng API:

async function verifyIdentity() {
    try {
        // Máy chủ tạo và ký điện tử dữ liệu yêu cầu.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // Yêu cầu chỉ định giao thức 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data chứa yêu cầu mdoc đã được ký điện tử.
            data,
        };
 
        // API phải được gọi từ trong một cử chỉ của người dùng.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Gửi phản hồi đã mã hóa từ ví tới máy chủ để giải mã và xác thực.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Hiển thị chi tiết đã xác minh...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Xử lý lỗi, ví dụ: người dùng hủy bỏ.
    }
}

Sự xác nhận này củng cố các chiến lược khác biệt trong thị trường trình duyệt. Trong khi Chrome xây dựng dựa 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 ban đầu bày tỏ lập trường tiêu chuẩn phủ định về Digital Credentials API. Những lo ngại của họ, được ghi lại chi tiết, là toàn diện và bắt nguồn từ sứ mệnh bảo vệ quyền riêng tư người dùng, quyền tự quyết, và đảm bảo một web mở, công bằng.

Các lo ngại chính do Mozilla nêu ra bao gồm:

• Rủi ro Quyền riêng tư: Tiềm năng gia tăng việc 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 chứng thực số trở nên phổ biến cho các tương tác nhỏ nhặt.
• 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 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 cá nhân.
• Vấn đề Tương thích: Lo ngại về sự gia tăng các định dạng chứng thực dẫn đến một hệ sinh thái phân mảnh thay vì tương thích phổ quát.
• Tiết lộ có chọn lọc: Lo lắng rằng lợi ích 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 mạnh mẽ về tính không thể liên kết (unlinkability), 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 Sự tin cậy và Quyền tự quyết của Người dùng: Lo sợ rằng API có thể dẫn đến sự gia tăng tập trung hóa sự tin cậy 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ó.

Mặc dù một Hội đồng W3C đã bác bỏ sự 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ị 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.

Cập nhật tháng 3/2026 — Đang triển khai: Mặc dù lập trường phủ định chính thức vẫn về mặt kỹ thuật không thay đổi, Mozilla đã bắt đầu tích cực triển khai Digital Credentials API. Trong Quý 1/2026, hỗ trợ DC API cơ bản đã có trong Firefox 149 (ẩn sau cờ tùy chọn), được theo dõi dưới meta bug 2004828. Mã nguồn nằm trong mozilla-central, bao gồm DigitalCredential.cpp, liên kết WebIDL, và cơ chế IPC. Công việc trên các lời nhắc cấp quyền cho máy tính và Android (bug 2010091, bug 2010093) đang diễn ra.

Ba kỹ sư của Mozilla — John Schanck, Martin Thomson, và Benjamin VanderSloot — là thành viên tích cực của W3C FedID Working Group, và Schanck đã cung cấp phản hồi thực chất từ việc triển khai về các PR quan trọng của đặc tả bao gồm thuật toán trình bày chứng thực và thuật toán chuẩn bị yêu cầu.

Đây là một sự phát triển quan trọng: trong khi Mozilla duy trì các lo ngại về tiềm năng bị lạm dụng của API, họ rõ ràng đang chọn cách định hình API từ bên trong — thông qua cả công việc đặc tả và triển khai — thay vì nhường thiết kế cho các nhà cung cấp trình duyệt khác. Nó báo hiệu rằng Digital Credentials API có khả năng đang trên con đường hướng tới sự hỗ trợ của cả ba trình duyệt, mặc dù với việc Mozilla thúc đẩy các rào chắn quyền riêng tư mạnh mẽ hơn (bao gồm đề xuất về nhật ký minh bạch cho các yêu cầu chứng thực).

Bảng 1: Hỗ trợ Trình duyệt cho Digital Credentials API & Giao thức (Tháng 3/2026)

Đối với các tổ chức (Relying Parties hoặc RPs) 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 sự lập kế hoạch chiến lược cẩn thận.

Với việc Safari (phát hành 15/9/2025) độc quyền hỗ trợ tương tác trực tiếp org-iso-mdoc (ISO 18013-7 Phụ lục C) thông qua Digital Credentials API, và Chrome (phát hành 30/9/2025) là đa giao thức hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C (mdoc), các RP nhắm đến phạm vi tiếp cận rộng nhất 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 phải có khả năng xử lý cả hai luồng giao thức, như hình dưới đây.

Mặc dù điều này làm tăng độ phức tạp, việc cố gắng ép tất cả người dùng vào một luồng giao thức duy nhất có thể sẽ loại trừ một phần đáng kể cơ sở người dùng, hoặc những người trên iOS hoặc những người 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 Relying Party phải nhận thức sâu sắc rằng ngay cả khi yêu cầu cùng một phần 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 yêu cầu và cách nó được trả về trong phản hồi có thể khác biệt đáng kể giữa truy vấn mdoc trực tiếp và truy vấn OpenID4VP (có thể sử dụng Presentation Exchange hoặc DCQL).

• Tiết lộ có chọn lọc mdoc: org.iso.mdoc có các cơ chế riêng cho 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ó salt (salted hashes) của các phần tử dữ liệu riêng lẻ. Ví của chủ sở hữu 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 người xác minh xác nhận chúng dựa trên các hàm băm mà không nhìn 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 namespace 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 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ữ Truy vấn Chứng thực Số (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 chứng thực và các tuyên bố (claims) riêng lẻ mà họ cần. Ví sau đó xây dựng một Verifiable Presentation 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à ví.

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. Việc hiểu các sắc thái của 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 là rất quan trọng để đảm bảo rằng chỉ dữ liệu tối thiểu cần thiết được yêu cầu và xử lý, từ đó tuân thủ các thực hành 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 ví cũng có thể khác nhau, yêu cầu 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 ứng dụng ví cho chủ sở hữu, môi trường hệ điều hành đóng vai trò quan trọng.

Bên phát hành ví đố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: Nhìn chung 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 native bên thứ ba đăng ký làm người nắm giữ chứng thực. Các ứng dụng holder đã đăng ký này sau đó có thể tham gia vào các luồng trình bày chứng thực được điều phối bởi hệ thống, phản hồi các yêu cầu từ Digital Credentials API (qua Chrome) hoặc các trình xác minh ứng dụng native. Android cũng hỗ trợ rõ ràng OpenID4VCI cho phát hành chứng thực, cho phép người dùng chọn ví bên thứ ba tương thích để nhận các chứng thực mới được phát hành. Mặc dù các ứng dụng native là trọng tâm chính cho khả năng holder đầy đủ, hệ thống được thiết kế cho sự tham gia rộng rãi hơn.

• iOS: Apple duy trì 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í 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 như là người nắm giữ chứng thực cấp hệ thống cho các chứng thực đảm bảo cao (như mDL dành cho Apple Wallet) thường chịu sự quản lý của các quy trình và quyền hạ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 phát hành nhà nước và việc 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 vào 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 nhà cung cấp tài liệu bên thứ ba đã đăng ký.

Cách tiếp cận "khu vườn kín" (walled garden) 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ư mDL của tiểu bang, Apple đã giới thiệu framework IdentityDocumentServices cho các ứng dụng iOS native. Đ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 native 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 tổ chức chứng thực tin cậy (CAs) cho việc ký yêu cầu.
2. Triển khai App Extension: Thêm một UI App Extension "Identity Document Provider" vào dự án. Phần mở rộng này chịu trách nhiệm hiển thị giao diện ủy quyền cho người dùng khi ứng dụng được chọn trong quá trình xác minh trên web.

Điều này có nghĩa là mặc dù việc tạo một ví tích hợp hoàn toàn trên iOS yêu cầu xây dựng một ứng dụng native và sử dụng các framework cụ thể của Apple — không phải các công nghệ web như PWA — nhưng có một cơ chế rõ ràng, mặc dù được kiểm soát chặt chẽ, cho các ứng dụng bên thứ ba hoạt động như nhà cung cấp tài liệu song song 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 OS, sau đó gửi các yêu cầu đến Apple Wallet hoặc bất kỳ ứng dụng nhà cung cấp tài liệu nào khác đã đăng ký và được ủ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, 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 chứng thực. Với Chrome 141 (30/9/2025) và Safari 26 (15/9/2025) phát hành hỗ trợ trình bày ổn định, và Firefox 149 hiện mang mã triển khai cơ bản, API đang trên con đường hướng tới việc bao phủ cả ba trình duyệt. Chúng tôi sẽ cập nhật bài viết này khi bối cảnh thay đổi.

Giai đoạn kể từ tháng 10 năm 2025 được định nghĩa bởi sự trưởng thành của API từ một ống dẫn thử nghiệm thành một tiêu chuẩn được quản trị. Việc loại bỏ sổ đăng ký giao thức mở tại TPAC (tháng 11/2025) là tín hiệu rõ ràng nhất: W3C FedID WG hiện nêu tên rõ ràng và quản trị các giao thức mà API hỗ trợ. Điều này cho phép đánh giá toàn diện về bảo mật và quyền riêng tư nhưng cũng biến Nhóm làm việc thành người gác cổng — một sự đánh đổi có chủ ý mà không phải tất cả người tham gia đều thoải mái (đáng chú ý là sự phản đối tường phí ISO từ Ping Identity vẫn chưa được giải quyết).

Trong khi đó, API đang mở rộng từ trình bày sang toàn bộ vòng đời: Origin Trial phát hành của Chrome 143 thông qua navigator.credentials.create() cho phép các trang web kích hoạt việc cấp phép ví. Nhưng một lỗ hổng ràng buộc lựa chọn ví — nơi các ứng dụng ví độc hại có thể chặn mã phát hành — đang ngăn cản sự chấp nhận của chính phủ đối với tính năng này.

Về mặt quy định, Chủ đề F trong ARF của EU yêu cầu có điều kiện hỗ trợ DC API cho tất cả ví của quốc gia thành viên EUDI, chờ đợi đặc tả đạt được Khuyến nghị của W3C. Việc áp dụng trong thế giới thực đang tăng tốc: DMV California đã thêm hỗ trợ DC API, và các bộ kiểm thử tuân thủ đang được phát triển bởi Hiệp hội Ví Châu Âu.

Thách thức vẫn còn đó. Thực tế giao thức kép (hỗ trợ đa giao thức của Chrome so với sự tập trung chỉ mdoc của Safari) vẫn tồn tại đối với các relying party. Câu hỏi về việc liệu các trình duyệt có phải hỗ trợ tất cả các giao thức được liệt kê hay chỉ một vẫn chưa được giải quyết — gắn liền trực tiếp với các ràng buộc nền tảng của Apple. Và các cân nhắc về quyền riêng tư vẫn là khoảng trống lớn nhất ngăn cản sự tiến bộ hướng tới Khuyến nghị Ứng viên, với các yêu cầu quy chuẩn cho tiêu chí bao gồm giao thức vẫn chưa được viết ra. Đặc tả ước tính còn 1–2 năm nữa mới đạt được Khuyến nghị của W3C.

Safari 26 sử dụng độc quyền chuỗi giao thức org-iso-mdoc, trong khi Chrome 141 hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C. Các Relying Party phải phát hiện trình duyệt và định tuyến đến đường dẫn giao thức phù hợp. Việc tiết lộ có chọn lọc cũng khác nhau: mdoc sử dụng các hàm băm có salt trên các namespace được xác định trước, trong khi OpenID4VP sử dụng các ngôn ngữ truy vấn như Presentation Exchange hoặc DCQL.

Mozilla đã đưa mã DC API cơ bản vào Firefox 149 (Quý 1/2026) trong khi lập trường tiêu chuẩn phủ định chính thức của họ về mặt kỹ thuật vẫn không thay đổi. Mozilla đang chọn cách định hình API từ bên trong thay vì nhường thiết kế cho các nhà cung cấp khác. Ba kỹ sư của Mozilla là thành viên tích cực của W3C FedID Working Group, cung cấp phản hồi thực chất từ việc triển khai về các pull request quan trọng của đặc tả.

Một lỗ hổng ràng buộc lựa chọn ví cho phép các ứng dụng ví độc hại chặn các mã ủy quyền trước khi phát hành trong các luồng được kích hoạt bởi navigator.credentials.create(). Các bên phát hành chính phủ đã tuyên bố họ sẽ không áp dụng phát hành qua trung gian trình duyệt cho đến khi vấn đề này được giải quyết. Chrome 143 đã ra mắt Origin Trial cho việc phát hành qua OpenID4VCI, nhưng lỗ hổng vẫn mở tính đến đầu năm 2026.

Các điều kiện trong EUDI ARF Chủ đề F bao gồm việc DC API đạt trạng thái Khuyến nghị của W3C và đáp ứng các kỳ vọng về chức năng, tính trung lập của trình duyệt/hệ điều hành, quyền riêng tư và bảo vệ chống từ chối dịch vụ. Hiệp hội Ví Châu Âu đã đưa các trường hợp kiểm thử DC API vào chương trình kiểm tra sự tuân thủ của mình. Đặc tả hiện ước tính còn 1 đến 2 năm nữa mới đạt Khuyến nghị của W3C.

W3C FedID Working Group đã quy định cứng năm định danh giao thức: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned và org-iso-mdoc cho trình bày, cộng với openid4vci-v1 cho phát hành. Các user agent được mong đợi sẽ từ chối bất kỳ giao thức nào không nằm trong danh sách này. Ping Identity đã đưa ra phản đối chính thức đối với việc bao gồm ISO 18013-7, trích dẫn những lo ngại về việc tham chiếu quy chuẩn đến một đặc tả phải trả phí.