Кратко

  • В первом индивидуальном Internet-Draft AAuth Events от 28 сентября 2026 года ресурс может отправить подписанное асинхронное событие постоянному посреднику агента — Agent Provider (AP).
  • Ответ HTTP 202 допускается лишь после долговременной записи принятого события у AP. Он не доказывает, что агент получил, проверил или использовал сообщение до истечения срока действия токена.

Контрольная сумма body_s256 совпала, подпись верна, посредник ответил 202. Кажется, инцидент с пропущенным уведомлением исключен. Однако ни одна из этих проверок не показывает, сколько времени сообщение пролежало после приема и успел ли агент открыть его до окончания допустимого окна. Именно несовпадение целостности и своевременности делает первый проект AAuth Events вопросом управления, а не только форматом передачи событий.

Dick Hardt датировал индивидуальную версию -00 28 сентября 2026 года. Намерение идти по пути Standards Track не означает утвержденный RFC или принятие рабочей группой. На момент проверки IETF Datatracker подтверждал существование проекта, а не результаты эксплуатации службы доставки. Документ дополняет отдельный проект протокола AAuth, который описывает действия агента от имени человека у ресурса. Новая задача возникает позже: ресурс хочет сообщить об изменении агенту, который может быть отключен или не имеет публичного адреса для входящего вызова.

Агент подписывается на события ресурса. После события ресурс формирует подписанный токен с телом сообщения и отправляет его AP. Посредник проверяет подпись ресурса, назначенного получателя, наличие действующей подписки и соответствие тела значению body_s256. Он может определять повторные события по паре издатель-идентификатор. Так устанавливаются условия приема на первом участке пути. Даже безупречная проверка не говорит, что запущен процесс агента или что он увидел содержимое.

Для ответа 202 Accepted проект ставит конкретное условие: AP сначала должен надежно записать принятое событие для последующей передачи. Мгновенное подтверждение после чтения сетевого пакета, но до долговременного хранения, не соответствует описанному поведению. Ресурс получает весомое свидетельство передачи события на хранение, однако только посреднику. Способ доставки от AP к агенту зависит от платформы и находится за пределами проекта. Общей очереди повторов, унифицированной квитанции агента и сквозной гарантии исполнения этот текст не создает.

У токена события есть срок действия. Когда агент наконец получает сообщение, он должен проверить токен, адресата, хеш тела и собственный контекст. Нельзя действовать на основании просроченного токена или неверного тела. Представим сигнал о возможности изменить заказ, действующий недолго. AP получает его вовремя и хранит без искажения; агент подключается лишь после окончания срока. У посредника есть правильная запись и у ресурса есть правильный ответ, но у агента уже нет основания для действия. Это модельный пример, а не сообщение о фактическом сбое. Сохранность записи не равна сохранности возможности.

Сам проект прямо ограничивает защиту body_s256: значение помогает обнаружить замену или изменение тела у AP, но не мешает AP скрыть или задержать событие. Задержка может возникнуть из-за отказа сети, загруженной очереди или особенностей пробуждения агента, без всякого злого умысла. Поздний, но неизменный текст остается поздним. И наоборот, своевременное попадание к агенту еще не означает, что тот признал событие относящимся к задаче или совершил действие. Следовательно, «принято», «доставлено», «проверено» и «исполнено» — разные утверждения с разными доказательствами.

Постоянно доступный почтовый ящик также меняет картину приватности. AP видит, на какие ресурсы подписаны его агенты, и видит тела событий. Проект отмечает расхождение с попыткой основного протокола AAuth не раскрывать посреднику сведения о том, какими ресурсами пользуется человек. Это не обвинение конкретной внедренной службы в наблюдении за пользователями. Но нельзя одновременно предполагать, что AP принимает содержательные события, и без дополнительного механизма объявлять его слепым к связям и тексту. Минимизация тела, управление доступом и срок хранения требуют собственных решений владельца системы.

Поэтому полезнее проверять не только правильность криптографического конверта, но и цепочку ответственности. Что именно ресурс может доказать после 202? Какая платформа доставляет сообщение агенту и как фиксирует результат? Что происходит, если срок токена истек на этом участке? Что AP узнает о подписках и содержании ради доступности? Первый проект определяет надежный прием, но не подменяет ответами остальные пункты. Пока текст остается черновиком, тем более нельзя приписывать ему свойства утвержденной или проверенной службы.

Источники