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

最終更新日: 2025年10月30日

主要ブラウザにおけるデジタル認証情報 API のサポート状況の概要です。

デジタル認証情報の世界は急速に動いています。ここでは、主要な開発と予測のスナップショットを紹介します。

Want to experience digital credentials in action?

Try Digital Credentials

2025年7月からの変更点

• リリース済み: Chrome 141 (2025年9月30日) & Safari 26 (2025年9月15日)。
• Chrome: プロトコルに依存しない (OpenID4VP および ISO 18013-7 Annex C)、CTAP を介したデスクトップのクロスデバイス対応。
• Safari: mdoc のみ (org-iso-mdoc)、CTAP を介したクロスデバイスフロー。
• API の形状: navigator.credentials.get()、requests/data の命名、DigitalCredential による機能検出。

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

この記事では、ウェブ上でのアイデンティティ情報のやり取りの方法を再構築する可能性を秘めた重要な開発である、デジタル認証情報 API の現状について解説します。その基本的な仕組み、サポートするプロトコル、現在のブラウザの採用状況を探り、この急速に進化する状況を乗り切るための証明書利用者とウォレット発行者の両方への推奨事項を提供します。

信頼性が高く安全な方法で身元を証明することは、ウェブのアーキテクチャにおいて長年にわたる根強い課題でした。インターネットは前例のない接続性と情報交換を促進しましたが、同時に不正表示や詐欺の新たな道を開きました。

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

多くの地域における本人確認の代替手段は、伝統的に摩擦の大きいプロセスを伴いました。例えば、郵便局での物理的な確認は、大幅な遅延と不便をもたらします。ビデオ通話と書類のアップロードを組み合わせた方法は、よりデジタルな代替手段となり、最近では自動化された書類スキャンとライブネスチェックが台頭しました。これらの方法は進歩しているにもかかわらず、重大な欠点があります。時間がかかり、人的なエラーや偏見が生じやすく、巧妙な偽造に対して脆弱であることが頻繁に指摘されています。

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

Want to experience digital credentials in action?

Try Digital Credentials

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

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

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

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

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

この説明はプロトコルに中立です。なぜなら、発行、所有、そして暗号チャレンジによる検証という中心的な原則は、異なる基盤技術に共通しているからです。

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

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

主要な用語:

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

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

エンドツーエンドのフロー (例: オンライン年齢確認):

1. 発行 (VC API - 発行者 ↔ ウォレット): 州の DMV が「所有者は18歳以上である」という検証可能な認証情報を発行します。
2. 保存 (ウォレットアプリ - OS): 認証情報は、その暗号証明とともにユーザーのウォレットに保管されます。
3. 要求 (navigator.credentials.get() (DC API経由) - ウェブサイト → ブラウザ): ビール販売サイトが「ユーザーが18歳以上であることの証明を見せてください」と要求します。
4. 提示 (DC APIがウォレットにディスパッチ → OpenID4VP (プロトコル) → VC ペイロード): ウォレットが同意 UI を表示し、ユーザーが承認すると、ウォレットは検証可能な提示 (Verifiable Presentation) を返します。
5. 検証 (VC API - ビール販売サイトのバックエンド): サイトのバックエンドが署名と発行者の DID/公開鍵を検証し、アクセスを許可します。

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

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

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

重要なポイント:

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

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

プレゼンテーションレイヤーの重要なコンポーネントとして、デジタル認証情報 API は、ウェブサイトがユーザーのデジタルウォレットからデジタルアイデンティティ情報を要求し、受け取るための安全で標準化された方法を提供するために現在開発中のウェブ標準です。この取り組みは、2025年4月に FedID Community Group から移行し、主に W3C の Federated Identity Working Group (FedID WG) 内で行われています。公式の仕様ドラフトはこちらで確認できます: 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 プロトコルのみをサポートしています。Chrome は、Credential Manager システムを通じてAndroid上でこれをネイティブにサポートしており、またデスクトップでは CTAP/BLE を利用した QR ハンドオフを介してクロスデバイスデジタル認証情報 API もサポートしています。

この API は、navigator.credentials.get() を介してデジタル認証情報のリクエストを可能にすることで、既存のCredential Management API を拡張します。W3C FedID WG の Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md) によると、API は以前提案されていた 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 はプロトコルに依存しないように設計されており、認証情報交換のためのさまざまな基盤プロトコルをサポートできます。しかし、現在の実装と議論の中心となっているのは、org.iso.mdoc ( ISO 18013-5 とその拡張である ISO 18013-7 「Annex C」に由来) と、OpenID Foundation の OpenID for Verifiable Presentations (OpenID4VP) および OpenID for Verifiable Credential Issuance (OpenID4VCI) 仕様の2つの主要なプロトコルファミリーです。

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

• データモデル: mdocs は、コンパクトさと効率性のために 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)、mdocs、SD-JWT、その他のフォーマットを運ぶことができます。インタラクションモデルには、検証者 (RP) からの認可リクエストと、vp_token (Verifiable Presentation Token) を含む所有者のウォレットからのレスポンスが含まれます。選択的開示は通常、Presentation Exchange (DIF PE) や新しい Digital Credentials Query Language (DCQL) のようなクエリ言語を使用して管理されます。
• 典型的なユースケース: 本人確認、資格証明 (例: 学位証明書、専門資格)、会員証明など、幅広いアプリケーションが含まれます。これらは、証明書利用者がさまざまな発行者からの主張を検証する必要があるオンラインインタラクションに適しています。

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

欧州連合デジタルアイデンティティ (EUDI) ウォレットは、すべての EU 市民と居住者に、身分証明書と証明のための安全なデジタルウォレットを提供することを目指す主要なイニシアチブです。EUDI ウォレットのアーキテクチャと参照フレームワークは、mdoc (特にモバイル運転免許証用) と W3C 検証可能な認証情報の両方をサポートすることを明示的に計画しており、提示と発行のフローには OpenID4VP と OpenID4VCI を利用します。参照実装には、mDocs を転送する OpenID4VP と、mDoc および SD-JWT-VC 形式で PID および mDL を発行する OpenID4VCI のサポートが含まれています。このような大規模なプロジェクトによるこの二重のサポートは、両方のプロトコルファミリーの重要性を強調しています。しかし、この方向性には批判がないわけではありません。一部のオブザーバーは、「米国のビッグテック」企業に強く影響されたデジタル認証情報 API が、最終的な EUDI ウォレットの仕様に深く組み込まれる可能性があると指摘しています。この GitHub ディスカッションのようなコミュニティフォーラムで議論されているように、EU の重要なインフラストラクチャの一部に対する非 EU 組織の潜在的な影響について懸念が提起されています。

デジタル認証情報 API のブラウザの状況は、2025年9月に Chrome 141 と Safari 26 が安定版サポートをリリースしたことで、今や形作られました。ブラウザ間でアプローチとサポートレベルに顕著な違いがあります。

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 Wallet が早期採用者であり、Samsung Wallet と 1Password が発表されています。

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

私たちが正しく予測したように、WWDC25 はこの戦略を確認しました。Safari 26 (iOS/iPadOS/macOS) は2025年9月15日にデジタル認証情報 API のサポートを伴ってリリースされ、その実装が提示用に**org-iso-mdoc プロトコル (ハイフン付き) を排他的にサポート**することを確認しました。

これは、WWDC25 のセッション ウェブ上で身分証明書を検証する で詳しく説明されました。この API を使用すると、ウェブサイトは Apple Wallet やサードパーティのドキュメントプロバイダーアプリに保存されている運転免許証などの身分証明書から検証可能な情報を要求できます。

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

• MDOC のみ: この API は、ISO/IEC 18013-7 Annex C 標準に基づいたプロトコル文字列 "org-iso-mdoc" を排他的に使用します。Safari のデジタル認証情報 API の実装には、OpenID4VP のサポートはありません。
• 提示のみ: この API は、既存の認証情報の提示 (検証) 用です。Apple Wallet や他のアプリへの発行は、ブラウザとは別の、非ブラウザプロセスとして残ります。
• ユーザー中心 & 安全: フローはユーザーのジェスチャーによって開始され、「部分リクエスト」メカニズムを活用します。これにより、OS はまずリクエストをサンドボックスで解析および検証してからウォレットアプリケーションに渡し、セキュリティを強化します。
• アプリへの拡張性: Apple Wallet に加えて、サードパーティのアプリは、新しい 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 に対して、正式に標準化に否定的な立場を表明しています。彼らの懸念は包括的であり、ユーザーのプライバシーと主体性を保護し、オープンで公平なウェブを確保するという彼らの使命に根ざしています。

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

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

Mozilla は、このような API が既存のアドホックな認証情報提示方法よりも有用性を提供する可能性があることを認めつつも、新しいウェブプラットフォーム機能はウェブ全体を明らかに改善し、ユーザーの利益を優先しなければならないと強調しています。W3C 評議会はこれらの懸念に関連する正式な異議を却下しましたが (作業を潜在的に透明性の低い場所ではなく W3C 内で進めるため)、評議会はワーキンググループがこれらの潜在的な害を軽減するために積極的に取り組むことを推奨しました。

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

ユーザーからデジタル認証情報を要求し、検証しようとする組織 (Relying Parties または RP) にとって、現在の状況は慎重な戦略計画を必要とします。

Safari (2025年9月15日リリース) がデジタル認証情報 API を通じて直接的な org-iso-mdoc インタラクション (ISO 18013-7 Annex C) のみをサポートし、Chrome (2025年9月30日リリース) が OpenID4VP と ISO 18013-7 Annex C (mdoc) の両方をサポートするプロトコルに依存しないアプローチを取っていることを考えると、可能な限り広範なリーチを目指す RP は、両方のアプローチに基づいたインタラクションをサポートする準備をすべきです。

これは、以下のようなシステムを設計することを意味します:

1. navigator.credentials.get() API を介して認証情報リクエストを開始し、ブラウザの検出やユーザーエージェントの機能に基づいて、異なるプロトコルパラメータ ("org-iso-mdoc" (Safari 用) または "openid4vp" (Chrome/OID4VP フロー用)) を指定する。
2. 直接 mdoc 形式 (ISO 18013-7 Annex C) で来る可能性のあるレスポンス、または OpenID4VP を介した vp_token として来るレスポンスを処理する。後者の場合は、それを解析して基になる認証情報 (それ自体が mdoc や別の VC 形式である可能性があります) を抽出する必要がある。

これにより複雑さが増しますが、すべてのユーザーを単一のプロトコルパスに強制しようとすると、選択したパスに応じて、iOS ユーザーまたは Chrome/Android ユーザーのいずれかのかなりの部分を排除することになるでしょう。実用的ではありますが、より開発集約的なアプローチは、両方を処理できる柔軟性を構築することです。

証明書利用者は、同じ論理的な情報 (例:「ユーザーは21歳以上か？」) を要求する場合でも、リクエストでそれがどのように定義され、レスポンスでどのように返されるかが、直接的な mdoc クエリと OpenID4VP クエリ (Presentation Exchange や DCQL を使用する可能性があります) との間で大きく異なる可能性があることを強く認識しなければなりません。

• mdoc の選択的開示: org.iso.mdoc には独自の選択的開示メカニズムがあり、通常は発行者が個々のデータ要素のソルト付きハッシュを作成することを含みます。所有者のウォレットは、要求された要素とそのソルトのみを公開し、検証者が他のデータを見ることなくハッシュと照合して確認できるようにします。特定の要素のリクエストは、mdoc 標準内の事前定義された名前空間とデータ要素識別子に結び付けられています。
• OpenID4VP の選択的開示: OpenID4VP は通常、リクエストの presentation_definition 内に埋め込まれた Presentation Exchange (DIF PE) や新しい Digital Credentials Query Language (DCQL) などのクエリ言語を使用します。これにより、RP は必要な認証情報の種類と個々のクレームを指定できます。ウォレットは、認証情報のフォーマットとウォレットがサポートしていれば、要求された情報のみを含む検証可能な提示 (Verifiable Presentation) を構築します。

RP は、特定のデータ要件をこれらのさまざまなプロトコル構造にマッピングする必要があります。プライバシーのベストプラクティスとデータ最小化の原則を遵守するために、各プロトコルで選択的開示がどのように実装され、要求されるかのニュアンスを理解することが不可欠です。ウォレットから返される開示データのフォーマットと構造も異なる可能性があり、RP のバックエンドで個別の解析および検証ロジックが必要になります。

デジタル認証情報を発行し、所有者向けのウォレットアプリケーションを提供しようとする組織にとって、オペレーティングシステム環境は重要な役割を果たします。

ウォレット発行者は、ウォレットの作成、システム統合、デジタル認証情報 API とのインタラクションに関して、iOS と Android で明らかに異なる状況に直面します。

• Android: 一般的によりオープンなエコシステムを提供します。Android Credential Manager には、サードパーティのネイティブアプリケーションが認証情報所有者として登録できる Holder API が含まれています。これらの登録された所有者アプリは、システムが仲介する認証情報提示フローに参加し、デジタル認証情報 API (Chrome 経由) またはネイティブアプリの検証者からのリクエストに応答できます。Android はまた、認証情報発行のために OpenID4VCI を明示的にサポートしており、ユーザーは新しく発行された認証情報を受け取るために互換性のあるサードパーティウォレットを選択できます。完全な認証情報所有者機能の主な焦点はネイティブアプリですが、システムはより広範な参加のために設計されています。

• iOS: Apple はエコシステムをより厳格に管理しています。サードパーティのウォレットアプリは App Store に存在できますが、Apple Wallet を対象とした mDL のような高保証の認証情報に対して、システムレベルの認証情報所有者として深く統合する能力は、多くの場合 Apple の特定のプロセスとエンタイトルメントに左右されます。例えば、Apple Wallet に ID を追加することは、州の発行当局と Apple の検証を伴う管理されたフローです。Safari のデジタル認証情報 API では、インタラクションは密接に管理され、主に Apple Wallet 自体と登録されたサードパーティのドキュメントプロバイダーアプリから提示される org.iso.mdoc に焦点が当てられるでしょう。

Apple の「壁に囲まれた庭 (walled garden)」アプローチは確立されており、デジタル認証情報の実装も例外ではありません。しかし、WWDC25 はサードパーティの参加への道筋を明確にしました。

州の mDL のような認証情報の主要な組み込みプロバイダーは Apple Wallet ですが、Apple はネイティブ iOS アプリ向けに IdentityDocumentServices フレームワークを導入しました。これにより、サードパーティの開発者は、独自の身分証明書をプロビジョニングし、提示できるアプリケーションを構築できます。

ウェブフローに参加するためには、ネイティブアプリは以下を行う必要があります:

1. ドキュメントの登録: IdentityDocumentProviderRegistrationStore を使用して、アプリが管理する mdoc をオペレーティングシステムに登録します。この登録には、ドキュメントタイプとリクエスト署名のための信頼できる認証局が含まれます。
2. アプリ拡張機能の実装: プロジェクトに「Identity Document Provider」UI App Extension を追加します。この拡張機能は、ウェブベースの検証フロー中にアプリが選択されたときに、ユーザーに承認 UI を表示する責任があります。

これは、iOS で完全に統合されたウォレットを作成するには、PWA のようなウェブ技術ではなく、ネイティブアプリケーションを構築し、Apple の特定のフレームワークを使用する必要がある一方で、サードパーティアプリが Apple Wallet と並んでドキュメントプロバイダーとして機能するための明確で、厳しく管理されているメカニズムが存在することを意味します。これにより、Safari のデジタル認証情報 API とのインタラクションは OS によって管理され、リクエストは Apple Wallet または他の登録および承認されたドキュメントプロバイダーアプリにディスパッチされることが確認されます。

デジタル認証情報 API は、デジタルアイデンティティ分野における大きな進歩であり、本人確認と認証情報提示に対して、より安全で、ユーザー中心で、プライバシーを保護するアプローチを提供します。Chrome 141 (2025年9月30日) と Safari 26 (2025年9月15日) が安定版サポートをリリースしたことで、API は実験段階から本番環境に対応可能な段階へと移行しました。エコシステムが進化し続ける中で、証明書利用者とウォレット発行者の両方が、この新しい技術の可能性に適応し、受け入れることが不可欠です。状況が変化するにつれて、この記事を最新の状態に保ちます。

しかし、課題は残っています。異なる認証情報フォーマット、プロトコル、ウォレット実装の間で真のグローバルな相互運用性を達成することは、大きな事業です。プライバシー、排除、ユーザーの主体性に関して Mozilla のような組織が提起した正当な懸念に対処することは、これらの技術が人類に貢献することを確実にするために最も重要です。Chrome のプロトコルに依存しない実装と Safari の mdoc のみへの焦点という異なるアプローチは、証明書利用者とウォレット発行者が、当面の間、デュアルプロトコルの状況を乗り切らなければならないことを意味します。