Кратко

  • Редакция 02 заменяет один объект с баллом массивом результатов и требует у каждой записи схему оценки и URI издателя.
  • URI сообщает, кому приписан результат, но не подтверждает авторство, неизменность перепубликации или качество методики.
  • Автоматизация должна хранить вместе субъект, схему, оценщика, публикующий сервер, дату, статус и доказательства, а не только число.

Число рядом с доменным именем начинает управлять решениями раньше, чем пользователь открывает описание методики. Поэтому важнейшая часть draft-bertoldi-regext-rdap-reliability-scoring-02, поданного 6 сентября, — не новый JSON, а попытка ограничить власть, которую интерфейс может приписать этому числу.

Название расширения меняется с reliabilityScoring на reliabilityAssessment. Один объект заменён массивом reliabilityAssessment_results для нескольких оценщиков и схем. scoreScheme и scoreIssuer обязательны; добавлены срок актуальности, идентификатор результата и состояния active, under review и withdrawn. Известных реализаций авторы пока не называют.

Указанный источник ещё не доказанный автор

Документ различает идентичность, доверие и подлинность. Идентичность отвечает, кому приписано утверждение. Доверие — почему потребитель готов полагаться на эту сторону. Подлинность — действительно ли утверждение создано ею и дошло без изменения.

scoreIssuer решает первую задачу. Его URI должен быть глобально уникальным, стабильным и желательно находиться под контролем издателя. Но URI не является подписью над результатом. Доверие задаётся вне протокола, а подписанное утверждение отложено на будущее.

HTTPS не заменяет подпись третьей стороны. По RFC 7481 TLS удостоверяет сервер и защищает ответ в пути. Это подтверждает, какой узел передал байты, но не доказывает авторство внешнего оценщика, упомянутого внутри. Целостность передачи и правдивость содержания — разные свойства.

Одинаковая форма, разные цепочки контроля

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

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

Поэтому сервисы оценки не добавляются в bootstrap RFC 9224, находящий авторитетные источники регистрационных данных. Не предлагается и обычная ссылка от авторитетного сервера: её легко принять за одобрение оценщика. Возможность найти endpoint не создаёт доверия.

Для решения нужен контекст, а не балл

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

Рабочая единица — связанный субъект, схема, URI оценщика, публикующий endpoint, ID оценки, дата, срок, состояние и сохранённое доказательство.

Связь с субъектом также неполна. Домен доступен по ldhName. Для регистратора сервис использует локальный handle, а IANA Registrar ID появляется в publicIds только после получения объекта. Клиент, знающий один ID, не может сформировать запрос внутри протокола. Теги RFC 8521 остаются открытой идеей; регистраторы ccTLD и стороны без IANA ID не получили окончательной схемы.

Процедура обязательна, но судья не назначен протоколом

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

При этом проект не устанавливает продолжительность срока, арбитра, структуру управления и последствия успешного спора. Эти решения принадлежат конкретной схеме. Общий формат способен переносить статус спора, но не получает полномочий его разрешать.

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

Источники

  1. Карточка IETF Datatracker
  2. Проект RDAP, редакция 02
  3. Проект RDAP, редакция 01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy