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

@martinthomson -- thanks for the in depth feedback! @samuelgoto may want to add or clarify to my response below.

1. Venue

Agree the majority of this belongs in IETF -- but if the browsers are not interested -- then starting in IETF does not matter IMHO. Having it all in one doc enabled us to see the whole flow. Sam and I are planning on splitting this proposal between here and IETF. This would also allow innovation on how the feature is exposed in the browser independent of the protocol. Assuming we move forward with the 3 party model (see below) the non-browser part of this could be a fit for the IETF SPICE WG. WDYT?

2. Design -- 3 party model.

With the browser as the intermediary, the issuer does not learn the RP the user is presenting to. For many sites, login is done with email verification. This protocol will improve user's privacy by not disclosing where they are logging into. This does add a fair amount of complexity as you have noted as the SD-JWT+KB is the binding between the issuer | browser | RP. We thought the privacy improvements were worth it. What do you think?

2. Design -- SD-JWT

I was reluctant to build on SD-JWT -- but it defines key binding and the '~' mechanism to connect the two JWTs -- which are needed for the privacy feature -- and there are SD-JWT libraries to process the SD-JWT+KB. A selective disclosure is optional in the SD-JWT spec.

2. Design -- DNS

Where email goes is controlled in DNS. Starting the delegation in DNS aligns with what people in charge of email have control over. One of the key audiences for EVP are people with their own domain. They often only use it for email and don't host a web page. They set their MX and other mail DNS records. Setting another record is a within their existing infrastructure.

2. Design - DKIM

The .well-known has the issuance endpoint as well as the jwks_uri. In my experience, rotating DKIM is rare -- but rotating the JWKS file is pretty common infrastructure practice, and getting keys from a jwks_uri is common from OIDC deployments and JWT processing.

2. Design - active cookies

Using cookies seemed like a good place to start and built on the learnings from FedCM. Note that the user experience fallback is to verify their email how they do it today, so if there are no active cookies, it is business as usual. I'd love for passkeys to also be able to be used -- this would allow the user to authenticate to the issuer without cookies -- the issuer would send a webauthn like request object in its response -- with the advantage that the issuer knows which credentials it will accept as the user has been identified by the email address. This effectively gives an RP the security of passkeys, without having to implement passkeys. Additionally, on mobile, the browser could talk directly to the mail app rather than calling a server.

3. User Benefit

We have gotten similar feedback. https://github.com/WICG/email-verification-protocol/issues/27 -- will address.

4. Usage

Informal feedback from RPs has been very positive. While a site could create a list of who they trust -- I think it is going to follow the pattern of email -- list of domains that are not trusted such as https://github.com/disposable-email-domains/disposable-email-domains.

5. Enrollment

See above for passkeys. Definitely an area worth more real world exploration.

Break down into sections.

Agreed -- we have received lots of feedback and it is clear there is interest in the protocol being used in multiple ways by the browser. A rework is in progress.

Assuming we move forward with the 3 party model (see below) the non-browser part of this could be a fit for the IETF SPICE WG. WDYT?

That's not the DISPATCH answer I'd give. The novel parts of this belong in ART, probably in a focused WG. SPICE might be able to help with the definition of attributes for the various formats if those are necessary, but if you have a working group, I'd be inclined to use SPICE for consultation only and do all the work in the one place.

We thought the privacy improvements were worth it. What do you think?

A lot of the design rides on this assumption. As I said, I am unconvinced. Or rather, I am almost firm in a conviction that it's the wrong choice in this case.

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.

Having to build key binding is something to avoid. Not just because it is much more complex.

We thought the privacy improvements were worth it. What do you think?

A lot of the design rides on this assumption. As I said, I am unconvinced. Or rather, I am almost firm in a conviction that it's the wrong choice in this case.

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 for1, 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 agree there is little value in privacy from the mail provider if the email is being used to communicate.

I respectfully disagree strongly with your view on email as an identifier

Correlating a user across trust domains is both a feature and a bug. While I think we all agree that tracking is bad, we all want someone to be able to fund our stuff and share things with us.

There are only 2 global, general purpose identifiers: email and phone.

These are identifiers that we know about ourselves, that we can share with others, and that others have associated with their view of us. Use of disposable email addresses is a customer service nightmare. While there is value in using them for receiving communication, they are not a memorable identifier.

Being able to prove you control an email address, effectively being able to identify yourself, is a fundamental feature of the internet. Many systems won't work without it.

You may like the tracking that emails enable, but I strongly view you are swimming against the tide wanting to take it away.

@martinthomson do you think a simpler version to share an email for communication is worthwhile?

If we build that, then people will use it to prove control of the email identifier regardless -- so would it not be better to protect the user's privacy in those scenarios? Or are you suggesting we not do the protocol at all because it makes it easier for users to provide their email for tracking?

wrt. disposable emails -- a browser could coordinate with an email provider to provide a signed token containing a disposable email address -- simplifying providing a privacy preserving communication identifier.

@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/or follow ups, 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

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 and digital asset links. 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.

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" ¹.

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 interested in tracking ¹ the user. 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, why would we deliberate choose not to do that?

You could argue that the three party model is harder for developers (for relying parties, issuers and email providers -- as well as browser vendors), but I'd argue that it meaningfully serves users better, and users > developers > browsers.

To be clear, there are problems with disposable email addresses and we're working on solutions for that (see recent Anti-Fraud CG discussions), but I think they should be the default. In other words, privacy with respect to the RP is the main concern I have

I just wanted to re-enforce what @dickhardt said here:

wrt. disposable emails -- a browser could coordinate with an email provider to provide a signed token containing a disposable email address -- simplifying providing a privacy preserving communication identifier.

That's correct: we designed this such that if a browser wanted to provide directed/disposable email addresses (that are also cryptographically verifiable) through this system they would be able to (without any modification to relying parties, meaning interoperable with the other parts of the system).

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": 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.

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

Yeah, I think I generally agree with this dichotomy: the service-specific identifiers will have to be kept either by email providers or password managers, and I agree that the latter is the best place (under the definition that we'd allow ourselves to call "password managers" and "user agents" interchangeably).

In fact, this proposal allows for service-specific identifiers to be provided and managed at the browser level (again, I'm using "browser" and "password manager" interchangeably here, architecturally speaking): both Firefox Relay and Safari's Hide my Email offer users service-specific identifiers, which could also be offered during autofill, and could provide both a (a) service-specific as well as an (b) interoperable cryptographic proof of ownership. The browser relay isn't kept blind to the service because it is operating at the browser level, and so can generate a service-specific email address, while still operating in a three party topology (just so happens that the holder and the issuer are under the control of the same entity).

This also works at the individual level: I have my own personal email domain (I'm me@sgo.to), and would equally be able to provide service-specific email addresses that are also cryptographically verified (e.g. example.com@sgo.to) through this proposal, because my own personal issuer that I'm operating could authorize *@sgo.to if I'm logged in to this service (since this is a single-user domain: me).

All of that to say, I think this proposal reconciles well with site-specific email addresses.

A thought occurs: will sites want to use this in place of passkeys for login?

I think the answer is "yes", but not that that's necessarily bad.

I think it would be useful to ask yourself: in practice, what do you think happens before a user is able to create a passkey in the first place?

Spoiler alert: the user provides an email address and has to go through email verification.

In 2025, we wanted to test the following hypothesis: “in practice, most password/passkey creation start with email verification”. We went through the list of the most visited websites and followed their account creation process.

These are very non scientific (so take them with a grain of salt) but are probably reproducible findings:

• 72% of them (18) offered social login (so already get verified email addresses through that)
• 95% of them (23/24) allowed me to create accounts with email addresses
  • 73% of them (17/23) blocked the registration flow on email verification
  • 26% of them (6/23) started with email verification before anything else
  • 47% of them (11/23) performed email verification before I could set up a password (and, transitively, a passkey)

Email verification (as well as phone number verification) plays two key roles in account creation: provides a re-engagement channel as well as a reliable account recovery channel.

So, by the time that you are presenting a passkey, in practice, the website already has your email address (or phone number) associated with your account. There are obvious exceptions to this rule (e.g. anonymous online forums, games), but it is true for a large part of the web (e.g. at the head, traffic weighted).

In fact, this is such a common account creation pattern, that we are actively working on a WebAuthn Creation API that combines creating a passkey with the acquisition of the user's name and email address (and we expect that it would be useful to provide verified email addresses there too -- in addition to autofill).

That seems like a terrible idea, but email verification is how Slack manages login today. What steps would you take to discourage that?

That to say: it is not clear to me that it would be terrible if this was used for Sign-in (in addition to Sign-up and Recovery), specially if we can make it as private as the status quo with regards to issuer-blindness and had a path to make it more private than the status quo with regards to service-blindness.

I'm only aware of a single reservation I have with this, which is the fact the email can get recycled as DNS changes hands (e.g. I believe x.com was an email provider before turning into twitter). That actually happens in practice at scale and is a massive security problem, but one that a certain category of website tolerates without second factors.

But beyond that, it is not clear to me that passkeys will have necessarily a strictly better privacy/security and recoverability trade-off than email verification, because it is not clear to me that (a) they'll ever be as recoverable as email (although the intent is to make them as recoverable as email) and (b) websites won't require email for re-engagement.

To me, it is clear that, right now, based on the data that we gathered, they don't.

Long term, different websites make different trade-offs in the security/convenience spectrum, and I think that there is a sustainable and valid space in the market for verified email addresses to be used for login that will strike the right balance (e.g. when email was required at passkey creation anyway).

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.

I think the biggest user value we are delivering with the three party model architectural element is to minimize least surprise: users, right now, don't expect the email provider to be necessarily and programatically contacted every time a selection is made in autofill, and anything beyond that would break their expectations (or require extra permission prompts).

A thought occurs: will sites want to use this in place of passkeys for login?

I would suspect so for simpler sites. Passkeys have many sharp edges -- and sites want a memorable identifier -- which passkeys don't provide today.

A WebAuthN interaction between the browser and the issuer as part of EVP I think provides a fantastic step up for simpler sites. The issuer knows the credentials it supports for the email address provided -- and the site gets a verified email and the security of passkeys without having to directly support passkeys.

A browser integrated with an issuer can do the same thing to provide a directed email address to the site and use a passkey for authenticating the user transparent to the site as Sam mentions above.

@samuelgoto @dickhardt,

After discussion with the TAG, we think that this discussion is best taken to the IETF, as I think we all agreed. The TAG has consensus on that point. I think that we generally like the use case.

There are a number of points here on which both of you and I, personally, might disagree. We don't have consensus in the TAG on any of that, but we do have consensus that a lot of those issues are best resolved with more discussion at the IETF. So, we encourage you to continue to polish the proposal and take it to the IETF (where I'm sure you'll hear from me at some point as well).

I've marked this as both validated and ambivalent at different levels.

we think that this discussion is best taken to the IETF, as I think we all agreed

@dickhardt and I both appreciate the early guidance from the TAG with incomplete information.

We acknowledge that this isn't a trivial trade-off, and are grateful that this review uncovered/pushed on some of the big open questions (e.g. the three party model vs the two party model), their trade-offs (e.g. developer ergonomics vs privacy) and some second order / unintended consequences (e.g. its relationship to passkeys) that we should dig through.

We'll follow your guidance and take the protocol/backend to the IETF (and the html/frontend somewhere in the W3C and/or possibly to the WHATWG), which we'll report back on this thread as it goes along.