デジタル認証情報 API (2026): Chrome と Safari でサポート開始

最終更新日: 2026年3月26日

主要ブラウザにおけるデジタル認証情報 API（Digital Credentials API）のサポート状況を簡単にまとめました。

デジタル認証情報（Digital Credentials）の世界は急速に動いています。主要な出来事と今後の予測をまとめました。

Want to experience digital credentials in action?

Try Digital Credentials

2025年10月以降、何が変わったのか？

• プロトコルガバナンスの転換: W3C FedID WG は TPAC (2025年11月) で オープンプロトコルレジストリを廃止 し、OpenID4VP、OpenID4VCI、ISO 18013-7 Annex C という サポート対象プロトコルを仕様に直接ハードコード しました。API はもはや単なる「土管 (dumb pipe)」ではありません。
• 発行機能の登場: Chrome 143 は navigator.credentials.create() による 認証情報発行のオリジン・トライアル を開始し、提示だけでなく発行にも対応範囲を広げました。
• Firefox の実装開始: 標準化に対する否定的な立場 は変わっていませんが、Mozilla は Firefox 149 に ベースラインとなる DC API コード を導入し、UX 面の作業も進行中です。
• EU による条件付き義務化: EUDI Architecture Reference Framework (Topic F) は現在、すべての加盟国ウォレットに対し、DC API のサポートを条件付きで要求しています。
• 実世界での採用: カリフォルニア州 DMV は OpenCred プラットフォームに DC API サポートを追加しました (2026年2月)。

デジタル認証情報（Digital Credentials）は現在、アイデンティティ分野で非常にホットなトピックです。私たちの生活がデジタル領域とますます密接になるにつれ、自分の身元や資格をオンラインで証明するための、安全でユーザー中心、かつプライバシーを保護する方法の必要性がかつてないほど高まっています。従来の手法は時代遅れになりつつあり、より堅牢なソリューションへの需要は明らかです。

この記事では、ウェブ上でのアイデンティティ情報の扱い方を大きく変える可能性を秘めた重要な進展である「デジタル認証情報 API」の現状について議論します。基本的な仕組み、サポートされているプロトコル、現在のブラウザ採用状況、そしてこの急速に進化する状況において、リライイング・パーティー（検証者）とウォレットの発行者（イシュア）の双方がとるべき推奨事項について見ていきましょう。

信頼性が高く安全な本人確認は、ウェブのアーキテクチャにおいて長年の課題でした。インターネットはかつてないほどの接続性と情報交換を可能にしましたが、同時に詐称や不正行為の新たな手段も生み出しました。

一部の国では、既存の信頼関係を活用して銀行コンソーシアムなどがオンライン本人確認サービスを開発し、解決策が登場しました。政府も介入し、国家的なデジタルアイデンティティウォレットやサービスを強制または提供しています。しかし、これらのソリューションはサイロ化されていたり、地理的に限定されていたり、相互運用性がなかったりすることがよくありました。

多くの地域における本人確認の代替手段は、伝統的に高フリクション（手間のかかる）プロセスを伴うものでした。例えば、郵便局での対面確認は大幅な遅延と不便をもたらします。ビデオ通話と書類アップロードを組み合わせた方法は、よりデジタルな代替手段となり、最近では自動ドキュメントスキャンと生体検知（liveness checks）の普及が続いています。

進歩は見られるものの、これらの方法には大きな欠点があります。時間がかかり、人的ミスや偏見が生じやすく、高度な偽造に対して脆弱であることが度々露呈しています。

ディープフェイク、高度な AI によるなりすまし技術、ますます巧妙化するフィッシング攻撃の登場により、課題は劇的にエスカレートしています。これらの技術は、非常にリアルだが完全に捏造されたビデオ、音声、文書証拠を作成できるため、従来のシステムや AI を活用した検証ツールでさえ、本物のユーザーと詐欺師を区別することが非常に困難になっています。合成アイデンティティの作成や生体データの操作によるチェックの回避は、特に金融機関や堅牢な顧客確認 (KYC) プロセスを必要とするサービスにとって深刻な脅威です。この脅威の増大は、より安全で、暗号学的に検証可能なオンラインアイデンティティと確認メカニズムの緊急性を浮き彫りにしています。

Want to experience digital credentials in action?

Try Digital Credentials

デジタル認証情報がどのように機能するかを理解するには、関与する主要なプレーヤーと、その機能を可能にするさまざまな技術レイヤーを見る必要があります。

デジタル認証情報の概念、特に新しいウェブ API の文脈におけるその核心は、3者間モデルを中心に展開します。

1. 発行者 (Issuer): 主体に関する特定の情報について権限を持ち、その情報を証明するデジタル認証情報を発行できるエンティティ（例: 政府、大学、雇用主）。
2. 保有者 (Holder): 情報の主体（つまりユーザー）であり、発行者から認証情報を受け取り、それをデジタルウォレットに保存します。保有者は、いつ、どの情報を共有するかを制御します。
3. 検証者 (Verifier) または リライイング・パーティー (RP): サービスやリソースへのアクセスを許可するために、保有者に関する特定の情報を検証する必要があるエンティティ（例: ウェブサイト、オンラインサービス）。検証者は保有者に必要な情報を要求します。

この3者間モデルが重要なのは、ユーザー（保有者）が自身のデータをコントロールできるようにすることを目指しているからです。データが中央に保存されたり、ユーザーの直接的な介入なしに当事者間で共有されたりする従来のアイデンティティシステムとは異なり、このモデルはユーザーの同意と選択的開示 (Selective Disclosure) を重視しています。保有者は、特定のトランザクションに対して認証情報全体を公開するのではなく、どの情報を共有するかを決定します。

これらのシステムの基本的な側面は、暗号鍵ペアの関与です。発行者は認証情報にデジタル署名を行い、真正性と完全性を保証します。一方、保有者は（多くの場合、デバイスハードウェアによって保護された）デジタルウォレット内で安全に管理される秘密鍵を使用して、認証情報の管理権限を証明し、検証者への提示を承認します。これには通常、検証者がチャレンジ（ランダムなデータ）を提示し、保有者のウォレットが認証情報に関連付けられた秘密鍵を使用して署名するというプロセスが含まれます。検証者は対応する公開鍵を使用して署名を確認し、提示を認証できます。

この説明はプロトコルに依存しないものであり、発行、保持、および暗号学的チャレンジによる検証の基本原則は、さまざまな基盤技術に共通しています。

この記事では、デジタル認証情報の検証と、ソースドキュメント全体を公開することなく特定の属性（例：「18歳以上である」、「有効な運転免許証を持っている」）を証明できるようにする選択的開示の原則に焦点を当てています。デジタル認証情報の基盤システムは、適格電子署名 (QES) やリモート署名機能（法的拘束力のある署名のための EU デジタルアイデンティティウォレットなどの包括的なソリューションに見られる）をサポートしている場合がありますが、特にデジタル認証情報 API におけるここでの焦点は、これらの広範な署名機能ではなく、主にオンラインインタラクションのためのアイデンティティアサーションと属性検証にあります。

デジタル認証情報がどのように機能するかを理解するには、レイヤーモデルを視覚化すると役立ちます。各レイヤーは、データ形式そのものから、ウェブブラウザでユーザーに提示される方法まで、エコシステムの異なる側面に対応しています。この記事では主に、プレゼンテーションレイヤーで動作する デジタル認証情報 API に焦点を当てています。

主要用語:

• デジタル認証情報 (Digital credential): 機械可読なあらゆる認証情報（バーコード付き PDF、ISO mDL、W3C VC、SD-JWT など）。「デジタル」であることは、暗号学的な検証可能性については何も語っていません。
• 検証可能な認証情報 (Verifiable Credential - VC): W3C VC データモデルによって定義されるデジタル認証情報の一種。改ざん検知機能と暗号学的証明が追加されており、常に3者間（発行者 → 保有者 → 検証者）の世界に存在します。
• Verifiable Credential API: バックエンドシステム（発行者、ウォレット、検証者）間で VC を発行、保存、提示、検証するための REST/HTTP サービスインターフェース。
• デジタル認証情報 API (DC API): ウェブサイトがユーザーのデバイス側ウォレットに対して、サポートされている任意のデジタル認証情報（VC、ISO mDoc、SD-JWT など）をプライバシーに配慮した方法で提示するよう要求できるようにする、ブラウザ/OS API（JavaScript + ネイティブ機能）。

VC はデータモデル、VC API はバックエンド仕様、DC API は認証情報をウェブに提示するフロントエンド実装と考えてください。レイヤー 1（データモデル層）より上のすべてはフォーマットに依存しませんが、それより下は認証情報のフォーマットに依存します。

エンドツーエンドのフロー（例：オンライン年齢確認）:

以下の図は、実際のシナリオでこれらのレイヤーがどのように連携するかを示しています。

データが VC であり、ウェブ上の転送手段が DC API、その下の交換プロトコルが OpenID4VP であり、サーバー側のチェックが VC API を使用していることに注目してください。

なぜ分離が存在するのか:

• 相互運用可能なデータモデル（暗号学的証明、選択的開示）: VC データモデル（およびその他のフォーマット）によって解決。
• バックエンドシステム用の標準 REST エンドポイント: VC API によって解決。
• プライバシーを保護するウォレット ↔ ウェブサイト間のハンドシェイク: DC API によって解決。
• 異なる信頼レベル/ドキュメントタイプ（政府 ID vs コース修了証）: DC API の下で適切なフォーマット（高保証 ID には ISO mDoc、一般的な主張には W3C VC）を使用することで解決。

重要なポイント:

1. 「デジタル認証情報」は包括的な用語です。
2. 検証可能な認証情報 (VC) は、暗号学的検証機能が組み込まれたデジタル認証情報の一種です。
3. VC API は、VC のライフサイクル操作のためのサーバー間インフラです。
4. デジタル認証情報 API は、具体的なフォーマットが何であれ、認証情報をウェブアプリにスムーズに流すことを可能にする、ブラウザとウォレットの架け橋です。
5. これら3つの要素は競合するものではなく、補完的なものです。同じスタックの異なるレイヤーに位置し、オープンウェブ上で安全なユーザー中心のアイデンティティを共に実現します。

参加者とデジタル認証情報の全体的なレイヤーアーキテクチャを探ったところで、この記事ではプレゼンテーションレイヤー、特にデジタル認証情報 API とその現状についてさらに深く掘り下げていきます。

プレゼンテーションレイヤーの重要なコンポーネントとして、デジタル認証情報 API は、ウェブサイトがユーザーのデジタルウォレットからデジタルアイデンティティ情報を要求し、受信するための安全で標準化された方法を提供するために開発中のウェブ標準です。この取り組みは主に W3C の Federated Identity Working Group (FedID WG) 内で行われており、2025年4月に FedID Community Group から移行しました。公式ドラフト仕様はこちらで確認できます: https://w3c-fedid.github.io/digital-credentials/。

2025年10月の時点で、この API は Chrome 141（2025年9月30日）と Safari 26（2025年9月15日）の両方の 安定版で出荷 されています。Chrome の実装は OpenID4VP と ISO 18013-7 Annex C の両方をサポートしていますが、Safari は org-iso-mdoc プロトコルのみをサポートしています。

重要 (2026年3月更新): API とプロトコルの関係は根本的に変化しました。2025年11月の TPAC において、W3C FedID WG は オープンなプロトコルレジストリを廃止 し、代わりに サポート対象プロトコルの有限リストを仕様に直接ハードコードする ことで合意しました。現在のリストは、openid4vp-v1-unsigned、openid4vp-v1-signed、openid4vp-v1-multisigned、org-iso-mdoc（提示用）、および openid4vci-v1（発行用）です。ユーザーエージェントはリストにないプロトコルを拒否することが期待されています。これにより、ワーキンググループは将来のプロトコル追加に対する事実上のゲートキーパーとなります。これは、API を通過するすべてのものに対して包括的なセキュリティとプライバシーのレビューを可能にするための意図的なトレードオフです（現在のワーキングドラフトを参照）。

仕様は現在、navigator.credentials.create() を介した 認証情報の発行 もカバーしています。Chrome 143 はこのための オリジン・トライアル を開始し、ウェブサイトが OpenID4VCI を使用してウォレットのプロビジョニングフローをトリガーできるようにしました。しかし、悪意のあるウォレットアプリが発行時の事前承認コードを傍受できるという ウォレット選択のバインディングに関する脆弱性 が依然として懸念事項として残っています。政府の発行機関は、これが解決されるまでブラウザを介した発行を採用しない意向を示しています。

Chrome は、Android 上では Credential Manager システム を通じてネイティブに提示をサポートし、デスクトップ上では CTAP/BLE バックの QR ハンドオフを介して クロスデバイス・デジタル認証情報 API をサポートしています。

この API は、既存の Credential Management API を拡張し、navigator.credentials.get() を介してデジタル認証情報の要求を可能にします。W3C FedID WG の Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md) によると、以前提案されていた navigator.identity ではなく、この確立されたインターフェースを使用するように戻りました。ウェブサイトは、デジタル認証情報用の特定のパラメータを指定して navigator.credentials.get() を呼び出すことで、認証情報を要求します。

以下は、ウェブサイトが OpenID4VP を使用して認証情報を要求するために API を呼び出す方法の例です。

async function requestCredential() {
    // デジタル認証情報 API のサポートを確認
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // これらのパラメータは通常、バックエンドから取得します。
            // ここではプロトコル拡張性の説明のために静的に定義しています。
            const oid4vp = {
                protocol: "oid4vp", // ウォレットへの OpenID4VP リクエストの例。 // https://github.com/openid/OpenID4VP/issues/125 に基づく
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // Presentation Exchange リクエスト、簡潔にするため省略
                    },
                },
            };
 
            // Abort Controller を作成
            const controller = new AbortController();
 
            // バックエンドからの提示リクエストを使用してデジタル認証情報 API を呼び出す
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // 暗号化されたレスポンスをバックエンドに送信して復号と検証を行う
            // 簡潔にするため省略
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // フォールバックシナリオ、説明用のみ
        alert("このブラウザではデジタル認証情報 API はサポートされていません。");
    }
}

この例は こちら から引用しています。

デジタル認証情報 API は、本質的に安全なラッパーまたは仲介役として機能します。これにより、ブラウザは基盤となるオペレーティングシステムの機能を活用して、リクエスト に一致する利用可能なウォレットと認証情報を検出し、アイデンティティ情報の要求を仲介できるようになります。ブラウザと OS は、認証情報を選択し、その提供を承認するための一貫したユーザーインターフェースを提示し、ユーザーの同意を確保し、ウェブサイトが機密データに勝手にアクセスするのを防ぐことで、セキュリティとプライバシーを強化します。レスポンスに含まれる実際の認証情報データはブラウザ自体には不透明（暗号化）であることを意図しており、復号と解釈はリライイング・パーティーとウォレット/保有者によって処理されます。

デジタル認証情報 API は当初、あらゆるプロトコルが登録できるオープンレジストリを備えた「土管（dumb pipe）」として、完全にプロトコル非依存であるように設計されていました。しかし、2026年1月現在、仕様はサポートするプロトコルを明示的に指名しており、ユーザーエージェントはリストにないものを拒否することが期待されています。現在仕様にハードコードされている2つの主要なプロトコルファミリーは、org.iso.mdoc (ISO 18013-5 およびその拡張 ISO 18013-7 "Annex C" から派生) と、OpenID Foundation の OpenID for Verifiable Presentations (OpenID4VP) および OpenID for Verifiable Credential Issuance (OpenID4VCI) 仕様です。

• 起源と標準化: org.iso.mdoc は、主にモバイル運転免許証 (mDL) などのモバイルドキュメントのデータ形式と相互作用モデルを指し、国際標準化機構 (ISO) と国際電気標準会議 (IEC) によって標準化されています。基本となる標準は ISO/IEC 18013-5 で、NFC、Bluetooth、または QR コードを使用した対面（近接）提示のための mDL アプリケーション、データ構造、プロトコルを定義しています。ISO/IEC 18013-7 はこれを拡張し、mDL のオンライン/リモート提示を可能にします。プロトコル文字列 "org.iso.mdoc" は、デジタル認証情報 API のような API で使用するために ISO/IEC TS 18013-7 (Annex C) で具体的に定義されています。

• データモデル: mdoc は、コンパクトさと効率性のために CBOR (Concise Binary Object Representation) に基づいた厳密に定義されたデータ構造を持っています。一般的な運転免許証の属性に対して名前空間とデータ要素を指定し、発行者認証、デバイスバインディング、保有者認証（顔写真経由）、セッション暗号化、選択的開示などの強力な暗号セキュリティ機能をサポートしています。

• 一般的なユースケース: 主に運転免許証や国民 ID などの政府発行の身分証明書。対面（例：交通検問、年齢制限商品の購入）およびオンライン（例：政府サービスへのアクセス、銀行口座開設のためのリモート本人確認）の両方における高保証シナリオ向けに設計されています。

• 起源と標準化: OpenID4VP（提示用）と OpenID4VCI（発行用）は、OpenID Foundation によって開発された仕様です。これらは OAuth 2.0 を拡張して、検証可能な認証情報の交換をサポートします。これらは、政府だけでなく、さまざまな種類の認証情報に対する広範な相互運用性を目指したオープン標準です。2025年初頭現在、OpenID4VP はドラフトの最終段階にあります（例：4月時点でドラフト28）。OpenID4VCI も成熟しつつあります。
• データモデル: OpenID4VP/VCI は、認証情報の形式に依存しないように設計されています。JSON/JSON-LD または JWT 形式の W3C 検証可能な認証情報 (VC)、mdoc、SD-JWT、その他の形式を運ぶことができます。相互作用モデルには、検証者 (RP) からの認可リクエストと、vp_token（Verifiable Presentation Token）を含む保有者のウォレットからのレスポンスが含まれます。選択的開示は通常、Presentation Exchange (DIF PE) や DCQL (Digital Credentials Query Language) のようなクエリ言語を使用して管理されます。
• 一般的なユースケース: 本人確認、資格証明（例：教育修了証書、専門資格）、会員証明など、幅広い用途。リライイング・パーティーがさまざまな発行者からのクレームを検証する必要があるオンラインインタラクションに適しています。

これらは必ずしも相互排他的ではないことを認識することが重要です。たとえば、OpenID4VP を使用して [org.iso.mdoc] を要求し、転送することができます。どちらを選択するかは、特定のユースケース、認証情報の種類、エコシステムの参加者によって異なることがよくあります。

欧州連合デジタルアイデンティティ (EUDI) ウォレットは、すべての EU 市民と居住者に、身分証明書と証明書のための安全なデジタルウォレットを提供することを目的とした主要なイニシアチブです。EUDI ウォレットのアーキテクチャと参照フレームワークは、提示と発行のフローに OpenID4VP と OpenID4VCI を利用し、mdoc（特にモバイル運転免許証用）と W3C 検証可能な認証情報の両方をサポートすることを明示的に計画しています。リファレンス実装には、mDoc を転送する OpenID4VP と、mDoc および SD-JWT-VC 形式で PID と mDL を発行するための OpenID4VCI のサポートが含まれています。このような大規模プロジェクトによるデュアルサポートは、両方のプロトコルファミリーの重要性を強調しています。

2026年3月更新: デジタル認証情報 API に対する EU のコミットメントはより具体的になりました。EUDI Architecture Reference Framework (ARF) Topic F は現在、EUDI ウォレットユニットとリライイング・パーティーに対し、リモート提示および証明書発行フローのために DC API をサポートすることを 条件付きで要求 しています。条件には、DC API が W3C 勧告ステータスに達すること、および機能性、ブラウザ/OS の中立性、プライバシー、および DoS 攻撃保護に関する期待を満たすことが含まれます。European Wallet Consortium (EWC) は、適合性テストプログラムに DC API のテストケースを組み込んでおり、NOBID コンソーシアムは、DC API が現在運んでいるのと同じプロトコルである OpenID4VP を使用した支払いパイロットを完了しました。

しかし、この方向性に批判がないわけではありません。一部の観測者は、「米国のビッグテック」企業の影響を強く受けたデジタル認証情報 API が、最終的な EUDI ウォレット仕様に深く組み込まれる可能性があると指摘しています。この GitHub ディスカッションなどのコミュニティフォーラムで議論されているように、EU の重要なインフラに対する非 EU 企業の影響力を懸念する声も上がっています。また、仕様内で ISO 18013-7 を参照してハードコードする という決定に対し、Ping Identity から 異議 が出ています。有料の仕様を規範的に参照することはオープンウェブの原則と矛盾するという主張であり、仕様が勧告候補（Candidate Recommendation）に移行する際に正式な異議申し立てとして表面化する可能性があります。

デジタル認証情報 API のブラウザ情勢は現在固まりつつあり、Chrome 141 と Safari 26 が2025年9月に安定版サポートを出荷しました。ブラウザ間でアプローチとサポートレベルには顕著な違いがあります。

Chrome は Chrome 141 (2025年9月30日) でデジタル認証情報 API を 出荷 しました。Chrome の実装は プロトコル非依存 であり、OpenID4VP と ISO 18013-7 Annex C (mdoc オンライン) の両方と互換性があります。デスクトップ版は、モバイルウォレットからの クロスデバイス 提示を CTAP/BLE バック のチャネル (QR ハンドオフ) 経由でサポートしており、レスポンスはブラウザに対して不透明（内容は不可視）です。API の形状は navigator.credentials.get() に移行し、パラメータ名が変更 されました (providers → requests, request → data)。

機能検出:

if (typeof DigitalCredential !== "undefined") {
    // デジタル認証情報 API がサポートされています
}

Android の Credential Manager は、提示用に OpenID4VP、発行用に OpenID4VCI をネイティブにサポートしており、Android アプリがこれらの標準を使用して認証情報の保有者および検証者として機能することを可能にします。Google はウォレットのサポート拡大に言及しており、Google ウォレット が早期採用者となり、Samsung Wallet や 1Password も発表されています。

この記事の以前のバージョンでは、Apple のアプローチは org.iso.mdoc プロトコルに焦点を当てることで Google とは異なるものになると予測しました。歴史的な文脈として、私たちの推論は以下の通りでした。

私たちが正しく予想した通り、WWDC25 でこの戦略が確認されました。Safari 26 (iOS/iPadOS/macOS) は2025年9月15日にデジタル認証情報 API のサポートを 出荷 し、その実装が提示において 排他的に org-iso-mdoc プロトコル（ハイフン付き）をサポートすることを確認しました。

これは、WWDC25 のセッション Verify identity documents on the web で詳細に説明されました。この API を使用すると、ウェブサイトは Apple ウォレットやサードパーティのドキュメントプロバイダーアプリに保存された運転免許証などの本人確認書類から、検証可能な情報を要求できます。

Apple の実装からの重要なポイント:

• MDOC のみ: API は、ISO/IEC 18013-7 Annex C 標準に基づき、プロトコル文字列 "org-iso-mdoc" のみを使用します。Safari のデジタル認証情報 API 実装には、OpenID4VP のサポートはありません。
• 提示のみ: API は既存の認証情報の提示（検証）用です。Apple ウォレットやその他のアプリへの発行は、別の非ブラウザプロセスのままです。
• ユーザー中心かつ安全: フローはユーザーのジェスチャーによって開始され、「部分リクエスト」メカニズムを活用します。OS はまずサンドボックス内でリクエストを解析および検証してからウォレットアプリケーションに渡すため、セキュリティが強化されます。
• アプリへの拡張性: Apple ウォレットに加えて、サードパーティのアプリも新しい IdentityDocumentServices フレームワークとアプリ拡張機能を実装することで、ドキュメントプロバイダーとして機能できます。
• クロスデバイスサポート: Apple 以外のプラットフォームからの クロスデバイス 提示は、QR コード ハンドオフ後の近接通信に CTAP を使用します。JS レスポンスはブラウザに対して暗号化/不透明のままです。

Apple は、リライイング・パーティーが API を使用する方法について、明確なコード例を提供しました。

async function verifyIdentity() {
    try {
        // サーバーはリクエストデータを生成し、暗号署名します。
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // リクエストは 'org-iso-mdoc' プロトコルを指定します。
        const request = {
            protocol: "org-iso-mdoc",
            // data には暗号署名された mdoc リクエストが含まれます。
            data,
        };
 
        // API はユーザージェスチャー内から呼び出す必要があります。
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // ウォレットからの暗号化されたレスポンスをサーバーに送信し、復号と検証を行います。
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // 検証された詳細を表示...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // エラー処理（例: ユーザーによるキャンセル）。
    }
}

この確認により、ブラウザ市場における戦略の違いが固まりました。Chrome が柔軟な OpenID4VP トランスポート層の上に構築しているのに対し、Apple は ISO mdoc エコシステムへの深い投資を活用して、公的な本人確認書類に特化した、柔軟性は低いものの高度に統合された安全なソリューションを提供しています。

Mozilla は当初、デジタル認証情報 API に対して 標準化に否定的な立場 (negative standards position) を表明しました。詳細に文書化された彼らの懸念は包括的であり、ユーザーのプライバシーと主体性を保護し、オープンで公平なウェブを確保するという彼らの使命に根ざしています。

Mozilla が提起した主な懸念事項は以下の通りです。

• プライバシーリスク: デジタル認証情報の要求が些細なやり取りで一般的になれば、個人データの共有が増加し、オンラインでの匿名性が低下する可能性があります。
• ユーザーの排除: デジタル認証情報を使用できない、または使用しないことを選択した個人が、オンラインサービスやコミュニティから排除されるリスク。主要なユースケースである政府発行の認証情報は、個人のアイデンティティ提示の選択と一致しない場合があります。
• 相互運用性の問題: 認証情報フォーマットの乱立により、普遍的に相互運用可能なエコシステムではなく、分断されたエコシステムにつながる懸念。
• 選択的開示: 選択的開示のプライバシー上の利点は、強力な非リンク性（unlinkability）保証なしに実装された場合、またはユーザーが何を共有しているかを完全に理解していない場合、損なわれる可能性があります。
• 信頼とユーザー主体性の集中化: API が信頼の集中化を招き、ユーザーの主体性を低下させ、既存の社会的権力不均衡を固定化するのではないかという懸念。

W3C 理事会がこれらの懸念に関連する正式な異議申し立てを却下しました（透明性の低い場所ではなく、W3C 内で作業を進めるため）が、理事会はワーキンググループに対し、これらの潜在的な害を軽減するために積極的に取り組むよう勧告しました。

2026年3月更新 — 実装が進行中: 正式な否定的な立場は技術的には変わっていませんが、Mozilla はデジタル認証情報 API の 積極的な実装 を開始しました。2026年第1四半期、Firefox 149 に（設定フラグの背後で）ベースラインとなる DC API サポート が導入されました。これは メタバグ 2004828 で追跡されています。DigitalCredential.cpp、WebIDL バインディング、IPC 配管を含む ソースコード は mozilla-central にあります。デスクトップおよび Android の許可プロンプトに関する作業 (バグ 2010091, バグ 2010093) も進行中です。

3人の Mozilla エンジニア（John Schanck、Martin Thomson、Benjamin VanderSloot）が W3C FedID ワーキンググループの アクティブメンバー となっており、Schanck は 認証情報提示アルゴリズム や リクエスト準備アルゴリズム などの主要な仕様 PR に対して、実装に基づいた実質的なフィードバックを提供しています。

これは重要な進展です。Mozilla は API の悪用可能性について懸念を持ち続けていますが、設計を他のブラウザベンダーに委ねるのではなく、仕様策定と実装の両方を通じて内部から API を形成することを選択していることは明らかです。これは、デジタル認証情報 API が3ブラウザサポートへの道を歩んでいる可能性が高いことを示していますが、Mozilla は（認証情報リクエストのための 透明性ログ の提案など）より強力なプライバシーガードレールを推進しています。

表 1: デジタル認証情報 API とプロトコルのブラウザサポート (2026年3月)