Кратко

  • Первую версию проекта Steven Mih о Disclosure Envelope объявили 27 сентября. Это индивидуальный Internet-Draft без одобрения IETF и без формального статуса стандарта.
  • Предлагаемая оболочка добавляет к неизменной подписанной Agent Action Capsule исходный ввод или вывод агента по выбору отправителя. Проверять саму капсулу и соответствие каждого раскрытого значения прежнему хешу следует независимо.
  • Совпавший хеш подтверждает связь с ранее зафиксированным значением, но не истинность содержания, не полномочие на раскрытие и не тайну данных после отправки.

Подписанный след действия агента может быть доступен нескольким проверяющим. Одному достаточно убедиться, что запись существовала; другому нужно прочитать то, что агент получил на входе. Если ради второго переписать первоначальный документ, исчезнет неизменность общего следа. Если просто переслать текст отдельно и назвать его «подтверждённым», исчезнет проверка связи с этим следом. Это не описание реального расследования, а задача, которую ставит опубликованный 27 сентября проект draft-mih-agent-disclosure-envelope-00.

Автор документа Steven Mih опирается на собственное предложение Agent Action Capsule. Datatracker относит новый текст к активным индивидуальным проектам и прямо предупреждает: IETF его не одобрила, формального положения в процессе стандартизации у него нет. В базовой модели поля agent_input_digest и agent_output_digest содержат SHA-256 от значений JSON, приведённых к канонической форме по RFC 8785. Самих читаемых исходных данных в этих полях подписанной капсулы нет. Последующее раскрытие не следует описывать так, будто исходный текст всё время находился внутри подписанной записи.

Новая оболочка содержит исходную капсулу и соседний, необязательный объект disclosures. В первой версии разрешены лишь agent_input и agent_output; каждый из них может остаться WITHHELD — нераскрытым. Это не означает, что такого значения не было. Оболочка не является подписанным заявлением, которое регистрируется в службе прозрачности SCITT. Её создают позже, поэтому добавленные данные не входят ни в подпись капсулы, ни в расчёт capsule_id. Разным адресатам можно отправить разные раскрытия, сохраняя один и тот же исходный идентификатор.

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

Интерфейс, который без расчёта показывает «раскрыто — проверено», приписывает неподписанному приложению чужой доказательный статус.

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

Есть и граница конфиденциальности. Получатель заполненной оболочки читает вход или выход в открытом виде, а проект не предусматривает шифрования для конкретного адресата и защиты от пересылки копии. Отправитель может готовить отдельные оболочки для разных проверяющих, но критерий доступа и безопасность доставки задаются вне операции сравнения хеша. В этом состоит вывод Daniel Kade: неизменность реестра свидетельств не равна правомерности каждого последующего раскрытия. Источники не показывают ни внедрения, ни утечки, ни обязательного нового правила IETF.

Источники