[Secdispatch] SECDISPATCH agenda request (IETF 126): Email Verification Protocol — dispatch guidance on venue

[Dick Hardt <[e-mail]>]

Hi SECDISPATCH chairs,

I'd like to request an agenda slot at IETF 126 (Vienna) to dispatch new
work: the
Email Verification Protocol (EVP). I'm looking for the WG's help
identifying the
right home (or homes) for it, as it spans several areas.

**Problem statement.** Verifying that a user controls an email address today
relies on out-of-band OTPs or "magic links." The user has to leave the
site, dig
the code out of their inbox, and come back. This adds friction and
conversion
loss, and it is phishable — a malicious site can relay an OTP in real time.

**What EVP does.** EVP lets a browser verify email control
cryptographically,
without sending any email. It uses a three-party model: a verifier (the
site), the
user agent (browser), and an issuer (the email provider). The browser
obtains a
signed Email Verification Token from the issuer, binds it to the verifier's
origin
and a form nonce, and returns it. The verifier checks the signature,
origin, and
nonce — no inbox round-trip, and the issuer is blinded to which verifier
the user
is interacting with.

**Why now (evidence of interest).** This work started as a W3C incubation
and
was deployed by Chrome behind a flag and by Google for gmail.com users that
were
whitelisted. After significant user research, a Google Chrome origin trial
is
beginning shortly.

Based on W3C TAG feedback, the specification has been divided into the W3C
Email
Verification API that defines the browser APIs, and the IETF Email
Verification Protocol that defines the browser and issuer interactions.

The Chrome origin trial will last 3 - 6 months, and changes are welcome in
that period,
and the IETF had an opportunity to provide feedback, which is exactly why I
want to
engage the community now rather than present a fait accompli.

- I-D: draft-hardt-email-verification (Hardt, Goto)

https://dickhardt.github.io/email-verification/draft-hardt-email-verification.html
- W3C WICG companion (browser API):
  https://wicg.github.io/email-verification/

**The dispatch question.** EVP deliberately reuses existing building
blocks, and
that's the crux of where it should live:

- The token is an SD-JWT with key binding (EVT + KB-JWT) — credential-format
  territory that overlaps SPICE / OAuth.
- Issuer discovery uses DNS delegation.
- Requests are authenticated with HTTP Message Signatures and a Fetch
metadata
  request header — httpbis territory.

I am genuinely of the right venue and am not wedded to any single WG, or
for it
to be adopted by a WG. I'd welcome dispatch's read on whether this belongs
in one WG,
warrants a BoF, or should be AD-sponsored. The goal is to find the home
that gives this the best
review on a timeline that can still shape deployment.

**Ask.** ~10–15 minutes at IETF 126 for a problem statement and venue
discussion.

/Dick