メールの確認

Email Verification API は、ブラウザがメール プロバイダと直接通信して、ユーザーがメールアドレスを所有していることを確認できるようにする提案です。ユーザーがメールアドレスを入力してフォームを送信すると、サイトはメールを送信したりユーザーのフローを中断したりすることなく、ブラウザからプロバイダに署名付きメール確認トークンを送信して検証します。

登録、ログイン、購入手続き、ニュースレターの登録、アカウント復元時にメールアドレスを収集する場合、サイトは通常、フォームを送信したユーザーがそのアドレスを管理していることを確認します。既存の確認方法では、ユーザーはサイトを離れ、アプリを切り替えて受信トレイを確認し、OTP をコピーするか、確認リンクをクリックする必要があります。この中断により、人間ユーザーと自動エージェントの両方で離脱とセッションの放棄が増加します。ユーザーは、メールの遅延、リンクの有効期限切れ、コードの認識エラーなど、既存の確認方法で不便を感じることがよくあります。

メール確認のユーザー プロンプトのデモ
メールアドレスの確認のユーザー プロンプトのデモ

メール確認は、既存のフローのプログレッシブ エンハンスメントとして機能します。

  • 中断なし: ユーザーがフォームに記入している間に、バックグラウンドで検証が行われます。
  • 機能検出は不要: サイトは、メール入力と非表示のトークン入力をフォームに追加します。ブラウザまたはプロバイダがメール認証をサポートしていない場合、または認証に失敗した場合、サイトはデフォルトのメール確認フローにフォールバックします。
  • フィッシングのリスクを最小限に抑える: コピーするコードや、ユーザーを偽のサイトに誘導する機会がありません。

デモでフローをテストできます。

オリジン トライアルに関する考慮事項

オリジン トライアルはフィードバックを収集するための試験運用であるため、利用当事者または ID プロバイダとして参加する場合は、入力が重要になります。問題を報告するには、次の GitHub リポジトリを使用します。

Chrome の実装でバグが発生した場合は、次のコンポーネントで問題を報告してください。

オリジン トライアル トークンを含めることで、レスポンスごとにオリジン トライアル機能を制御できます。これにより、A/B テストの対象ユーザーなど、特定のユーザー セグメントに機能を制限できます。また、ベータ版テストや早期プレビューのユーザー グループがある場合は、そのグループに対して機能を有効にする必要があるかもしれません。この場合、トークンを発行または検証する前に、指定されたメールアドレスと照合します。

オリジン トライアルには、リリース前にこの機能に依存するサイトを最小限に抑えるためのトラフィック制限もあります。発行者 API は開発中であり、Chrome UX の更新に伴い、下位互換性のない変更が加えられる可能性があります。

開発の進捗状況については、こちらのブログと evp-announce@chromium.org メーリング リストで随時お知らせします。

メール確認フロー

以降のセクションでは、Email Verification API を使用する際の主な用語とプロトコルの手順について説明します。

主な用語

メールアドレス確認 API の主な用語は次のとおりです。

  • 検証サイト: メールアドレスを収集し、そのメールアドレスを検証したいサイト。検証ツールは、Relying Party とも呼ばれます。
  • メール プロバイダ: ユーザーのメールアドレスを提供するサービス（gmail.com など）。
  • 発行者: ユーザーのメールのアカウントを管理するサービス（accounts.google.com など）。発行者は ID プロバイダとも呼ばれます。

メール プロバイダと発行者が同じドメインで運営されている場合もあります。ただし、メール確認 API は、ID プロバイダを検証方法としてブラウザのアクティブ セッションを使用しているため、両者を区別することが重要です。たとえば、example@gmail.com を確認するには、同じブラウザでそのアカウントを使用して google.com にログインする必要があります。

プロトコル フロー

メール確認フローのアーキテクチャ
メールアドレスの確認フローのアーキテクチャ
  1. フォームの提示: 信頼当事者は、<input type="email"> と、autocomplete="email-verification-token" とインスタンスごとに一意の nonce でマークされた非表示の入力を含む HTML フォームを提供します。
  2. メールアドレスの入力: ユーザーがメールアドレスを入力すると（自動入力の候補を選択するか、入力または貼り付けを行ってフィールドを終了する（blur））、ブラウザはバックグラウンドで検証をトリガーします。
  3. 検出とセッション: ブラウザは _email-verification.<email-domain> の DNS TXT レコードをクエリして、プロバイダの承認済み発行者のオリジンを検出し、発行者の .well-known/web-identity 構成と FedCM アカウント エンドポイントを使用して、ユーザーがアクティブなセッションを持っているかどうかを確認します。ドメインが EVP レコードを公開していない場合や、アクティブなセッションが存在しない場合、ブラウザはユーザーにプロンプトを表示せずに検証を停止します。
  4. トークンの発行: ブラウザは .well-known/email-verification からプロバイダの issuance_endpoint を検出し、エフェメラル鍵ペアを作成して、発行者のファーストパーティ セッション Cookie とターゲット メールアドレスを使用して HTTP メッセージ署名（RFC 9421）で HTTP POST リクエストを送信し、署名付きメール確認トークン（EVT）を受け取ります。
  5. キー バインディングと送信: ブラウザは、署名付き EVT を Key Binding JWT（KB-JWT）内の証明書利用者オリジンとフォーム nonce にバインドします。ユーザーがフォームを送信すると、Chrome は非表示の入力欄に結合されたトークン（<EVT>~<KB-JWT>）を入力し、メール プロバイダがアドレスを確認したことをユーザーに知らせる小さな通知を表示します。
  6. クレームと KB を検証する: 信頼できるパーティ サーバーは <EVT>~<KB-JWT> トークンを解析し、予期されるクレーム（email、email_verified、aud、nonce、iat、exp）を検証し、cnf.jwk のエフェメラル公開鍵に対してキー バインディング署名を検証します。
  7. DNS と公開鍵: 信頼当事者は _email-verification.<email-domain> DNS TXT レコードをクエリして、トークンの iss クレームと一致することを確認し、発行者の .well-known/email-verification メタデータと公開鍵を jwks_uri から取得します。
  8. EVT を検証して完了: 信頼当事者は、プロバイダの公開 JWKS を使用して、発行者の EVT 署名を検証します。トークンが受信されない場合や、検証ステップが失敗した場合は、サイトは既存のメール確認プロセスにフォールバックします。

ユーザーが初めてメールアドレスを確認するとき、Chrome はトークンをリクエストする前に権限プロンプト（パソコンではダイアログ、Android ではボトムシート）を表示します。この権限が付与されると、参加サイト全体でメールアドレスごとに記憶されます。

Chromeの設定

ユーザーは確認済みのメールを管理できます。

  • パソコンの場合: [設定] > [自動入力とパスワード] > [連絡先情報] > [確認済みのメールアドレス]（または chrome://settings/contactInfo を開く）
  • Android の場合: [設定] > [住所など] > [確認済みのメールアドレス]

ユーザーは、この機能を完全に無効にすることも、個々の確認済みメールアドレスを管理することもできます。

ユースケースの考慮事項

メール確認は、既存のフローを段階的に強化するもので、ユーザーが OTP を取得したりリンクをクリックしたりするためにサイトを離れる必要がなくなります。サイトは、ログイン、ニュースレターの登録、アカウントの作成、パスワードの再設定など、関連するすべてのフォームにメールアドレス確認フィールドを追加できます。EVP は、ブラウザがサポートしている場合にのみトリガーされます。送信時にコードが受信されない場合や、検証手順のいずれかが失敗した場合は、デフォルトのメール確認フローにフォールバックできます。これは、API の機能検出がないことも意味します。検証サイトは EVT を省略可能として扱い、リクエストに存在する場合は処理します。

メール確認では、ユーザーがメールアドレスのプロバイダとのアクティブなセッションを持っていることを確認します。メールがユーザーに届いたことを確認するものではありません。既存のウェルカム メールやオンボーディング メールを送信し、迷惑メールの設定を確認するようユーザーに求める必要がある場合もあります。