Кратко

  • В проекте от 28 сентября предлагается поле client_attesters: издатель метаданных клиента указывает допустимых для него аттестаторов, но сервер авторизации отдельно решает, каким из них доверять.
  • Удаление аттестатора влияет на будущую аутентификацию после получения изменения сервером. Старые разрешения и токены доступа сами по себе не аннулируются.

Одобрение аттестатора — не то же самое, что доверие к нему, а отзыв одобрения — не то же самое, что уничтожение всех последствий прежнего доверия. Такова последовательность, которую стоит сохранить при чтении OAuth 2.0 Client Attester Endorsement. Новый текст отвечает на вопрос, кто вправе аттестовать экземпляры данного клиента, но не превращает редактирование списка в универсальную команду прекратить доступ.

K. McGuinness датировал первую редакцию -00 28 сентября 2026 года. Это индивидуальный Internet-Draft с предполагаемым статусом Standards Track; карточка IETF подтверждает существование проекта, но не публикацию RFC, принятие рабочей группой OAuth, развертывание или реальный инцидент. Проект опирается на другой пока не окончательный текст об аутентификации клиентов с аттестацией. Он не вводит новую учетную сущность и новый метод аутентификации. Его узкая задача — сделать связь между клиентом и уполномоченными им аттестаторами явной в метаданных.

Издатель может поместить client_attesters в регистрацию клиента либо в Client ID Metadata Document. Указываются аттестаторы и местонахождение проверочных ключей. Однако для запроса, подпадающего под этот профиль, сервер авторизации должен проверить два условия: авторитетные метаданные сейчас одобряют издателя аттестации, а политика самого сервера разрешает этого аттестатора для данного клиента и определяет надежный источник его ключей. Сервер вправе сузить одобренный набор, но не дополнить его никем, кого клиент не одобрил. Клиент, в свою очередь, не может заставить сервер доверять выбранному им имени. Ни одно из этих решений не заменяет разрешения пользователя на доступ к ресурсу.

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

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

Вторая граница относится к прошлым решениям. Раздел 6.3 прямо называет отзыв перспективным: дальнейшая аутентификация клиента под удаленным одобрением прекращается, но существующие grants и access tokens не отзываются. Запрос обновления, которому нужна аттестация, проверяется снова. Для прекращения доступа требуется отдельно отозвать затронутые разрешения и токены и остановить дальнейшее продление. Интроспекция RFC 7662 может сообщить, что отозванный токен неактивен. Сервер ресурсов, проверяющий токен локально, зависит от иного механизма отзыва или срока истечения токена. Обновленный кэш одобрений не управляет автоматически каждым уже выпущенным токеном.

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

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

Источники