Кратко

  • Индивидуальный проект от 28 октября предлагает «verdict record»: заявление автора, результат, указанное правило и ссылки на доказательства по SHA-256 от их точных байтов.
  • Проверяющий использует собственную политику, доверенные ключи и сами материалы. Отчёт различает released, held и refused и не объявляет всю запись «verified».

Чужая папка, свои правила

Выдавший заключение способен собрать внушительную папку. Он же может придержать лист, который портит картину. Предложение Даррена Райта строится на этом простом конфликте: составитель вывода не должен единолично снабжать проверку всеми основаниями для успеха. Документ числится индивидуальным Internet-Draft с предполагаемым экспериментальным статусом.

Формат записи намеренно строг. Канонический JSON задаёт порядок полей и правила представления; дубликаты имён и слишком глубокие вложения отвергаются. В записи есть writer, формулировка проверяемого утверждения, перечень доказательств с форматом и SHA-256, а также check с правилом и результатом. Последующая версия может ссылаться на хеш предыдущей. Подпись, связь ключа с автором и верхняя граница времени существования записи подтверждаются её внешним носителем. Подписанное заявление SCITT с проверенной квитанцией — один пример такого носителя, а не единственный путь.

Для решающего шага проверяющий должен держать входы вне контроля автора. Он сам считает хеши полученных байтов, проверяет подписи и повторно запускает правило. Его политика и опорные ключи тоже выбираются им, а не лежат в папке как указание издателя. Автор вправе сказать «я получил этот результат». Но его слова не превращают отсутствующий документ в присутствующий и не проводят шаг, который без них не прошёл бы. Поставщик не становится экзаменатором собственного товара.

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

Вместо одного большого «да» появляются четыре состояния. Все шаги прошли — released. Есть провал — refused. Провала нет, но шаг не удалось выполнить — held. Собственная политика проверяющего неверна — no verdict. В отчёте нужны результаты шагов, их причины, установленная временная граница и хеши использованной политики и наборов доверенных ключей. Проект отдельно запрещает называть запись целиком «verified», «valid», «true», «trusted», «correct», «proven», «confirmed» или «OK». Такая табличка на экране незаметно превращала бы проверку происхождения высказывания в удостоверение истины.

Состояние released имеет точный смысл: указанный автор заявил такой результат на таких материалах по такому правилу не позднее указанной границы времени. Истинность исходного утверждения требует иных данных. Именно эта граница делает запись пригодной для разбора спора, а не для красивого закрытия дела.

Источники: проект Райта, статус IETF, RFC 9943, RFC 8259.