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

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

Ok, now let me try to focus on the specific question of the usage three party model:

> 2 Design. There are a number of aspects to the proposed design that are hard to justify on a more detailed analysis. It seems likely that a simpler design is achievable. The design involves a three-party model where the issuer provides a credential and the credential is bound to a key. 

This is correct: we are indeed proposing a three-party model design.

> There are two reasons to share email with someone: to allow them to communicate with you and to allow them to identify you. The latter I have no care for, but the former always involves the mail provider. So I'm very much of the view that privacy with respect to an email provider is a non-goal.

I think you got the framing right (i.e. email has two uses: communication and identification), but I think I'm in disagreement with the following presupposition and the conclusion that you arrived at because of this false premise:

> Without a clear need for communication, asking for email is tracking

I think there are valid use cases for "identification" that aren't "tracking".

We need to agree on what we mean by "tracking" here, but I'm going to assume that you are referring to "selling global identifiers to data brokers with the association of the usage on the site (e.g. purchase history)" (since you don't have that problem when the email is directed to the RP).

Websites use emails (and/or phone numbers) for account creation and recovery because it is a reliable and recoverable unique identifier for the user, not, necessarily (nor sufficiently), because they are selling it to data brokers. The fact that websites send a confirmation email for those cases is an unfortunate accident of path dependence: the website doesn't need (nor want) to communicate with the user at that point (or even at all), they send confirmation emails to verify if the user owns it. The fact that it is memorable and utterable by a user makes it specifically recoverable, for example, on cases like talking over the phone with a customer services agent (e.g. with an airline representative or banks).

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.

One of the principles here that I think applies is "minimal data for a constrained use" and "justified parties": if we can provide proof of ownership of an user's email address to a website without revealing that to the email provider (and, and as I stated above, in account creation/recovery neither communication nor tracking needs to be involved), why would we deliberate choose do that?



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

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