I was thinking about that when reading the explainer, and I can see why
not doing it initially. If you are signing up for an account at
www.possibly-malicious.site it could be scary to have something asking
for your email password. Such questions could also make it easier for
www.really-malicious.site to trick a user to hand over their email
password to the wrong party.
It is certainly possible, but it would also add complexity and risks.
/Daniel
On 2025-09-09 19:22, Reilly Grant wrote:
It would be nice if this could support the case where the user is not
logged into their email provider (i.e. it could open an authentication
page if no cookie is present). This matters for email providers that
don't use a web-based client. For example, since I access my email
with Thunderbird there's no cookie in my browser related to my email
provider.
Reilly Grant | Software Engineer |[email protected] |Google Chrome
<https://www.google.com/chrome>
On Tue, Sep 9, 2025 at 9:11 AM Sam Goto <[email protected]> wrote:
On Tue, Sep 9, 2025 at 8:24 AM Daniel Bratell
<[email protected]> wrote:
That seems to be a major hurdle for this, unless every mail
provider in the world sets up an email verification service
Yeah, this presupposes that email servers are going to be
exporting this email verification service, which is a big if.
, sites will have to maintain two code paths for email
verification.
Yeah, same goes for websites: it requires them to add support for
it too, so it certainly comes at a cost.
I do think that the benefits outweigh the costs, at least for a
meaningful part of websites, that can help enough users.
Hard to know at the moment, so I'll keep an eye on the
cost/benefit ratio for websites and see if we are striking the
right balance, but that's part of the hypothesis that we are
trying to test in this intent to prototype.
it also requires the user to be logged in to some kind of
webmail service for their email in the browser they are using,
with authentication handled by cookies, and for the
verification site to be the same domain/site as the webmail so
that those cookies are sent. It seems to require a lot of
things to be just right to be as smooth as envisioned.
It does indeed require the user to be logged in.
You are right that it requires a lot of things to go right before
it can provide value, but I think the key insight here is that
this progressively enhances the status quo, without requiring any
user behavioral change. Meaning, if none of the stars align (e.g.
the email provider provides the service, the website supports the
cryptographic proof and the user is logged in), the user just goes
through what they were already going through with no behavioral
change. But when the stars do align, they have a better time. So,
a strict win, with no losses (other than the implementation cost)
when it isn't available.
(The spec could use more characters by the way, not everything
needs to be 3 letters long, kty, alg, typ, iat, cnf, jwp, iss,
aud, evp, ...)
All of these are coming from the JWT/SD-JWT+KB RFC, so a
convention that is already in place and time-tested by developers
deploying variations of OAuth.
/Daniel
On 2025-09-08 21:43, Reilly Grant wrote:
There's been some discussion recently on chromium-dev@ about
a new phone number verification mechanism using flash calls.
I'm curious if there's interest in expanding this work on
email verification to include both email addresses and phone
numbers.
Unrelatedly, as someone who hosts their own email I'm curious
if there are reference implementations available for the
email provider side of this system. I'd love to play around
with this API and want to be sure it's not limited to users
of the major email providers.
Reilly Grant | Software Engineer
|[email protected] |Google Chrome
<https://www.google.com/chrome>
On Fri, Sep 5, 2025 at 4:52 PM Chromestatus
<[email protected]> wrote:
Contact emails
[email protected]
Explainer
https://github.com/dickhardt/email-verification-protocol
Specification
None
Summary
The EVP (email verification protocol) helps users create,
access and recover accounts by providing cryptographic
proof that they own an email address, rather than having
to manually verify email addresses with magic links.
https://github.com/dickhardt/email-verification-protocol
Blink component
Blink>Identity
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%22>
Web Feature ID
Missing feature
Motivation
Verifying email addresses on the web today involves
receiving magic link and proving that you have access to
the email inbox. This is cumbersome for users and
inefficient for developers: emails can take a while to
arrive, can get into SPAM folders and users have to
switch applications to verify them.
Initial public proposal
https://github.com/dickhardt/email-verification-protocol
TAG review
None
TAG review status
Pending
Risks
Interoperability and Compatibility
None
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/Other signals/:
WebView application risks
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
None
Debuggability
None
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Flag name on about://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5205725253074944?gate=5165657771606016
This intent message was generated by Chrome Platform
Status <https://chromestatus.com>.
--
You received this message because you are subscribed to
the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68bb77c8.050a0220.257801.0191.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68bb77c8.050a0220.257801.0191.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMbiA47vS6bxcjChRrsHVSgOhPzBLC0ymng7-gPoOefs2A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMbiA47vS6bxcjChRrsHVSgOhPzBLC0ymng7-gPoOefs2A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6b1d2ec-1861-47ef-a3b5-63237de70e7b%40gmail.com.
