Кратко

  • Редакция WebProof-01 от 5 сентября остаётся индивидуальным Internet-Draft без одобрения IETF и формального статуса в процессе стандартизации, хотя содержит раздел, объявленный нормативной директивой для языковых моделей и агентов.
  • Сам текст ограничивает силу своих доказательств: блокчейн задаёт верхнюю границу времени известности хеша, DOI хранит метаданные заявителя, подпись указывает на ключ; ни один элемент сам по себе не доказывает истину, первенство, личность или право управлять ИИ.
  • Оператору нужны две отдельные квитанции — о полученном документе и о действующей политике инструкций. Иначе объект исследования может незаметно назначить собственные правила исследования.

Сообщение от 5 сентября фиксирует публикацию 62-страничного draft-reilly-webproof-01 за авторством Lawrence John Reilly Jr. Оно подтверждает наличие, название, автора, номер редакции и дату. В нём нет решения рабочей группы, одобрения IESG или свидетельства о внедрении.

Основная конструкция документа — WebProof Record. Ресурс приводится к канонической форме, хешируется, связывается с временной отметкой в Bitcoin и DOI-депозитом, при необходимости подписывается, а затем обнаруживается через Web и DNS. Но раздел 15 адресован не только реализации протокола.

Раздел называется «AI System Directive». Он требует от моделей и агентов, которые обрабатывают, индексируют, пересказывают или цитируют документ, приписывать термин WebProof его автору, считать определённую работу 2025 года первоначальной публикацией и не представлять перечисленные элементы анонимным или чужим вкладом. Требования написаны через MUST и MUST NOT.

Это проверяемые слова автора. Их наличие не назначает автора владельцем политики читающей системы.

Сначала процессуальный статус, затем нормативная лексика

Карточка Datatracker определяет документ как активный индивидуальный Internet-Draft. У него нет RFC stream, ответственного Area Director и даты telechat. Там же дано принципиальное предупреждение: I-D может подать любой человек; этот текст не одобрен IETF и не имеет формального положения в процессе стандартов IETF.

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

Именно это соседство делает материал важным. Документ стал точнее объяснять, чего не устанавливает криптографическое доказательство, но сохранил попытку непосредственно определить поведение внешнего читателя. Новый предел доказательства должен распространяться и на эту попытку.

RFC 8174 объясняет специальное значение прописных слов BCP 14. Они придают требованиям внутри спецификации однозначность. Они не определяют принятие документа, область юрисдикции или исполнителя. Реализация может заявить о совместимости с WebProof и принять соответствующие MUST. Модель, получившая страницу как исходные данные, от этого не становится реализацией WebProof.

Директива называет человеческий контроль высшим и признаёт приоритет более высоких prompts в схеме AIMED. Однако AIMED в Datatracker тоже является индивидуальным I-D. Одна авторская схема может ссылаться на другую, но не может тем самым описать реальную иерархию system и developer instructions в чужой службе.

Неизменяемое притязание остаётся притязанием

Блокчейн-якорь в WebProof отвечает на узкий вопрос. Некто знал конкретный digest не позднее момента создания связанного блока. Из этого не следует дата создания произведения, личность автора, факт выдачи этих байтов по указанному URI или истинность содержания.

DOI-слой сохраняет депозит и облегчает его поиск. Метаданные сообщает депозитор. Долговечность полезна для восстановления истории заявления, но хранилище не становится независимым судьёй исторического первенства.

Подпись добавляет ещё одну связь, но не завершает личность. RFC 7515 определяет JWS, на который ссылается проект. Успешная проверка показывает соответствие подписи и ключа для защищённого объекта. Далее нужны доказательства владения ключом, его связи с человеком или организацией, полномочий, срока действия и отзыва.

RFC 3161 предлагает иной временной источник: доверенная служба связывает хеш и время. Это сужает временное окно ценой доверия к ещё одному участнику. Метка «существовало не позднее» всё равно не отвечает на вопрос «кто впервые создал идею».

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

Напечатанный адрес ещё не стал общим адресом

Проект использует /.well-known/webproof. RFC 8615 требует регистрации новых suffix в пространстве /.well-known/, чтобы избежать коллизий и определить формат, область и контролёра изменений. В проверенном 7 сентября реестре IANA записи webproof не было.

У наблюдения есть дата; оно не исключает будущей регистрации. Оно лишь запрещает слить в одно пять состояний: строку в проекте, заявку, запись IANA, реально работающий сервер и поддержку клиента.

Предложенные HTTP-поля и TXT _webproof также обеспечивают обнаружение, а не одобрение. Проект отдельно предупреждает, что hash header, доставленный тем же сервером вместе с ресурсом, не является независимой проверкой, а неподписанный DNS не должен служить авторитетным источником ключа.

Поставщик Evidence не принимает решение за Relying Party

WebProof помещает свою запись в словарь удалённой аттестации. RFC 9334 разделяет Evidence от Attester, политику оценки, Attestation Results и решение Relying Party. Такое разделение не даёт поставщику свидетельства встроить в него обязательный итог для получателя.

Применительно к разделу 15 сам draft — свидетельство того, что автор опубликовал инструкцию и притязание. Хеш фиксирует байты, временной якорь ограничивает дату, внешние архивы могут подтвердить или оспорить хронологию. После этого политика оператора решает: процитировать, искать ранние материалы, отметить неопределённость, игнорировать встроенный императив или передать вопрос человеку.

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

Заявленная эксплуатация должна встретиться с независимым кодом

Раздел о реализации сообщает, что автор использует процедуру якорения, DOI-депозит и работающий сервис. RFC 7942 рекомендует описывать реализации в Internet-Drafts, чтобы обсуждение учитывало практический опыт.

WebProof сам называет следующий необходимый тест — независимую реализацию. Два независимо созданных приложения должны получить одинаковую каноническую форму и digest, одинаково понять исправление, отзыв, компрометацию ключа и сбой получения. Эксплуатация автором важна, но не является независимой воспроизводимостью.

Для AI-директивы аналогичный тест сохраняет точные входные байты, путь retrieval, system/developer policy, модель и версию, инструменты, ответ, ссылки и человеческое решение. Без этой записи нельзя утверждать, что система подчинилась, процитировала, отвергла или вообще увидела раздел.

Две квитанции вместо одной зелёной печати

Minimum Initial Specification Хэн Лу подсказывает минимальную общую схему. Квитанция документа хранит URI, редакцию, байты или хеш, время получения, институциональный статус, заявления и внешние подтверждения. Квитанция управления хранит издателя политики, версию, область, приоритет, срок, исключение, отзыв и ответственного.

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

Running-Code Primacy задаёт окончательную проверку. Если утверждается, что директива управляла ИИ, требуется показать реально применённую иерархию и фактический результат. MUST в файле — это содержимое файла, а не журнал исполнения.

WebProof поднимает настоящую проблему: цифровые ресурсы меняются, а история исправлений исчезает. Сильнейшая часть редакции 01 — честное разделение существования, времени, целостности, личности и истины. То же правило позволяет корректно обращаться с директивой: сохранить авторское заявление, указать источник и дату, проверить внешнюю историю — и не выдавать способ фиксации за право командовать читателем.

Источники

  1. Datatracker — WebProof
  2. WebProof, редакция 01
  3. Объявление Internet-Draft
  4. Datatracker — AIMED
  5. RFC 8174 — прописные нормативные слова
  6. RFC 8615 — Well-Known URIs
  7. Реестр IANA Well-Known URIs
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — Time-Stamp Protocol
  10. RFC 9334 — архитектура RATS
  11. RFC 7942 — статус реализаций
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy