Email Verification Protocol (EVP) は何を証明するのか
Email Verification Protocol (EVP) は、Web サイトが確認メールを送らずに「このブラウザを操作しているユーザーが、あるメールアドレスをコントロールしている」ことを暗号学的に確認するための提案である。
2026年8月時点では、IETF 側は draft-hardt-email-verification-01、ブラウザ API は WICG の Email Verification API として策定中であり、完成した標準ではない。Chrome と Edge には Origin Trial があり、Gmail と Hellō の issuer 実装が知られている。
三者モデル
EVP には主に次の三者が登場する。
- RP (Relying Party): メールアドレスを検証したい Web サイト
- Issuer: そのメールアドレスをユーザーがコントロールしていると証明できるサービス
- Browser: RP と Issuer の間を仲介する主体
メールドメインは DNS で Issuer を委譲する。ブラウザは Issuer に対して、現在のログイン状態や WebAuthn を使ってメールアドレスのコントロールを確認し、署名済みの Email Verification Token (EVT) を受け取る。さらにブラウザが RP の origin と nonce に対する Key Binding JWT を作り、EVT+KB として RP に提示する。
この分離により、Issuer が EVT を発行するときには原則として「どの RP が検証を要求したか」を知る必要がない。一方 RP は、EVT の署名、メールドメインから発見した Issuer、KB の audience、nonce などを検証することで、そのメールアドレスに対する証明を確認できる。
EVP が証明するもの
EVP が直接証明するのはメールアドレスのコントロールである。人間としての法的な本人性、雇用状態、特定人物との一致などを証明するものではない。
また IETF draft 自身が明記しているように、EVP は「そのメールアドレスでメールを受信できること」を確認する deliverability check でもない。Issuer が、そのユーザーがメールアドレスをコントロールしていると認証できることを証明する仕組みである。
この性質は、秘密の招待 URL の所持とは別物である。URL は bearer capability として扱われるため、招待先メールアドレスとの結び付きを追加したい場合は 秘密の招待URLは「本人」を証明しない と EVPで招待URLを招待先メールアドレスに束縛する のような設計が必要になる。
現在の実装上の制約
WICG の現行 API 案では、ユーザーがブラウザの autofill からメールアドレスを選択したことを契機に EVP が開始される。Issuer 側でログイン状態が確認でき、accounts endpoint に対象メールアドレスが存在する必要がある。
したがって、現時点の EVP は「あらゆるブラウザで、任意のメールアドレスをサーバーから無条件に検証できる API」ではない。対応ブラウザ、対応 Issuer、Issuer での認証状態、ユーザー操作が揃って初めて利用できる。
本番サービスでは当面 メールアドレス所有確認のフォールバック設計 を併設する必要がある。