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

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

@martinthomson thanks for the feedback, much appreciated!

Let me start with the parts that I think I we'd be generally in agreement with and/or just needs clarification, and I'll post separately the part of the feedback that I think needs more thought.

> 1. Venue

Yeah, this is already something that we are actively working on with folks at the IETF to help us figure out where this fits. We'll report back to this review as this settles (and loop you in as it evolves).

>> The HTML parts are better off being taken directly to WHATWG HTML (the <input type=email> piece is tiny).

Yeah, I'm particularly unsatisfied with the `nonce` attribute added to `input`: it seems out of place. I'll follow up and report back on where this settles once this moves to a place that can get some HTML experts to look at this.

> 2. Design
> Form interaction seems like the first thing to build, which is good,

Yeah, that was our first intuition too: much of this fits into form filling. 

> The current design does not follow [our principle on where state belongs for events](https://w3ctag.github.io/design-principles/#state-and-subclassing)

Yeah, good point on having the state be in the `target` rather than the `Event` property. We'll take that and address.

> A nicer design might be to have the email field point to a (hidden) email validation field that the browser is expected to populate (read: autofill) with the token

So, this did indeed occur to us (to model this after something like a `for` attribute), and is still a valid alternative design for us. We figured that a JS event (rather than a declarative `for`) would allow this to be polyfilled, so seemed like a better start, but I don't think this is something that we feel strongly about and would be happy to experiment with.

> Whether it can then block form submission on having that field is an interesting question, you should consult someone who knows more about form submission interactions.

Yeah, we've been thinking about how to synchronize with form submission indeed ... specifically, one of the challenging event sequencing questions is with regards to users typing emails (rather than selecting them from a list): since we don't know when users are "done" typing emails, `onblur` seemed like a good option to start the process (but we think that this might be "too late", since `onblur` is probably happening right as if the user is clicking on the `<button>` to submit the form). In any case, yeah, we are already engaging more with the folks more familiar with form submission and actively trying to figure out how we could make this work. 

We'll also report back as we gather implementation experience and learn how this might work.

> 3 User benefit. The justification for this feature is pretty compelling, but the explainer doesn't make a great case. As I understand it, the reason to do this is because verifying that you control an email address is super annoying. 

Yeah, I think you got it right on: the user benefit here is that verifying control of an email address today is possible but super annoying (read: inefficient).

> 4. Usage. Will sites believe these claims, or will they build a list of mail services that they trust to provide this sort of proof?

We believe sites will believe these claims, because they are authoritative statements made by the email provider itself, and doesn't require any allow-listing of any sort: we expect website to believe these statements in the same (open) way that they believe a user that is able to recover a non-guessable OTP from access to their inboxes.

> 5. Enrollment and UX. The browser needs to know to match the request to something it has. For services with webmail that is actively used, this might be something that can be automated. Because there will be active cookies for the domain that the mail provider delegates to. But what if there are no active cookies? Do you offer the user an option to enroll when they pick the email address? It seems like the current design doesn't offer validation if there are no cookies, but is that the right choice? My sense is that if this doesn’t work when someone is not logged in, it will have failed. (I understand that you might want to insist on the mail provider having web presence of some sort, but that’s it.)

There are a couple of things that occurred to us:  

- First, most users using browsers on mobile devices are not logged in to their email website, but rather to their email native app. We think we can make this work well for browsers on mobile devices by talking directly to native apps, rather than via HTTP. For example, on Android, via things like [bound services](https://developer.android.com/develop/background-work/services/bound-services) and [digital asset links](https://developers.google.com/digital-asset-links/v1/getting-started). This isn't well written in our explainer, but it is something that we are actively exploring for FedCM and I think is fairly transposable to this. I'll also take the action item to write down and report back on this thread how this might work.
- Second, we think there are various ways in which we can give users options to login to their email provider in case they are logged out (which they are going to have to, anyway, if the user experience degrades to manual email verification). For example, the issuer can return a special response code when the user is logged out with a WebAuthn challenge that the browser can use.

So, while this isn't well covered in the explainer, we do think we have reasonable answers here to handle logged out users.

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

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