電子郵件驗證

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

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

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

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

  • 不中斷：使用者填寫表單時，系統會在背景進行驗證。
  • 無須偵測功能：網站會在表單中加入電子郵件輸入內容和隱藏式權杖輸入內容。如果瀏覽器或供應商不支援電子郵件驗證，或驗證失敗，網站會改用預設的電子郵件確認流程。
  • 降低網路釣魚風險：使用者不必複製任何程式碼，也不會被導向假冒網站。

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

  • 簽發者示範：提供模擬電子郵件帳戶和已登入的工作階段。
  • 驗證者試用版：驗證試用版電子郵件或任何參與計畫的供應商電子郵件。

來源試用注意事項

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

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

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

來源試用也有流量限制，可盡量減少網站在上線前對這項功能的依賴。發行者 API 仍在開發中，因此 Chrome 使用者體驗更新時，您可能會遇到不相容的變更。

開發作業進行期間，請密切關注這個網誌和 evp-announce@chromium.org 郵寄清單的最新消息。

電子郵件驗證流程

以下各節說明使用 Email Verification API 時的重要術語和通訊協定步驟。

重要詞彙

電子郵件驗證 API 的重要用語如下：

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

在某些情況下，電子郵件服務供應商和發行者會使用相同網域。 不過，請務必區分兩者，因為電子郵件驗證 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，就會處理該項目。

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