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.
The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.
The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse
It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.
Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.
Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.
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.
* It's not clear if this service would be provided by a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.
** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+<whatever>@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.
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.
I'll put this on the backlog of things to implement if I'm incredibly bored and want to weaken the security of my infrastructure.
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.
Neither, I do it so I can track which companies sold my email address on without my permission so I can put them on my shit list / report them to my government / shame them on the internet / whatever.
> The protocol proposes to alleviate a UX burden. The back and forth.
That seems to be _one_ aspect but that assumes you're logged into whatever email verification provider is in use.
> 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.
You assume that it's the email provider which has to implement this, which isn't so clear to me.
Only the email provider can attest that + addressing is in place, if a third party is involved, they can only explicitly match on full email addresses.
Like I said in my original comment, if it's the email provider that has to implement this, then the bulk of my issue is gone. Aside from the fact that now, as my own email provider, I have to implement this protocol somehow (easier said than done given my current infrastructure approach is aimed towards moving as many things into a non internet facing network).
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.
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 <insert site>" 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?
Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing
* 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.
Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?
Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?
The signup protocol and user flow is the same if the feature is supported or not. You just skip a step if the convenience feature is supported.
With SSO the user is inconvenienced with an additional option at sign up and login, and there's the risk of duplicate accounts. Also stronger vendor lock in.
Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite difficult.
OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.
The problem is that no one that mattered implemented them.
If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.
Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.
Oooh I like this idea!
God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost when it goes south once
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
Not really, as I can enter any email on a service login page that uses magic links for auth. The owner of that email will receive the login link but that doesn't mean they tried to login on that system.
https://github.com/WICG/email-verification-protocol/blob/mai...
could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims.
I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.
Less easily than you'd think.
You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers.
Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: <* or your domain>` and `Access-Control-Allow-Credentials: true` in its response.
Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content.
> I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol.
Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.