Hampir setiap pendaftaran akun berakhir dengan ritual yang sama: pengguna mengetik alamat email, berpindah ke kotak masuk, menyalin kode OTP atau mengeklik tautan ajaib, lalu kembali ke situs. Setiap perpindahan itu adalah titik calon pengguna hilang. Google kini menguji cara memangkas ritual tersebut lewat Email Verification API, yang mulai dibuka sebagai origin trial di Chrome 150 untuk desktop, dengan Gmail sebagai penyedia email pertama yang ikut serta.

Apa itu Email Verification API

Email Verification API adalah proposal di WICG yang memungkinkan browser memastikan bahwa pengunjung benar-benar memiliki alamat email yang ia ketik, tanpa mengirim pesan apa pun. Modelnya melibatkan tiga pihak: verifier (situs yang mengumpulkan email), issuer (layanan yang mengelola akun, misalnya accounts.google.com), dan browser sebagai perantara.

Kuncinya adalah sesi login yang sudah ada. Kalau pengguna sedang masuk ke akun Gmail di browser yang sama, browser dapat mengambil token bertanda tangan dari penyedia email dan menaruhnya di form. Server situs tinggal memvalidasi token itu saat form dikirim. Google menyebut issuer tidak mengetahui situs mana yang meminta verifikasi karena permintaan dimediasi browser.

Perlu dicatat: ini bukan pengganti email sepenuhnya, melainkan cara membuktikan kepemilikan alamat lewat sesi yang sudah aktif. Jika tidak ada sesi, atau penyedianya bukan Gmail, situs harus kembali ke alur OTP biasa.

Alur kerjanya

1. Pengguna memilih alamat email dari saran autofill di form. Situs menyiapkan field tersembunyi berisi nonce unik per sesi.
2. Browser membaca record DNS _email-verification milik domain email untuk menemukan issuer yang berwenang.
3. Issuer memastikan ada sesi aktif untuk alamat tersebut, lalu menerbitkan Email Verification Token (EVT).
4. Browser membungkus EVT bersama origin situs dan nonce menjadi token SD-JWT dengan key binding.
5. Saat form dikirim, token dimasukkan ke field tersembunyi dan ikut terkirim ke server.
6. Server memvalidasi email, nonce, dan tanda tangan; pengguna melihat notifikasi kecil bahwa alamatnya sudah terverifikasi.

Karena token hanya muncul kalau browser dan penyedia mendukung, tidak ada deteksi fitur khusus di sisi situs. Tim cukup memperlakukan token sebagai data opsional: kalau ada, divalidasi; kalau kosong, jalankan alur lama.

Menyiapkan form

Perubahan di sisi front end relatif kecil. Field email wajib memakai type="email" dan autocomplete="email", sedangkan field token memakai autocomplete="email-verification-token" plus nonce yang terikat ke sesi pengguna:

<form method="post" action="/daftar">
  <input type="email" name="email" autocomplete="email" required>

  <input type="hidden" name="evt"
         autocomplete="email-verification-token"
         nonce="rAnD0m-SeSsIoN-123">

  <button type="submit">Daftar</button>
</form>

Jangan lupa mendaftarkan origin trial dan menyajikan token OT lewat header atau tag <meta> di halaman yang memakai form tersebut.

Validasi di server

Bagian yang lebih berat ada di server. Token berformat SD-JWT+KB (RFC 9901), terdiri dari JWT yang ditandatangani issuer, nol atau lebih disclosure, dan JWT key binding yang dipisahkan tanda tilde. Di Node.js, dokumentasi Chrome mencontohkan penggunaan @sd-jwt/core bersama jose.

Setidaknya ada lima pemeriksaan yang harus lolos:

1. Parse token dengan pustaka SD-JWT yang sesuai platform.
2. Cocokkan klaim: email_verified harus true, email sama dengan yang dikirim, aud sama dengan origin situs, nonce sama dengan nonce sesi, serta iat/exp masih dalam masa berlaku.
3. Verifikasi delegasi DNS: query TXT _email-verification.<domain>, misalnya untuk Gmail menghasilkan iss=accounts.google.com, lalu pastikan issuer memakai HTTPS dan cocok dengan klaim iss.
4. Ambil metadata issuer dari https://<issuer>/.well-known/email-verification dan unduh JWKS dari jwks_uri.
5. Verifikasi tanda tangan EVT dengan kunci issuer, tanda tangan browser pada KB-JWT dengan kunci di cnf.jwk, serta ikatan aud, nonce, dan sd_hash.

import { decodeSdJwtSync } from "@sd-jwt/core";
import { createHash } from "node:crypto";

const hasher = (data, alg) =>
  createHash(alg === "sha-256" ? "sha256" : alg).update(data).digest();

const decoded = decodeSdJwtSync(tokenDariForm, hasher);
const evt = decoded.jwt.payload;

if (evt.email_verified !== true) return fallbackKeOTP();
if (evt.email !== emailYangDikirim) return fallbackKeOTP();
// Lanjutkan: cek aud, nonce, DNS delegation, lalu verifikasi JWKS

Kalau salah satu langkah gagal, jangan menampilkan error ke pengguna. Cukup jalankan alur konfirmasi email yang sudah ada.

Batasan yang perlu diketahui

• Cakupan masih sempit. Trial dimulai di Chrome 150 desktop; dukungan Android dan third-party origin trial baru ditambahkan di Chrome 154.
• Gmail satu-satunya issuer pada tahap ini, dan pengguna harus sedang login ke akun tersebut di browser yang sama.
• Masih eksperimen. Kontrak API bisa berubah. Origin trial diperpanjang sampai Chrome 160, dan token yang diterbitkan sebelum perpanjangan kedaluwarsa pada 17 November 2026.
• Perilaku klaim berubah. Sejak Chrome 156, alamat email dikembalikan persis seperti yang diketik; sebelumnya perbandingan harus case-insensitive.
• Kritik soal privasi. Sebagian pengembang di Hacker News menilai klaim privasi tipis, karena situs tetap mengirim email onboarding atau pengingat setelah verifikasi.

Layak dicoba sekarang?

Untuk tim yang mengelola formulir pendaftaran, e-newsletter, atau reset password, API ini layak diuji sebagai progressive enhancement, bukan sebagai satu-satunya jalur verifikasi. Pasang di sebagian trafik, catat berapa persen pengiriman form yang membawa token valid, dan bandingkan tingkat penyelesaian pendaftaran dengan alur OTP. Mengingat mayoritas pengguna di Indonesia memakai Gmail, potensi penghematan biaya dan pengurangan friksi cukup nyata, tetapi alur cadangan wajib tetap hidup.

Sumber: Chrome for Developers — Relying party implementation, Chrome for Developers — Test the Email Verification Protocol with an origin trial, InfoQ — Chrome Opens Trial for the Email Verification API, WICG/email-verification.