On Tue, Sep 9, 2025 at 10:22 AM Reilly Grant <reil...@chromium.org> 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. > Were you thinking Thunderbird on desktop or mobile? I can totally see how on mobile users are, for the most part, using native apps for email clients, rather than web email clients. So, yeah, will totally have to work on mobile too with native apps. But for desktop, that hasn't occurred to me yet. > Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome > <https://www.google.com/chrome> > > > On Tue, Sep 9, 2025 at 9:11 AM Sam Goto <g...@google.com> wrote: > >> >> >> On Tue, Sep 9, 2025 at 8:24 AM Daniel Bratell <bratel...@gmail.com> >> 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 | reil...@chromium.org | Google Chrome >>> <https://www.google.com/chrome> >>> >>> >>> On Fri, Sep 5, 2025 at 4:52 PM Chromestatus < >>> ad...@cr-status.appspotmail.com> wrote: >>> >>>> Contact emails g...@google.com >>>> >>>> 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 blink-dev+unsubscr...@chromium.org. >>>> 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 blink-dev+unsubscr...@chromium.org. >>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc5AmAU-dfneW_amEe42R%3DN5fbs9BFyh%2BP1QB0tLM8mJOg%40mail.gmail.com.
