Email Verification Protocol (EVP).

Email verification is the most common onboarding step in CIAM and one of the leakiest. The BoF request for the IETF session describes the problem plainly: the user switches to a mail client, waits, finds the message and re-enters a code, many abandon at that step, and because the user carries the code by hand, any site that asks for it can phish it. EVP replaces that loop with a token the browser fetches in the background.

The mechanics are in draft-hardt-email-verification-02. The issuer signs an Email Verification Token; the browser signs a key binding naming the relying party's origin and nonce; the relying party checks both signatures, the audience and the nonce. That is the same pattern as a sender-constrained token: possession of the token alone is not enough. The draft also supports private per-RP addresses, which the issuer creates and forwards to the real mailbox. The draft says they should be unique per user and per relying party origin, which serves data minimization: two sites cannot match the user by email address.

Status. The Email Address Verification BoF request was approved as working-group forming, with Andy Newton as responsible AD. It proposes a working group starting from two drafts: EVP, and an OTP-Token email header that carries an origin-bound code for domains without an EVP issuer. The session is on the IETF 127 agenda for Tuesday, November 17, 2026, 14:00 to 16:00 Pacific. The browser side is the W3C WICG Email Verification API.

Our reading. Do not rip out code-based verification. EVP only works where the email domain has delegated to an issuer and the browser supports the API, so OTP or magic links stay as the fallback for years. The practical move for a CIAM team is to keep the verification step pluggable, so a verified-token path can be added next to the code path. The trade-offs between today's two methods are in magic links vs OTP.