Problem Description
The current implementation of the Email Verification Protocol relies on the user interacting with an <input type="email"> element (either via autofill or manual typing followed by a blur or change event) to trigger the verification process.
However, I have seen mamy identity systems use multi-step authentication, account recovery, or password reset flows where the user's email is already known by the Relying Party (RP) by the time they reach the verification step. In these scenarios, the UI typically presents the user's email as read-only text or baked directly into a button (e.g., <button>Send verification to user@example.com</button>), rather than presenting an editable <input> field.
Because there is no active <input> field for the user to interact with, these services bypass the browser's form-fill interception entirely, making it impossible to trigger the Email Verification Protocol without regressing the UX (i.e., forcing the user to re-enter or focus an input field they already provided in a previous step).
Proposed Solution
Provide a programmatic Javascript API bound to user activation (like a button click) that allows an RP to explicitly pass a known email address to the browser for verification, instead of relying exclusively on DOM input triggers.
For example, this could potentially leverage the Credential Management API:
document.getElementById('verify-btn').addEventListener('click', async () => {
try {
const verification = await navigator.credentials.get({
emailVerification: {
email: "user@example.com",
nonce: "random-session-nonce"
}
});
// Send EVT to backend
} catch (err) {
// Fallback to sending a traditional magic link / OTP
}
});Use Cases
- Account Recovery / Password Reset: A user clicks a reset link or enters their username on page 1. On page 2, they are asked to confirm by clicking a button to verify the pre-established email.
- Multi-page Login: Step 1 collects the identifier. Step 2 handles authentication/verification.
- Authenticated Session Step-up: A user initiates a high-risk action (e.g., changing a password) where their email is already tied to their active session cookie. The site just needs a quick inline check without showing an input form.
Benefits
A programmatic approach would allow broader adoption of the protocol across a wide variety of existing identity platforms without forcing them to rebuild their standard UI flows or artificially insert <input> fields just to trigger the browser's interception layer.
Problem Description
The current implementation of the Email Verification Protocol relies on the user interacting with an
<input type="email">element (either via autofill or manual typing followed by ablurorchangeevent) to trigger the verification process.However, I have seen mamy identity systems use multi-step authentication, account recovery, or password reset flows where the user's email is already known by the Relying Party (RP) by the time they reach the verification step. In these scenarios, the UI typically presents the user's email as read-only text or baked directly into a button (e.g.,
<button>Send verification to user@example.com</button>), rather than presenting an editable<input>field.Because there is no active
<input>field for the user to interact with, these services bypass the browser's form-fill interception entirely, making it impossible to trigger the Email Verification Protocol without regressing the UX (i.e., forcing the user to re-enter or focus an input field they already provided in a previous step).Proposed Solution
Provide a programmatic Javascript API bound to user activation (like a button click) that allows an RP to explicitly pass a known email address to the browser for verification, instead of relying exclusively on DOM input triggers.
For example, this could potentially leverage the Credential Management API:
Use Cases
Benefits
A programmatic approach would allow broader adoption of the protocol across a wide variety of existing identity platforms without forcing them to rebuild their standard UI flows or artificially insert
<input>fields just to trigger the browser's interception layer.