--- url: 'https://www.corbado.com/vi/blog/digital-credentials-api' title: 'API Chứng thực Số (2026): Chrome & Safari đã chính thức hỗ trợ' description: 'Tìm hiểu về API Chứng thực Số, tình hình hỗ trợ trên Chrome & Safari, và luôn cập nhật những thay đổi sắp tới qua hướng dẫn toàn diện của chúng tôi.' lang: 'vi' author: 'Vincent Delitz' date: '2025-07-25T07:01:05.990Z' lastModified: '2026-08-28T12:01:34.497Z' keywords: 'digital credentials api, dc api, chứng thực số, mdoc, openid4vp, xác thực danh tính, ví kỹ thuật số' category: 'Engineering' --- # API Chứng thực Số (2026): Chrome & Safari đã chính thức hỗ trợ ### Digital Credentials API: Tình hình hỗ trợ trên các trình duyệt (Tháng 3/2026) _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](https://www.corbado.com/blog/digital-credentials-api) (API [Chứng thực](https://www.corbado.com/vi/glossary/attestation) Số) trên các trình duyệt chính: | Trình duyệt | Trạng thái hỗ trợ (Tháng 3/2026) | Phiên bản ổn định / Triển vọng | | :-------------- | :------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Google Chrome | ✅ **Đã phát hành (Ổn định)** — đa giao thức (OpenID4VP **và** ISO 18013-7 Phụ lục C) | **Chrome 141** ([Ổn định từ **30/9/2025**](https://developer.chrome.com/blog/digital-credentials-api-shipped)); hỗ trợ đa thiết bị trên máy tính qua CTAP/BLE. [Xem §6.1](#61-google-chrome-shipped) | | Apple Safari | ✅ **Đã phát hành (Ổn định)** — **chỉ hỗ trợ mdoc** qua `org-iso-mdoc` | **Safari 26** ([phát hành **15/9/2025**](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/)); hỗ trợ ứng dụng Ví & nhà cung cấp tài liệu đã đăng ký. [Xem §6.2](#62-apple-safari-mdoc-focus) | | Mozilla Firefox | 🔧 **Đang phát triển** — nền tảng cơ bản đã có trong Firefox 149 | [Lập trường tiêu chuẩn phủ định](https://github.com/mozilla/standards-positions/issues/1003) chính thức không đổi, nhưng [đang tích cực triển khai](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [Xem §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | Microsoft Edge | ✅ **Đã phát hành (Ổn định)** — dựa trên Chromium, theo sát Chrome 141 | **Edge 141** (Ổn định đầu tháng 10/2025); thừa hưởng các tính năng của Chromium 141. | ## Dòng thời gian: Trạng thái của Chứng thực Số hiện nay ra sao? Thế giới [chứng thực](https://www.corbado.com/vi/glossary/attestation) 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: | **Biểu tượng** | **Ngày / Giai đoạn** | **Sự kiện** | **Mô tả & Nguồn** | | :------------- | :------------------------ | :---------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🚀🤖 | 20 tháng 8, 2024 | Origin Trial cho Digital Credentials API trên Android | [Chrome 128 ra mắt Origin Trial cho Digital Credentials API trên Android](https://developer.chrome.com/release-notes/128), cho phép yêu cầu thông qua hệ thống IdentityCredential CredMan của Android. | | 🚀🍏 | 27 tháng 2, 2025 | Safari Technology Preview 214 | WebKit (có trong [Safari Technology Preview 214](https://www.webkit.org/blog/16512/release-notes-for-safari-technology-preview-214/)) thêm Cờ tính năng (Feature Flag) cho Digital Credentials API. ([Pull Request](https://github.com/WebKit/WebKit/pull/40008), [So sánh](https://github.com/WebKit/WebKit/compare/c968abdda41af3ad0abbf5c5c2c1fe0d5bb1c016...837aec74d9c8ea88f094c9de12a0a3c936735634)) | | 🚀🤖 | 4 tháng 3, 2025 | Origin Trial trên Chrome 134 Desktop | [Chrome 134 ra mắt Origin Trial trên máy tính cho Digital Credentials API](https://developer.chrome.com/origintrials/#/view_trial/3981410680008146945), cho phép giao tiếp bảo mật với ví điện thoại Android. (Nguồn: Ghi chú phát hành Chrome 134) | | 🚀🍏 | 31 tháng 3, 2025 | Phát hành Safari 18.4 | [Các tính năng WebKit trong Safari 18.4](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) cho phép thử nghiệm các phần của Digital Credentials API qua Feature Flag. Các thay đổi đang diễn ra được theo dõi [tại đây](https://bugs.webkit.org/buglist.cgi?quicksearch=Digital%20Credentials). | | 💡 | Tháng 4, 2025 | W3C FedID WG nắm quyền điều hành | Việc phát triển Digital Credentials API chính thức chuyển sang [Nhóm làm việc về Định danh Liên kết của W3C (W3C Federated Identity Working Group)](https://github.com/w3c-fedid/digital-credentials). | | 🚀🤖 | 30 tháng 4, 2025 | Công bố Origin Trial Đa thiết bị của Chrome | Chrome công bố [Origin Trial cho Digital Credentials API Đa thiết bị](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) bắt đầu từ Chrome 136, cho phép Chrome trên máy tính trình bày chứng thực từ thiết bị Android một cách an toàn. | | ⚠️🤖 | 2 tháng 5, 2025 | Thay đổi lớn trong API Chrome | Chrome phác thảo các thay đổi lớn (breaking changes) cho các phiên bản API trong Chrome 136 & 138 (ví dụ: định dạng yêu cầu, API `navigator.credentials.create()` được thêm dưới dạng cờ). | | 🚀🍏 | 10 tháng 6, 2025 | WWDC25: Apple xác nhận hỗ trợ API | Apple chính thức công bố hỗ trợ Digital Credentials API trong Safari tại WWDC25, xác nhận việc tập trung vào giao thức `org.iso.mdoc` để trình bày tài liệu định danh. Tính năng này có sẵn trong Safari 26 Beta với iOS 26. (Nguồn: [Xác minh tài liệu định danh trên web](https://developer.apple.com/videos/play/wwdc2025/232/)) | | 🧭 | 15 tháng 9, 2025 | Phát hành Safari 26 | [Safari/iOS 26 phát hành Digital Credentials API](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) với **`org-iso-mdoc`** (mdoc Phụ lục C). | | 🚀🤖 | 30 tháng 9, 2025 | Chrome 141 Ổn định | [Digital Credentials API phát hành bản **ổn định** trong Chrome 141](https://developer.chrome.com/blog/digital-credentials-api-shipped) (Android + đa thiết bị máy tính). | | 📣 | 3 tháng 10, 2025 | Blog ra mắt | [Chrome](https://developer.chrome.com/blog/digital-credentials-api-shipped) và [WebKit](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) xuất bản bài viết về việc phát hành; Chrome nhấn mạnh hỗ trợ **đa giao thức** (OpenID4VP **và** ISO 18013-7 Phụ lục C); WebKit chi tiết hóa mô hình **chỉ mdoc** của Safari và các luồng đa thiết bị CTAP. | | ⚙️ | 14 tháng 11, 2025 | TPAC: Loại bỏ Sổ đăng ký Giao thức | W3C FedID WG [đạt được sự đồng thuận](https://github.com/w3c-fedid/digital-credentials/issues/396) để loại bỏ sổ đăng ký giao thức mở và **quy định cứng các giao thức được hỗ trợ** (OpenID4VP, OpenID4VCI, ISO 18013-7 Phụ lục C) trực tiếp trong đặc tả kỹ thuật. Được thực hiện trong [PR #401](https://github.com/w3c-fedid/digital-credentials/pull/401) (đã gộp ngày 28/1/2026). [Xem §5](#5-underlying-protocols) | | 🦊 | _Quý 1 2026_ | Firefox bắt đầu triển khai DC API | Mozilla đưa [hỗ trợ DC API cơ bản](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) vào **Firefox 149**, mặc dù [lập trường tiêu chuẩn phủ định](https://github.com/mozilla/standards-positions/issues/1003) không thay đổi. [Mã nguồn triển khai](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) có trong mozilla-central. [Xem §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | 🇺🇸 | 27 tháng 2, 2026 | DMV California thêm DC API | Nền tảng [OpenCred của DMV California thêm hỗ trợ DC API](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) trong bản v10.0.0, trở thành một trong những đơn vị chính phủ sớm áp dụng việc trình bày chứng thực qua trình duyệt. | | 🚀🤖 | _Quý 1 2026_ | Origin Trial Phát hành trên Chrome 143 | Chrome ra mắt [Origin Trial cho việc **phát hành** chứng thực](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) thông qua `navigator.credentials.create()` với OpenID4VCI, mở rộng API ra ngoài việc chỉ trình bày. [Xem §4](#4-how-does-the-digital-credentials-api-work) | | 🇪🇺📅 | _Cuối năm 2026 (Dự kiến)_ | Khả dụng Ví EUDI | Các Quốc gia Thành viên EU dự kiến sẽ cung cấp Ví EUDI theo [eIDAS 2.0](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026). [Chủ đề F trong ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) của EU 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. [Xem §5.4](#54-eu-digital-identity-wallet-support) | **Đ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ở](https://github.com/w3c-fedid/digital-credentials/issues/396) tại TPAC (tháng 11/2025) và hiện [quy định cứng các giao thức được hỗ trợ](https://github.com/w3c-fedid/digital-credentials/pull/401) trực tiếp trong đặc tả: [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), OpenID4VCI, và [ISO 18013-7](https://www.corbado.com/glossary/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](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) 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](https://github.com/mozilla/standards-positions/issues/1003) không thay đổi, Mozilla [đã đưa mã DC API cơ bản](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) 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)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) hiện yêu cầu có điều kiện về hỗ trợ [DC API](https://www.corbado.com/blog/digital-credentials-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](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) đã thêm hỗ trợ [DC API](https://www.corbado.com/blog/digital-credentials-api) vào nền tảng OpenCred của họ (tháng 2/2026). ## Key Facts - **Chrome 141** và **Safari 26** đã phát hành hỗ trợ Digital Credentials API ổn định vào tháng 9/2025; Firefox 149 đã có mã triển khai cơ bản tính đến Quý 1/2026. - **Safari 26** chỉ hỗ trợ `org-iso-mdoc`; Chrome 141 hỗ trợ cả OpenID4VP và ISO 18013-7 Phụ lục C, yêu cầu các bên dựa vào (relying parties) phải xây dựng backend hỗ trợ song song hai giao thức. - **W3C FedID WG** đã loại bỏ sổ đăng ký giao thức mở tại TPAC (tháng 11/2025), mã hóa cứng OpenID4VP, OpenID4VCI và ISO 18013-7 Phụ lục C trực tiếp vào đặc tả kỹ thuật. - **EUDI ARF Chủ đề F** yêu cầu có điều kiện về hỗ trợ DC API cho tất cả ví của quốc gia thành viên, tùy thuộc vào việc đặc tả đạt trạng thái Khuyến nghị của W3C. - Mặc dù có **lập trường tiêu chuẩn tiêu cực** chính thức, Mozilla đã đưa mã DC API cơ bản vào Firefox 149 trong Quý 1/2026, báo hiệu khả năng bao phủ trên cả ba trình duyệt trong tương lai. ## 1. Giới thiệu: API Chứng thực Số 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](https://www.corbado.com/blog/digital-credentials-api) 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](https://www.corbado.com/glossary/issuer) [ví](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc) đang điều hướng trong bối cảnh thay đổi nhanh chóng này. ## 2. Định danh Kỹ thuật số & Xác minh 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](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ều [năm](https://www.finextra.com/blogposting/27820/the-evolution-of-identity-verification-and-whats-next). 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ủ](https://www.corbado.com/passkeys-for-public-sector) cũng tham gia, thực thi hoặc cung cấp các [ví](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc) và dịch vụ [định danh kỹ thuật số](https://www.corbado.com/blog/digital-identity-guide) quốc gia. Tuy [nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ê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](https://www.corbado.com/blog/digital-identity-guide) ở [nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ề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](https://www.identity.com/the-identity-verification-process-comprehensive-guide/) (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](https://www.corbado.com/vi/blog/vai-tro-cua-ai-trong-phat-hien-moi-de-doa-mang) đ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](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). 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](https://www.corbado.com/vi/blog/vai-tro-cua-ai-trong-phat-hien-moi-de-doa-mang), 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](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) để 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ẽ](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). 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ã. ## 3. Chứng thực Số hoạt động như thế nào? Để 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. ### 3.1. Mô hình Ba bên 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ủ](https://www.corbado.com/passkeys-for-public-sector), 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](https://www.corbado.com/glossary/issuer) 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](https://www.corbado.com/glossary/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. ![three party model](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/three_party_model_5eedaec078.png) 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](https://www.corbado.com/glossary/issuer) ký số vào chứng thực, đảm bảo tính [xác thực](https://www.corbado.com/vi/blog/trien-khai-webauthn-server) 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](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) 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í](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc) 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](https://www.corbado.com/vi/blog/trien-khai-webauthn-server) 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í](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc) [Định danh Kỹ thuật số](https://www.corbado.com/blog/digital-identity-guide) 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](https://www.corbado.com/glossary/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 phải chủ yếu về các chức năng ký rộng hơn này. ### 3.2. Các lớp của Chứng thực Số Để 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. ![Digital credential layers ](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_26eaf37952.png) **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](https://www.corbado.com/blog/mobile-drivers-license), 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](https://www.corbado.com/glossary/issuer) → chủ sở hữu → bên xác minh. - **[Verifiable Credential API](https://w3c-ccg.github.io/vc-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í](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc), bên xác minh). - **[Digital Credentials API (DC API)](https://github.com/w3c-fedid/digital-credentials):** 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/digital-credentials-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](https://www.corbado.com/glossary/open-id-4-vp), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/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](https://www.corbado.com/blog/digital-credentials-api) API và trạng thái hiện tại của nó. ## 4. Digital Credentials API hoạt động như thế nào? Là thành phần quan trọng tại lớp trình bày, [Digital Credentials API](https://www.corbado.com/blog/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ố](https://www.corbado.com/blog/digital-identity-guide) từ các [ví](https://www.corbado.com/vi/blog/dam-bao-vi-ky-thuat-so-eu-hoa-ky-uc) 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/](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](https://www.corbado.com/glossary/open-id-4-vp) và [ISO 18013-7](https://www.corbado.com/glossary/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](https://github.com/w3c-fedid/digital-credentials/issues/396) để **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ợ](https://github.com/w3c-fedid/digital-credentials/pull/401) 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) (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](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) 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](https://www.w3.org/TR/digital-credentials/)). Đặ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](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) 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í](https://github.com/w3c-fedid/digital-credentials/issues/382) — 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) thông qua hệ thống [Credential Manager](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html) và cũng hỗ trợ [Digital Credentials API Đa thiết bị](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) trên máy tính thông qua kênh [CTAP](https://www.corbado.com/blog/passkeys-explained-clearly)/BLE (quét [mã QR](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-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](https://www.w3.org/TR/credential-management-1/) 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](https://www.corbado.com/blog/digital-credentials-api) của W3C FedID WG ([https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md](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: ```javascript 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](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md). Digital Credentials API về cơ bản hoạt động như một lớp vỏ [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). 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](https://w3c-fedid.github.io/digital-credentials/) 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](https://www.corbado.com/glossary/relying-party) và ví/[chủ sở hữu](https://w3c-fedid.github.io/digital-credentials/). ## 5. Các giao thức nền tảng 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](https://github.com/w3c-fedid/digital-credentials/pull/401) các giao thức mà nó hỗ trợ — các [user agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) đượ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](https://www.corbado.com/glossary/mdoc) (bắt nguồn từ [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) và phần mở rộng [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) "Phụ lục C") và các đặc tả OpenID for Verifiable Presentations (OpenID4VP) và OpenID for [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) Issuance (OpenID4VCI) của OpenID Foundation. ### 5.1. org.iso.mdoc - **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](https://www.iso.org/standard/69084.html), định nghĩa ứng dụng [mDL](https://www.corbado.com/blog/mobile-drivers-license), 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](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-qr). [ISO/IEC 18013-7](https://www.iso.org/standard/82772.html) mở rộng điều này để cho phép trình bày [mDL](https://www.corbado.com/blog/mobile-drivers-license) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/vi/blog/trien-khai-webauthn-server) 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ủ](https://www.corbado.com/passkeys-for-public-sector) 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ủ](https://www.corbado.com/passkeys-for-public-sector), [xác minh danh tính](https://www.corbado.com/blog/digital-identity-guide) từ xa để [mở tài khoản](https://www.corbado.com/vi/blog/xac-minh-danh-tinh-ky-thuat-so) ngân hàng). ### 5.2. OpenID4VP và OpenID4VCI - **Nguồn gốc và Tiêu chuẩn hóa**: OpenID4VP (cho trình bày) và [OpenID4VCI](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/oauth2) để hỗ trợ việc trao đổi [chứng thực có thể xác minh](https://www.corbado.com/glossary/microcredentials). Đâ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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/microcredentials)) ở định dạng JSON/[JSON-LD](https://www.corbado.com/glossary/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](https://www.corbado.com/vi/glossary/open-id-4-vp)). 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](https://www.corbado.com/blog/digital-identity-guide), 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](https://www.corbado.com/glossary/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 [relying party](https://www.corbado.com/glossary/relying-party) cần xác minh các tuyên bố từ nhiều [bên phát hành](https://www.corbado.com/glossary/issuer) khác nhau. ### 5.3. So sánh org.iso.mdoc và OpenID4VP/VCI | Tính năng | org.iso.mdoc (ISO 18013-5/7) | OpenID4VP / OpenID4VCI | | :-------------------------- | :-------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- | | **Cơ quan Tiêu chuẩn hóa** | ISO/IEC | OpenID Foundation | | **Trọng tâm chính** | Giấy phép Lái xe Di động (mDL) & ID chính thức | Trao đổi chứng thực có thể xác minh chung (bất kỳ loại nào) | | **Định dạng Dữ liệu** | Dựa trên CBOR, các phần tử dữ liệu định nghĩa chặt chẽ | Không phụ thuộc; thường là [W3C VC](https://www.w3.org/TR/vc-data-model-2.0/) (JSON/JWT), mdoc, SD-JWT | | **Truyền tải** | Được định nghĩa cho cự ly gần (NFC, BLE, QR) & trực tuyến (18013-7) | Chủ yếu dựa trên OAuth 2.0 cho trực tuyến; có thể khởi tạo qua QR, deep link | | **Tiết lộ có chọn lọc** | Tích hợp sẵn qua các claim được băm và thêm salt (salted hashed claims) | Thông qua ngôn ngữ truy vấn như Presentation Exchange hoặc DCQL | | **Độ trưởng thành** | ISO 18013-5: Tiêu chuẩn đã xuất bản. ISO 18013-7: TS đã xuất bản. Chuỗi ISO 23220 (mDoc chung): Đang phát triển | OpenID4VP: Dự thảo Nâng cao (ví dụ: dự thảo 28, tháng 4/2025). OpenID4VCI: Dự thảo Nâng cao | | **Bên phát hành điển hình** | Cơ quan chính phủ (Sở GTVT, v.v.) | Chính phủ, tổ chức giáo dục, nhà tuyển dụng, bất kỳ thực thể nào | | **Chi phí Tiêu chuẩn** | Trả phí | Miễn phí / Mở | Đ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. ### 5.4. Hỗ trợ Ví Định danh Kỹ thuật số EU 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](https://www.corbado.com/vi/glossary/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](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026), sử dụng OpenID4VP và [OpenID4VCI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/mobile-drivers-license) ở 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](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) 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)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) 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)](https://eudiwalletconsortium.org/) đã đư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](https://www.nobidconsortium.com/) đã hoàn thành các thí điểm [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet) 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Riêng biệt, quyết định [mã hóa cứng tham chiếu ISO 18013-7](https://github.com/w3c-fedid/digital-credentials/pull/401) trong đặc tả đã dẫn đến [sự phản đối từ Ping Identity](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228), 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). ## 6. Trình duyệt nào hỗ trợ Digital Credential API? 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. ### 6.1. Google Chrome: Đã phát hành bản 141; Đa giao thức 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](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-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:** ```javascript if (typeof DigitalCredential !== "undefined") { // Digital Credentials API được hỗ trợ } ``` Hệ thống Credential Manager của [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) hỗ trợ native OpenID4VP cho trình bày và OpenID4VCI cho [phát hành](https://www.androidcentral.com/apps-software/android-os/google-enhances-digital-credentials-access-with-androids-open-standards-support), cho phép các ứng dụng [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html) 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ố. ### 6.2. Apple Safari: Đã phát hành bản 26; Chỉ mdoc (`org-iso-mdoc`) 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: > Bằng chứng từ trình theo dõi lỗi WebKit và các đóng góp tiêu chuẩn cho thấy Safari sẽ > chọn **tập trung hỗ trợ `org.iso.mdoc`** trực tiếp, thay vì ưu tiên OpenID4VP làm lớp > vận chuyển cho tất cả các loại chứng thực. Điều này có khả năng được thúc đẩy bởi những > lo ngại kỹ thuật về sự phức tạp của OpenID4VP trong bối cảnh trình duyệt và sự đầu tư > sâu của Apple vào việc định hình các tiêu chuẩn ISO mdoc để phù hợp với mô hình bảo mật > của nền tảng họ. Như chúng tôi đã dự đoán chính xác, [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) đã 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](https://developer.apple.com/videos/play/wwdc2025/232/) tại [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26). 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](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet) hoặc trong các ứng dụng nhà cung cấp tài liệu [bên thứ ba](https://www.corbado.com/vi/blog/nha-cung-cap-passkey). 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](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-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](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet), các ứng dụng [bên thứ ba](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) 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](https://www.corbado.com/blog/passkeys-explained-clearly) 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: ```javascript 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. ### 6.3. Mozilla Firefox: Từ lập trường phủ định đến tích cực triển khai 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](https://github.com/mozilla/standards-positions/issues/1003), 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](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys), 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](https://www.w3.org/2025/02/council-report-fedid-dig-cred.html) 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](https://github.com/mozilla/standards-positions/issues/1003), 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](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) đã có trong **Firefox 149** (ẩn sau cờ tùy chọn), được theo dõi dưới [meta bug 2004828](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [Mã nguồn](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=2010091), [bug 2010093](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://www.w3.org/groups/wg/fedid/participants/) 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](https://github.com/w3c-fedid/digital-credentials/pull/419) và [thuật toán chuẩn bị yêu cầu](https://github.com/w3c-fedid/digital-credentials/pull/420). Đâ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](https://github.com/w3c-fedid/digital-credentials/issues/472) cho các yêu cầu chứng thực). ### 6.4. Bảng Tổng quan **Bảng 1: Hỗ trợ Trình duyệt cho Digital Credentials API & Giao thức (Tháng 3/2026)** | Tính năng / Trình duyệt | Google Chrome (Android & Desktop) | Apple Safari (iOS & macOS) | Mozilla Firefox | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------ | | **Digital Credentials API (`navigator.credentials.get`)** | ✅ **Ổn định** (141) | ✅ **Ổn định** (26) | 🔧 **Đang phát triển** ([Firefox 149](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), ẩn sau cờ) | | **org.iso.mdoc qua API** | ✅ **Có** (qua ISO 18013-7 Phụ lục C dưới DC API) | ✅ **Có** (**duy nhất**; `protocol: "org-iso-mdoc"`) | 🔧 TBD (macOS có thể dùng OS API; ban đầu chỉ mdoc) | | **OpenID4VP qua API** | ✅ **Có** | ❌ **Không** (Triển khai Safari chỉ mdoc) | 🔧 TBD | | **Phát hành qua Web API (OpenID4VCI)** | 🔧 [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) (Chrome 143) qua `credentials.create()` | ❌ API trình duyệt không dùng cho phát hành (chỉ luồng ứng dụng native) | ❌ N/A | | **Luồng đa thiết bị** | ✅ Desktop↔Mobile qua chuyển giao QR CTAP/BLE (mờ đối với trình duyệt) | ✅ Chuyển giao Mac/iPad sang iPhone; không phải Apple qua QR + CTAP trên iPhone | ❌ N/A | ## 7. Khuyến nghị cho Relying Parties Đố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. ### 7.1. Chiến lược: Chuẩn bị cho Thế giới Giao thức Kép 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) hoặc những người trên Chrome/[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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. ### 7.2. Hiểu sự khác biệt về Tiết lộ Thông tin 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](https://www.corbado.com/glossary/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. ## 8. Khuyến nghị cho Bên phát hành Ví Đố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. ### 8.1. Cân nhắc Nền tảng: iOS vs. Android [Bên phát hành](https://www.corbado.com/glossary/issuer) ví đối mặt với những bối cảnh khác biệt rõ rệt trên [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-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 Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_digital_credential_cfe8d92b1e.png) - **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](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) đă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](https://www.corbado.com/blog/native-app-passkeys). 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. ![Apple Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/apple_digital_credential_f763cdaeb9.png) - **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](https://www.corbado.com/blog/mobile-drivers-license) 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](https://support.apple.com/en-us/118260) 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ý. ### 8.2. "Khu vườn kín" của Apple cho việc Tạo Ví 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](https://www.corbado.com/blog/wwdc25-passkeys-os26) đã 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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/native-app-passkeys) 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. ## 9. Kết luận: Từ Đã phát hành đến Được quản trị chặt chẽ 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](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), 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ở](https://github.com/w3c-fedid/digital-credentials/issues/396) 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](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228) 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](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) 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í](https://github.com/w3c-fedid/digital-credentials/issues/382) — 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](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) 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](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) đã 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](https://eudiwalletconsortium.org/). 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](https://github.com/w3c-fedid/digital-credentials/issues/439) 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](https://github.com/w3c-fedid/digital-credentials/issues/255) 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. ## Các Câu hỏi Thường gặp ### Tôi phải xử lý sự khác biệt giữa Safari và Chrome như thế nào khi triển khai Digital Credentials API? 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. ### Tại sao Mozilla lại triển khai Digital Credentials API nếu họ có lập trường tiêu chuẩn phủ định? 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ả. ### Điều gì đang ngăn cản các bên phát hành chính phủ áp dụng việc phát hành chứng thực qua trung gian trình duyệt thông qua Digital Credentials API? 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. ### Những điều kiện nào phải được đáp ứng trước khi các ví của quốc gia thành viên EU bắt buộc phải hỗ trợ Digital Credentials API? 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. ### Digital Credentials API hỗ trợ cụ thể những giao thức nào sau các thay đổi tại TPAC tháng 11/2025? 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) đượ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í.