メールの確認

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

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

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

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

役に立つリンク

• メール確認 API 仕様（WICG）（GitHub リポジトリ）
• メール確認プロトコル Internet-Draft（IETF）（GitHub リポジトリ）
• Chrome プラットフォームのステータスでのメール確認
• メール確認のオリジン トライアル登録

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

• 発行者のデモ: モックのメール アカウントとログイン セッションを提供します。
• 検証者のデモ: デモ メールまたは参加プロバイダのメールを確認します。

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

オリジン トライアルはフィードバックを収集するための試験運用です。証明書利用者または ID プロバイダとして参加する場合は、ご意見をお寄せください。問題を報告するには、次の GitHub リポジトリを使用してください。

• ブラウザのメール確認 API: WICG/email-verification
• Email Verification Protocol: dickhardt/email-verification

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

• 新しい問題: Chromium > Blink > Identity > EVP

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

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

開発が進むにつれて、こちらのブログと evp-announce@chromium.org メーリング リストで最新情報をお知らせします。

メール確認フロー

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

主な用語

Email Verification API の主な用語は次のとおりです。

• 検証者: メールアドレスを収集して検証するサイト。検証者は証明書利用者 とも呼ばれます。
• メール プロバイダ: ユーザーのメールアドレスを提供するサービス（ 例: gmail.com）。
• 発行者: ユーザーのメールのアカウントを管理するサービス（ accounts.google.comなど）。発行者は Identity Provider とも呼ばれます。

メール プロバイダと発行者が同じドメインから運営されている場合もあります。 ただし、Email Verification 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. トークンの発行: ブラウザはプロバイダの issuance_endpoint から .well-known/email-verification を検出し、一時的な鍵ペアを作成して、 発行者のファーストパーティ セッション Cookie とターゲット メールアドレスを使用して、HTTP メッセージ署名（RFC 9421）で HTTP POST リクエストを送信し、 署名付きのメール確認トークン（EVT）を受け取ります。
5. 鍵のバインドと送信: ブラウザは、署名付きの EVT を 鍵バインド 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 を省略可能として扱い、リクエストに存在する場合は処理します。

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