このページでは、デジタル ID と認証情報に関する Google ウォレットとの統合について、よくある質問とその回答を紹介します。
オンボーディングと利用開始
Q: 新しいパートナーが証明書利用者（RP）としてオンボーディングするための手順を教えてください。
A: コースを選択の手順ガイドに沿って操作してください。
Q: RP のオンボーディング プロセスにかかる一般的な期間はどのくらいですか？
A: 通常、オンボーディングには 3 ～ 5 営業日かかります。
Q: 提出後に、証明書利用者（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 Reference Implementation。
- テスト用ウェブサイト: verifier.multipaz.org
確認者登録事業者
Q: Verifier Registrar とは何ですか？また、どのように機能しますか？
A: 検証者登録機関は、ダウンストリーム クライアント（エンド RP）をオンボーディングする認証局として機能します。エンド RP は Google ウォレットと直接やり取りしません。
Q: 認証登録事業者とその下流のクライアントの具体的なオンボーディング プロセスはどのようなものですか？
A: Verifier Registrar Guide の手順を参照してください。
Q: RP との直接統合とはどのように異なりますか？
A: 検証者登録事業者は、クライアントの信頼関係を管理し、クライアントに代わって Google ウォレットとの統合を処理します。一方、直接 RP は、Google との独自の設定を管理します。
Q: 検証者登録機関では、Google の構成で許可リストに登録されるのは、検証者登録機関、エンド RP、またはその両方のどちらですか？
A: Google は、検証者登録機関のルート CA 証明書を許可リストに登録します。その後、検証者登録機関は、各下流エンド RP に新しいリーフ証明書を発行します。
Q: エンド RP、検証者登録機関、Google ウォレットの間でデータはどのように流れますか？
A: 検証者登録機関が、エンド 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: 個々の証明書利用者（RP）のお客様ごとに個別のリーフ証明書を管理する必要がありますか？
A: はい。最初のリリース期間中、アグリゲータは下流の RP ごとに個別の証明書を管理する必要があります。これにより、RP ごとの表示構成と正確な不正行為の追跡が可能になります。この方法では、大規模な運用でオーバーヘッドが増加しますが、最初のロールアウト後に、RP メタデータ ハッシュの使用など、代替手段を検討する予定です。
Q: パートナーは複数の有効な証明書を同時に保持できますか？
A: はい。この構成では、RP またはアグリゲーターごとに任意の数の有効な証明書がサポートされます。これは、さまざまなビジネス名で運営しているパートナーにとって便利です。
Q: 識別名（サブジェクト）はどのようにフォーマットすればよいですか？
A: 識別名は、パートナーごとにグローバルに一意である必要があります。これは、Google が受信したパートナー リクエストをモニタリングし、エコシステムの信頼性を確保するために使用する静的識別子として機能します。
Q: ドメイン バインディングはどのように機能しますか？オリジンを証明書に埋め込む必要がありますか？
A: ドメインを証明書自体に直接埋め込む必要はありません。代わりに、API 呼び出し内の expected origins パラメータを使用してドメイン検証が行われます。さらに、複数のドメインを 1 つの証明書にシームレスに関連付けることができます。署名されていないリクエストの場合、バインディングはドメインまたはアプリ パッケージ名とフィンガープリントを使用して実行されます。
Q: ホワイトラベルのエクスペリエンスでは、確認 UI からアグリゲータの詳細を省略できますか？
A: はい。検証ツールのメタデータ内で、アグリゲータ情報（名前、ロゴ、URL、プライバシー ポリシーなど）は完全に任意です。これにより、エンド RP の詳細のみがユーザーに表示される、完全にホワイトラベル化されたソリューションが実現します。
Q: サンドボックス環境でテストを開始するには、何を提供する必要がありますか？
A: 技術的な観点からは、サンドボックス ルート証明書のみを提供する必要があります。サンドボックスは、本番環境をそのままミラーリングするように設計されています。
Q: 検証者登録事業者（アグリゲーター）のオンボーディング プロセスは、直接 RP とどのように異なりますか？
A: アグリゲータのプロセスは、少し異なります。特定の検証者登録機関の利用規約を締結すると、登録手続きは 2 つの部分に分かれます。まず、検証者登録機関としてのステータスを確立するためのメインフォームがあり、次に、オンボーディングする個々の RP ごとに必要な簡素化されたフォームがあります。通常、RP の提出ごとに統合の動画録画が必要であり、審査プロセスには通常 2 ～ 3 営業日かかります。
Q: 仲介業者として活動する、または他の事業者に身元確認サービスを再販する予定のお客様をオンボーディングすることはできますか？
A: いいえ。Google の現在のモデルと優先事項は、ネストされた販売パートナーや仲介モデルをサポートするのではなく、検証者登録機関（アグリゲーター）とその直接のエンド RP と直接連携することです。
技術統合と API
Q: リクエストの基盤となるプロトコルは何ですか？サポート対象のバージョン
A: 主なプロトコルは、OpenID for Verifiable Presentations（OpenID4VP）バージョン 1.0 です。
Q: Google は、mDL の提示に関して、どの ISO 18013-7 付属書（付属書 B、C、D など）をサポートしていますか？
A: Google は Annex D [現在ドラフト段階]（DC API を使用した OpenID4VP）をサポートしています。
Q: 1 回のユーザー プレゼンテーションで複数の認証情報をリクエストする API リクエストを正しく構成するにはどうすればよいですか？
A: 両方の認証情報タイプを、同じ JSON リクエスト内の単一の dcql クエリ オブジェクト内でリクエストする必要があります。
Q: API では、考えられるすべての認証情報タイプをリストアップせずに、一般的な認証情報をリクエストできますか？
A: いいえ。
Q: API は年齢確認をどのように処理しますか？正確な生年月日をリクエストできますか？それとも「X 歳以上」というシグナルのみですか？
A: どちらもサポートされています。birth_date、age_in_years、またはプライバシーを保護する「X 以上」のシグナルをリクエストできます。ゼロ知識証明（ZKP）は、true/false シグナルにも使用できます。
Q: PKI インフラストラクチャの要件は何ですか？
A: RP は署名付きリクエストに署名するために PKI を必要とします。検証登録事業者は独自の CA として機能します。
Q: 既存の独自の証明書を使用できますか？それとも、Google が署名した新しい証明書を取得する必要がありますか？
A: RP には、Google または検証者登録機関によって署名された新しい証明書が必要です。検証者登録事業者の場合、ドキュメントの「信頼の確立」の手順に沿って操作すると、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: エンドツーエンドのフロー全体をテストするために、サンドボックス環境にアクセスするにはどうすればよいですか？
A: サンドボックスは Sandbox Mode で開きます。
Q: 正式にリリースされた地域に拠点を置いていないパートナーが、テスト用の許可リストに追加されるプロセスはどのようなものですか？
A: テスト用ウォレットの Gmail ID を wallet-identity-rp-support@google.com にメールで送信してください。
Q: 本番環境の認証情報を持つユーザーがデモ目的でテスト用のウェブサイトやアプリを提示できるようにするには、どのようなプロセスが必要ですか？
A: パートナーは、サンドボックス動画デモを含む標準の RP オンボーディングを完了する必要があります。
ユーザー エクスペリエンス（UX）
Q: ユーザーが本人確認フローを開始したときに、デジタル ID を持っていない場合や Google ウォレット アプリをインストールしていない場合、ユーザー エクスペリエンスはどうなりますか？
A: アプリをインストールしていないユーザーは、Google Play ストアに誘導されます。ID を持っていないユーザーは、ハーフスクリーン UI を使用してフロー内で ID を作成できます。
Q: 本人確認オプションを表示する前に、ユーザーがウォレットにデジタル ID を登録しているかどうかをプログラムで検出できますか？
A: いいえ。プライバシーを保護するため、API はユーザーが呼び出す必要があります。
Q: 認証情報を提示する前に、生体認証でデバイスのロックを解除するようユーザーに要求することはできますか？
A: ユーザー認証（生体認証、PIN、パターン）はデフォルトで必須であり、無効にすることはできません。
Q: ユーザーの同意画面で、リクエストされた属性の順序をカスタマイズすることはできますか？
A: いいえ。Google ウォレットではアルファベット順に並べ替えられます。
セキュリティとコンプライアンス
Q: ユースケースに、ユーザーデータをサードパーティと再共有することが含まれています。これは利用規約で許可されていますか？
A: はい。制限が適用される場合があります。詳しくは、利用規約をご覧ください。
Q: コンプライアンスを目的としたデジタル ID ソリューションのセキュリティ、信頼性、アクセシビリティに関するドキュメントはありますか？
A: パートナーは、Trail of Bits のセキュリティ レビューを参照できます。
上級者向け機能とロードマップ
Q: プライバシーを保護する年齢確認におけるゼロ知識証明（ZKP）の機能は何ですか？
A: ゼロ知識証明（ZKP）は、個人（証明者）が、特定の個人情報を所有していること、または特定の基準を満たしていること（18 歳以上である、有効な認証情報を保持しているなど）を、実際の基礎となるデータ自体を明らかにすることなく、検証者に証明できる暗号手法です。
Q: ZK 回路の異なるバージョンはどのように処理されますか？
A: RP は、利用可能な最新の回路をリクエストするために、ZK 検証サービスを実装する必要があります。
Q: スマートフォンとウェアラブルなど、複数のデバイス間で認証情報の共有と管理はどのように行われますか？
A: 認証情報は 1 台のデバイスにプロビジョニングされ、共有することはできません。
その他
Q: パスポートが取り消された場合、Google は ID パスの取り消しをどのように処理しますか？
A: ユーザーは Google アカウントの設定からパスを削除できます。デバイスを紛失した場合は、報告して認証情報を取り消すことができます。
Q: mDL の取り消しはどのように処理されますか？リアルタイムですか？
A: ユーザーがトリガーすることも、発行元（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 でサポートされていません。