EVP Configuration Generator

Generate the verifier form for websites, and the DNS record and issuer metadata for email providers.

Verifier form generator

EVP integration for a website is two form fields and a server checklist. Generate the form, keep your existing verification email as the fallback, and validate any token that arrives with the validator.

Two sides of the protocol, in thirty seconds

A verifier (any website with a signup form) integrates with two HTML fields and a server checklist. The token is optional by design: when it shows up and validates, the user skips the inbox trip; when it does not, nothing changes. An issuer (an email provider) has the heavier job: appoint itself in DNS, publish metadata and signing keys, and run an issuance endpoint that answers the browser signed requests for the users already signed in to it.

Both sides are still moving during the origin trial, so treat the generated configuration as a faithful starting point from the current specification and Chrome guides, and re-check it against the domain checker once your endpoints are live.

Frequently Asked Questions

Two form fields: the email input it already has, plus a hidden input with autocomplete="email-verification-token" and a fresh random nonce per form instance, stored server-side. On submit, if the hidden field carries a token, the server runs the validation checklist before trusting it. If the field is empty, the site uses its existing verification email flow unchanged.
The nonce is what ties a token to one specific form submission. The browser binds it into the key binding JWT and the issuer includes it in the signed claims, so the server can prove the token was minted for this signup attempt and not replayed from another session, site or day.
Three things: a DNS TXT record at _email-verification.<domain> naming the issuer origin; a metadata JSON at /.well-known/email-verification on that origin with the issuance endpoint and jwks_uri; and the JWKS signing keys themselves. It also runs the issuance endpoint and a FedCM-style accounts endpoint so the browser can confirm the user session.
A POST from the browser carrying the provider first-party session cookies and HTTP Message Signatures (RFC 9421). Since Chrome 153 the body is JSON with just the email; earlier versions sent a form-encoded request_token. It answers with an issuance_token: the signed SD-JWT followed by a tilde, to which the browser adds its key binding.
No. EVP is in origin trial and the issuer API has already changed once (the Chrome 153 request format). The generator follows the current specification and Chrome guides as of October 2026. Re-run the domain checker after deploying, and expect to adjust as the trial evolves.

Was this tool helpful?

Comments

Loading comments...

Check Out Other Popular Tools