Кратко

  • Предлагаемый Agent Authorization Center хранит связи пользователя с агентами и правила автоматического доступа. Сервис из разрешённого списка получает одобрение без нового вопроса, запрещённый — отказ, остальные идут на подтверждение к человеку.
  • Токен должен нести идентификаторы аккаунта, агента и центра. Указывать, было ли одобрение автоматическим или человеческим, проект позволяет, но не требует. Раздел безопасности пока состоит из TBD.

Стоит заранее внести сервис в разрешённый список — и агенту больше не придётся каждый раз спрашивать пользователя. Именно так проект Agent Authorization Center передаёт решение списку. Речь об агентах на личных устройствах, которые обращаются к чужим сервисам от имени пользователя. Экономия на подтверждениях передаёт решение в ведение правила, составленного до следующего конкретного запроса.

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

Дальше центр выдаёт код авторизации по схеме OAuth. Сервис обменивает код на токен, проверяет его и обслуживает запрос в рамках прав пользователя. В токене должны быть идентификаторы аккаунта, агента и AAC. Указание способа одобрения — человеком или автоматически — остаётся необязательным. Проверить подлинность токена получится и тогда, когда сервису не сообщено, видел ли человек именно этот запрос.

Список удобен для повторяющихся поручений. Но проект не определяет границы отдельных действий для занесённого сервиса, историю версий правил, срок действия записи или порядок отзыва. Фраза «сервису можно доверить доступ» не описывает конкретную покупку, передачу данных или правку учётной записи. Документ оставляет обслуживание в рамках прав пользователя на стороне сервиса; значит, там и придётся проводить более тонкую линию между доступом и действием.

В разделе Security Considerations написано только TBD. Действующие рекомендации OAuth в RFC 9700 и защита кода через PKCE в RFC 7636 дают точку отсчёта. Проекту нужен текст о том, какие защитные меры применяет каждый из трёх участников; данных о внедрении он не приводит.

Datatracker показывает индивидуальный Informational-проект со статусом I-D Exists. Практический тест: включить сервис в автоматический список, разрешить одно ограниченное действие, изменить запись и посмотреть, что сервис может узнать из следующего токена. Подлинный токен и доказательство согласия на конкретный шаг — разные вещи.