發布日期：2026 年 8 月 13 日，上次更新日期：2026 年 10 月 5 日
電子郵件驗證來源試用已在 Chrome 150 開始。根據您的意見回饋，我們進行了多項修正和改良。這篇文章將概略說明異動內容，以及您應在網站或服務上採取的行動。
首先，我們將簡要說明電子郵件驗證功能 (詳情請參閱先前的公告)。在網站上，使用者通常會在註冊、登入、帳戶救援等程序中輸入電子郵件地址，然後前往電子郵件信箱點選神奇連結或取得一次性密碼。電子郵件驗證功能可直接在瀏覽器中向供應商驗證電子郵件地址，進一步提升安全性。網站接著會從瀏覽器收到權杖，並透過電子郵件服務供應商驗證權杖，完全略過傳送電子郵件的步驟。
面向使用者的更新
使用者介面或面向使用者的行為有所變更。
輸入電子郵件
過去，使用者必須使用自動完成或自動填入功能輸入電子郵件地址。現在，只要在欄位中輸入電子郵件地址 (例如輸入或貼上)，使用者離開 input 元素後就會觸發驗證程序，與 change 事件類似。也就是說，只要輸入電子郵件地址，系統就會觸發電子郵件驗證程序。
進度指標
我們也正在 Chrome 152 以上版本中測試驗證程序的進度指標。雖然驗證程序很快，但使用者仍有可能在程序完成前提交表單。驗證時，進度指標會顯示微調器，完成後則會在輸入欄位的內嵌結尾 (從左到右語言的右側) 顯示勾號。
如果這導致任何問題或出現非預期行為，請回報錯誤。
僅限電腦
電子郵件驗證功能僅適用於電腦版 Chrome 152 以下版本。我們也正積極探索 Android 支援選項，日後會在此更新。
驗證者更新
網站收集及驗證電子郵件地址的異動。
權杖驗證
電子郵件驗證權杖會以 JSON Web Token (SD-JWT) 選擇性揭露格式提供。原始格式如下：簽發者簽署的 JWT，後方為零或多個揭露事項，最後是金鑰繫結 JWT，每個元件都以半形波浪號分隔：
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
目前形式的電子郵件驗證權杖只會傳回簽署者簽署的 JWT 和金鑰繫結 JWT，不含任何揭露資訊。原始網誌文章和第一個版本的示範只是將權杖分成兩部分，並剖析這兩個 JWT。這項做法很脆弱，日後新增選擇性揭露內容時就會失效。
您不應依賴目前提案的這項功能，而應確保實作項目會根據規格正確剖析 SD-JWT 權杖，最好是使用適用於您平台的程式庫。舉例來說，示範驗證碼現在會使用 @sd-jwt/core 剖析權杖，並驗證金鑰繫結 (對象、Nonce 和雜湊)，然後使用 jose 驗證簽章，適用於簽發者的 EVT 和瀏覽器的金鑰繫結 JWT。
第三方原始碼試用
自 8 月起，電子郵件驗證不再支援第三方原始碼試用。第三方來源試用計畫可讓第三方來源在納入該來源的網站上啟用試用功能，例如跨來源 JavaScript 依附元件。如果這是您用途的優先事項，請在追蹤錯誤中留言或追蹤。
不區分大小寫的電子郵件比較
提醒您，即使表單中提供的是 demo.user@example.com，電子郵件服務供應商仍可能會傳回含有大寫字母的標準電子郵件地址，例如 Demo.User@example.com。請務必以不區分大小寫的方式，比較收到的電子郵件地址。此外，我們也修正了設定頁面中的錯誤，現在不會再列出大小寫不同的相同電子郵件地址。
提供者更新
電子郵件服務供應商的變更。
簽發要求的 HTTP 訊息簽章
我們將在 Chrome 153 中推出重大變更，屆時核發要求只會以 application/json 格式傳送 email，並採用 HTTP 訊息簽章。
- Chrome 152 (和更早版本)：發行端點會收到內文含有
request_token的application/x-www-form-urlencodedPOST要求。 - Chrome 153 以上版本：內容類型會變更為
application/json，並包含Signature、Signature-Input和Signature-Key標頭，以及僅含email鍵的內文。
視目前的流量和測試目標而定，您可以採取下列任一做法：
- 支援兩種格式，並根據內容類型切換。Chrome 153 於 8 月底推出穩定版後，您就可以評估流量，然後移除舊版功能。
- 只要切換至新格式，舊版 Chrome 的使用者就會無法通過驗證。
示範程式碼中的核發端點已更新，可使用 structured-headers 和 http-message-sig 處理這兩種流程。
完整要求格式：
POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"
{email: "demo@example.com"}
回覆格式維持不變：application/json 主體中的 issuance_token。
您可以閱讀並在提案存放區中提出其他意見回饋：WICG/email-verification 和 dickhardt/email-verification。目前為止，社群的回應對我們很有幫助，因此我們將持續進行更新和改良。