On Tue, Sep 9, 2025 at 12:48 PM Daniel Bratell <bratel...@gmail.com> wrote:
> 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. > Yeah, signing-in to the email provider can open a lot of challenges. Doesn't seem like we are cornering ourselves, but yeah, probably simplifies a bunch if we assume that the user is already logged in to the email provider. > /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 | 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/CAMtUnc6tit4yHzbSkDOBDM-U49U4T7QLHf9F%2Br37%3D1y7N9SYkg%40mail.gmail.com.
