61–70 of 151 posts
Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.
OIDC is usually limited to a small selection of providers.
There's also a proposal to add stateless ephemeral clients.
1) Not all email providers will implement this, and
2) Users may not be signed into their email at the moment they signup
As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support staff. Again, not a bad proposal but perhaps not very useful in practice.
I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.
Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?
* It's lowering the friction to the site identifying the user (separate from the identification done now by the more sophisticated third-party tracking by surveillance companies like Google and Meta), even for sites that previously couldn't justify the friction of trying to do that. * It's putting surveillance companies even more in the loop, building on the recent "log in with [surveillance company]" buttons, while…
The ideas proposed in here aren't bad, but it does seem like you'll need to maintain two user flows as a site owner because: 1) Not all email providers will implement this, and 2) Users may not be signed into their email at the moment they signup As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support…
Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…
What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email. Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?
If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.
This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.
Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
This looks broadly similar to that, but with some newer primitives (SD-JWT) and a focus on autocomplete as an entrypoint to the flow. If I recall correctly, the entire JOSE suite (JWT, JWK, JWE, etc.) was still under active iteration while we were building Persona.
And hey, I applaud the effort. Persona got a lot of things right, and I still think we as an industry can do better than Passkeys.
For historic interest, the Persona After Action Report has a few key insights from when we spun down the project: https://wiki.mozilla.org/Identity/Persona_AAR
Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…
The protocol proposes to alleviate a UX burden. The back and forth.
it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.
I haven't managed to formulate the exact issue yet, but if I squint, I swear there's a path to track and/or deanonymize someone visiting your site. If you have any kind of previous information about the user, such as Meta, or Google or etc, you could easily try and see if the user holds any number of emails you think they might hold. From there on out we're practically back to third party cookie tracking.