Digital Credentials API (2025年)：ChromeとSafariの対応状況 (WWDC25)

最終更新日：2025年7月15日（WWDC25後）

主要ブラウザにおけるDigital Credentials APIのサポート状況の概要です。

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

現在、ID（アイデンティティ）の分野で大きな注目を集めているのが、デジタルクレデンシャルです。私たちの生活がデジタル空間と深く結びつくにつれて、オンラインで自分の身元や資格を証明するための、安全でユーザー中心、そしてプライバシーを保護する仕組みが、これまで以上に重要になっています。従来の方法は古くなりつつあり、より強力なソリューションが求められているのは明らかです。

この記事では、ウェブ上での本人確認情報のやり取りを大きく変える可能性を秘めた重要な技術開発である、Digital Credentials APIの現状について解説します。その基本的な仕組み、サポートするプロトコル、現在のブラウザの採用状況を探り、この急速に進化する分野を航海するRelying Party（依拠当事者）とWalletのIssuer（発行者）双方への推奨事項を提示します。

ウェブのアーキテクチャにおいて、信頼性が高く安全な方法で本人確認を行うことは、長年にわたる根強い課題でした。インターネットは前例のない接続性と情報交換を可能にしましたが、同時に、なりすましや詐欺の新たな温床ともなりました。

一部の国では、主に初期の銀行コンソーシアムが主導する形で解決策が生まれました。彼らは既存の信頼関係をオンラインでの本人確認に活用するサービスを開発しました。政府もまた、国民向けのデジタルIDWalletやサービスを義務化または提供することで、この動きに加わりました。しかし、これらの解決策はしばしばサイロ化され、地理的に限定されており、普遍的な相互運用性はありませんでした。

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

デジタルクレデンシャルがどのように機能するかを理解するには、関係する主要なプレイヤーと、その機能を可能にするさまざまな技術レイヤーに目を向ける必要があります。

デジタルクレデンシャルの概念、特に新しいウェブAPIの文脈では、その核心に三者間モデルがあります。

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

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

これらのシステムの基本的な側面は、暗号鍵ペアの関与です。Issuerはクレデンシャルにデジタル署名し、その真正性と完全性を保証します。一方、Holderは、自身の秘密鍵（多くの場合、デバイスのハードウェアで保護されたデジタルWallet内に安全に保管されている）を使用して、クレデンシャルの管理を証明し、Verifierへの提示を承認します。これは通常、Verifierがチャレンジ（ランダムなデータ）を提示し、HolderのWalletがクレデンシャルに関連付けられた秘密鍵を使用してそれに署名することで行われます。Verifierは対応する公開鍵を使用して署名を確認し、提示を認証できます。

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

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

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

主要な用語：

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

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

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

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

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

なぜこの分割が存在するのか：

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

重要なポイント：

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

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

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

2025年現在、このAPIはまだ大幅な変更が進行中であると説明されています。これは、APIが活発な開発段階にあることを示しています。それにもかかわらず、そのポテンシャルは非常に大きいです。Chromeは、開発者がその機能を実験できるOrigin Trialを公開し、最初に何かを公にリリースしました。Chromeはまた、AndroidのCredential Managerシステムを通じてこれをネイティブにサポートしており、最近ではデスクトップでのCross-Device Digital Credentials 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）によると、APIは以前提案されていたnavigator.identityではなく、この確立されたインターフェースを使用する形に戻りました。ウェブサイトは、デジタルクレデンシャル用の特定のパラメータを指定してnavigator.credentials.get()を呼び出すことで、デジタルクレデンシャルを要求します。

以下は、ウェブサイトがOpenID4VPを使用してクレデンシャルを要求するためにAPIを呼び出す方法を示す illustrative な例です。

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

この例はこちらから引用しました。

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

Digital Credentials 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」は、Digital Credentials APIのようなAPIで使用するために、ISO/IEC TS 18013-7（Annex C）で具体的に定義されています。

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

• 典型的なユースケース：主に政府発行の運転免許証や国民IDカードなどの身分証明書。対面（例：交通検問、規制商品の年齢確認）とオンライン（例：政府サービスへのアクセス、銀行口座開設のためのリモート本人確認）の両方で、高い保証レベルが求められるシナリオ向けに設計されています。

• 起源と標準化：OpenID4VP（提示用）とOpenID4VCI（発行用）は、OpenID Foundationによって開発された仕様です。これらはOAuth 2.0を拡張して、検証可能なクレデンシャルの交換をサポートします。これらは、政府発行のものだけでなく、様々な種類のクレデンシャルに対して幅広い相互運用性を目指すオープンスタンダードです。2025年初頭現在、OpenID4VPは高度なドラフト段階（例：4月時点でドラフト28）にあり、OpenID4VCIも成熟しつつあります。
• データモデル：OpenID4VP/VCIは、クレデンシャルフォーマットに依存しないように設計されています。JSON/JSON-LDまたはJWT形式のW3C Verifiable Credentials (VCs)、mdocs、SD-JWT、その他のフォーマットを運ぶことができます。対話モデルは、Verifier (RP)からのAuthorization Requestと、vp_token (Verifiable Presentation Token)を含むHolderのWalletからのレスポンスで構成されます。選択的開示は、通常、Presentation Exchange (DIF PE)や新しいDigital Credentials Query Language (DCQL)のようなクエリ言語を使用して管理されます。
• 典型的なユースケース：本人確認、資格証明（例：卒業証書、専門資格証明書）、会員証明など、幅広いアプリケーション。これらは、Relying Partyが様々なIssuerからの主張を検証する必要があるオンラインのやり取りに適しています。

これらは必ずしも相互に排他的ではないことを認識することが重要です。例えば、OpenID4VPは[org.iso.mdoc]を要求し、転送するために使用できます。選択は、特定のユースケース、クレデンシャルの種類、およびエコシステムの参加者に依存することが多いです。

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

Digital Credentials APIに関するブラウザの状況はまだ形成途上にあり、アプローチとサポートレベルには顕著な違いがあります。

Google Chromeは、特にAndroidにおいて、Digital Credentials APIの早期採用者であり実装者です。彼らはOrigin Trialを実施し、それをAndroidのネイティブなCredential Managerと統合しました。Chromeの実装は、主にnavigator.credentials.get() API呼び出しを介してクレデンシャルを要求するためのプロトコルとしてOpenID4VPを活用しています。OpenID4VP自体はフォーマットに依存せず、org.iso.mdocやW3C Verifiable Credentialsをペイロードとして運ぶことができますが、Googleからの実践的な重点は、トランスポートメカニズムとしてのOpenID4VPフローにあるようです。AndroidのCredential Managerは、提示のためのOpenID4VPと発行のためのOpenID4VCIもネイティブにサポートしています。これにより、Androidアプリは、これらの標準を使用してクレデンシャルのHolderおよびVerifierとして機能できます。

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

私たちが正しく予測したように、WWDC25はこの戦略を裏付けました。カンファレンスで、AppleはSafari 26（2025年秋にiOS 26およびその他のOSアップデートと共に出荷）でのAPIサポートを正式に発表し、その実装が提示のために**org.iso.mdocプロトコルのみをサポートする**ことを確認しました。

これはWWDC25のセッションVerify identity documents on the webで詳述されました。このAPIにより、ウェブサイトはApple Walletやサードパーティのドキュメントプロバイダーアプリに保存されている運転免許証などのID文書から検証可能な情報を要求できます。

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

• MDOCのみ：APIは、ISO/IEC 18013-7 Annex C標準に基づいたプロトコル文字列"org-iso-mdoc"のみを使用します。SafariのDigital Credentials API実装では、OpenID4VPのサポートはありません。
• 提示のみ：APIは既存のクレデンシャルの提示（検証）用です。Apple Walletや他のアプリへの発行は、ブラウザ外の別のプロセスとして残ります。
• ユーザー中心で安全：フローはユーザーのジェスチャーによって開始され、「部分的なリクエスト」メカニズムを活用します。OSはまずサンドボックス内でリクエストを解析・検証してからウォレットアプリケーションに渡し、セキュリティを強化します。
• アプリへの拡張性：Apple Walletに加えて、サードパーティアプリは新しいIdentityDocumentServicesフレームワークとアプリ拡張機能を実装することで、ドキュメントプロバイダーとして機能できます。

Appleは、Relying PartyがAPIをどのように使用するかについて、明確なコード例を提供しました。

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

この確認は、ブラウザ市場における戦略の相違を固めるものです。Chromeが柔軟なOpenID4VPトランスポートレイヤーを基盤としているのに対し、AppleはISO mdocエコシステムへの深い投資を活用して、公式なID文書に特化した、高度に統合され安全な、しかし柔軟性に欠けるソリューションを提供しています。

Mozillaは、現状のDigital Credentials API提案に対して、公式に**「否定的」な立場**を表明しています。彼らの懸念は包括的であり、ユーザーのプライバシーと主体性を保護し、オープンで公平なウェブを確保するという彼らの使命に根ざしています。

Mozillaが提起した主な懸念には以下が含まれます：

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

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

表1：Digital Credentials APIとプロトコルのブラウザサポート

ユーザーからデジタルクレデンシャルを要求し、検証しようとする組織（Relying PartyまたはRP）にとって、現在の状況は慎重な戦略的計画を必要とします。

大きな市場シェアを持つSafariがDigital Credentials APIを介した直接的なorg.iso.mdoc対話を優先する可能性が高く、Chrome/AndroidがOpenID4VP（mdocsや他のVerifiable Credentialフォーマットを運ぶことができる）を重視していることを考えると、可能な限り広い範囲のユーザーにリーチすることを目指すRPは、両方のアプローチに基づいた対話をサポートする準備をすべきです。

これは、以下のようなシステムを構築することを意味します：

1. navigator.credentials.get() APIを介してクレデンシャル要求を開始し、ブラウザの検出やユーザーエージェントの能力に基づいて、異なるプロトコルパラメータ（「org.iso.mdoc」または「openid4vp」）を指定する可能性がある。
2. 直接mdoc形式で来るか、OpenID4VPを介してvp_tokenとして来る可能性のあるレスポンスを処理する。後者の場合は、基になるクレデンシャル（それ自体がmdocや別のVCフォーマットである可能性がある）を抽出するために解析する必要がある。

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

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

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

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

デジタルクレデンシャルを発行し、Holder向けのウォレットアプリケーションを提供しようとする事業体にとって、オペレーティングシステム環境は重要な役割を果たします。

WalletのIssuerは、ウォレットの作成、システム統合、およびDigital Credentials APIとの対話に関して、iOSとAndroidで著しく異なる状況に直面します。

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

• iOS：Appleは自社のエコシステムに対してより厳格な管理を維持しています。サードパーティのウォレットアプリはApp Storeに存在できますが、Apple Walletを対象としたmDLのような高保証クレデンシャルのシステムレベルのクレデンシャルホルダーとして深く統合する能力は、しばしばAppleの特定のプロセスとエンタイトルメントの対象となります。例えば、Apple WalletにIDを追加することは、州の発行機関とAppleの検証を伴う管理されたフローです。SafariのDigital Credentials APIについては、対話は緊密に管理され、主にApple Wallet自体と登録されたサードパーティのドキュメントプロバイダーアプリから提示されるorg.iso.mdocに焦点が当てられるでしょう。

Appleの「壁に囲まれた庭（walled garden）」アプローチは確立されており、デジタルクレデンシャルの実装も例外ではありません。しかし、WWDC25はサードパーティの参加への道を明確にしました。

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

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

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

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

Digital Credentials APIは、デジタルID分野における重要な進歩であり、本人確認とクレデンシャル提示に対して、より安全で、ユーザー中心で、プライバシーを保護するアプローチを提供します。エコシステムが進化するにつれて、Relying PartyとWallet Issuerの両方が、この新しい技術の可能性に適応し、受け入れることが不可欠です。私たちは、状況が変化するにつれて、この記事を最新の状態に保ち続けます。

しかし、課題は残っています。異なるクレデンシャルフォーマット、プロトコル、ウォレット実装の間で真のグローバルな相互運用性を達成することは、重要な取り組みです。プライバシー、排除、ユーザーの主体性に関してMozillaのような組織から提起された正当な懸念に対処することは、これらの技術が人類に奉仕することを保証するために最も重要です。ブラウザのサポートとプロトコルの重点における現在の断片化は、Relying PartyとWallet Issuerが当面の間、複雑な状況を乗り越えなければならないことを意味します。