電子郵件驗證

電子郵件驗證 API 提案可讓瀏覽器直接與電子郵件服務供應商通訊，驗證使用者是否擁有該電子郵件地址。使用者輸入電子郵件並提交表單後，網站會透過瀏覽器向供應商驗證已簽署的電子郵件驗證權杖，不需傳送電子郵件或中斷使用者流程。

在註冊、登入、結帳、訂閱電子報或帳戶復原期間收集電子郵件地址時，網站通常會確認提交表單的人員是否控管該地址。現有的驗證方法需要使用者離開網站、切換應用程式查看收件匣、複製動態密碼，或點選驗證連結。這種干擾會導致人類使用者和自動化代理的中斷率和工作階段放棄率增加。使用者經常在現有驗證方法中遇到問題，例如電子郵件延遲、連結過期或代碼無法辨識。

電子郵件驗證使用者提示示範
電子郵件驗證使用者提示示範

電子郵件驗證可作為現有流程的漸進增強：

  • 不中斷流程：驗證會在背景進行，使用者填寫表單時不會受到影響。
  • 不需要偵測功能：網站會在表單中加入電子郵件輸入欄位和隱藏的權杖輸入欄位。如果瀏覽器或供應商不支援電子郵件驗證，或驗證失敗，網站會改用預設的電子郵件確認流程。
  • 降低網路釣魚風險：使用者無需代碼，也不會被導向假冒網站。

您可以在試用版中測試流程：

來源試用注意事項

來源試用是收集意見回饋的實驗，因此如果您以依賴方或識別資訊提供者的身分參與，您的意見至關重要。如要回報問題，請使用下列 GitHub 存放區：

如果 Chrome 實作項目發生錯誤，請在下列元件中回報問題：

您可以在每個回應中加入來源試用權杖，控管來源試用功能。您可以將這項功能限制在特定使用者區隔，例如 A/B 測試族群。或者，如果您有 Beta 版測試或早期預先發布版使用者群組，可能需要為他們啟用這項功能。在這種情況下，請先檢查提供的電子郵件地址，再核發或驗證權杖。

來源試用也有流量限制，可盡量減少網站在上線前對這項功能的依賴。發卡機構 API 仍在開發中，預計會推出回溯不相容的變更，並更新 Chrome 使用者體驗。

隨著開發進度推進，請持續關注此處的網誌更新，以及 evp-announce@chromium.org 郵寄清單。

電子郵件驗證流程

以下各節說明使用電子郵件驗證 API 時的重要術語和通訊協定步驟。

重要詞彙

Email Verification API 的重要用語如下：

  • 驗證者：收集電子郵件地址並想驗證該地址的網站。驗證者也稱為信賴憑證者。
  • 電子郵件服務供應商：提供使用者電子郵件地址的服務，例如 gmail.com。
  • 簽發者：管理使用者電子郵件帳戶的服務，例如 accounts.google.com。發行者也稱為「身分識別提供者」。

在某些情況下，電子郵件服務供應商和發布者會使用相同的網域。 不過，請務必區分兩者，因為 Email Verification API 會使用瀏覽器中的有效工作階段，並以識別資訊提供者做為驗證方法。舉例來說，如要驗證 example@gmail.com，使用者必須在同一個瀏覽器中登入 google.com。

通訊協定流程

電子郵件驗證流程架構
電子郵件驗證流程架構
  1. 表單呈現：信賴方會提供含有 <input type="email"> 的 HTML 表單，以及標示有 autocomplete="email-verification-token" 和每個執行個體專屬 nonce 的隱藏輸入內容。
  2. 輸入電子郵件地址：使用者輸入電子郵件地址時 (選取自動填入建議，或輸入/貼上並離開欄位 (blur))，瀏覽器會在背景觸發驗證。
  3. 探索和工作階段：瀏覽器會查詢 _email-verification.<email-domain> 的 DNS TXT 記錄，找出提供者授權的核發者來源，然後使用核發者的 .well-known/web-identity 設定和 FedCM 帳戶端點，檢查使用者是否有有效工作階段。如果網域未發布 EVP 記錄，或沒有任何有效工作階段，瀏覽器就會停止驗證，不會提示使用者。
  4. 核發權杖：瀏覽器會從 issuance_endpoint .well-known/email-verification 探索供應商，建立臨時金鑰配對，並使用 HTTP 訊息簽章 (RFC 9421) 傳送 HTTP POST 要求，其中包含核發者的第一方工作階段 Cookie 和目標電子郵件地址，以接收已簽署的電子郵件驗證權杖 (EVT)。
  5. 金鑰繫結和提交：瀏覽器會將已簽署的 EVT 繫結至依賴方來源，並在金鑰繫結 JWT (KB-JWT) 中形成 nonce，然後顯示一則簡短通知，告知使用者電子郵件服務供應商已驗證其地址。使用者提交表單時，Chrome 會在隱藏輸入內容中填入合併權杖 (<EVT>~<KB-JWT>)。
  6. 驗證聲明和 KB：信賴方伺服器會剖析 <EVT>~<KB-JWT> 權杖、驗證預期聲明 (email、email_verified、aud、nonce、iat 和 exp)，並根據 cnf.jwk 中的暫時性公開金鑰，驗證金鑰繫結簽章。
  7. DNS 和公開金鑰：依賴方會查詢 _email-verification.<email-domain> DNS TXT 記錄，確認與權杖的 iss 宣告相符，然後從 jwks_uri 擷取發行者的 .well-known/email-verification 中繼資料和公開金鑰。
  8. 驗證 EVT 並完成：依賴方使用提供者的公開JWKS，驗證發行者的EVT簽章。如果未收到權杖或任何驗證步驟失敗，網站會改用現有的電子郵件確認程序。

使用者首次驗證電子郵件地址時，Chrome 會先顯示權限提示 (電腦上為對話方塊，Android 上為底部功能表)，再要求權杖。如果授予這項權限，系統會記住每個電子郵件地址在參與網站上的權限。

Chrome 設定

使用者可以管理已驗證的電子郵件地址：

  • 在電腦上，依序前往「設定」 >「自動填入和密碼」 >「聯絡資訊」 >「已驗證的電子郵件」 (或開啟 chrome://settings/contactInfo)
  • Android：依序前往「設定」 >「地址和其他資訊」 >「已驗證的電子郵件」

使用者可以完全停用這項功能，或管理個別已驗證的電子郵件地址。

用途注意事項

電子郵件驗證是現有流程的漸進增強功能，可讓使用者不必離開網站即可擷取動態密碼或點選連結。網站可以在所有相關表單中新增電子郵件驗證欄位，例如登入、電子報訂閱、帳戶建立和密碼復原表單。只有在瀏覽器支援的情況下，EVP 才會觸發。如果提交後未收到驗證碼，或任何驗證步驟失敗，可以改用預設的電子郵件確認流程。這也表示 API 沒有功能偵測機制；驗證器網站會將 EVT 視為選用，如果要求中含有 EVT，就會處理。

電子郵件驗證可確認使用者與電子郵件地址供應商之間有有效的會話群組。但無法確認電子郵件是否送達使用者信箱。您可能仍想傳送現有的歡迎或新手上路電子郵件，並可能想或需要提示使用者檢查垃圾郵件設定。