Connecting an email address through a standard protocol

[Changaco]

Instead of having to send a verification message to an email address, applications like Liberapay could theoretically use a standard API to redirect the user to the email provider's website to confirm the user's address and obtain permission to send emails to that user. Unfortunately I'm not aware of any such standard protocol.

Having this would ultimately solve email delivery issues, since applications would have explicit authorizations to send messages to a specific email address. Of course anti-spam systems would have to be adapted to take this into account, and that would probably take many years, but if the big email providers like Google adopted this hypothetical standard then a large proportion of email addresses could quickly become compatible.

Having this would also pretty much kill the demand for “features” like “Sign in with Google” (#1651).

[Changaco]

Technical notes about how that standard protocol should work:

• Unlike OAuth, the protocol probably shouldn't require the application to obtain and store an ID/secret pair, because that would add complexity and hinder adoption. The authorization should be tied to the application's domain name, and a receiving email server should check that the message is signed with that domain's current DKIM key.
• Don't use a specific DNS query to determine whether an email domain supports the protocol, because that would hinder adoption. The authentication process should start with an HTTPS request to a /.well-known/... endpoint, and the application should abort if that request returns a 404 or if it fails completely (the email domain doesn't have any A or AAAA record, the server doesn't accept connections on port 443, etc.).

[bortzmeyer]

Before designing a new protocol, I suggest to think a bit about which problem exactly we are trying to solve. Ensuring we can send email? (If so, there is no best solution than to send an email.) A form of authentication?

[Changaco]

It's about solving multiple problems, really.

Firstly, the whole process of confirming an email address by sending a message containing a verification link is bad user experience. Most of us are used to it and consider it to be a minor inconvenience, but people who are more used to the “Sign in with {Google/Facebook/etc.}” buttons see it more negatively.

Secondly, this traditional way of doing things allows anyone to “trick” an application like Liberapay into sending an unsolicited email to someone else's address. Of course we have rate limits in place to prevent large-scale abuse, but it would be better to eliminate the problem entirely. Maybe ten years from now we would be able to stop supporting the old way of connecting an email address.

Thirdly, it's about avoiding the false positives of anti-spam filters by explicitly authorizing an application to send you emails, without any extra effort on your part (no “Add us to your contacts/whitelist to make sure you receive our emails”).

Fourthly, it's about reducing the appeal of the proprietary and centralized authentication solutions (Google, Facebook, etc.) by providing a standard alternative which could be adopted by all email providers, big or small.

[Changaco]

This email authentication protocol would of course be built upon existing standards. I've already mentioned DKIM, HTTP and TLS. The payload format would most likely be JSON.

My understanding of WebAuthn is that it's trying to solve a different problem. The email auth protocol would be complementary. It may even be possible to integrate both standards together in browsers to provide an even better user experience.

[Changaco]

A relevant previous attempt to solve some of the same problems is Mozilla Persona. The difference is that Persona was an intermediary, whereas my proposal is that email providers would perform the authentication directly. The advantage is that the email provider can add the application's domain to the authenticated user's whitelist, whereas Persona didn't improve email deliverability.

[Changaco]

The email auth protocol could also optionally provide an avatar URL. This would pretty much negate our need for the Libravatar protocol (#1367) and WebFinger (#1460).

[Changaco]

Two other relevant protocols are OpenID Connect and IndieAuth, however neither of them is designed to be implemented by email providers.

[Changaco]

Alternative approach with very different trade-offs: #2291.