> with authentication handled by cookies I created an issue <https://github.com/dickhardt/email-verification-protocol/issues/14> for that part as (to my limited knowledge) it seems like it could be done in other ways.
☆*PhistucK* On Tue, Sep 9, 2025 at 8:54 PM 'Sam Goto' via blink-dev < [email protected]> wrote: > > > On Tue, Sep 9, 2025 at 12:48 PM Daniel Bratell <[email protected]> > 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 | [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/CAMtUnc6tit4yHzbSkDOBDM-U49U4T7QLHf9F%2Br37%3D1y7N9SYkg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc6tit4yHzbSkDOBDM-U49U4T7QLHf9F%2Br37%3D1y7N9SYkg%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/CABc02_%2BfR-d9VC9qe7F0ssk114PJM7Mfk1kN4Chgf2W3yANd%2BA%40mail.gmail.com.
