HTTP Message Signatures (RFC 9421)

HTTP Message Signatures คืออะไร

HTTP Message Signatures ถูกกำหนดไว้ใน RFC 9421 ซึ่งเป็นมาตรฐานของ IETF สำหรับการสร้างและตรวจสอบลายเซ็นดิจิทัลบนบางส่วนของ HTTP request หรือ response client จะเลือกคอมโพเนนต์ที่จะครอบคลุม (เช่น method, target URI, authority และ headers ที่เลือก), สร้าง canonical signature base จากคอมโพเนนต์เหล่านั้น และเซ็นด้วย private key ผลลัพธ์จะถูกส่งไปในสอง headers: Signature-Input (Section 4.1), ซึ่งระบุรายการคอมโพเนนต์ที่ครอบคลุมและพารามิเตอร์เช่น created, expires, keyid และ alg, และ Signature (Section 4.2), ซึ่งบรรทุกค่าลายเซ็นโดยตรง ทั้งสองใช้ Structured Field Values syntax ของ RFC 9651

ผู้รับจะสร้าง signature base เดียวกันขึ้นมาใหม่ (Section 2.5) จาก request ที่ได้รับจริง ค้นหา public key ที่อ้างอิงโดย keyid และตรวจสอบลายเซ็น หากสิ่งใดก็ตามที่ลายเซ็นครอบคลุมเปลี่ยนไประหว่างทาง การตรวจสอบจะล้มเหลว

เหตุผลที่มีความสำคัญต่อ apps, APIs และ MCP servers

ทราฟฟิกอัตโนมัติส่วนใหญ่ระบุตัวเองด้วย user-agent string หรือชื่อ client ที่ตั้งเอง ซึ่งทั้งสองอย่างคัดลอกได้ง่ายมาก message signature แตกต่างออกไปตรงที่มันผูก request เข้ากับ key และมีเพียงผู้ถือ private key เท่านั้นที่สร้างลายเซ็นที่ถูกต้องได้ สำหรับ application ที่รับทราฟฟิกจาก crawlers, assistants และ autonomous agents สิ่งนี้เปลี่ยน "client นี้บอกว่ามันคือ X" ให้เป็น "request นี้ถูกเซ็นโดย key ที่ X เผยแพร่"

ความแตกต่างนั้นคือพื้นฐานของการปฏิบัติต่อ automated clients ที่ทำงานร่วมกันในฐานะผู้เข้าร่วมที่รู้จัก แทนที่จะเป็นทราฟฟิกนิรนาม มันช่วยให้ API ส่ง signed crawler ไปยัง structured endpoint, ใช้ rate limit แบบต่างออกไปกับ operator ที่รู้จัก หรือให้ MCP server มีบริบทมากขึ้นว่าใครเป็นผู้เรียก tool

วิธีการตรวจสอบในทางปฏิบัติ

1. parse Signature-Input และ Signature และยืนยันว่าครอบคลุมคอมโพเนนต์ที่คาดไว้ signature ที่ครอบคลุมสิ่งที่ไม่มีประโยชน์พิสูจน์อะไรได้ไม่มาก
2. ตรวจสอบพารามิเตอร์ created และ expires เพื่อปฏิเสธ request ที่ล้าสมัยหรือถูก replay ภายในขอบเขตที่คุณยอมรับได้ (ดู Section 7.2.2 เกี่ยวกับ signature replay)
3. resolve keyid ไปยัง public key จากแหล่งที่คุณไว้วางใจ เช่น key directory ที่ operator เผยแพร่ไว้ในตำแหน่งที่ทราบได้ IETF Web Bot Auth protocol draft กำหนด key directory ลักษณะนี้สำหรับ automated clients
4. สร้าง signature base ใหม่ให้ตรงตามข้อกำหนดทุกประการ และตรวจสอบด้วยอัลกอริทึมที่ประกาศไว้
5. บันทึกว่าสิ่งใดได้รับการยืนยันและในบริบทใด เพื่อให้การตัดสินใจในภายหลังอ้างอิงกลับไปได้

ใน production ควรใช้ implementation ของ RFC 9421 ที่ดูแลรักษาอยู่ แทนการ parse เองด้วยมือ เพราะรายละเอียดของ canonicalization ทำให้ผิดพลาดได้ง่าย คู่มือเรื่อง วิธีตรวจสอบ signed AI agent requests จะไล่ทุกขั้นตอนพร้อมโค้ด

ลายเซ็นที่ถูกต้องพิสูจน์อะไรได้และพิสูจน์อะไรไม่ได้

ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่า request ถูกเซ็นโดย key และหาก key นั้นถูกเผยแพร่ภายใต้โดเมน ก็พิสูจน์ได้ว่า request นั้นเกี่ยวข้องกับ operator ของโดเมนนั้น แต่ไม่ได้พิสูจน์ว่า:

• operator ซื่อสัตย์หรือการกระทำนั้นปลอดภัย,
• มีบุคคลสั่งหรืออนุมัติ request นั้นหรือไม่ (ดู delegated authority),
• client ได้รับอนุญาตให้ทำสิ่งที่กำลังขออยู่หรือไม่ (ดู agent authorization).

หลักฐานด้าน identity และ permission เป็นคนละคำถามกัน การยืนยันตัวตนและการกำหนดสิทธิ์ของ application ของคุณเองยังคงเป็นสิ่งที่ตัดสินได้ว่าลูกค้าทำอะไรได้บ้าง บล็อกโพสต์ของเราเรื่อง สิ่งที่ signed AI agent requests พิสูจน์ได้ และสิ่งที่พิสูจน์ไม่ได้ อธิบายเรื่องนี้ลึกขึ้น

ความเข้าใจผิดที่พบบ่อย

• "Signed หมายถึงน่าเชื่อถือ" Signed หมายถึงระบุที่มาได้ ความน่าเชื่อถือเป็นการตัดสินเชิงนโยบายที่คุณกำหนดต่อฝ่ายที่ระบุที่มาได้
• "ลายเซ็นมาแทน API keys" ทั้งสองตอบคำถามคนละแบบ API key บอกว่า account ใดเป็นผู้เรียก ส่วนลายเซ็นบอกว่า client ใดเป็นผู้สร้าง request การติดตั้งจำนวนมากได้ประโยชน์จากทั้งสองอย่าง
• "ทราฟฟิกที่ไม่มีลายเซ็นคือทราฟฟิกอันตราย" ทราฟฟิกอัตโนมัติส่วนใหญ่ในปัจจุบันไม่มีลายเซ็น การไม่มีลายเซ็นทำให้สิ่งที่ยืนยันได้ลดลงเท่านั้น ไม่มีมากไปกว่านั้น นั่นคือเหตุผลที่ Unknown เป็นผลลัพธ์ระดับแรก

Proof of Actor จัดการลายเซ็นอย่างไร

ใน Proof of Actor ลายเซ็นที่ตรวจสอบผ่านกับ public key ที่เผยแพร่จะถูกบันทึกด้วย basis เป็น verified โดยจำกัดขอบเขตไว้ตรงกับสิ่งที่การตรวจสอบยืนยันได้เท่านั้น คือ key และ identifier ที่เป็นเจ้าของ ผลลัพธ์ของ class ที่ได้ (โดยปกติคือ Agent) ไม่ได้หมายความถึง authorization เสมอไป ผลลัพธ์จะไหลเข้าสู่ Understand เพื่อการวิเคราะห์ และเข้าสู่ Route ซึ่งนโยบายของคุณจะตัดสินว่าผู้ใช้ที่เซ็นแล้วควรได้รับเส้นทางที่มีโครงสร้าง, limit ที่ต่างออกไป, หรือไม่มีการเปลี่ยนแปลงเลย มาตรฐาน signed-agent เช่น Web Bot Auth ยังพัฒนาอยู่ และ Proof of Actor ถูกออกแบบมาเพื่อตรวจสอบ request ที่เซ็นเมื่อมาตรฐานเหล่านี้เติบโตสมบูรณ์

อ่านเพิ่มเติมเกี่ยวกับ สิ่งที่ evidence ยืนยันได้ หรือ สมัครขอสิทธิ์เข้าถึงก่อน

แหล่งที่มา

• RFC 9421: HTTP Message Signatures: มาตรฐานของ IETF ที่กำหนด signature components, parameters และ verification
• RFC 9651: Structured Field Values for HTTP: syntax ของ Signature-Input และ Signature
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft ที่นำ RFC 9421 มาใช้กับ automated clients (อยู่ระหว่างดำเนินการ ณ เดือน November 2026)