ステップ 4: 統合をテストする

本番環境でリリースする前に、テスト ID パスを使用して、サンドボックスで統合がエンドツーエンドで機能することを確認し、フロー全体のデモ動画を録画します。Google は、オンボーディングのステップ 5 でこの動画を審査します。

開始

パスを選択 RP、確認登録者、対面式
1
サンドボックスをセットアップする アカウントを許可リストに登録してスイッチ デバイスを切り替える
2
テスト ID を作成する テスト ID パスをウォレットに追加する
3
統合 パスごとに構築:
証明書利用者→ 検証者登録機関→
4Here
統合をテストする E2E チェックリストを実行して動画を録画する
5
リリース リリース方法を選択:
証明書利用者→ 検証者登録機関→

このページの手順

A サンドボックスの設定を確認するデバイス、テスト ID、署名鍵、IACA ルート B リクエストと UX フローをテストするセレクタ、同意画面、エラーを確認する C サーバー検証をテストするJWE 復号と IACA 署名を確認する D E2E 動画を録画するRP または VR の承認用のデモを録画する

テストに関する重要なリファレンス

サポートされている認証情報と属性

mDL、ID パス、写真付き身分証明書でサポートされている正確な doctype_value 識別子とクレームパスを確認します。

サポートされている発行元と IACA 証明書

本番環境発行者の IACA ルート証明書と Utopia サンドボックス証明書をダウンロードします。

インタラクティブなウェブ検証ツール

統合を OpenWallet Foundation のホスト型リファレンス検証ツールと並べて比較します。

ステップ A: サンドボックス テストの設定を確認する

エンドツーエンド テストを実行する前に、次の 4 つの前提条件が満たされていることを確認してください。

  1. テスト ID を使用したサンドボックス モードのデバイス: Android テストデバイスが SANDBOX に切り替えられ（ステップ 1）、Google ウォレットに Utopia の ID パスが追加されている（ステップ 2）。
  2. サンドボックス リクエストの署名:
    • 証明書利用者: サーバーは、事前に信頼されたサンドボックス テスト鍵ペアとメタデータを使用してリクエストに署名します。
    • 検証者登録機関: Google は、サンドボックス ルート CA がサンドボックス トラストストアに存在することを確認しました。サーバーは、サンドボックス ルート CA にチェーンされたリーフ証明書を使用して署名付きリクエストに署名し、CBOR エンコードされた gw_rp_metadata_bytes を含めます（ステップ 3.A: VR 仕様）。
  3. リクエストに ID パス doctype が含まれている: サンドボックス テスト ID は ID パスであるため、dcql_query は com.google.wallet.idcard.1 または org.iso.23220.photoid.1 をリクエストします（または、ステップ 3.A のマルチ認証情報リクエストを使用します）。
  4. サーバーが Utopia Sandbox 証明書を信頼している: サーバーのトラストストアに Utopia Sandbox 証明書が含まれているため、Utopia テスト ID の issuerAuth 署名検証が成功します。

ステップ B: リクエスト、ユーザー エクスペリエンス、エラー処理をテストする

サポートしている各プラットフォーム（Android アプリ、モバイルウェブ、パソコンのクロスデバイス ウェブ）で、次の各チェックを行います。

  • 目に見えるエントリ ポイント: ユーザーがタップまたはクリックすると、わかりやすいボタン（「デジタル ID で確認」など）によってリクエストが開始されます。
  • Android アプリ（該当する場合）: CredentialManager.getCredential() をタップすると、Android の認証情報セレクタが開き、サンドボックス テストの ID パスが表示されます。
  • ウェブ（該当する場合）: navigator.credentials.get() は、モバイル ブラウザで認証情報セレクタを開き、署名付きリクエストを使用している場合は、パソコンのブラウザでクロスデバイス QR コードを表示します。
  • Google ウォレットの同意画面: 認証情報をタップすると Google ウォレットが開き、gw_rp_metadata_bytes の表示名、ロゴ、プライバシー ポリシーのリンクと、リクエストした属性のみが表示されます。
  • データの最小化: ユースケースに必要な属性のみがリクエストされ（サポートされている認証情報と属性を参照）、各クレームに intent_to_retain が正確に設定されている。
  • ユーザーによるキャンセルと代替: シートのキャンセル（Android の GetCredentialCancellationException、ウェブの拒否された Promise）または照合用のウェブ商品アイテム ID がないテスト（NoCredentialException）が UI で適切に処理される。

ステップ C: サーバーサイドの復号と暗号検証をテストする

Google ウォレットで同意画面を承認したら、サーバーが必要なすべての暗号チェックを実行することを確認します。

  • JWE 復号: サーバーは、client_metadata.jwks 暗号化公開鍵に対応する秘密鍵を使用して、返された identityToken を復号し、vp_token を抽出します。
  • SessionTranscript の再構築: サーバーは、OpenID4VPDCAPIHandover を使用して、正確なリクエスト nonce、暗号化 JWK サムプリント、プラットフォーム オリジン（android:apk-key-hash:... またはウェブにおけるオリジン URL）で SessionTranscript を再構築します。
  • IACA 証明書チェーンの検証（issuerAuth）: サーバーは、issuerAuth から発行者の証明書チェーンを抽出し、サンドボックスの Utopia Sandbox 証明書と照合して検証します。本番環境では、サポートされている発行者と IACA 証明書の公式の本番環境ルート証明書と照合して検証します。この確認は必ず行ってください。
  • MSO、ValueDigests、deviceSignature の検証: サーバーは、モバイル セキュリティ オブジェクト（MSO）の署名を検証し、ValueDigests が返されたデータ要素と一致することを確認し、deviceSignature を検証します（ISO/IEC 18013-5 のセクション 9.1.2 と 9.1.3）。
  • ゼロ知識証明（実装されている場合）: mso_mdoc_zk をリクエストする場合、サーバーは longfellow-zk を使用して返された証明を検証します。

ステップ D: エンドツーエンドのデモ動画を録画する

統合がステップ B と C に合格したら、アプリまたはウェブサイトから Google ウォレットの同意を経て、確認済みの状態に戻るまでのユーザー ジャーニー全体を示すスクリーン キャプチャ動画を録画します。次の表に、オンボーディング パスに基づいて含める内容を示します。

動画の要件 証明書利用者（直接） 検証者登録事業者（アグリゲータ）
表示する画面 ユーザー ジャーニー全体: エントリ画面 → 認証情報セレクタ → Google ウォレットの同意と認証 → アプリまたはサイトでの確認結果 最初の（1 番目の）ダウンストリーム証明書利用者向けの完全なユーザー ジャーニー
記録するフロー Android アプリまたはウェブ統合フロー 検証ツールホスト型（セルフホスト型）フローと販売者ホスト型（RP ホスト型）フローの両方（該当する場合）
ブランディングとディスプレイのアセット 実際の表示名、ロゴ、プライバシー ポリシー / 利用規約の URL 実際の販売者の表示アセット（名前、ロゴ、利用規約の URL）とアグリゲータの表示アセット

次のステップ

オンボーディング パスを選択して動画を送信し、本番環境でリリースします。

ステップ 5（証明書利用者）: 稼働開始 → ステップ 5（検証者登録機関）: 稼働開始 →