Verifikasi Email

Email Verification API adalah proposal yang memungkinkan browser berkomunikasi langsung dengan penyedia email untuk memverifikasi bahwa pengguna memiliki alamat email tersebut. Pengguna memasukkan email mereka, mengirimkan formulir, dan situs memverifikasi token verifikasi email yang ditandatangani dari browser dengan penyedia tanpa mengirim email atau mengganggu alur pengguna.

Saat mengumpulkan alamat email selama pendaftaran, login, checkout, langganan newsletter, atau pemulihan akun, situs biasanya mengonfirmasi bahwa orang yang mengirimkan formulir mengontrol alamat tersebut. Metode verifikasi yang ada mengharuskan pengguna meninggalkan situs Anda, beralih aplikasi untuk memeriksa kotak masuk mereka, menyalin OTP, atau mengklik link verifikasi. Gangguan ini meningkatkan pengabaian dan penghentian sesi untuk pengguna manusia dan agen otomatis. Pengguna sering mengalami kesulitan dengan metode verifikasi yang ada, seperti email yang tertunda, link yang tidak berlaku, atau kode yang tidak dikenali.

Verifikasi email berfungsi sebagai peningkatan progresif untuk alur yang ada:

• Tidak ada gangguan: Verifikasi terjadi di latar belakang saat pengguna mengisi formulir.
• Tidak diperlukan deteksi fitur: Situs menambahkan input email dan input token tersembunyi ke formulirnya. Jika browser atau penyedia tidak mendukung verifikasi email, atau jika verifikasi gagal, situs akan kembali ke alur konfirmasi email default.
• Meminimalkan risiko phishing: Tidak ada kode yang dapat disalin atau peluang untuk mengirim pengguna ke situs palsu.

Link penting

• Spesifikasi Email Verification API (WICG) (repositori GitHub)
• Protokol Verifikasi Email Internet-Draft (IETF) (repositori GitHub)
• Verifikasi Email di Status Platform Chrome
• Pendaftaran uji coba origin Verifikasi Email

Anda dapat menguji alur dalam demo:

• Demo penerbit: Menyediakan akun email tiruan dan sesi login.
• Demo verifikator: Verifikasi email demo atau email penyedia yang berpartisipasi.

Pertimbangan uji coba origin

Uji coba origin adalah eksperimen untuk mengumpulkan masukan, sehingga masukan Anda sangat penting jika Anda berpartisipasi sebagai pihak yang mengandalkan atau penyedia identitas. Untuk melaporkan masalah, gunakan repositori GitHub berikut:

• Browser Email Verification API: WICG/email-verification
• Email Verification Protocol: dickhardt/email-verification

Jika Anda menemukan bug dalam penerapan Chrome, ajukan masalah di komponen berikut:

• Masalah baru: Chromium > Blink > Identity > EVP

Anda mengontrol fungsi uji coba origin berdasarkan per respons dengan menyertakan token uji coba origin. Hal ini memungkinkan Anda membatasi fitur ke segmen pengguna tertentu, seperti populasi pengujian A/B. Atau, jika Anda memiliki grup pengguna uji beta atau pratinjau awal, Anda mungkin ingin atau perlu mengaktifkan fitur tersebut untuk mereka. Dalam hal ini, periksa alamat email yang diberikan sebelum menerbitkan atau memvalidasi token.

Uji coba origin juga memiliki batas traffic untuk meminimalkan situs yang mengandalkan fitur sebelum peluncuran. Issuer API sedang dalam pengembangan, dan Anda harus memperkirakan perubahan yang tidak kompatibel dengan versi lama bersama dengan update pada UX Chrome.

Perhatikan info terbaru di blog di sini dan di evp-announce@chromium.org milis seiring perkembangan pengembangan.

Alur verifikasi email

Bagian berikut menjelaskan istilah utama dan langkah-langkah protokol saat menggunakan Email Verification API.

Istilah utama

Istilah utama untuk Email Verification API adalah:

• Verifikator: Situs yang mengumpulkan alamat email dan ingin memverifikasi nya. Verifikator juga disebut Pihak yang Mengandalkan.
• Penyedia Email: Layanan yang menyediakan alamat email pengguna, misalnya gmail.com.
• Penerbit: Layanan yang mengelola akun untuk email pengguna, misalnya accounts.google.com. Penerbit juga disebut Penyedia Identitas.

Dalam beberapa kasus, penyedia email dan penerbit beroperasi dari domain yang sama. Namun, penting untuk membedakannya karena Email Verification API menggunakan sesi aktif di browser dengan penyedia identitas sebagai metode verifikasi. Misalnya, untuk memverifikasi example@gmail.com, pengguna harus login ke google.com dengan akun tersebut di browser yang sama.

Alur protokol

1. Presentasi formulir: Pihak yang mengandalkan menyajikan formulir HTML yang berisi <input type="email"> dan input tersembunyi yang ditandai dengan autocomplete="email-verification-token" dan nonce per instance yang unik.
2. Entri email: Saat pengguna memasukkan alamat email—baik dengan memilih saran isi otomatis atau dengan mengetik atau menempel dan keluar dari kolom (blur)—browser akan memicu verifikasi di latar belakang.
3. Penemuan dan sesi: Browser membuat kueri data TXT DNS untuk _email-verification.<email-domain> untuk menemukan origin penerbit resmi penyedia, lalu memeriksa apakah pengguna memiliki sesi aktif menggunakan konfigurasi .well-known/web-identity penerbit dan endpoint akun FedCM. Jika domain tidak memublikasikan data EVP atau tidak ada sesi aktif, browser akan menghentikan verifikasi tanpa meminta pengguna.
4. Penerbitan token: Browser menemukan issuance_endpoint penyedia dari .well-known/email-verification, membuat pasangan kunci efemeral, dan mengirim permintaan POST HTTP menggunakan Tanda Tangan Pesan HTTP (RFC 9421) dengan cookie sesi pihak pertama penerbit dan alamat email target untuk menerima Token Verifikasi Email (EVT) yang ditandatangani.
5. Pengikatan kunci dan pengiriman: Browser mengikat EVT yang ditandatangani ke origin pihak yang mengandalkan dan nonce formulir di dalam JWT Pengikatan Kunci (KB-JWT) dan menampilkan notifikasi kecil yang memberi tahu pengguna bahwa penyedia email mereka telah memverifikasi alamat mereka. Saat pengguna mengirimkan formulir, Chrome akan mengisi input tersembunyi dengan token gabungan (<EVT>~<KB-JWT>).
6. Validasi klaim dan KB: Server pihak yang mengandalkan mengurai token <EVT>~<KB-JWT>, memvalidasi klaim yang diharapkan (email, email_verified, aud, nonce, iat, dan exp), dan memverifikasi tanda tangan pengikatan kunci terhadap kunci publik efemeral di cnf.jwk.
7. DNS dan kunci publik: Pihak yang mengandalkan membuat kueri data TXT DNS _email-verification.<email-domain> untuk mengonfirmasi bahwa data tersebut cocok dengan klaim iss token, lalu mengambil metadata .well-known/email-verification dan kunci publik penerbit dari jwks_uri.
8. Verifikasi EVT dan selesaikan: Pihak yang mengandalkan memverifikasi EVT tanda tangan penerbit menggunakan JWKS publik penyedia. Jika tidak ada token yang diterima atau langkah validasi gagal, situs akan kembali ke proses konfirmasi email yang ada.

Saat pengguna memverifikasi alamat email untuk pertama kalinya, Chrome akan menampilkan perintah izin (dialog di desktop, atau sheet bawah di Android) sebelum meminta token. Jika diberikan, izin ini akan diingat per alamat email di seluruh situs yang berpartisipasi.

Setelan Chrome

Pengguna dapat mengelola email terverifikasi mereka:

• Di desktop, di bagian Setelan > Pelengkapan otomatis dan sandi > Info kontak > Email Terverifikasi (atau buka chrome://settings/contactInfo)
• Di Android, di bagian Setelan > Alamat dan lainnya > Email Terverifikasi

Pengguna dapat menonaktifkan fitur sepenuhnya atau mengelola alamat email terverifikasi satu per satu.

Pertimbangan kasus penggunaan

Verifikasi email adalah progressive enhancement untuk alur yang ada yang menghilangkan kebutuhan pengguna untuk meninggalkan situs Anda guna mengambil OTP atau mengklik link. Situs dapat menambahkan kolom verifikasi email ke semua formulir yang relevan, seperti login, pendaftaran newsletter, pembuatan akun, dan pemulihan sandi. EVP hanya dipicu jika browser mendukungnya. Jika tidak ada kode yang diterima saat pengiriman atau salah satu langkah validasi gagal, Anda dapat kembali ke alur konfirmasi email default. Hal ini juga berarti tidak ada deteksi fitur untuk API; situs verifikator memperlakukan EVT sebagai opsional, memprosesnya jika ada dalam permintaan.

Verifikasi email mengonfirmasi bahwa pengguna memiliki sesi aktif dengan penyedia alamat emailnya. Verifikasi ini tidak memverifikasi bahwa email Anda telah diterima pengguna. Anda mungkin masih ingin mengirim email sambutan atau orientasi yang ada dan mungkin ingin atau perlu meminta pengguna untuk memeriksa setelan spam mereka.