發布日期：2026 年 10 月 5 日
電子郵件驗證來源試用仍在進行中，我們根據您的意見回饋，進一步更新了這項功能。我們預期不會再有重大變更，並準備推出這項功能。我們也推出了新的說明文件專區，提供電子郵件驗證的相關資訊，並為驗證者和簽發者分別設立專區。
電子郵件驗證來源試用已在 Chrome 150 電腦版啟動。根據開發人員的意見回饋，以及在整個生態系統中進行的測試，我們將持續改善實作方式。本文將介紹 Chrome 154 的更新內容，包括 Android 支援、第三方原始測試、權杖驗證期間的鍵探索處理，以及電子郵件服務供應商的標頭更新。
面向使用者的更新
使用者介面或面向使用者的行為有所變更。
Android 版 Chrome 支援
自 Chrome 154 起，Android 版 Google Chrome 支援電子郵件驗證。驗證者或供應商不需要進行任何變更，因為 API 或通訊協定維持不變。適用相同的前提條件，包括使用者必須在瀏覽器中登入電子郵件供應商。
使用者可以依序前往「設定」 >「地址等資訊」 >「已驗證的電子郵件」，存取相關設定。
驗證者更新
網站收集及驗證電子郵件地址的異動。
第三方原始碼試用
自 Chrome 154 起，電子郵件驗證支援第三方來源試用 (請參閱問題 534377131)。如果您提供內嵌指令碼或 Identity SDK，現在可以註冊第三方試用權杖，並將其插入代管指令碼的網頁。嵌入您指令碼的網站不需要註冊個別的來源試用權杖。
但有一項重要附註：原始碼試用註冊者和簽發者必須位於相同網站。具體來說，試用版註冊的來源必須與簽發者網域一致。
支援的設定：
- 發卡機構網域：
issuer.example - OT 註冊者：
https://issuer.example - JavaScript 來源：
https://issuer.example(或https://app.issuer.example，適用於子網域比對)
不支援的設定：
- 子網域註冊者：簽發者網域為
issuer.example，但 OT 註冊者為https://app.issuer.example。 - 跨網站註冊者：發布者網域為
issuer.example，但 OT 註冊者為https://different.example。
處理 EVT 中的選填 kid
驗證電子郵件驗證權杖 (EVT) 時，伺服器會擷取供應商的 JSON Web Key Set (JWKS)，驗證簽發者的加密簽章。金鑰可選擇性包含 kid 金鑰 ID，JWT 也可選擇性包含金鑰 ID，指出用於簽署權杖的金鑰。如果權杖不含 kid 聲明 (例如使用 Gmail)，請逐一檢查金鑰，找出正確的金鑰。說明文件和示範會顯示執行這項操作的程式碼。
完全按照提供的內容傳回 email 聲明
自 Chrome 156 起，權杖中的電子郵件地址會完全按照表單提交內容傳回 (請參閱問題 549217427)。先前，發卡機構可能會傳回帳戶的標準電子郵件地址 (例如，表單提交內容包含 first.last@example.com 時，傳回 First.Last@example.com)。請注意，對傳回的電子郵件執行不區分大小寫的比較，一律是良好的做法，因此這項異動不應造成中斷。
提供者更新
電子郵件服務供應商的變更。
完全按照提供的內容傳回 email 聲明
從供應商的角度來看，這項規定更加嚴格：如果供應商未完全按照提供的電子郵件地址傳回電子郵件，Chrome 就會拒絕權杖。這樣做可避免揭露比傳送確認電子郵件更多的資料。以處理電子郵件傳送作業的方式，根據登入的使用者驗證收到的電子郵件是否相符。
將「Sec-Fetch-Dest」重新命名為「email-verification」
自 Chrome 154 起，權杖核發要求傳送的 Sec-Fetch-Dest 標頭已更新為使用連字號：
- Chrome 154 以上版本：
Sec-Fetch-Dest: email-verification - Chrome 153：
Sec-Fetch-Dest: emailverification
這項變更會根據網頁平台命名慣例，將擷取目的地 ID 標準化 (請參閱問題 546618576)。
如果核發端點會驗證 Sec-Fetch-Dest 標頭 (建議您這麼做，以防範 CSRF 和非預期的要求環境)，請更新檢查作業，接受 email-verification。為避免瀏覽器推出期間發生中斷情形，請在轉換期間接受這兩個值。