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

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

> When websites send emails to users, email providers don't currently get a machine-readable proof that the user has an account with this website (as opposed to, say, OIDC Identity Providers), and that seems like an important property to keep: an email provider doesn't (nor could) keep a list websites the user has an account on. On frequency, email providers also don't get notified every time a user is using the email to sign-in (which happens way more frequently than signing-up or recovery), which also seems like a property worth keeping.

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).

I don't see any way in which this arrangement changes, even if the email provider is involved in verification.  Because email verification will be a high energy event, even when automated in this way, I can't imagine any reason that a site will choose to trigger verification often.  At least not any more than a site would ask you to check your email for a code (which happens altogether too often, for sure).

A thought occurs: will sites want to use this in place of passkeys for login?  That seems like a terrible idea, but email verification is how Slack manages login today.  What steps would you take to discourage that?

> One of the principles here that I think applies is ["minimal data for a constrained use" and "justified parties"](https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf): if we can provide proof of ownership of an user's email address to a website without revealing that to the email provider, why would we deliberate choose not to do that?

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.

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

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