- นโยบาย Signed Agents ของ Cloudflare อ้างเรื่องความปลอดภัยเป็นเหตุผล แต่ในความเป็นจริงคือ ความพยายามแบบปิดที่ทำให้การเข้าถึงเว็บต้องได้รับอนุญาตก่อน
- ในเชิงประวัติศาสตร์ เว็บเติบโตมาได้ด้วย ความเปิดกว้างและมาตรฐาน และเทคโนโลยีปิดอย่าง Flash และ Silverlight ก็สุดท้ายถูกมาตรฐานเปิดอย่าง HTML5 แทนที่จนหายไป
- ต่อไปผู้ใช้งานหลักของเว็บจะเป็น AI agent และสิ่งนี้ต้องการ ระบบยืนยันตัวตนที่กระจายศูนย์และตรวจสอบได้ รวมถึงการให้สิทธิ์ตามหน่วยงาน
- โมเดลที่ถูกต้องคือการผสาน การมอบหมายสิทธิ์แบบอิงเชน + หลักฐานระดับคำขอ เพื่อให้เกิดการยืนยันตัวตนที่เชื่อถือได้และการควบคุมสิทธิ์ที่ละเอียด
- แทนที่จะให้บริษัทใดบริษัทหนึ่งถือกุญแจไว้ ควรรักษาเว็บที่ทุกคนสามารถเข้าร่วมและสร้างนวัตกรรมได้ผ่าน โปรโตคอลและมาตรฐานแบบเปิด
วิจารณ์ Signed Agents ของ Cloudflare
- Cloudflare เสนอระบบ Signed Agents ใหม่ แต่ในทางปฏิบัติมันคือ การควบคุมการเข้าถึงแบบอิงรายชื่อที่ได้รับอนุญาต
- การที่บริษัทบางแห่งเป็นผู้ตัดสินว่า agent ใดจะลงทะเบียนได้หรือไม่ เป็นเพียง ระบบอนุมัติโดยผู้ขาย ไม่ใช่โปรโตคอลอินเทอร์เน็ต
- สิ่งนี้ขัดกับธรรมชาติแบบเปิดของอินเทอร์เน็ต และ “การกรอกแบบฟอร์มเพื่อขออนุญาต” ไม่อาจกลายเป็นมาตรฐานได้
เว็บต้องเปิดกว้าง
- กลยุทธ์ “embrace and extend” ของ Microsoft ในยุค 90 ล้มเหลว และสิ่งนี้เกิดขึ้นได้เพราะเว็บยังคงความเปิดกว้างไว้
- รันไทม์แบบปิด อย่าง Flash และ Silverlight ท้ายที่สุดก็ถูกแทนที่ด้วยมาตรฐานเปิดอย่าง HTML5
- ประวัติศาสตร์พิสูจน์มาโดยตลอดว่า มาตรฐานเปิดช่วยเร่งนวัตกรรม
การมาถึงของยุค agent
- AI agent จะเป็นผู้ใช้หลักของเว็บในอนาคต โดยจะทำงานอย่าง ค้นหาข้อมูล ทำงานอัตโนมัติ ชำระเงิน และเจรจาสัญญา
- เส้นแบ่งระหว่างการกระทำของมนุษย์กับ agent จะเลือนรางลง และสิ่งนี้ทำให้ ระบบยืนยันตัวตนแบบอิงการมอบหมายสิทธิ์ กลายเป็นสิ่งจำเป็น
การยืนยันตัวตน (Authentication) และการให้สิทธิ์ (Authorization)
- การยืนยันตัวตน: ใครเป็นผู้กระทำ?
- การให้สิทธิ์: ทำอะไรได้บ้าง?
- Cloudflare สับสนระหว่างสองแนวคิดนี้ และพยายามใช้ “passport” เพื่อแก้ทุกปัญหา แต่สิ่งนี้เป็นไปไม่ได้โดยพื้นฐาน
- การยืนยันตัวตนที่ถูกต้องควรทำผ่าน เชนการมอบหมายสิทธิ์และลายเซ็นระดับคำขอ พร้อมใช้ กลไกการตรวจสอบแบบกระจายศูนย์ เช่น การเผยแพร่กุญแจสาธารณะบน DNS
การจัดการสิทธิ์
- ซอฟต์แวร์แบบเดิมใช้โมเดล OAuth scope ได้ผลดี เพราะมี ขอบเขตที่จำกัด
- แต่ agent เป็นเครื่องมืออเนกประสงค์ จึงต้องมี การให้สิทธิ์ตามงาน (Task-Scoped)
- ตัวอย่าง: สิทธิ์สำหรับ “ชำระค่าอาหารเย็น” และสิทธิ์สำหรับ “ดูประวัติการใช้จ่ายย้อนหลัง 3 เดือน” แม้เป็น agent ตัวเดียวกันก็ควรใช้ โทเคนคนละชุด
- เพื่อสิ่งนี้ สามารถใช้โทเคนแบบมีข้อจำกัดอย่าง Macaroons, Biscuits และเอนจินนโยบายอย่าง OPA/AWS Cedar
โปรโตคอลต้องมาก่อน ไม่ใช่ผู้เฝ้าประตู
- การยืนยันตัวตน การให้สิทธิ์ และการสร้างรายได้ ควรอยู่บน มาตรฐานแบบเปิดที่ทำงานร่วมกันได้ ไม่ใช่อยู่ภายใต้บริษัทใดบริษัทหนึ่ง
- หากมีเพียงไม่กี่บริษัทที่ตัดสินความถูกต้องของ agent เว็บก็จะเสื่อมสภาพเป็น สวนปิด (Walled Garden) ในไม่ช้า
- ดังนั้น จึงมีการเสนอ การมอบหมายสิทธิ์แบบอิงเชน หลักฐานระดับคำขอ และการให้สิทธิ์ตามขอบเขตงาน ในรูปแบบโอเพนซอร์ส เพื่อให้ทุกคนสามารถนำไปใช้งานได้
บทสรุป
- อนาคตของเว็บไม่ได้ขึ้นอยู่กับ “ใครควบคุมประตู” แต่ขึ้นอยู่กับ โปรโตคอลที่ทุกคนช่วยกันสร้างและต่อยอดนวัตกรรมได้
ยังไม่มีความคิดเห็น