Protocol field notes · reviewed October 14, 2026

Give every registration path a result.

Browser Email Verification can replace a confirmation-message step when its prerequisites are met. Treat it as an enhancement to an existing signup flow.

Use the playground.

Build a form to generate escaped HTML attributes, then inspect the generated markup. The flow walkthrough lets you compare a valid token, an absent token and a rejected token. It simulates your application’s decision; it does not call the browser EVP API or verify a real token.

Start with a small fixture

Keep the email and hidden token inputs together. The email control needs type="email" and autocomplete="email"; the hidden control uses autocomplete="email-verification-token" and a session-bound nonce. The preflight catches common markup omissions. It cannot prove that the nonce was generated securely or bound to a session.

Official verifier implementation and troubleshooting ↗

Separate syntax from verification

An issuer’s discovery JSON contains issuance_endpoint, jwks_uri and signing_alg_values_supported. The optional checker validates field shapes and URL syntax only. Your server must still establish issuer trust and validate signatures and session claims.

Official issuer implementation ↗

Account for the October changes

Chrome’s October 5 update covers Android, third-party trials and key discovery. A missing kid alone is not grounds to reject a token; verification needs to try appropriate candidate keys. Issuance requests use Sec-Fetch-Dest: email-verification from Chrome 154. Follow the official rollout guidance when supporting older versions.

Read the dated change notice ↗

Run an acceptance test

Use an application you control and a disposable test identity.
Check the signed-out form in a fresh browser profile. A separate WebTraceCheck session can help reproduce profile differences.
Exercise the empty-token route and confirm your normal email process works. A CleanTempMail inbox can receive non-sensitive fallback test messages; this does not test the EVP issuer path.
Record expected behavior, actual result and the application release. Keep tokens and credentials out of the report.

Do not infer EVP support from a static preflight result. Browser settings, participating-provider state and trial configuration must be checked in the real environment.

APPLICATION ACCEPTANCE / NOT A TOKEN VERIFIER

Write the failure path before the happy-path demo.

The playground can explain a branch, but only your server can validate a real token. These original acceptance cases tell you what to arrange and observe in an application you control. They are not signed tokens and do not claim an EVP issuer is available.

A / ABSENT

No token, ordinary user.

email: test identity you control
verification_token: ""
session: fresh

Expected decision: do not mark the address verified from absence. Continue your normal verification route. Observe an actual non-sensitive confirmation message and finish that route.

Failure to catch: a backend treats the missing field as “verification unnecessary”, or a frontend blocks registration while waiting indefinitely for browser support.

B / PRESENT, WRONG SESSION

A stale tab meets a new nonce.

token nonce: issued for session A
active nonce: session B
signature: not sufficient by itself

Expected decision: the token must not establish verification for session B. Follow the documented verification failure/fallback path. Keep the test in an owned environment; do not paste a real token into this site.

Failure to catch: a signature-only implementation ignores the nonce binding, or the application silently overwrites the nonce while a second tab is open.

C / VALIDATED PACKAGE

Verification is one decision in signup.

issuer and key binding: verified
email and expected claims: matched
application admission: still separate

Expected decision: the application may use the verified-email result while independently applying its own account-admission and session rules. A verified address is not proof of age, organisation membership or entitlement to a paid account.

Failure to catch: the UI shows “signed in” from the token alone even though account creation or session establishment failed.

Download eight application acceptance cases and a blank result row. The reference describes decisions to exercise; it does not execute verification or supply a cryptographic library.

Two tabs are a useful test, not an edge to ignore.

In a controlled test, open the same signup flow in tabs A and B. Record whether your server gives each attempt an independent nonce or deliberately invalidates an earlier one. Complete B, then submit A. The expected result must follow your documented nonce lifecycle; an old form must not silently inherit a new attempt’s verification.

Keep a trace with four facts: tab label, nonce identifier represented by a harmless test label, submission time and server decision. Do not record the live nonce or token. Repeat using the normal email fallback so the comparison changes only the verification path.

Chrome’s verifier guidance requires matching session claims and validating the issuer and key binding. Decoding JSON or matching a field name is not that validation. An empty token uses the ordinary verification flow.

What belongs in a release note?

Observed: “Fresh supported-profile attempt completed; no-token attempt received ordinary confirmation; stale-session token did not mark the address verified.” Keep a result for each case.
Still unknown: Actual browser/provider coverage, unavailable issuer combinations and untested device versions. Do not convert three passing cases into universal support.
Reproduction: Application release, browser version, enabled trial state, non-sensitive case label and expected/actual decision. Exclude raw tokens, keys and recovery links.

A useful comparison uses the same app release in a separate browser session and the same ordinary fallback with a non-sensitive test inbox. Those observations test your application path; they do not certify either service as an EVP issuer.

Inspect your form →