เผยแพร่: 13 สิงหาคม 2026, ปรับปรุงล่าสุด: 5 ตุลาคม 2026
ช่วงทดลองใช้จากต้นทางสำหรับการยืนยันอีเมลเริ่มต้นใน Chrome 150 เราได้ทำการแก้ไขและปรับปรุงหลายอย่างตามความคิดเห็นของคุณ โพสต์นี้จะแสดงภาพรวมของการเปลี่ยนแปลงและสิ่งที่คุณควรทำในเว็บไซต์หรือบริการ
ก่อนอื่นมาดูสรุปฟังก์ชันการยืนยันอีเมล (หรือดูรายละเอียดเพิ่มเติมได้ในประกาศก่อนหน้านี้) รูปแบบที่พบบ่อยในเว็บไซต์คือให้ผู้ใช้ป้อนอีเมลเป็นส่วนหนึ่งของการลงชื่อสมัครใช้ การลงชื่อเข้าใช้ การกู้คืนบัญชี และอื่นๆ จากนั้นผู้ใช้จะต้องไปที่อีเมลเพื่อคลิกลิงก์มหัศจรรย์หรือรับ OTP การยืนยันอีเมลจะช่วยปรับปรุงการทำงานนี้ให้ดียิ่งขึ้นด้วยการยืนยันอีเมลกับผู้ให้บริการโดยตรงในเบราว์เซอร์ จากนั้นเว็บไซต์จะได้รับโทเค็นจากเบราว์เซอร์ซึ่งสามารถตรวจสอบกับผู้ให้บริการอีเมลและข้ามการส่งอีเมลนั้นไปเลย
การอัปเดตที่แสดงต่อผู้ใช้
การเปลี่ยนแปลงในอินเทอร์เฟซผู้ใช้หรือลักษณะการทำงานที่ผู้ใช้มองเห็น
การป้อนอีเมล
ก่อนหน้านี้ ผู้ใช้ต้องใช้การเติมข้อความอัตโนมัติหรือการป้อนข้อความอัตโนมัติเพื่อป้อนอีเมล ตอนนี้การป้อนอีเมลในช่องไม่ว่าจะด้วยวิธีใด (เช่น การพิมพ์หรือการวาง) จะทริกเกอร์กระบวนการยืนยันเมื่อผู้ใช้ออกจากองค์ประกอบ input ซึ่งคล้ายกับเหตุการณ์ change ซึ่งหมายความว่าการยืนยันอีเมลควรทริกเกอร์อย่างมีประสิทธิภาพเมื่อมีการป้อนอีเมล
ตัวบอกสถานะความคืบหน้า
นอกจากนี้ เรายังทดสอบตัวบ่งชี้ความคืบหน้าสำหรับกระบวนการยืนยันใน Chrome 152 ขึ้นไปด้วย แม้ว่ากระบวนการยืนยันจะรวดเร็ว แต่ผู้ใช้ก็ยังส่งแบบฟอร์มได้ก่อนที่กระบวนการจะเสร็จสมบูรณ์ ตัวบ่งชี้ความคืบหน้าจะแสดงวงกลมหมุนขณะยืนยัน จากนั้นจะแสดงเครื่องหมายถูกเมื่อเสร็จสมบูรณ์ที่ส่วนท้ายของช่องป้อนข้อมูล (ด้านขวาสำหรับภาษาที่เขียนจากซ้ายไปขวา)
หากการดำเนินการนี้ทำให้เกิดปัญหาหรือคุณเห็นลักษณะการทำงานที่ไม่คาดคิด โปรดรายงานข้อบกพร่อง
เฉพาะเดสก์ท็อป
การยืนยันอีเมลใช้ได้บนเดสก์ท็อปเท่านั้นจนถึง Chrome 152 เรากำลังพิจารณาการรองรับบน Android ด้วย และจะอัปเดตข้อมูลที่นี่ในอนาคต
ข้อมูลอัปเดตสำหรับผู้ยืนยัน
การเปลี่ยนแปลงสำหรับเว็บไซต์ที่รวบรวมและยืนยันอีเมล
การตรวจสอบโทเค็น
โทเค็นการยืนยันอีเมลจะอยู่ในรูปแบบการเปิดเผยข้อมูลแบบเลือกสำหรับโทเค็นเว็บ JSON (SD-JWT) ในรูปแบบดิบ ข้อมูลนี้จะมีลักษณะดังนี้ JWT ที่ลงนามโดยผู้ออก ตามด้วยการเปิดเผย 0 รายการขึ้นไป และปิดท้ายด้วย JWT การเชื่อมโยงคีย์ โดยแต่ละคอมโพเนนต์จะคั่นด้วยเครื่องหมายตัวหนอน
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
โทเค็นการยืนยันทางอีเมลในรูปแบบปัจจุบันจะแสดงเฉพาะ JWT ที่ลงนามโดยผู้ออกและ JWT การเชื่อมโยงคีย์โดยไม่มีการเปิดเผยข้อมูลใดๆ บล็อกโพสต์ต้นฉบับและรุ่นแรกของเดโมเพียงแค่แยกโทเค็นออกเป็น 2 ส่วนและแยกวิเคราะห์ JWT ทั้ง 2 รายการ ซึ่งมีความเปราะบางและจะใช้งานไม่ได้หากมีการเพิ่มการเปิดเผยข้อมูลแบบเลือกในอนาคต
คุณควรตรวจสอบว่าการติดตั้งใช้งานของคุณได้แยกวิเคราะห์โทเค็น SD-JWT อย่างถูกต้องตามข้อกำหนดของโทเค็น โดยใช้ไลบรารีสำหรับแพลตฟอร์มของคุณจะเป็นวิธีที่ดีที่สุด แทนที่จะพึ่งพาฟีเจอร์นี้ของข้อเสนอปัจจุบัน เช่น ตอนนี้รหัสยืนยันการสาธิตใช้ @sd-jwt/core เพื่อแยกวิเคราะห์โทเค็นและตรวจสอบการเชื่อมโยงคีย์ (ผู้ชม, Nonce และแฮช) จากนั้นใช้ jose เพื่อยืนยันลายเซ็นสำหรับ EVT ของผู้ออกและ JWT การเชื่อมโยงคีย์ของเบราว์เซอร์
การทดลองใช้ต้นทางของบุคคลที่สาม
ช่วงทดลองใช้จากต้นทางของบุคคลที่สามไม่รองรับการยืนยันอีเมล ณ เดือนสิงหาคม ช่วงทดลองใช้จากต้นทางของบุคคลที่สามช่วยให้ต้นทางของบุคคลที่สามเปิดใช้ฟังก์ชันการทดลองในเว็บไซต์ที่มีการรวมไว้ได้ เช่น การอ้างอิง JavaScript แบบข้ามต้นทาง หากกรณีการใช้งานของคุณให้ความสำคัญกับเรื่องนี้ โปรดแสดงความคิดเห็นหรือติดตามข้อบกพร่องในการติดตาม
การเปรียบเทียบอีเมลโดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
โปรดทราบว่าผู้ให้บริการอีเมลอาจส่งคืนอีเมล Canonical ที่มีตัวอักษรพิมพ์ใหญ่ เช่น Demo.User@example.com แม้ว่าคุณจะระบุ demo.user@example.com ในแบบฟอร์มก็ตาม ตรวจสอบว่าคุณกำลังเปรียบเทียบอีเมลที่ได้รับโดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ นอกจากนี้ เรายังได้แก้ไขข้อบกพร่องในหน้าการตั้งค่าที่คุณอาจเห็นอีเมลเดียวกันในรูปแบบที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
ข้อมูลอัปเดตจากผู้ให้บริการ
การเปลี่ยนแปลงสำหรับผู้ให้บริการอีเมล
ลายเซ็นข้อความ HTTP สำหรับคำขอออกใบรับรอง
เราจะเปิดตัวการเปลี่ยนแปลงที่ทำให้เกิดข้อผิดพลาดใน Chrome 153 ซึ่งคำขอออกใบรับรองจะส่งเฉพาะ email ในรูปแบบ application/json พร้อมลายเซ็นข้อความ HTTP
- Chrome 152 (และเวอร์ชันก่อนหน้า): อุปกรณ์ปลายทางการออกจะได้รับคำขอ
application/x-www-form-urlencodedPOSTที่มีrequest_tokenในเนื้อหา - Chrome 153 (และเวอร์ชันต่อๆ ไป): ประเภทเนื้อหาจะเปลี่ยนเป็น
application/jsonโดยมีส่วนหัวSignature,Signature-InputและSignature-Keyรวมถึงเนื้อหาที่มีเฉพาะคีย์email
คุณสามารถทำอย่างใดอย่างหนึ่งต่อไปนี้ได้ ทั้งนี้ขึ้นอยู่กับระดับการเข้าชมปัจจุบันและเป้าหมายในการทดสอบ
- รองรับทั้ง 2 รูปแบบและสลับตามประเภทเนื้อหา เมื่อ Chrome 153 เป็นรุ่นเสถียรในช่วงปลายเดือนสิงหาคม คุณจะประเมินการเข้าชมเพื่อนำฟังก์ชันเดิมออกได้
- เพียงเปลี่ยนไปใช้รูปแบบใหม่ ซึ่งหมายความว่าการยืนยันจะล้มเหลวสำหรับผู้ใช้ Chrome เวอร์ชันก่อนหน้า
เราได้อัปเดตปลายทางการออกในโค้ดเดโมเพื่อรองรับทั้ง 2 โฟลว์โดยใช้ 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"}
รูปแบบการตอบกลับจะยังคงเหมือนเดิม นั่นคือ issuance_token ในส่วนเนื้อหาของ application/json
คุณอ่านและแสดงความคิดเห็นเพิ่มเติมเกี่ยวกับที่เก็บข้อเสนอได้ที่ WICG/email-verification และ dickhardt/email-verification การตอบสนองของชุมชนจนถึงตอนนี้มีประโยชน์อย่างยิ่ง ดังนั้นคุณจึงคาดหวังได้ว่าเราจะอัปเดตและปรับปรุงต่อไป