このページでは、デジタル ID と認証情報のために Google ウォレットと統合する際のよくある質問について説明します。
オンボーディングと利用開始
Q: 新しいパートナーが Relying Party（RP）としてオンボーディングするための手順を教えてください。
A: ウォレットの身分証明書をオンラインで確認するの手順を参照してください。
Q: RP のオンボーディング プロセスの一般的な期間はどのくらいですか？
A: 通常、オンボーディングには 3 ～ 5 営業日かかります。
Q: 申請を送信した後、Relying Party（RP）の申請ステータスを確認するにはどうすればよいですか？
A: 5 日経っても返信がない場合は、wallet-identity-rp-support@google.com でサポートチームにお問い合わせください。
Q: RP オンボーディング フォームと公式のデベロッパー ドキュメントはどこで確認できますか？
A:
- オンボーディング フォーム: Google ウォレットの ID 依存パートナーの連絡先フォーム
- デベロッパー向けドキュメント: デジタル ID の概要
Q: 提供した情報（商品名やロゴなど）は、プロダクト エクスペリエンスでどのように使用されますか？
A: ユーザー向けの同意画面にプロダクト名とロゴが表示され、どの証明書利用者がデジタル ID をリクエストしているかをユーザーが確認できるようになっています。URL とポリシーへのリンクは、プロダクト エクスペリエンスで表示されることもあります。
Q: サンドボックス環境を開発とテストにのみ使用する場合、利用規約に署名する必要がありますか？
A: いいえ。利用規約への同意はテストに必要な手順ではありません。
Q: 始めるにあたって、リファレンス実装、サンプルコード、デモアプリはどこで入手できますか？
A:
- GitHub リポジトリ: Identity リファレンス実装。
- テスト用ウェブサイト: verifier.multipaz.org
検証担当者登録機関
Q: Verifier Registrar とは何ですか？また、どのように機能しますか？
検証ツール登録者は、ダウンストリーム クライアント（エンド RP）をオンボーディングする認証局として機能します。エンド RP は Google ウォレットと直接やり取りしません。
Q: 検証者登録機関とそのダウンストリーム クライアントの具体的なオンボーディング プロセスを教えてください。
A: Verifier Registrar Guide の手順を参照してください。
Q: 直接 RP 統合との違いは何ですか？
A: 検証ツール登録業者はクライアントの信頼関係を管理し、クライアントに代わって Google ウォレットとの統合を処理しますが、直接 RP は Google との構成を独自に管理します。
Q: Verifier Registrar では、Google の構成で許可リストに登録されるのは、Verifier Registrar、エンド RP、それとも両方ですか？
A: Google は、検証ツール登録機関のルート CA 証明書を許可リストに登録します。検証ツール登録者は、各ダウンストリーム エンド RP に新しいリーフ証明書を発行します。
Q: エンド RP、検証ツール登録機関、Google ウォレットの間でデータはどのように流れますか？
A: Verifier Registrar は、エンド RP のために Google ウォレットに API リクエストを送信します。Google ウォレットは暗号化された認証情報データを検証者登録機関に返し、検証者登録機関はそれを処理して最終的なシグナルをエンド RP に送信します。
Q: ホワイトラベル ソリューションの場合、ユーザーの同意フローで検証機関登録者の名前を表示する必要がありますか？それとも、エンド RP の名前のみでよいですか？
A: いいえ。検証機関の登録者は、詳細情報を表示しないように選択できます。
Q: ルート CA と RP 証明書で許可されている鍵の種類と曲線は何ですか？
A: 証明書は P-256 / ECDSA を使用して生成する必要があります。
Q: ルート CA と RP リーフ証明書の間で中間署名者証明書を使用できますか？
A: はい。有効期間の長いルート証明書を安全に保存（HSM など）して、運用の中間証明書に署名する頻度を減らすことができます。これらの中間証明書を使用してエンド RP リーフ証明書に署名すると、ルートに影響を与えることなく、侵害が発生した場合に簡単にローテーションできます。
Q: 証明書の有効期間はどのくらい必要ですか？
A: ルート CA 証明書の有効期間が 10 年間であることは、まったく問題ありません。通常、エンド RP リーフ証明書は、問題が発生した場合に効率的にローテーションできるように、約 1 年の更新スケジュールに従う必要があります。
Q: 個々の Relying Party（RP）のお客様ごとに個別のリーフ証明書を管理する必要がありますか？
A: はい。初期リリース期間中、アグリゲータはダウンストリーム RP ごとに個別の証明書を管理する必要があります。これにより、RP ごとのディスプレイ構成と不正行為の正確な追跡が可能になります。この方法では、大規模な運用オーバーヘッドが発生しますが、初回ロールアウト後に、代替案（RP メタデータ ハッシュの使用など）を再検討する予定です。
Q: パートナーは複数の有効な証明書を同時に持つことができますか？
A: はい。この構成では、RP またはアグリゲータごとに任意の数の有効な証明書をサポートしています。これは、さまざまなビジネス名で運営しているパートナーにとって便利です。
Q: 識別名（サブジェクト）はどのようにフォーマットすればよいですか？
A: 識別名はパートナーごとにグローバルに一意である必要があります。これは、Google がパートナーからのリクエストをモニタリングし、エコシステムの信頼性を確保するために使用する静的 ID として機能します。
Q: ドメイン バインディングの仕組みを教えてください。オリジンを証明書に埋め込む必要がありますか？
A: ドメインを証明書自体に直接埋め込む必要はありません。代わりに、API 呼び出し内の expected origins パラメータを使用してドメイン検証が行われます。また、複数のドメインを 1 つの証明書にシームレスに関連付けることができます。署名なしのリクエストの場合、バインディングはドメインまたはアプリ パッケージ名とフィンガープリントを使用して実行されます。
Q: ホワイトラベル エクスペリエンスの確認 UI でアグリゲータの詳細を省略できますか？
A: はい。アグリゲータ情報（名前、ロゴ、URL、プライバシー ポリシーなど）は、検証ツールのメタデータ内で完全に任意です。これにより、エンド RP の詳細のみがユーザーに表示される完全なホワイトラベル ソリューションが可能になります。
Q: サンドボックス環境でテストを開始するには、何を提供する必要がありますか？
A: 技術的な観点からすると、サンドボックス ルート証明書のみを提供する必要があります。サンドボックスは、本番環境を完全にミラーリングするように設計されています。
Q: 検証機関（アグリゲータ）のオンボーディング プロセスは、直接 RP と比べてどう違うのですか？
A: アグリゲータは、若干変更されたプロセスを経ます。特定の Verifier Registrar 利用規約に同意すると、登録手続きは 2 つの部分に分かれます。まず、Verifier Registrar としてのステータスを確立するためのメインのフォームに記入し、次に、オンボーディングする RP ごとに必要な簡略化されたフォームに記入します。通常、RP の申請には統合の動画録画が必要で、審査プロセスには通常 2 ～ 3 営業日かかります。
Q: 仲介業者として行動したり、確認サービスを他の事業者に再販したりすることを目的とするお客様をオンボーディングできますか？
A: いいえ。Google の現在のモデルと優先事項は、ネストされた販売パートナー モデルや仲介モデルをサポートするのではなく、検証機関登録事業者（アグリゲータ）とその直接のエンド RP と直接連携することです。
技術統合と API
Q: リクエストの基盤となるプロトコルは何ですか？サポートされているバージョン
A: 主なプロトコルは、Verifiable Presentations（OpenID4VP）バージョン 1.0 の OpenID です。
Q: Google は mDL プレゼンテーションでどの ISO 18013-7 付録（付録 B、C、D など）をサポートしていますか？
A: Google は付録 D（DC API を使用する OpenID4VP）をサポートしています（現在ドラフト版）。
Q: 1 回のユーザー提示で複数の認証情報をリクエストするには、API リクエストをどのように構成すればよいですか？
A: 両方の認証情報タイプを同じ JSON リクエスト内の単一の dcql クエリ オブジェクト内でリクエストする必要があります。
Q: API で、可能なすべての認証情報タイプをリストせずに汎用認証情報をリクエストできますか？
A: いいえ。
Q: API は年齢確認をどのように処理しますか？正確な生年月日をリクエストできますか？それとも「X 歳以上」のシグナルのみですか？
A: どちらもサポートされています。birth_date、age_in_years、またはプライバシーの保護を目的とした「X 以上」シグナルをリクエストできます。ゼロ知識証明（ZKP）は、真偽シグナルにも使用できます。
Q: PKI インフラストラクチャの要件は何ですか？
A: RP はリクエストに署名するために PKI を必要とします。検証者登録事業者は独自の CA として機能します。
Q: 既存の証明書を使用できますか？それとも、Google が署名した新しい証明書を取得する必要がありますか？
A: RP は、Google または Verifier Registrar によって署名された新しい証明書が必要です。検証ツール登録機関の場合、ドキュメントの「信頼の確立」の手順に沿って対応すれば、Google はルート証明書を信頼します。
Q: ウェブと Android アプリで推奨される統合戦略は何ですか？
A: リクエスト全体をサーバーサイドで生成する必要があります。Android では Credman API を使用し、ウェブでは Digital Credentials（DC）API を使用します。
Q: デベロッパーが利用できるデバッグ、ロギング、オブザーバビリティ ツールは何ですか？
A: パートナー様は wallet-identity-rp-support@google.com サポート エイリアスを使用できます。特定のロギング ツールやオブザーバビリティ ツールは提供されていません。
認証情報とデータ
Q: 国や地域ごとにサポートされているデジタル ID、発行者、認証情報はどれですか？
A: サポートされているリージョンについては、サポートされている発行者と証明書をご覧ください。
Q: 新しい国や地域の認証情報のサポートはいつから開始されますか？
A: 新しい地域を積極的に追加しています。最新情報については、サポートされているカード発行会社に関するページをご確認ください。
Q: 発行者が認証情報を更新した場合、エンドユーザーに通知は届きますか？
A: はい。ユーザーに通知され、アップデートが自動的に適用されます。
Q: Google はサーバーにどのような認証情報データを保存していますか？特に GDPR の観点から教えてください。
A: Google は認証情報関連のデータをサーバーに保存しません。データはユーザーのデバイスにローカルで安全に保存されます。
テストと環境
Q: エンドツーエンドのフロー全体をテストするためのサンドボックス環境にアクセスするにはどうすればよいですか？
A: サンドボックスは サンドボックス モードで開きます。
Q: 公式にリリースされた地域に拠点を置いていないパートナーがテスト用の許可リストに追加されるプロセスを教えてください。
A: テスト用ウォレットの Gmail ID を wallet-identity-rp-support@google.com にメールで送信してください。
Q: テスト用のウェブサイトやアプリをデモ目的で有効にして、本番環境の認証情報を持つユーザーが誰でもデモを行えるようにするには、どのような手順が必要ですか？
A: パートナー様は、サンドボックス動画デモを含む標準の RP オンボーディングを完了する必要があります。
ユーザー エクスペリエンス（UX）
Q: 確認フローを開始したときに、デジタル ID を持っていない、または Google ウォレット アプリがインストールされていない場合、ユーザー エクスペリエンスはどうなりますか？
A: アプリをインストールしていないユーザーは Google Play ストアに誘導されます。ID をお持ちでない場合は、ハーフスクリーン UI を使用してフロー内で作成できます。
Q: ユーザーに本人確認オプションを表示する前に、ユーザーがウォレットにデジタル ID を登録しているかどうかをプログラムで検出できますか？
A: いいえ。プライバシーを保護するため、API はユーザーが呼び出す必要があります。
Q: 認証情報を提示する前に、生体認証でデバイスのロックを解除するようユーザーに要求できますか？
A: ユーザー認証（生体認証、PIN、パターン）はデフォルトで必須であり、無効にすることはできません。
Q: ユーザーの同意画面でリクエストされる属性の順序をカスタマイズすることはできますか？
A: いいえ。Google ウォレットでは、カードはアルファベット順に並べ替えられます。
セキュリティとコンプライアンス
Q: ユーザーデータを第三者と再共有するユースケースがあります。これは利用規約で許可されていますか？
A: はい、制限が適用される場合があります。詳しくは、利用規約をご覧ください。
Q: コンプライアンスの目的で、デジタル ID ソリューションのセキュリティ、信頼性、アクセシビリティに関するドキュメントはありますか？
A: パートナーは Trail of Bits のセキュリティ レビューを参照できます。
高度な機能とロードマップ
Q: プライバシー保護の年齢確認におけるゼロ知識証明（ZKP）の機能は何ですか？
A: ゼロ知識証明（ZKP）は、個人（証明者）が、実際の基盤となるデータ自体を開示することなく、特定の ID 情報を持っていることや特定の基準を満たしていること（18 歳以上である、有効な認定資格を保持しているなど）を検証者に証明できる暗号手法です。
Q: ZK 回路のさまざまなバージョンはどのように処理されますか？
A: RP は、利用可能な最新の回路をリクエストするために、ZK 検証ツール サービスを実装する必要があります。
Q: スマートフォンやウェアラブルなど、複数のデバイス間で認証情報の共有と管理はどのように機能しますか？
A: 認証情報は 1 つのデバイスにプロビジョニングされ、共有することはできません。
その他
Q: パスポートが取り消された場合、Google は ID パスの取り消しをどのように処理しますか？
A: ユーザーは Google アカウントの設定からパスを削除できます。デバイスを紛失した場合は、報告して認証情報を取り消すことができます。
Q: mDL の取り消しはどのように処理されますか？リアルタイムですか？
ユーザーがトリガーすることも、発行者（DMV）がプッシュすることもできます。デバイスがオンラインの場合はリアルタイムで、そうでない場合は短期間のセキュリティ オブジェクト（MSO）の有効期限が切れます。
Q: RP の鍵のローテーション ポリシーは何ですか？
A: 年 1 回のローテーションをおすすめします。
Q: Digital Credentials API でサポートされている最小の Android バージョンは何ですか？
A: Android 9（API レベル 28）以降。
Q: Digital Credentials API をサポートする最小の Chrome バージョンは何ですか？
A: Chrome バージョン 128 以降。
Q: Digital Credentials API に対応しているブラウザを教えてください。
A: ブラウザのサポートの詳細については、https://digitalcredentials.dev/ecosystem-support をご覧ください。
Q: 新しい国でサービスが開始されたときに ID を追加できるのは、どのユーザーですか？
A: アクセスは、Google Play ストアのユーザーの国設定に基づいています。
Q: Digital Credentials API は iOS で動作しますか？
A: はい。この API は、Safari などのサポートされているブラウザで動作します。ただし、OpenID4VP は Apple でサポートされていません。