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

Rowan Merewood

Published: July 8, 2026

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

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

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

คุณสามารถลองใช้ขั้นตอนต่างๆ ด้วยบัญชีทดลองได้ดังนี้

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

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

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

คำสำคัญ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<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" เบราว์เซอร์ใช้แอตทริบิวต์นี้เพื่อระบุช่องที่จะป้อนข้อมูล

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

ตรวจสอบ EVT

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

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

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

ข้อมูลดิบจากการส่งแบบฟอร์มจะมี EVT และการอ้างสิทธิ์ที่ลงนามใน โทเค็นเว็บของ JSON การเปิดเผยข้อมูลแบบเลือก (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

ยืนยันระเบียน DNS _email-verification สำหรับโดเมนอีเมล เช่น สำหรับ demo@gmail.com ให้ค้นหาระเบียน TXT ของ _email-verification.gmail.com สำหรับผู้ให้บริการรายนี้ คำค้นหาจะแสดงตำแหน่งของผู้ให้บริการบัญชี นั่นคือ 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 เพื่อยืนยัน EVT JWT ที่แยกออกมาจากโทเค็น ไลบรารี JOSE ส่วนใหญ่มีฟังก์ชันในการจัดการการยืนยันนี้

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

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

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

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

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

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

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

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

รูปแบบระเบียน: _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

ทรัพยากร JSON .well-known เพิ่มเติมที่คุณอาจติดตั้งใช้งานแล้วเป็น ส่วนหนึ่งของ 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 จะได้รับคำขอ POST application/x-www-form-urlencoded ที่มี 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. ตอบกลับด้วยโทเค็น

เมื่อยืนยันเซสชันและโทเค็นคำขอสำเร็จแล้ว ให้สร้าง 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...~"
}

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

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

• Browser Email Verification API: WICG/email-verification
• Email Verification Protocol: dickhardt/email-verification

หากพบข้อบกพร่องในการติดตั้งใช้งาน Chrome ให้แจ้งข้อบกพร่องกับคอมโพเนนต์ต่อไปนี้

• New issue: Chromium > Blink > Identity > EVP

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

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

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