Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
Email verification protocol
21–30 of 151 posts
Re: Email verification protocol
#22Hard 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.
Re: Email verification protocol
#23Why must apps require email? Why not only username and password?
Because emails of real people can be sold to advertisers.
Re: Email verification protocol
#24Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
Re: Email verification protocol
#25Why must apps require email? Why not only username and password?
Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds.
It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
Re: Email verification protocol
#26Earlier quoted context omitted.
Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.
> If one only has a username and forgets the password, there’s no way to reverify the user. Tough beans?
A good user experience does its best to avoid tough beans. That's kind of UX 101.
Re: Email verification protocol
#27Re: Email verification protocol
#28Why must apps require email? Why not only username and password?
Weird that no one said this yet: To verify users' legitimacy. If you make effort to block 10 minute email services it works kinda well and slows down bots
Re: Email verification protocol
#29This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting).
This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") by making email verification exponentially more complex, with only one correct flow, and will only work for domains that have opted in and configured this protocol.
Importantly, the protocol seems to rely on 1st party web cookies, which means you could no longer run a "pure" MTA that offers IMAP; you would need to have some web interface where your users can log in, even if there is no webmail functionality.
The bigger question is: why would the company who is hosting the email have any economic incentive to invest time and money in implementing and maintaining this protocol which currently has zero adoption? It's a chicken-and-egg with no upside.
Re: Email verification protocol
#30* 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 existing login methods are destroyed through dark pattern practices or simply removed.
* It can be a ready-made platform, waiting for the next authoritarian government directives that say, now that everyone is hooked up or can easily be hooked up, turn on oppressive feature X, Y, or Z for all targeted Web sites/people.