Кратко

  • Ответ 202 в draft-deshpande-secevent-http-multi-set-push-03 может подтвердить часть jti, отклонить другие через setErrs и сообщить результаты прежних запросов. Код относится к принятому конверту, а не к завершению всего пакета.
  • Документ является индивидуальной заявкой при поддержке Area Director и находится на Last Call до 23 сентября 2026 года. У него нет статуса рабочей группы, подтверждённой реализации, одобрения IESG, номера RFC или завершённой регистрации IANA.

В одном POST отправлены четыре Security Event Token. Сервер отвечает 202, но в теле три идентификатора находятся в ack, четвёртый — в setErrs, а ещё один результат может относиться к вчерашней передаче. Даже подтверждённый токен не доказывает, что нижестоящая система закрыла сессию или изменила состояние учётной записи.

Так устроена редакция 03 HTTP Push Delivery of Multiple Security Event Tokens. Она снижает транспортные издержки, не создавая транзакцию. Поэтому превращение 202 в отметку «пакет выполнен» уничтожает различия, которые спецификация сохраняет намеренно.

Единица сверки — jti

Тип application/secevents+json содержит объект sets, где ключами служат jti токенов. Получатель проверяет каждый SET отдельно. В ответе 202 обязателен массив ack, а ошибки по идентификаторам могут появиться в setErrs. Пример проекта совмещает подтверждения и ошибку в одном принятом ответе.

Ответ не ограничен текущим POST. Получатель может вернуть результат прежнего SET, а отправитель — послать пустой sets, чтобы запросить отложенные результаты. Подтверждение неизвестного идентификатора следует игнорировать. Значит, сверять нужно событие, а не только HTTP-вызов.

Неподтверждённый SET повторяется до подтверждения, отдельной ошибки или предела попыток. Локальные ограничения времени и хранилища могут привести к удалению недоставленного события. Эти решения невозможно вывести из первоначального 202.

Доставка не равна действию

Подтверждение означает получение, разбор и проверку, но не последующее деловое действие. RFC 8935 разделяет доставку и дальнейшую обработку, а RFC 8417 описывает SET как утверждение о факте, а не команду.

RFC 9110 определяет 202 как запрос, принятый к обработке, но ещё не завершённый; обработка может вообще не состояться. Multi-SET Push добавляет сведения по элементам внутри этого открытого ответа, не меняя семантику HTTP.

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

Точная граница этапа IETF

Datatracker показывает редакцию 03 как активный индивидуальный Internet-Draft в Security Area с предполагаемым статусом Proposed Standard. Last Call начался 26 августа и завершается 23 сентября. Working Group state — None, telechat не назначен.

В записи shepherd сказано, что SECEVENT уже завершился, а энергии для повторного создания группы не хватило. Поэтому документ идёт как AD-sponsored individual submission под ответственностью Deb Cooley. Это не свидетельство технического конфликта, но и не консенсус рабочей группы.

Security Directorate оценил текст как Ready, предложив небольшую правку. Подтверждённых реализаций нет; намерение включить механизм в OpenID Shared Signals Framework не является доказательством внедрения. Действия IANA зависят от будущего одобрения. Last Call — не одобрение IESG и не RFC.

Квитанция, пригодная для аудита

Daniel Kade предлагает сохранять для каждого jti исходный запрос и время, точное подтверждение или ошибку, связь с прежним запросом, число попыток, следующее решение и причину окончательного удаления. К ним нужно добавить версию конфигурации получателя, время проверки и состояние «применено», «отклонено» или «ожидает» в последующей системе.

Это редакционная модель управления, а не требование IETF. Она позволяет агрегировать данные, не теряя путь к отдельному событию. 202 доказывает принятие конверта; только цепочка jti показывает, что произошло дальше.

Источники