HTTP Message Signatures (RFC 9421)

HTTP Message Signatures là gì

HTTP Message Signatures được định nghĩa trong RFC 9421, một tiêu chuẩn IETF để tạo và xác minh chữ ký số trên một phần của HTTP request hoặc response. Client chọn các thành phần cần bao phủ (ví dụ method, target URI, authority và các header được chọn), xây dựng một canonical signature base từ chúng, rồi ký bằng private key. Kết quả được truyền trong hai header: Signature-Input (Section 4.1), header này liệt kê các thành phần được bao phủ và các tham số như created, expires, keyid và alg, và Signature (Section 4.2), header này mang chính giá trị chữ ký. Cả hai đều dùng cú pháp Structured Field Values của RFC 9651.

Bên nhận tái tạo cùng một signature base (Section 2.5) từ request mà nó thực sự nhận được, tra public key được tham chiếu bởi keyid, rồi kiểm tra chữ ký. Nếu bất kỳ phần nào được chữ ký bao phủ bị thay đổi trên đường truyền, việc xác minh sẽ thất bại.

Vì sao chúng quan trọng với app, API và MCP server

Phần lớn lưu lượng tự động tự nhận diện bằng user-agent string hoặc một tên client do chính nó chọn. Cả hai đều rất dễ sao chép. Message signature thì khác: nó gắn request với một khóa, và chỉ bên giữ private key mới có thể tạo chữ ký hợp lệ. Với một ứng dụng nhận traffic từ crawler, assistant và autonomous agent, điều đó biến "client này nói nó là X" thành "request này đã được ký bởi khóa mà X công bố".

Sự khác biệt đó là nền tảng để xem các client tự động hợp tác như những bên tham gia đã biết thay vì lưu lượng ẩn danh. Nó cho phép một API định tuyến crawler đã ký đến một endpoint có cấu trúc, áp dụng rate limit khác cho một operator đã biết, hoặc cung cấp cho một MCP server thêm ngữ cảnh về người đang gọi một tool.

Việc xác minh hoạt động trong thực tế như thế nào

1. Phân tích Signature-Input và Signature rồi xác nhận các thành phần mong đợi đã được bao phủ. Một chữ ký không bao phủ điều gì hữu ích thì chứng minh rất ít.
2. Kiểm tra các tham số created và expires để từ chối request cũ hoặc bị phát lại trong mức dung sai của bạn (xem Section 7.2.2 về signature replay).
3. Giải quyết keyid thành một public key từ nguồn bạn tin cậy, chẳng hạn một key directory do operator công bố tại một vị trí đã biết. IETF Web Bot Auth protocol draft định nghĩa một directory như vậy cho client tự động.
4. Tái tạo signature base đúng như đặc tả và xác minh nó bằng thuật toán đã khai báo.
5. Ghi lại những gì đã được xác minh và trong ngữ cảnh nào, để các quyết định sau này có thể tham chiếu đến nó.

Trong môi trường production, hãy dùng một implementation RFC 9421 được duy trì thay vì tự viết parsing: các chi tiết canonicalization rất dễ làm sai. Hướng dẫn về cách xác minh signed AI agent requests sẽ đi qua từng bước kèm code.

Một chữ ký hợp lệ chứng minh gì và không chứng minh gì

Một chữ ký hợp lệ chứng minh rằng request đã được ký bằng một khóa, và nếu khóa đó được công bố dưới một domain, thì request gắn với operator của domain đó. Nó không chứng minh:

• rằng operator trung thực hoặc hành động là an toàn,
• rằng một người đã chỉ đạo hoặc phê duyệt request (xem delegated authority),
• rằng client được phép làm điều mà nó đang yêu cầu (xem agent authorization).

Bằng chứng danh tính và quyền hạn là hai câu hỏi riêng biệt. Cơ chế authentication và authorization của chính ứng dụng bạn vẫn quyết định client có thể làm gì. Bài viết trên blog của chúng tôi về signed AI agent requests chứng minh gì, và không chứng minh gì trình bày sâu hơn về điều này.

Những hiểu lầm phổ biến

• "Đã ký nghĩa là đáng tin." Đã ký nghĩa là có thể quy trách nhiệm. Việc có tin hay không là một quyết định chính sách bạn đưa ra đối với bên được quy trách nhiệm.
• "Chữ ký thay thế API key." Chúng trả lời một câu hỏi khác. API key cho biết tài khoản nào đang gọi; chữ ký cho biết client nào đã tạo ra request. Nhiều triển khai sẽ có lợi khi dùng cả hai.
• "Lưu lượng không có chữ ký là độc hại." Phần lớn lưu lượng tự động hiện nay không có chữ ký. Thiếu chữ ký chỉ làm giảm những gì có thể xác định được, không hơn. Đó là lý do Unknown là một kết quả cấp một.

Proof of Actor xử lý chữ ký như thế nào

Trong Proof of Actor, một chữ ký xác thực thành công đối với một public key đã công bố sẽ được ghi nhận với basis là verified, giới hạn đúng vào những gì phép kiểm tra đã xác lập: khóa và định danh mà nó thuộc về. Class kết quả (thường là Agent) không bao giờ hàm ý quyền hạn. Kết quả đi vào Understand để phân tích và vào Route, nơi các chính sách của bạn quyết định một client đã ký có được một đường đi có cấu trúc, một giới hạn khác, hay hoàn toàn không thay đổi. Các tiêu chuẩn signed-agent như Web Bot Auth vẫn đang phát triển, và Proof of Actor được thiết kế để xác minh các request đã ký khi chúng trưởng thành hơn.

Đọc thêm về bằng chứng có thể xác lập điều gì, hoặc đăng ký quyền truy cập sớm.

Nguồn

• RFC 9421: HTTP Message Signatures: tiêu chuẩn IETF định nghĩa các thành phần chữ ký, tham số và việc xác minh
• RFC 9651: Structured Field Values for HTTP: cú pháp của Signature-Input và Signature
• draft-ietf-webbotauth-httpsig-protocol: bản nháp IETF Web Bot Auth áp dụng RFC 9421 cho client tự động (đang trong quá trình phát triển tính đến tháng 11 năm 2026)