HTTP Message Signatures (RFC 9421)

Что такое HTTP Message Signatures

HTTP Message Signatures определены в RFC 9421, стандарте IETF для создания и проверки цифровых подписей по частям HTTP-запроса или ответа. Клиент выбирает, какие компоненты включить в подпись, например метод, целевой URI, authority и выбранные заголовки, строит из них каноническую базу подписи и подписывает ее закрытым ключом. Результат передается в двух заголовках: Signature-Input (Section 4.1), который перечисляет включенные компоненты и параметры, такие как created, expires, keyid и alg, и Signature (Section 4.2), который содержит само значение подписи. Оба используют синтаксис Structured Field Values из RFC 9651.

Получатель воссоздает ту же базу подписи (Section 2.5) из фактически полученного запроса, находит открытый ключ, указанный в keyid, и проверяет подпись. Если в пути передачи что-то из того, что покрыто подписью, изменилось, проверка не проходит.

Почему это важно для приложений, API и MCP server

Большая часть автоматизированного трафика идентифицирует себя строкой user-agent или самостоятельно выбранным именем клиента. Оба варианта легко подделать. Подпись сообщения работает иначе: она связывает запрос с ключом, и только владелец закрытого ключа может создать действительную подпись. Для приложения, которое получает трафик от сканеров, ассистентов и автономных агентов, это превращает утверждение «этот клиент говорит, что он X» в «этот запрос подписан ключом, который публикует X».

Это различие лежит в основе отношения к сотрудничающим автоматизированным клиентам как к известным участникам, а не как к анонимному трафику. Оно позволяет API направить подписанный сканер на структурированный endpoint, применить иной rate limit к известному оператору или дать MCP server больше контекста о том, кто вызывает инструмент.

Как работает проверка на практике

1. Разберите Signature-Input и Signature и убедитесь, что покрыты ожидаемые компоненты. Подпись, которая не покрывает ничего полезного, мало что доказывает.
2. Проверьте параметры created и expires, чтобы отклонить устаревшие или повторно воспроизведенные запросы в пределах допустимого окна (см. Section 7.2.2 о повторном использовании подписи).
3. Разрешите keyid в открытый ключ из источника, которому вы доверяете, например из каталога ключей, который оператор публикует по известному адресу. Черновик протокола IETF Web Bot Auth определяет такой каталог для автоматизированных клиентов.
4. Воссоздайте базу подписи в точности по спецификации и проверьте ее с заявленным алгоритмом.
5. Зафиксируйте, что было проверено и в каком контексте, чтобы позже на это можно было опираться при принятии решений.

В production используйте поддерживаемую реализацию RFC 9421, а не самописный парсинг: детали canonicalization легко реализовать неверно. Руководство как проверять подписанные запросы AI-агента пошагово разбирает процесс с кодом.

Что действительная подпись подтверждает, а что нет

Действительная подпись подтверждает, что запрос был подписан ключом, а если ключ опубликован под доменом, то и то, что запрос связан с оператором этого домена. Она не подтверждает:

• что оператор действует добросовестно или что действие безопасно,
• что человек дал указание на этот запрос или одобрил его (см. делегированные полномочия),
• что клиенту разрешено делать то, о чем он просит (см. авторизация агента).

Сведения об идентичности и разрешение на действие - это разные вопросы. Собственная аутентификация и авторизация вашего приложения по-прежнему определяют, что может делать клиент. Наш пост в блоге что подтверждают подписанные запросы AI-агента и чего они не подтверждают разбирает это подробнее.

Распространенные заблуждения

• "Подписано значит доверено." Подписано значит можно атрибутировать. Доверие - это решение по политике, которое вы принимаете в отношении атрибутированной стороны.
• "Подписи заменяют API keys." Они отвечают на другой вопрос. API key говорит, какая учетная запись делает вызов; подпись говорит, какой клиент сформировал запрос. Во многих развертываниях полезны оба механизма.
• "Неподписанный трафик - это вредоносный трафик." Сегодня большая часть автоматизированного трафика не подписана. Отсутствие подписи лишь уменьшает то, что можно установить, и не более того. Именно поэтому Unknown - это результат первого класса.

Как Proof of Actor обрабатывает подписи

В Proof of Actor подпись, которая проходит проверку по опубликованному ключу, записывается с основанием Verified и строго в рамках того, что установила проверка: ключ и идентификатор, которому он принадлежит. Полученная категория, обычно Agent, никогда не означает авторизацию. Результаты поступают в Understand для анализа и в Route, где ваши собственные политики определяют, получит ли подписанный клиент структурированный путь, другой лимит или не изменится ничего. Стандарты для подписанных агентов, такие как Web Bot Auth, продолжают развиваться, и Proof of Actor рассчитан на проверку подписанных запросов по мере их зрелости.

Подробнее см. что может установить evidence, или подайте заявку на ранний доступ.

Источники

• RFC 9421: HTTP Message Signatures: стандарт IETF, определяющий компоненты подписи, параметры и проверку
• RFC 9651: Structured Field Values for HTTP: синтаксис Signature-Input и Signature
• draft-ietf-webbotauth-httpsig-protocol: черновик IETF Web Bot Auth, применяющий RFC 9421 к автоматизированным клиентам (work in progress as of November 2026)