Re: [w3ctag/design-reviews] Incubation: Email Verification Protocol (Issue #1169)

samuelgoto left a comment (w3ctag/design-reviews#1169)

> If we're serious about service-specific identifiers, then someone needs to maintain that information for people. I have many accounts and many email addresses (I'm in the process of moving to 1:1, but that's a long term project). I see two places for that: mail providers (mine holds some of that information for me along with mail aliases) and password managers (this being the best place).

Yeah, I think I generally agree with this dichotomy: the service-specific identifiers will have to be kept either by email providers or password managers, and I agree that the latter is the best place (under the definition that we'd allow ourselves to call "password managers" and "user agents" interchangeably).

In fact, this proposal allows for service-specific identifiers to be provided and managed at the browser level (again, I'm using "browser" and "password manager" interchangeably here, architecturally speaking): both [Firefox Relay](https://relay.firefox.com/) and [Safari's Hide my Email](https://support.apple.com/en-lk/guide/iphone/iphbb888fde2/26/ios/26) offer users service-specific identifiers, which could also be offered during autofill, and could provide both a (a) service-specific as well as an (b) interoperable cryptographic proof of ownership. The browser relay isn't kept blind to the service because it is operating at the browser level, and so can generate a service-specific email address, while still operating in a three party topology (just so happens that the holder and the issuer are under the control of the same entity).

This also works at the individual level: I have my own personal email domain (I'm `me@sgo.to`), and would equally be able to provide service-specific email addresses that are also cryptographically verified (e.g. `example.com@sgo.to`) through this proposal, because my own personal issuer that I'm operating could authorize `*@sgo.to` if I'm logged in to this service (since this is a single-user domain: me).

All of that to say, I think this proposal reconciles well with site-specific email addresses.

> A thought occurs: will sites want to use this in place of passkeys for login? 

I think the answer is "yes", but not that that's necessarily bad.

I think it would be useful to ask yourself: in practice, what do you think happens before a user is able to create a passkey in the first place?

Spoiler alert: the user provides an email address and has to go through email verification.

In 2025, we wanted to test the following hypothesis: “in practice, most password/passkey creation start with email verification”. We went through the list of the [most visited websites](https://en.wikipedia.org/wiki/List_of_most-visited_websites) and followed their account creation process. 

These are very non scientific (so take them with a grain of salt) but are probably reproducible findings:

- 72% of them (18) offered social login (so already get verified email addresses through that)
- 95% of them (23/24) allowed me to create accounts with email addresses
  - 73% of them (17/23) blocked the registration flow on email verification 
  - 26% of them (6/23) started with email verification before anything else
  - 47% of them (11/23) performed email verification before I could set up a password (and, transitively, a passkey)

Email verification (as well as phone number verification) plays two key roles in account creation: provides a re-engagement channel as well as a reliable account recovery channel.

So, by the time that you are presenting a passkey, in practice, the website already has your email address (or phone number) associated with your account. There are obvious exceptions to this rule (e.g. anonymous online forums, games), but it is true for a large part of the web (e.g. at the head, traffic weighted).

> That seems like a terrible idea, but email verification is how Slack manages login today. What steps would you take to discourage that?

That to say: it is not clear to me that it would be terrible if this was used for Sign-in (in addition to Sign-up and Recovery), specially if we can make it as private as the status quo with regards to issuer-blindness and had a path to make it more private than the status quo with regards to service-blindness.

I'm only aware of a single reservation I have with this, which is the fact the email can get recycled as DNS changes hands (e.g. I believe `x.com` was an email provider before turning into twitter). That actually happens in practice at scale and is a massive security problem, but one that a certain category of website tolerates without second factors.

But beyond that, it is not clear to me that passkeys will have necessarily a strictly better privacy/security and recoverability trade-off than email verification, because it is not clear to me that (a) they'll ever be as recoverable as email (although the intent is to make them as recoverable as email) and (b) websites won't require email for re-engagement. 

To me, it is clear that, right now, based on the data that we gathered, they don't.

Long term, different websites make different trade-offs in the security/convenience spectrum, and I think that there is a sustainable and valid space in the market for verified email addresses to be used for login that will strike the right balance (e.g. when email was required at passkey creation anyway).

> I see your argument. I'm just asking what user value all this complexity delivers to the user. It's not like the site couldn't send an email, which the mail provider would then see. Indeed, many sites send a "welcome to new users" email after signup.
> That said, it seems like it would be possible to design a verification protocol that didn't reveal the identity of who is asking for verification to the email provider.

I think the biggest user value we are delivering with the three party model architectural element is to minimize least surprise: users, right now, don't expect the email provider to be necessarily and programatically contacted every time a selection is made in autofill, and anything beyond that would break their expectations (or require extra permission prompts).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1169#issuecomment-3662178880
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1169/3662178880@github.com>