Lack of a problem statement

[keithamus]

The explainer immediately jumps into the concepts around this feature, but what I find lacking is any words toward what problems web developers encounter today, what solutions they implement, and what we're trying to solve by implementing new features.

What constraints and requirements are present? How can we verify the solution space successfully envelops such constraints & requirements?

[dickhardt]

Agreed, problem is assumed. Does the update address the issue?

[keithamus]

I guess I'd like to have some kind of explanation with zero context, and zero assumption of the solution space. Some questions that jump out to me are (fyi some of these are just leading questions but some are actual open questions I have):

• Why do developers use emails? What do they need it for? (The current explainer just says it's a frequent activity, but doesn't explain why).
• Why are existing alternatives insufficient; if the primary purpose for email is to identify someone as real, why email? Why not OID? (Point 2. goes into a little detail about OID and mentions that the application requires a relationship with each social provider, but that doesn't seem right to me, but I haven't written a lot of auth systems, so I'd like to hear more about that).
• If OID is untenable, then let's enumerate the problems with OID. How does this problem not re-instate the same problems that OID does? For example the claim is that OID requires relationships with each social provider - so how does this avoid the problem of requiring special relationships with each email provider? Same goes with passkeys, which also seem like they could solve for this problem?
• Why is this a problem? What do developers say is difficult to do? How are users failing here? Why are we solving for those problems and not solving more abstractly - IOW why does the solution need to continue to be tied to email?
• With the problems developers encounter, how do the aim to solve them today? For example the explainer mentions "Email-based flows require dealing with deliverability issues". How do developers counter this issue today? I presume by adding a button that says "re-send email"? Why is this insufficient? Presumably developers would like more robust-ness? How does this solution solve that kind of problem? It seems that this solves it by having the service the user is signing in on talking directly to the email service provider, rather than using an email - but this is assumed to be better without explicitly stating why.
• What new problems does this solution introduce? Presumably this will require a lot more server side co-ordination, and therefore more complexity? Are developers happy with this trade-off? It seems it requires co-ordination with email service providers, so are they happy with this? What if my email service provider doesn't implement this (presumably I'm back to the "old way" of doing this?).
• What drawbacks does this solution have? From my reading, it seems that this doesn't actually verify that I, the user, have actual access to the inbox I am putting an email in. Am I wrong? It also seems like there is no "user gesture" of confirmation here. By receiving an email and copying the code/clicking the link I am not only affirming that it's an email I control, but also one that I can access the inbox of, and that I am capable enough to copy or click the link inside that email (as opposed to, say, a bot spoofing a key).

I think enumerating the core use case, the constraints, and the problems (literally with numbered bullet points) then trying to demonstrate how each bullet is addressed by this solution would help toward validating that the solution solves the problems. It's difficult to ascertain, for example, how this solution solves the delivery problem without understanding subtext about emails, the user experience of handling these, and so on. As another example, it's difficult to ascertain how this would ever do anything without the co-operation of email service providers.

[dickhardt]

Why do developers use emails? What do they need it for? (The current explainer just says it's a frequent activity, but doesn't explain why).

Developers want emails for a variety of reasons, and users want to share them with the web site. I don't think the why is relavent for the explainer. Browsers support email autofill to make it easier to share an email. The proposal makes it easier to share a verified email.

Email-based flows require dealing with deliverability issues

This is more complex than a resend button. If the developers mail domain gets a reputation on sending spam, then sites will start filtering email to spam, or not even delivering it. A resend button does not help. I think describing that does not help a reader understand the complexity.

---

The questions below are useful to clarify aspects of the proposal, and I'll update the content. Responses inline to help drive clarity.

What new problems does this solution introduce? Presumably this will require a lot more server side co-ordination, and therefore more complexity? Are developers happy with this trade-off?

The web developer would need to add code to fetch metadata and to verify the signature chain. This will be encapsulated in libraries for popular platforms. No coordination between the mail provider and the developer.

It seems it requires co-ordination with email service providers, so are they happy with this?

The mail provider will have to add this support. Google is exploring prodiving support. Any user with their own domain can point it at an issuer that supports the functionality.

What if my email service provider doesn't implement this (presumably I'm back to the "old way" of doing this?).

Yes. The user is no worse off.

What drawbacks does this solution have? From my reading, it seems that this doesn't actually verify that I, the user, have actual access to the inbox I am putting an email in. Am I wrong?

EVP has the same characteristics as receiving an ID Token from Google or other provider that provides a verified email address. Control of the identifier is what the developer is getting.

It also seems like there is no "user gesture" of confirmation here.

The user is selecting the email from the list presented in auto complete.

As another example, it's difficult to ascertain how this would ever do anything without the co-operation of email service providers.

It requires cooperation of the domain owner. This is the same as the email service provider for public domains such as gmail.com, yahoo.com, icloud.com. For users that have their own domain, they can point their domain at any issuer that offers them the service.