Кратко

  • В IETF Datatracker заявка AUDIT BoF обозначена как Declined. Созданный 31 августа 2026 года список non-WG позволяет переработать возможный BoF и проект устава, но не учреждает Working Group.
  • IESG признала содержательность проблемы аудита действий агентов, сочла предложенный охват слишком широким и запросила точный анализ пробелов относительно OAuth, WIMSE, OpenTelemetry и смежных работ.
  • Индивидуальный проект архитектуры разделяет записи взаимодействия, действия, делегирования и перехода авторизации, однако не решает отказ сервиса от записи, всеобщий сговор, выравнивание модели и пока не содержит подробной модели угроз.
  • Публичная квитанция о состоянии полномочий должна раздельно показывать форум, решение по BoF, устав, принятие draft, рецензирование IETF, выпуск RFC и эксплуатацию.

Новая точка входа не переписывает прежнее решение

31 августа Секретариат IETF объявил о создании списка AUDIT. Участники получили устойчивое место, где можно сузить тему, разобрать пересечения и подготовить более убедительный устав. Это реальный институциональный шаг, но его предмет — канал общения, а не одобрение старой заявки.

Заявка AUDIT BoF версии 02 по-прежнему имеет тип «Declined BOF request» и состояние «Declined». Общий указатель заявок BoF показывает то же. Последнее обновление датировано 6 июля, ответственное руководство не указано. Security Area Directors и Yaroslav Rosomakho названы в тексте как предполагаемые AD и chair. Предложение кандидатуры не равнозначно назначению.

Сам список также не претендует на большее. В указателе списков non-WG его задача сформулирована как обсуждение потенциального AUDIT BoF, обновление предлагаемого устава и движение к формированию новой WG. На дату отсечения открытый архив содержит только объявление. Будущее время здесь точно отражает предел полномочий.

Рекомендации для списков non-WG специально допускают списки, предназначенные для подготовки WG. Соответствующий Area Director одобряет запрос на создание списка. Такое одобрение предоставляет средство коммуникации, но не BoF, устав, milestones или назначенных chairs.

RFC 2418 описывает рабочую группу иначе: узкий устав, ответственные Area Directors, назначенные председатели и определённый процесс. Каждой WG нужен список рассылки, однако обратный вывод неверен. Наличие обязательного атрибута группы не создаёт саму группу.

Почему «deferred» и «Declined» не надо склеивать

В ответе IESG от 3 июня использовалось слово “deferred”. Его текст сохранился в ответном письме инициаторов от 5 июня. Идею аудита действий агентов там назвали хорошей, но нынешнее предложение — чрезмерно широким. Авторам предложили сузить предмет, поговорить с участниками OAuth и WIMSE и показать, почему имеющиеся работы либо профиль OpenTelemetry не заполняют пробел. Некоторые понятия намерения и политики, по мнению авторов ответа, могли лучше относиться к правовой, а не протокольной рамке IETF.

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

Корректная история сохраняет “deferred” как лексику июньского сообщения и “Declined” как текущую запись Datatracker. У каждого слова есть дата, источник и компетентный субъект. Новая заявка в будущем может получить другое состояние; нынешний отказ не предсказывает вечную судьбу идеи.

Здесь проявляется ошибка, о которой Heng Lu пишет в эссе о мираже многосторонней модели: присутствие и участие сами по себе не указывают принципала и не доказывают поручение. Фраза «обсуждается в IETF» не должна превращаться в «одобрено IETF».

Четыре семейства записей для распределённой ответственности

Индивидуальный проект архитектуры AUDIT от 18 мая ставит практическую задачу. Человек поручает работу агенту; агент делегирует, вызывает сервисы в разных доменах доверия, получает дополнительные разрешения и вызывает эффект. Локальные журналы могут быть точны, но не соединять исходное намерение, переданное полномочие, изменение авторизации и действие.

Проект выделяет четыре семейства. Interaction Records сохраняют пользовательские запросы, ответы и подтверждения как свидетельства намерения. Action Records фиксируют событие на границе выполнения. Delegation Records описывают переданные полномочия, их объём и ограничения. Authorization Transition Records показывают первоначальную выдачу, step-up, сужение, отзыв и истечение.

Общий audit context может переносить корреляционные идентификаторы и ссылки на прежние события. Каждый субъект создаёт собственную перспективу, а частично доверенный audit store приводит материал к общему виду для аудитора. Attestation и transparency могут усиливать отдельные утверждения. Такое разделение не позволяет считать запрос, разрешение и результат одной строкой журнала.

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

Богатый аудит создаёт собственный риск. Interaction Records раскрывают prompts и цели, Action Records — инструменты, операции и контрагентов, а глобальный идентификатор связывает человека между организациями. Даже помещение одного hash в transparency service выдаёт факт события в определённое время. Полнота полезна аудитору и одновременно привлекательна для наблюдения.

Индивидуальный draft о проверяемых разговорах агентов предлагает возможный формат пользовательского свидетельства. Его не принимала AUDIT WG, поскольку такой WG нет. Подпись разговора также не определяет минимизацию, редактирование, выборочное раскрытие, хранение и безопасное связывание с последующим действием.

Соседние механизмы не отвечают на один и тот же вопрос

Требование IESG изучить пересечения защищает архитектуру от ложной универсальности.

RFC 8693 OAuth Token Exchange выражает делегирование и цепочки actors при обмене токенов. Это важный фрагмент истории полномочий, но не полный исходный запрос человека, все переходы, результат и политическое суждение аудитора. Базовый протокол оставляет за рамками подробную семантику токенов, свойства безопасности и модели доверия.

W3C Trace Context передаёт идентификаторы, связывающие части распределённого запроса. Корреляция показывает принадлежность событий одному потоку, но не разрешение. Trace ID не доказывает сужение делегации, пользовательское согласие или правильность действия.

RFC 9334 и архитектура RATS задают Evidence, Verifier, Attestation Result и применение политики Relying Party. Это помогает оценить компонент или среду. Юридическая власть и смысловая верность человеческому намерению из этого не следуют. Исправная система способна безошибочно выполнить недозволенную команду.

RFC 9943 и архитектура SCITT описывают подписанные statements, append-only transparency services и receipts регистрации или включения. Они делают удаление и заднее редактирование заметнее, но не превращают утверждение в истину, не доказывают полноту и не создают разрешение.

Будущий scope должен распределить собственность: что остаётся у OAuth, WIMSE, Trace Context, RATS, SCITT, HTTP и observability, а какая междоменная связка никому не принадлежит. Не число упомянутых технологий, а точность остатка определит необходимость AUDIT.

Квитанция для процесса, который проектирует квитанции

Техническая идея пытается показать, кто разрешил действие агента. Институциональная запись должна показывать, кто разрешил каждый этап стандартизации. В обоих случаях venue, запись и receipt не являются полномочием, смысл которого они удостоверяют.

Authority-state receipt может начинаться со стабильного имени проблемы и точной версии. Состояние перечисляется как proposal, deferred/declined BoF, non-WG discussion, approved BoF, chartering, active WG или concluded. Рядом — субъект, компетентный создать состояние, дата, ссылка и точная формулировка решения.

Новая версия обязана показать scope delta: что убрали, что передали соседним группам и какой пробел остался. AD и chair до назначения остаются proposed. Venue отделяется от authority. Устав имеет принятую редакцию и дату либо null. Документ обозначается individual или WG-adopted с записью о принятии.

WG Last Call, IETF Last Call, IESG evaluation и нерешённые возражения — разные состояния. Publication различает Internet-Draft, stream и категорию RFC. Реализация и владелец эксплуатационной политики находятся в deployment. Так работающий draft не становится консенсусом, а опубликованный RFC — доказательством внедрения.

Поздний успех не переписывает прошлое. Одобренный новый BoF связывается с отклонённым и показывает решившую исход разницу. Принятый WG документ не делает ранние индивидуальные версии продуктами группы. Неизменность старого решения позволяет проследить появление мандата.

Сегодняшняя запись AUDIT выглядит так: индивидуальные drafts существуют; BoF request 02 получил критический ответ по scope; Datatracker показывает Declined; non-WG список готовит потенциальный BoF и charter; назначенного руководства, утверждённого устава, WG, принятия документов и консенсуса IETF нет.

Подотчётность не выдаёт разрешение на тотальную корреляцию

Пересмотренный проект должен минимизировать данные по каждому типу. Контент, которому не нужно пересекать границу, можно отделить, представить hash или раскрыть выборочно. Pairwise и opaque identifiers предпочтительнее глобальных, если универсальная связь не имеет отдельного разрешения. Техническая возможность объединения не равна праву объединять.

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

Новый список полезен именно до выдачи мандата. На нём можно разделить протокольные требования, deployment profiles, организационную политику и право; сделать privacy и threat model результатами будущего charter; сузить “intent” до технически проверяемого предмета. Точное слово «список» защищает эту работу от преждевременного бренда IETF.