Кратко

  • RFC 9560 позволяет серверу RDAP идентифицировать пользователя и проверять Bearer Token через OpenID Connect и OAuth без отдельной учётной записи в каждом сервисе.
  • Необязательные заявления о цели и запрете отслеживания служат входными данными локальной политики; они не доказывают мотив, право конкретного запроса, отсутствие всех журналов или качество регистрационных данных.
  • Защищаемая аудиторская цепочка связывает проверку токена с версией политики, заявленной целью, раскрытыми полями, происхождением записи и последующим результатом расследования.

Bearer Token прошёл проверку. Издатель, аудитория, срок и структура дали серверу достаточно оснований продолжить. Это точный технический факт. Неточность появляется в следующей фразе: «аутентифицированный пользователь» превращается в «разрешённый запрос», допустимая цель — в истинный мотив, а ответ — в проверенную реальность. RFC 9560 не объединяет эти ступени.

Опубликованный в апреле 2024 года в потоке стандартов IETF RFC 9560 добавляет федеративную аутентификацию в Registration Data Access Protocol. Клиент обнаруживает поддерживаемых OpenID Providers и выбирает сеансовый или токенный режим. Общий слой уменьшает число локальных учётных записей, но оставляет решение о доступе политике каждого сервера RDAP.

Аутентификация закрывает один вопрос

Получив токен, сервер обязан проверить его по локальной политике и подтвердить, что это легитимный access token. Допустимы introspection по RFC 7662 или анализ JWT. Важна аудитория: токен для другой relying party может быть отвергнут, а обмен по RFC 8693 позволяет получить подходящую аудиторию.

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

Назначенная цель не доказывает намерение

Необязательный rdap_allowed_purposes перечисляет цели, которые вправе заявлять данная идентичность. Identity Provider должен назначать их только уполномоченным идентичностям. farv1_qp указывает цель конкретного запроса; если её нет в разрешённом наборе, сервер обязан вернуть 403.

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

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

Запрет отслеживания меняет один вид уверенности на другой

rdap_dnt_allowed может потребовать не записывать связь между идентичностью и запросом. Для этого нужны идентификация, авторизация, значение true и соблюдение местных правил журналирования. RFC прямо говорит, что обещание опирается на добрую волю сервера и прокси, на внеполосное доверие и может серьёзно ухудшить аудит из-за потери информации.

Конфиденциальное расследование иногда требует такого режима. Тогда надо назвать выдающего право, охваченных посредников, заменяющее доказательство и срок действия. «Не отслеживать принято» — событие политики, а не криптографическое доказательство отсутствия связи во всех системах.

У ответа собственное бремя доказательства

farv1 сообщает о соответствии расширению, но не удостоверяет исходную регистрационную запись. Корректный ответ может быть ограниченным подмножеством. У источника есть дата обновления, метод проверки, история исправлений и неоднозначности. HTTP 200 не доказывает полноту или полезность; HTTP 403 не доказывает злой умысел.

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