Email Verification Protocol (EVP)

ブラウザが仲介してメールアドレスの所有権を暗号学的に検証する、確認メールを送らずに完了するメール確認のプロトコル。著者はDick Hardt（Hellō）とSam Goto（Google）。IETF Internet-Draft（draft-hardt-email-verification、2026年7月4日提出、個人提案でIETF標準としての正式な地位はまだない）として仕様化され、W3C WICGでもExplainerが公開されている。ChromeとMicrosoft EdgeでOrigin Trialが実施中で、参加メールプロバイダとしてGmailが明記されている。 #protocol #security #browser

解決しようとしている課題

従来の確認メール送信・OTP入力方式は「ユーザーが受信トレイを開いてコードやリンクを取得する」というアウトオブバンドな手順が必要で、次の2つの問題があった。

  • ユーザーがサイトを離脱することによるコンバージョン率低下
  • 悪意あるサイトによるOTP詐取（フィッシング）への脆弱性

仕組み

  1. ユーザーがフォームでメールアドレスを選択する（オートフィル的な体験）
  2. ブラウザがメールプロバイダ（issuer）と直接通信し、Email Verification Token (EVT) というJWTを取得する。EVTには検証済みメールアドレスとブラウザの公開鍵が入るが、どのサイト（RP: Relying Party）向けかは含まれない
  3. ブラウザ側でKey Binding JWT (KB-JWT)を作り、EVTと結合してRPに提示する（RPのオリジン・nonce等を含む）
  4. RPはサーバー側でトークンの署名やDNS由来の発行者情報を検証する

メールプロバイダは.well-known/email-verificationエンドポイントを用意し、トークン発行エンドポイントや署名アルゴリズム（デフォルトEd25519）などのメタデータを公開する。

プライバシー設計

三者モデルの肝は「発行者（メールプロバイダ）がRPの正体を知らない」点。Well-known/Accountsの取得時やトークン発行リクエスト時にRefererやOriginヘッダを意図的に省略する設計になっており、メールプロバイダ側は「ユーザーが今どこかで認証中」だとは分かっても「どのサイトか」は分からないようになっている。RPごとに異なるプライベートなメールアドレスを使い、サイト間相関を防ぐ仕組みも想定されている。

想定用途

アカウント新規作成時のメール確認、パスワードレスサインイン、アカウント復旧フローなど。

FedCMとの関係

同じくブラウザが第三者とRPの間を仲介し、Cookieに頼らず身元・所有権を証明するという設計思想を共有する。FedCMは外部IdPのアカウントによるログイン全般を扱うのに対し、EVPはメールアドレス所有権の検証に特化している。

出典

🔗 リンクされているノート

作成日時: 2026-08-15 17:12 / 更新日時: 2026-08-15 17:14