Кратко

  • Редакция 07 использует ключ cnf.jwk из Workload Identity Token, чтобы подписать метод, путь, запрос, аудиторию, выбранные заголовки, digest содержимого и параметры подписи. Это аутентифицирует покрытое представление запроса, но не разрешает операцию.
  • Промах локального nonce-кэша не доказывает новизну во всём кластере. Удаление подписи ответа обнаружимо только тогда, когда клиент потребовал её в собственном подписанном запросе. Идентичность, replay, авторизация, исполнение и итог — разные квитанции.

Два честных валидатора

Запрос приходит на узел A. WIT действителен, связанный в cnf.jwk ключ проверяет подпись, Content-Digest совпадает с полученным телом, wimse-aud указывает нужный workload, а nonce отсутствует в локальной памяти. A принимает запрос и сохраняет значение.

Через секунды те же байты поступают на B до истечения expires. B не делит кэш с A. Подпись по-прежнему верна, а nonce для B новый. Оба результата истинны, поскольку описывают разные области состояния.

Затем возникают другие вопросы: разрешено ли этому principal выполнить действие над данным ресурсом? Зафиксировало ли приложение изменение? Сведение их к authenticated=true превращает ограниченное доказательство в полномочие, которого протокол не выдавал.

draft-ietf-wimse-http-signature-07 представлен 20 сентября 2026 года. В заголовке указан целевой Standards Track и срок действия до 24 марта 2027 года. Документ не является RFC. Это активный Internet-Draft рабочей группы, а не обязательное развёртывание, показатель распространения или подтверждение продукта. Перечень реализаций фиксирует экспериментальный код, не производственную перепись.

Что именно покрывает подпись

Профиль основан на RFC 9421. Запрос обязательно включает @method, @path и @query. При наличии также покрываются Content-Type, Content-Digest, Authorization, Txn-Token и Workload-Identity-Token. Для сообщения с телом получатель заново вычисляет Content-Digest по фактически принятым байтам.

Подписать текст digest-поля недостаточно: без пересчёта он не связан с содержимым. RFC 9530 задаёт смысл поля, а повторное вычисление замыкает связь. Полноценная квитанция хранит восстановленную базу подписи, список компонентов, вычисленный digest и решение верификатора.

Параметры включают created, короткий expires, случайный nonce и тег wimse-workload-to-workload; запрос добавляет wimse-aud. Параметры keyid и alg не применяются: ключ и алгоритм берутся из cnf.jwk WIT. Локальная политика всё равно должна разрешить алгоритм для данного домена доверия.

Несколько подписей с WIMSE-тегом означают отказ, а не выбор удобной. Иначе отправитель, прокси и приложение могли бы ссылаться на разные представления и называть каждое «подписанным запросом».

Непокрытое поле остаётся изменяемым. Если посредник подписывает сообщение заново, возникает новое утверждение нового principal; первая подпись не получает расширенную область задним числом.

Логическая аудитория вместо неизменной authority

@authority не входит в обязательный набор, поскольку TLS-терминирующие прокси и балансировщики меняют его. Привязка получателя переносится в подписанный wimse-aud.

Так разделяются три факта: идентичность TLS-сервиса по RFC 9525, authority на конкретном HTTP-переходе и логическая аудитория WIMSE. Канал может быть правильным, а правило аудитории слишком широким. Подпись может быть верна, а принимающий сервис — отклонить аудиторию.

След должен содержать ожидаемое имя сервиса, предъявленную идентичность, точку завершения TLS, отправленную аудиторию, её интерпретацию и конечный сервис. Одно слово «аутентифицировано» скрывает переход, на котором изменился смысл.

Владение ключом не создаёт мандат

Получатель сначала проверяет WIT, затем подпись связанным ключом. Успех означает, что обладатель соответствующего приватного ключа сформировал покрытые компоненты при допустимых временных и политических условиях.

Это не доказывает намерение, эксклюзивное хранение ключа в одном живом экземпляре или бизнес-роль. Главное — это не авторизует действие. Редакция 07 прямо выводит всю подсистему авторизации за пределы своего предмета и считает её доверенной предпосылкой.

Следовательно, нужна настоящая граница. Аутентификация передаёт principal и запрос. Первый компонент, который знает окончательные действие и ресурс и ещё способен остановить эффект, сопоставляет principal, действие, ресурс, контекст и версию политики.

Квитанция авторизации содержит правило, решение, обязательства, исключение и время. Если шлюз даёт всем WIT из домена доверия широкую роль, власть создала конфигурация шлюза. Именно её утверждение и история являются доказательством.

У replay есть топология

created и expires сужают окно, но не мешают повторной подаче внутри него. Nonce помогает только при наличии памяти о первом появлении. Draft позволяет replay-кэш и рекомендует отклонять известные значения, но не требует общего кэша у валидаторов. Из-за сложности распределённой синхронизации строгая защита не объявлена гарантированной целью протокола.

Поэтому промах означает лишь отсутствие значения в этой памяти, в её области и сроке хранения. Он не доказывает, что другой узел или резервный регион не принял запрос, старая запись не истекла или приложение не совершило эквивалентную операцию под другой ID.

Для идемпотентного чтения компромисс может быть разумным. Для списания, выпуска, удаления или управляющей команды нужен дополнительный барьер приложения: idempotency key, уникальное транзакционное ограничение или журнал commit. Надпись «replay-защита включена» без области кэша, retention и поведения failover ничего не гарантирует.

Надёжная подпись ответа начинается с требования клиента

Сервер может подписывать ответы. Сильная гарантия возникает, когда клиент включает wimse-sign-response=true в подписанные параметры запроса. Если сервер не может подписать, он не должен заменять это обычным успешным ответом; клиент обязан отвергнуть ответ без подписи.

Каждый подписанный ответ содержит wimse-req-nonce, равный nonce запроса. Это связывает покрытое представление ответа с конкретным вызовом.

Если клиент не потребовал подпись, внутренняя политика сервера не создаёт той же защиты от удаления. Посредник может снять подпись, а клиент должен принять обычный ответ. «Сервер подписывает» — заявление о возможности. «Клиент потребовал и проверил ответ, связанный с nonce» — квитанция транзакции.

Даже она не доказывает окончательный результат. Аутентичный ответ может означать только приём асинхронной задачи, которая позже завершится ошибкой.

Авторизация должна следовать за последним смысловым преобразованием

Посредники завершают TLS, нормализуют, маршрутизируют, декодируют и иногда подписывают заново. Изменение покрытого поля ломает подпись; непокрытое может меняться. Если шлюз разрешает POST /jobs, а приложение позже выбирает счёт по неподписанному заголовку, решение принято слишком рано.

Надёжный след связывает входную проверку, правило трансформации, идентичность новой подписи, разницу покрытия и последующую авторизацию. Не требуется замораживать каждый HTTP-байт. Требуется определить, кто меняет значения, определяющие эффект.

Получается шесть квитанций: WIT и отпечаток ключа; база подписи и пересчитанный digest; nonce, валидатор и область памяти; principal, действие, ресурс и политика; идемпотентность и commit; независимое наблюдение результата. Они могут расходиться. Верная подпись может быть replay, новый запрос — запрещён, разрешённая операция — не выполнена, commit — компенсирован.

Именно расхождение делает ответственность видимой. Приложение в appendix или заявление о совместимости доказывает способность. О работающем коде говорят capture, восстановленная база, решение по WIT, топология кэша, лог авторизации и переход состояния. Поскольку draft изменится, архитектурная запись должна фиксировать редакцию и локальные отклонения.

Источники