Summary

  • Проект предлагает документ /.well-known/agent-capabilities со сценариями, серверами авторизации и точками вызова для агентов.
  • Если операция отсутствует во всех объявленных сценариях, сервер ресурсов обязан отказать в ее выполнении даже при наличии прежнего одобрения в экземпляре авторизации.

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

Для оператора это способ быстро снять сценарий. Для противника с доступом на запись к статическим файлам исходного домена — другая возможность. Раздел 8.6 прямо описывает подмену документа: агенты, пришедшие позднее, могут получить указатели на выбранные противником точки вызова либо перестать видеть настоящие сценарии. Код приложения при этом остается прежним. Авторы советуют включать документ в тот же процесс контроля изменений, что и выпуск приложения. RFC 8615 давно предупреждала о забытых администраторами путях .well-known; теперь такой путь предлагается сделать частью рабочей границы.

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

Имя и логотип сервиса служат оформлением, а не удостоверением личности. Привязка идет через домен и аутентифицированную доставку; при публикации OAuth-метаданных защищенного ресурса списки серверов авторизации должны совпадать. Карточка IETF показывает статус индивидуального проекта. История файла и журналы отклоненных запросов конкретного сервиса нужны, чтобы говорить о работающем, а не предложенном переключателе.