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

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

I took a look at this. I have quite a few concerns:

1. Venue. The bulk of this work belongs at the IETF, which is where the email people engage in developing standards related to email. I know that W3C does some of the related work, but I can’t see any good reason for the W3C to be involved. There is only a tiny piece of work that touches the web, even though it is ostensibly driven by web needs.  Even that is largely coincidental: a great many things would benefit from a lower-friction means of validating email.  The HTML parts are better off being taken directly to WHATWG HTML (the `<input type=email>` piece is tiny).
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. The browser proves live access to that key by signing over a challenge that the site asking for verification freshly generates. There's no evidence that email providers can't or won't be involved in live issuance, but I believe that live signing would be more attractive to some.  The extra complexity needs to be justified. Personally, I'm not sure that keeping use of email addresses hidden from mail providers is a goal worth pursuing if it is going to cost this much. It's not like there is any value in convincing a site that you own an email address when you are offline and cannot contact the mail provider: you almost certainly can't contact the site either.  
   * Think very hard about whether key binding and attestations are really necessary.  I get how you might conclude that, but I am totally unconvinced about the necessity of that technology for this application.  Particularly when it comes with some very serious restrictions on usability and the ability to deploy this widely.  
   * There’s a lot of stuff being signed over, which makes the design and specification more complex than it needs to be. For example, time-based components for the key binding signatures don’t make sense as the module that would be signing doesn’t have a clock.  
   * Some of the time-based stuff might be needed if you were operating a PKI, which this design seems to be modeled on, but none of the other features or benefits that you get from a PKI are involved in the proposal. No revocation support as far as I can see (which you probably want in this sort of model) and no transparency, so that complexity is pure dead weight.  
   * Selective disclosure has no business being involved in this protocol. The only reason I can see that this is there is that the credentials involved look very much like other digital credentials that people are building. That's not a good reason to pull in all that baggage.  
   * Fundamentally, what you really need is a signature that covers the challenge (for liveness) and the email address (to prevent misbinding). Nothing else, not even key binding. You don't need JW\* for that.  
   * The issuance protocol seems overwrought also. The presence of cookies (which requires an interesting Fetch mode; though maybe FedCM fixed that issue) is enough to prove that there is active access to the account; the request therefore only needs to help the server identify which email address is being verified (if there are multiple associated with an account) and the challenge. The response could then be a simple signature.  
   * The DNS parts of this are critical, but they need a LOT more care than has been spared for them. The DNS is how a relying party determines that they will approve (or not) a given claim about an email, so you would think that there would be more substance to that. [DKIM](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6) describes a similar mechanism for distribution, so the choice to use DNS is probably consistent with mail practice, though the extra step via HTTP \- and especially the .well-known \- is likely unnecessary (at some level, using DKIM keys for this might be a better choice). This is something that a working group at the IETF would be able to address; maybe M3AAWG could.  I have virtually no confidence that any other organization could.  
   * Copying DKIM might not even be appropriate. The security model for this protocol is quite a bit different than DKIM \- mail providers use a lot more than just the DNS query to establish reputation for their peers. In comparison, this depends on many uninvolved sites and browsers making the same query securely \- so I'm not sure that this usage of DNS can be made secure to the degree necessary.  
   * Form interaction seems like the first thing to build, which is good, but the way that the token is presented to JS seems like it needs work. The current design does not follow [our principle on where state belongs for events](https://w3ctag.github.io/design-principles/#state-and-subclassing). 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. The browser can dispatch an event to notify the JS that the form is ready to submit (`onchange` probably works).  No reason not to be able to look at `e.target.value` on that either.  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.  
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. People have trouble copying codes from emails, links open new tabs in the wrong browser, and sites get a lot of drop-off from the friction that results. The case is therefore that this should make it easier to give sites your email address in a way that they will accept.  
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? If there are lists involved, we're back into the muck for those people who don't choose those services (that list is probably as short as three: Hotmail, GMail, Yahoo\! Mail and too bad if you are a smaller email service).  
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.)

As a bit of feedback on the explainer itself, I personally struggled with how this was presented. I don’t know if this holds for everyone, but I find ant-font sequence diagrams with this many lines extremely off-putting. This is presented as a monolithic thing, but there are distinct functions or phases involved. Indeed, the monolithic flow shown is almost certainly not how the process will run for many people; that’s just one of many potential arrangements.

This could be broken down for a smoother explanation. It would be easier to follow if it started with the interaction with a site (ask for email and proof, offer that proof) then have each discrete part (issuance, presentation) parts as distinct things.  Then, an overview can show how the high-level pieces might be composed, probably in different ways.

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

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