ทดสอบโปรโตคอลการยืนยันอีเมลด้วยช่วงทดลองใช้ Origin

Rowan Merewood

เผยแพร่: 8 กรกฎาคม 2026, ปรับปรุงล่าสุด: 5 ตุลาคม 2026

เมื่อรวบรวมอีเมลเป็นส่วนหนึ่งของการลงชื่อสมัครใช้ การลงชื่อเข้าใช้ การติดตาม การชำระเงิน การกู้คืนบัญชี หรือกระบวนการอื่นๆ แนวทางปฏิบัติทั่วไปคือการยืนยัน ว่าอีเมลเป็นของผู้ที่ป้อนอีเมลนั้น วิธีการยืนยันที่มีอยู่ เช่น รหัสผ่านแบบใช้ครั้งเดียว (OTP) หรือลิงก์ยืนยันทางอีเมล (ลิงก์มหัศจรรย์) กำหนดให้ผู้ใช้ต้องออกจากเว็บไซต์ของคุณ กระบวนการที่ขัดขวางนี้อาจเพิ่มความเสี่ยงที่ผู้ใช้ ไม่ว่าจะเป็นบุคคลหรือเอเจนต์ จะละทิ้งเซสชันทั้งหมดและไม่เคยดำเนินการตรวจสอบสิทธิ์ ให้เสร็จสมบูรณ์

Email Verification API เป็นข้อเสนอที่อนุญาตให้เบราว์เซอร์สื่อสาร กับผู้ให้บริการอีเมลโดยตรงเพื่อยืนยันว่าผู้ใช้เป็นเจ้าของอีเมล ผู้ใช้เลือกอีเมลจากคำแนะนำการป้อนข้อความอัตโนมัติหรือการเติมข้อความอัตโนมัติของเบราว์เซอร์ ส่งแบบฟอร์ม และเว็บไซต์จะยืนยันอีเมลกับผู้ให้บริการ โดยไม่ต้องส่งอีเมลหรือขัดขวางขั้นตอนของผู้ใช้

การเก็บรวบรวมอีเมลเป็นจุดเปลี่ยนที่สำคัญในเส้นทางของผู้ใช้ และ Chrome ต้องการความคิดเห็นเกี่ยวกับข้อเสนอจากเว็บไซต์ที่ต้องการยืนยันอีเมล ผู้ให้บริการอีเมลที่สามารถทำการยืนยัน และผู้ใช้ที่พบกระบวนการนี้ คุณสามารถลงชื่อสมัครเข้าร่วมช่วงทดลองใช้จากต้นทางได้แล้ววันนี้ และทำตามวิธีการติดตั้งใช้งานที่นี่ ดูการกำหนดค่าช่วงทดลองใช้จากต้นทางทั่วไปได้ที่เริ่มต้นใช้งานช่วงทดลองใช้จากต้นทาง

คุณลองใช้โฟลว์ด้วยบัญชีเดโมได้โดยทำดังนี้

• การสาธิตผู้ออกบัตรจะให้บัญชีอีเมล และเซสชันจำลองแก่คุณ
• การสาธิตโปรแกรมตรวจสอบจะยืนยันผู้ให้บริการที่เข้าร่วม

ขั้นตอนการยืนยันอีเมล

ส่วนต่อไปนี้จะอธิบายสิ่งที่คุณและผู้ใช้ต้องทำเพื่อเริ่มขั้นตอนการยืนยันอีเมล และเวิร์กโฟลว์ทั้งหมดเมื่อใช้โปรโตคอลการยืนยันอีเมล

คำสำคัญ

คำสำคัญสำหรับ Email Verification API มีดังนี้

• ผู้ยืนยัน: เว็บไซต์ที่รวบรวมอีเมลและต้องการยืนยัน อีเมลนั้น โดยผู้ยืนยันจะเรียกว่าฝ่ายที่ต้องอาศัยข้อมูลด้วย
• ผู้ให้บริการอีเมล: บริการที่ให้อีเมลแก่ผู้ใช้ เช่น gmail.com
• ผู้ออก: บริการที่จัดการบัญชีสำหรับอีเมลของผู้ใช้ เช่น accounts.google.com ผู้ออกใบรับรองยังเรียกว่าผู้ให้บริการข้อมูลประจำตัวด้วย

ในบางกรณี ผู้ให้บริการอีเมลและผู้ออกใบรับรองอาจดำเนินการจากโดเมนเดียวกัน อย่างไรก็ตาม คุณควรแยกความแตกต่างระหว่างการมีอีเมลแอดเดรสกับการมีเซสชันที่ใช้งานอยู่สำหรับบัญชีที่เชื่อมโยง

ข้อกำหนดเบื้องต้น

• ผู้ใช้ต้องลงชื่อเข้าใช้ผู้ให้บริการอีเมลหรือผู้ออกใบรับรองในโปรไฟล์เบราว์เซอร์เดียวกัน เช่น หากใช้ Gmail ผู้ใช้จะต้องลงชื่อเข้าใช้บัญชี Google
• ในฐานะเว็บไซต์ที่เข้าร่วมการทดลองใช้ Origin คุณต้องลงชื่อสมัครใช้การทดลองใช้ Origin และระบุโทเค็นในหน้าเดียวกันกับแบบฟอร์มอีเมล

• ผู้ใช้ต้องเลือกอีเมลจากเมนูแบบเลื่อนลงของการป้อนข้อความอัตโนมัติหรือการเติมข้อความอัตโนมัติ

  • หากผู้ใช้เคยป้อนอีเมลในช่องนี้มาก่อน ระบบจะแสดงอีเมลนั้นโดยใช้การเติมข้อความอัตโนมัติ

  • หากผู้ใช้เพิ่มอีเมลโดยใช้การตั้งค่า Chrome "การป้อนข้อความอัตโนมัติและรหัสผ่าน" (chrome://settings/autofill) ระบบจะ เสนออีเมลดังกล่าวโดยใช้การป้อนข้อความอัตโนมัติ

• ครั้งแรกที่ผู้ใช้ระบุอีเมลเพื่อยืนยัน ผู้ใช้จะเห็นข้อความแจ้งขอสิทธิ์ ซึ่งจะเกิดขึ้นเพียงครั้งเดียวต่ออีเมล

เมื่อผู้ใช้มีเซสชันที่ใช้งานอยู่ในเบราว์เซอร์แล้ว ก็จะเริ่มกระบวนการได้โดยทำดังนี้

1. ในแบบฟอร์มที่มีช่องอีเมล ผู้ใช้จะเลือกอีเมลของตนเองจากเมนูแบบเลื่อนลงของ การเติมข้อความอัตโนมัติ เว็บไซต์เครื่องมือตรวจสอบจะระบุฟิลด์ที่ซ่อนอยู่ใน แบบฟอร์มพร้อมค่า Nonce ต่ออินสแตนซ์เพื่อตรวจสอบคำขอนี้

2. จากนั้นเบราว์เซอร์จะเรียกข้อมูลระเบียน DNS สำหรับการยืนยันอีเมลของ โดเมนอีเมล ซึ่งจะนำเบราว์เซอร์ไปยังผู้ออกใบรับรอง จากนั้นผู้ออกบัตรจะ ยืนยันว่ามีเซสชันที่ใช้งานอยู่สำหรับอีเมลนั้น

3. จากนั้นผู้ออกบัตรจะระบุโทเค็นการยืนยันทางอีเมล (EVT) สำหรับ ที่อยู่ เบราว์เซอร์จะรวมข้อมูลดังกล่าวเป็น JWT ที่เชื่อมโยงกับคีย์ที่มี EVT, ต้นทางของเว็บไซต์ และ Nonce จากแบบฟอร์มอินพุต

4. เมื่อส่งแบบฟอร์ม ระบบจะเพิ่มแพ็กเกจ EVT ลงในฟิลด์ที่ซ่อนไว้และ ส่งไปยังเว็บไซต์

5. จากนั้นเว็บไซต์ที่ยืนยันจะยืนยันรายละเอียดแต่ละอย่าง ได้แก่ อีเมลที่คาดไว้ หมายเลขสุ่ม และลายเซ็นจากเบราว์เซอร์และผู้ออก

6. ผู้ใช้จะเห็นการแจ้งเตือนเล็กๆ ที่แจ้งให้ทราบว่าผู้ให้บริการอีเมล ได้ยืนยันอีเมลของผู้ใช้แล้ว

กระบวนการนี้จะให้การยืนยันแก่เว็บไซต์ที่ยืนยันว่าอีเมล ถูกต้องและเป็นของผู้ใช้ปัจจุบัน ซึ่งหมายความว่าเว็บไซต์จะข้ามการส่ง อีเมลยืนยันได้

ผู้ใช้จัดการอีเมลที่ยืนยันแล้วได้ที่การตั้งค่า > ป้อนข้อความอัตโนมัติและ รหัสผ่าน > ข้อมูลติดต่อ > อีเมลที่ยืนยันแล้ว (หรือเปิด chrome://settings/contactInfo)

ข้อควรพิจารณาเกี่ยวกับกรณีการใช้งาน

การยืนยันอีเมลเป็นการปรับปรุงขั้นตอนที่มีอยู่แบบค่อยเป็นค่อยไป ซึ่งจะช่วย ลดความจำเป็นที่ผู้ใช้ต้องออกจากเว็บไซต์เพื่อรับ OTP หรือคลิกลิงก์ เว็บไซต์สามารถเพิ่มช่องการยืนยันอีเมลลงในแบบฟอร์มที่เกี่ยวข้องทั้งหมด เช่น การเข้าสู่ระบบ การลงชื่อสมัครรับจดหมายข่าว การสร้างบัญชี และการกู้คืนรหัสผ่าน EVP จะทริกเกอร์ก็ต่อเมื่อเบราว์เซอร์รองรับเท่านั้น หากไม่ได้รับรหัสเมื่อส่ง หรือขั้นตอนการตรวจสอบใดๆ ล้มเหลว คุณสามารถกลับไปใช้ขั้นตอนการยืนยันทางอีเมลเริ่มต้น ได้ ซึ่งหมายความว่าไม่มีการตรวจหาฟีเจอร์สำหรับ API เว็บไซต์ผู้ยืนยันจะถือว่า EVT เป็นตัวเลือกและจะประมวลผลหากมีอยู่ใน คำขอ

การยืนยันทางอีเมลจะยืนยันว่าผู้ใช้มีเซสชันที่ใช้งานอยู่กับผู้ให้บริการอีเมล แต่ไม่ได้ยืนยันว่าอีเมลของคุณไปถึงผู้ใช้ คุณอาจยังคงต้องการส่งอีเมลต้อนรับหรืออีเมลเริ่มต้นใช้งานที่มีอยู่ และอาจต้องการหรือจำเป็นต้องแจ้งให้ผู้ใช้ตรวจสอบการตั้งค่าจดหมายขยะ

ติดตั้งใช้งานเว็บไซต์ยืนยัน

ดูรายละเอียดเพิ่มเติมได้ในการสาธิตแบบครบวงจร ของโค้ด และดูขั้นตอนการตรวจสอบในข้อเสนอAPI การยืนยันอีเมลและโปรโตคอลการยืนยันอีเมล

กำหนดค่าช่องแบบฟอร์ม

ตรวจสอบว่าช่องแบบฟอร์มมีแอตทริบิวต์ที่ถูกต้อง

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

ตั้งค่าแอตทริบิวต์ type และ autocomplete ของอินพุต email เป็น email เพื่อให้เบราว์เซอร์เสนอการเติมข้อความอัตโนมัติสำหรับอีเมล

ระบบจะป้อนข้อมูลโทเค็นการยืนยันทางอีเมลในช่อง hidden ใหม่เมื่อส่งแบบฟอร์ม แอตทริบิวต์ที่จำเป็นมีดังนี้

• ตั้งค่า type="hidden" เนื่องจากช่องนี้ไม่จำเป็นต้องมีข้อมูลจากผู้ใช้
• ตั้งค่า nonce="rAnD0m-VaLuE" เว็บไซต์ต้องระบุค่า Nonce ที่เชื่อมโยงกับเซสชันที่ไม่ซ้ำกันเพื่อยืนยันการส่งแบบฟอร์ม
• ตั้งค่า autocomplete="email-verification-token" เบราว์เซอร์ใช้แอตทริบิวต์นี้เพื่อระบุช่องที่จะป้อนข้อมูล

ตรวจสอบองค์ประกอบของแบบฟอร์มโดยดูที่แผงเครือข่ายในเครื่องมือสำหรับนักพัฒนาเว็บ เมื่อคุณ เลือกอีเมล คุณจะเห็นเบราว์เซอร์ทริกเกอร์ DNS และการค้นหาบัญชี ที่ตามมาสำหรับผู้ให้บริการอีเมลและผู้ออก คำขอเหล่านี้เป็นคำขอภายในของเบราว์เซอร์ เว็บไซต์ของคุณจะไม่ได้รับอะไรจนกว่าจะมีการส่งแบบฟอร์ม

ตรวจสอบ EVT

การตรวจสอบความถูกต้องของคอมโพเนนต์แต่ละรายการในแพ็กเกจ EVT มี 5 ขั้นตอน

1. แยกวิเคราะห์โทเค็น
2. ตรวจสอบค่าที่คาดไว้
3. ตรวจสอบการเชื่อมโยงคีย์
4. ตรวจสอบระเบียน DNS
5. ค้นหาผู้ออกใบรับรองและยืนยันลายเซ็น EVT

1. แยกวิเคราะห์โทเค็น

ข้อมูลดิบจากการส่งแบบฟอร์มประกอบด้วย EVT และการอ้างสิทธิ์ที่ลงนามใน JSON Web Token แบบเปิดเผยข้อมูลอย่างจำกัด (SD-JWT+KB) ซึ่งคั่นด้วยเครื่องหมายตัวหนอน (~) คุณจะต้องแยกส่วนเหล่านี้และถอดรหัสส่วนหัวและเพย์โหลดของ Javascript Object Signing and Encryption (JOSE) (เช่น โดยใช้ jose สำหรับ Node.js)

หาก example.com ยืนยัน demo@gmail.com เพย์โหลดที่ถอดรหัสแล้วจะมีลักษณะคล้ายกับ ตัวอย่างต่อไปนี้

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. ตรวจสอบค่าที่คาดไว้

ตรวจสอบว่าค่าพื้นฐานในเพย์โหลดตรงกับค่าที่คุณระบุ

• ตรวจสอบว่าได้ตั้งค่า email_verified เป็น true
• ตรวจสอบว่า email ตรงกับอีเมลที่ระบุไว้ในแบบฟอร์ม
• ตรวจสอบว่า nonce ตรงกับ Nonce ที่ระบุไว้ในแบบฟอร์ม
• ตรวจสอบว่า aud ตรงกับต้นทางของเว็บไซต์
• ตรวจสอบว่า iat มีการประทับเวลาล่าสุด เช่น หลังจากแสดงผลแบบฟอร์ม

3. ตรวจสอบความถูกต้องของการเชื่อมโยงคีย์

เบราว์เซอร์จะสร้างคีย์ชั่วคราวแบบชั่วขณะสำหรับธุรกรรมเพื่อยืนยัน ว่าได้ลงนามในโทเค็น ดึงคีย์นี้จากข้อมูลอ้างสิทธิ์ cnf (การยืนยัน) ใน EVT แล้วใช้เพื่อยืนยัน JWT ที่เชื่อมโยงกับคีย์

จากนั้นคำนวณแฮชที่คาดไว้และเปรียบเทียบกับsd_hashการอ้างสิทธิ์ ตัวอย่าง Node.js ต่อไปนี้แสดงวิธีทำการคำนวณนี้

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. ตรวจสอบระเบียน DNS

ยืนยัน_email-verificationระเบียน DNS สำหรับโดเมนอีเมล เช่น สำหรับ demo@gmail.com ให้ค้นหาเรคคอร์ด _email-verification.gmail.com TXT สำหรับผู้ให้บริการรายนี้ คำค้นหาจะแสดงตำแหน่งของบัญชี ผู้ให้บริการ ซึ่งก็คือ accounts.google.com

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. ค้นหาผู้ออกใบรับรองและยืนยันลายเซ็น EVT

ตรวจสอบว่าผู้ออกให้บริการ/.well-known/email-verification ซึ่ง ระบุปลายทางสำหรับการออกโทเค็น, JSON Web Key (JWK) สำหรับ เว็บไซต์ และอัลกอริทึมการลงนามที่รองรับ

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

ใช้ JWK เพื่อยืนยัน JWT ของ EVT ที่คุณแยกจากโทเค็น ไลบรารี JOSE ส่วนใหญ่มีฟังก์ชันในการจัดการการยืนยันนี้

หากทั้ง 5 ขั้นตอนสำเร็จ คุณจะยืนยันอีเมลกับผู้ให้บริการได้ หากไม่ ให้กลับไปส่งอีเมลยืนยันให้ผู้ใช้ตามโฟลว์ปกติ

ติดตั้งใช้งานบริการผู้ให้บริการอีเมลและผู้ออกใบรับรอง

ดูรายละเอียดเพิ่มเติมได้โดยดูโค้ดการสาธิตผู้ให้บริการอีเมลจำลอง และดูขั้นตอนของผู้ให้บริการในข้อเสนอAPI การยืนยันอีเมลและโปรโตคอลการยืนยันอีเมล

ในฐานะผู้ออก คุณไม่จำเป็นต้องลงชื่อสมัครใช้ช่วงทดลองใช้ Origin หรือระบุโทเค็น เนื่องจากเบราว์เซอร์จะทำงานตามเว็บไซต์ของบุคคลที่สาม คุณเพียง ต้องตรวจสอบว่ามีปลายทางที่คาดไว้เพื่อตอบสนองต่อคำขอเหล่านั้น

กำหนดค่าการค้นหาผู้ออกบัตร

หากต้องการอนุญาตให้เบราว์เซอร์ค้นหาปลายทางการยืนยันโดยอัตโนมัติเมื่อมีการเลือก อีเมลที่เป็นของโดเมน ให้เปิดเผยการกำหนดค่าโดยใช้ DNS และ.well-known ปลายทาง HTTP

กำหนดค่าระเบียนผู้มอบสิทธิ์ DNS

กำหนดค่าระเบียน DNS TXT ในโดเมนอีเมลที่มอบสิทธิ์การยืนยัน ให้กับตัวระบุผู้ออก ตัวระบุเหล่านี้สามารถใช้โดเมนเดียวกันได้ ขึ้นอยู่กับโครงสร้างพื้นฐานของคุณ

รูปแบบการบันทึก: _email-verification.<email-domain>

ตัวอย่างไฟล์โซน

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

โฮสต์.well-known/email-verificationปลายทาง

โฮสต์ไฟล์ข้อมูลเมตา JSON ในโดเมนผู้ออกบัตรภายใต้เส้นทาง /.well-known/ ไฟล์นี้ระบุความสามารถในการออกบัตรและอัลกอริทึมการลงนามด้วยการเข้ารหัส ที่โครงสร้างพื้นฐานของคุณรองรับ

ปลายทาง: https://<issuer-domain>/.well-known/email-verification

ตัวอย่างคำตอบ

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

โฮสต์.well-known/web-identityปลายทาง

.well-knownทรัพยากร JSON เพิ่มเติมที่คุณอาจติดตั้งใช้งานแล้ว เป็นส่วนหนึ่งของ Federated Credentials (FedCM) API ซึ่งจะให้ลิงก์ไปยังปลายทางของบัญชีและ URL การเข้าสู่ระบบ

ปลายทาง: https://<domain>/.well-known/web-identity

ตัวอย่างคำตอบ

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

ใช้ปลายทางบัญชี

ปลายทางบัญชีจาก FedCM API จะแสดงรายการบัญชีที่ลงชื่อเข้าใช้ ในขณะนั้น ตัวอย่างต่อไปนี้แสดงการตอบกลับขั้นต่ำ ดูรายละเอียดเพิ่มเติมได้ที่คู่มือการติดตั้งใช้งานผู้ให้บริการข้อมูลประจำตัว

ปลายทาง: ตามที่ระบุไว้ใน .well-known/web-identity

ตัวอย่างการตอบกลับมีดังนี้

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

ผสานรวมกับ Login Status API

ผู้ใช้ต้องมีเซสชันที่ใช้งานอยู่กับผู้ให้บริการ และคุณต้องส่งสัญญาณนั้นไปยังเบราว์เซอร์ด้วย Login Status API

เมื่อผู้ใช้ลงชื่อเข้าใช้หรือออกจากระบบสำเร็จ ให้แสดงส่วนหัวการตอบกลับ HTTP ที่ตรงกัน

Set-Login: logged-in
Set-Login: logged-out

หรือจะอัปเดตสถานะโดยใช้ JavaScript ในบริบทของเว็บแอปพลิเคชันก็ได้

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

จัดการคำขอออกบัตร

issuance_endpoint จะได้รับคำขอ application/x-www-form-urlencoded POST ที่มี request_token

ส่วนต่อไปนี้จะแสดงกระบวนการทั้งหมดในการจัดการคำขอออกใบรับรอง

1. ตรวจสอบคำขอออกใบรับรอง

แยกวิเคราะห์และตรวจสอบเพย์โหลดของเบราว์เซอร์ที่เข้ามา

• วิธีการ: POST
• การยืนยันเซสชัน: ตรวจสอบคุกกี้ของบุคคลที่หนึ่ง session/authenticationของผู้ใช้ที่ส่งพร้อมกับคำขอเพื่อให้แน่ใจว่ามีบริบทข้อมูลประจำตัวที่ได้รับอนุญาตและใช้งานอยู่
• การยืนยันพารามิเตอร์: ดึงพารามิเตอร์ request_token (JWT ที่ลงชื่อแล้ว ซึ่งสร้างโดยเบราว์เซอร์) ตรวจสอบว่ามี คีย์สาธารณะชั่วคราว อีเมลเป้าหมาย กลุ่มเป้าหมายที่ถูกต้อง และ การประทับเวลาที่ถูกต้อง

โทเค็นที่ถอดรหัสแล้วควรมีลักษณะดังนี้

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. ตอบกลับด้วยโทเค็น

เมื่อตรวจสอบเซสชันและโทเค็นคำขอสำเร็จแล้ว ให้สร้าง Selective Disclosure JWT (SD-JWT) ที่ลงชื่อโดยใช้เพย์โหลดต่อไปนี้

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

ลงนามเพย์โหลดโดยใช้คีย์ส่วนตัวและอัลกอริทึมที่รองรับ เช่น การใช้ jose ใน Node.js

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

ตัวอย่างการตอบกลับที่สําเร็จ (HTTP 200)

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

ข้อควรพิจารณาเกี่ยวกับช่วงทดลองใช้จากต้นทาง

ช่วงทดลองใช้จากต้นทางเป็นการทดลองเพื่อรวบรวมความคิดเห็น ดังนั้นความคิดเห็นของคุณจึงมีความสำคัญอย่างยิ่งหากคุณเข้าร่วมในฐานะผู้ให้บริการที่ต้องพึ่งพาหรือผู้ให้บริการข้อมูลประจำตัว หากต้องการรายงานปัญหา ให้ใช้ที่เก็บ GitHub ต่อไปนี้

• API การยืนยันอีเมลของเบราว์เซอร์: WICG/email-verification
• โปรโตคอลการยืนยันอีเมล: dickhardt/email-verification

หากพบข้อบกพร่องในการติดตั้งใช้งาน Chrome ให้แจ้งข้อบกพร่องเกี่ยวกับ component:

• ปัญหาใหม่: Chromium > Blink > Identity > EVP

การเปิดใช้ฟังก์ชันช่วงทดลองใช้จากต้นทางจะควบคุมตามการตอบกลับแต่ละครั้งโดยการรวมโทเค็น OT ซึ่งหมายความว่าคุณจะควบคุมได้อย่างละเอียดหากต้องการจำกัดฟังก์ชันการทำงานสำหรับผู้ใช้บางส่วน เช่น หากคุณมีเฟรมเวิร์กการทดสอบ A/B อยู่แล้ว คุณสามารถผสานรวมช่วงทดลองใช้จากต้นทางเข้ากับเฟรมเวิร์กดังกล่าวเพื่อใช้กับกลุ่มทดสอบที่มีการควบคุม หรือหากคุณมีกลุ่มผู้ใช้ที่ทดสอบเวอร์ชันเบต้า หรือทดลองใช้ก่อนเปิดตัว คุณอาจต้องการหรือจำเป็นต้องเปิดใช้ ฟีเจอร์สำหรับผู้ใช้เหล่านั้น ในกรณีนี้ ให้ตรวจสอบกับอีเมลที่ระบุก่อน ออกหรือตรวจสอบโทเค็น

นอกจากนี้ ช่วงทดลองใช้จากต้นทางยังมีขีดจำกัดการเข้าชมเพื่อลดจำนวนเว็บไซต์ที่ใช้ฟีเจอร์นี้ ก่อนเปิดตัว API ของผู้ออกอยู่ระหว่างการพัฒนา และคุณควรคาดหวัง การเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลังพร้อมกับการอัปเดต UX ของ Chrome

เราจะโพสต์ข้อมูลอัปเดตเพิ่มเติมในบล็อกที่นี่และในรายชื่ออีเมล evp-announce@chromium.org เมื่อการพัฒนาคืบหน้า