招待リンクとメール所有確認を分離している実例
「招待メールのリンクを知っている人」と「招待先メールアドレスをコントロールしている人」を分けて扱う設計は、EVP以前から実サービスで使われている。
Microsoft Entra B2B
Microsoft Entra External ID の B2B ゲスト招待では、招待リンクを開いた後、利用可能な federation 先がなければ email one-time passcode をフォールバックとして使える。
つまり invitation URL 単独で認証を完了させず、redemption 時に改めて招待先メールアドレスへコードを送り、そのコードを入力させる。これは メールアドレス所有確認のフォールバック設計 で述べた構成そのものである。
Google Drive の visitor sharing
Google Drive の visitor sharing では、Google アカウントを持たない相手にもメールアドレス単位でファイルを共有できる。受信者は招待メールのリンクを開いた後、Google から別途送られる PIN を入力して本人確認する。
確認後の visitor session には期限があり、再度確認が必要になる。この設計も「元の共有リンクの所持」と「メールアドレスへの現在のアクセス」を分離している。
GitHub Organization invitation
GitHub Organization では、ユーザー名ではなくメールアドレスを指定して招待した場合、その招待を受ける GitHub アカウントに同じメールアドレスが verified email として登録されている必要がある。
ここでは新しい OTP を送る代わりに、既存 GitHub アカウントで既に成立しているメールアドレス検証を利用して invitation と recipient を束縛している。
EVPとの関係
これらの例から分かるのは、秘密の招待URLは「本人」を証明しない の問題は特殊なものではないということだ。外部共有や B2B 招待では、「リンクは resource locator / invitation handle に留め、recipient identity を別経路で確認する」設計がすでに実用化されている。
Email Verification Protocol (EVP) は何を証明するのか は、このうち「メールアドレスを現在コントロールしている」という確認を、メール OTP の送受信なしでブラウザと Issuer の暗号学的証明に置き換えようとするものと捉えられる。
そのため EVPで招待URLを招待先メールアドレスに束縛する は新しい問題設定ではなく、既存の visitor / B2B invitation flow の verification step を EVP 化する設計だと見ると理解しやすい。