Email verification protocol

There is no advantage.

"User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)

So we get a new process that solves nothing, but makes everything complicated. (And complicated helps the big and hurt the little in th long run)

Not verified but feels like a Google draft that closes the web.

1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.

2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from " is enough.

3) The device receiving the verification message is often not the same device that initiated the process. It is very important that users are able to easily type out the code in the webapp, instead of what many do: require a link to be opened.

4) Alright, use email, but don't treat as a special or absolute means of contacting users. The whole "contact user" aspect should be abstracted to a point. Any messaging app that the user would like to use should be used. There are dozens of them, and all of them should be abstracted to the webapp. Managing api keys and integrations sounds like a nightmare, this is one big reason no one is doing it. But again, that's my gripe, this is a solvable problem, services and libraries to make it easier should exist, but where they don't .. the developers of the application should take on the costs associated with supporting them. Maybe not dozens but a handful of messaging protocols, based on target audience can be used (e.g.: Signal,Whatsapp, Weechat, VK, Telegram, Bluesky, Twitter) - 7 api keys to rotate once every few months and you've just made billions of potential users happy!

5) Perhaps the problem is a lack of a "secure address resolution layer" to messaging? Without requiring api keys and all of that, it should be possible to resolve the address of a recipient, encrypt a message to them, using their public key, and simply send it. Messaging apps should support a standard protocol of receiving external messages this way. The protocol should also allow including a "reply" address?

Source address verification doesn't really mean anything (no-reply@example.co.uk) and destination verification is obvious and as far as I am aware pretty much no-one doesn't do it already.

"delivery peers symmetric" - what does that mean?

I can't tell you how many times email verification context switches made me completely lose track of what I was doing.

There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login.

There are probably dozens, maybe hundreds, of services I never finished registering for all on account of this problem.

I worked authc/authz and security for a large fintech and we constantly butted heads against the growth folks. They fought hard and eventually won the right to do account creation and IDV without email verification. You don't have to verify your email until you're already making transactions, and that does wonders for growth. We're still accountable for all the stringent KYC regulations, of course.