EVPで招待URLを招待先メールアドレスに束縛する
秘密の招待 URL だけでは、その URL を開いたブラウザの利用者が招待先メールアドレスをコントロールしているかは分からない。秘密の招待URLは「本人」を証明しない
EVP を使える環境なら、招待 URL を「入口」に留め、権限付与の条件を 招待トークン + 招待先メールアドレスの EVP 証明 にできる。
想定フロー
- 既存ユーザーが
guest@example.comを一時利用者として招待する。 - サーバーは十分にランダムな invite token を発行し、招待レコードに
guest@example.comを保存する。 - 招待メールには redemption URL を送る。
- URL が開かれたら、サーバーは invite token だけでは権限を付与しない。
- redemption 用セッションに nonce を発行する。
- ブラウザ上でユーザーにメールアドレスを選択させ、EVP の EVT+KB を取得する。
- サーバーは EVT+KB の署名、issuer、audience、nonce を検証し、トークン中の verified email が招待レコードの
guest@example.comと一致するか確認する。 - 両方が成立したときだけ、一時セッションや匿名ユーザーに権限を与える。
この構成では、招待 URL が第三者に漏れても、その第三者が guest@example.com の EVP 証明を取得できなければ redemption を完了できない。
EVPとの相性が良い理由
EVP の Key Binding は、Issuer が署名した EVT を RP の origin と RP が発行した nonce に結び付ける。このため、別サイトや別セッションで取得した presentation token をそのまま持ち込む replay を防ぎやすい。
また Issuer は EVT 発行時に RP の identity を知る必要がないため、OIDC のように各 RP が個別に IdP と直接 federation するモデルとは性質が異なる。Email Verification Protocol (EVP) は何を証明するのか
現行ブラウザAPIでは完全に透明にはできない
重要な制約として、2026年8月時点の WICG Email Verification API 案では、ユーザーがフォームの email input でブラウザの autofill 候補からメールアドレスを選択したことが EVP 開始の契機になっている。さらにブラウザは、Issuer でログイン中か、accounts endpoint にそのメールが存在するかを検証し、ユーザーに確認 UI を出す。
したがって RP が招待レコードに保存したメールアドレスを hidden field に入れて、ユーザー操作なしに裏で EVP を済ませる、という API ではない。
招待画面では「この招待は guest@example.com 宛てです。ブラウザから同じメールアドレスを選択して確認してください」という UX が現状の仕様には近い。選択されたメールと招待先が一致しなければ拒否する。
対応できない場合
対象ブラウザが EVP 非対応、メールドメインが Issuer を提供していない、Issuer でログインしていない、対象アドレスがブラウザから利用可能でない、などの場合は EVP を必須にはできない。メールアドレス所有確認のフォールバック設計