Кратко

  • draft-deshpande-secevent-http-multi-set-push-03 проходит IESG Last Call до 23 сентября 2026 года. Это индивидуальный Internet-Draft в области безопасности, рассчитанный на статус Proposed Standard; окончательного одобрения нет.
  • Несколько SET можно поместить в один HTTPS POST. Получатель указывает идентификатор jti каждого события в ack либо setErrs. Ответ относится к приёму, разбору и проверке токена, а не к последующей блокировке или отзыву полномочий.
  • Для каждого события нужно отдельно подтвердить доставку, надёжное хранение, локальное сопоставление личности, решение, исполнение и наблюдаемый результат. HTTP 202 не объединяет эти этапы в одну завершённую операцию.

Сбой, который не виден в статистике запросов

Предположим, отправитель помещает шесть уведомлений об угрозе в один запрос. На пять идентификаторов приходит ack, на шестой — ошибка проверки. Отчёт, считающий только успешные HTTP-запросы, сообщит о полной доставке. Даже подтверждённая пятёрка, однако, может ожидать сопоставления с локальными пользователями и решения об отключении сессий. Это модельный пример для оценки протокола, а не сообщение о действительной аварии.

Смысл изменения понятен на фоне RFC 8935, который задаёт передачу одного SET в одном POST через TLS. При большом потоке событий отдельные запросы создают нагрузку и могут упереться в ограничения частоты. Новый проект определяет JSON-объект sets, где ключом служит jti токена; получатель возвращает массив ack и объект ошибок setErrs. Карточка IETF на 21 сентября показывает этап IESG Last Call и намерение выпустить Proposed Standard. Это не решение о публикации RFC и не сведения о внедрении в конкретной системе.

Граница подтверждения прописана в самом проекте. Получатель должен отразить каждый принятый jti в ack или setErrs; ошибки отдельного токена относятся к разбору и валидации. Проблему, возникшую позже в прикладной системе, через этот механизм сообщать нельзя. Следовательно, корректный 202 не доказывает, что чужой домен нашёл нужную учётную запись, признал событие достаточным основанием для действия и действительно отозвал доступ. Эти решения остаются у получателя.

Ответ также не обязательно касается именно последнего запроса. Пустой sets позволяет запросить отложенные подтверждения, а в новом ответе могут находиться jti из предыдущих передач. Сверка по номеру HTTP-вызова ненадёжна; нужна сверка по событию. После подтверждения отправитель не обязан хранить SET для повторной передачи. Если сохранность нужна для надёжности, ответственность переходит к получателю. Сам проект не определяет журнал последующего исполнения политики.

Для события, которое в разумный срок не оказалось ни в ack, ни в setErrs, рекомендуется повторная отправка; отправитель вправе ограничить число попыток. Подтверждённый или ошибочный jti отправлять снова нельзя. После ошибки для новой попытки потребуется новый SET с новым идентификатором. Защита от повторов на стороне получателя необязательна: уже встречавшийся идентификатор он может молча отбросить. Поэтому общий POST не даёт гарантии ровно одного прикладного действия.

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

RFC 9967 решает иную задачу: связывает асинхронный запрос SCIM с более поздним событием. Multi-SET описывает групповой транспорт и отдельные подтверждения. Ни одна из этих схем не передаёт отправителю власть над учётными записями другого домена.

Источники

Текущее состояние проекта IETF; текст версии 03; RFC 8935; RFC 8417; RFC 9967.