Кратко

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

Пожелание на полях разрешения

Человек пишет: «Отправь только этот счёт». В соседней строке он отмечает право редактировать все счета. Какой из двух пунктов увидит сервер, когда агент придёт за данными? Отмеченное право. В новой редакции проекта Christopher Emerson это разграничение сделано открыто: обычный текст хранит намерение, структурированная запись задаёт полномочие. Красивое поле для цели рядом с чрезмерно широкой галочкой превращает согласие в хорошую типографику без хорошего замка.

Объявление от 27 октября представило редакцию 01. Реестр IETF относит её к действующим индивидуальным Internet-Draft без потока RFC и одобрения организации. Предложенная цепочка начинается в сервисе, который хранит данные. Пользователь входит туда сам и открывает страницу управления соединениями. Сервис показывает возможные разрешения в пределах прав самого пользователя. Человек выбирает область доступа и срок, а также может ограничить число вызовов в определённый период. Старые разрешения видны на том же экране: их можно оставить осознанно или отозвать.

Дополнительная процедура присутствия позволяет аутентификатору подписать обязательство, связанное с точными выбранными правами, сроком, лимитами и записанными текстами. Сервис один раз показывает краткоживущий пропуск. Человек передаёт его агенту; агент обменивает его на ограниченный токен доступа без автоматического продления. Так момент передачи нового полномочия оказывается у пользователя, а не в канале, который устраивает платформа агента.

Запись объясняет, проверка останавливает

Редакция 01 отдельно разбирает заявленную сервисом цель и слова самого пользователя. Оба текста остаются в записи согласия и сопровождают историю проверок, аудит, отзыв и уведомления. Механизм доступа их не толкует. Проект запрещает расширять разрешение на основании свободного текста; автоматический анализ такой фразы может лишь подсказать человеку, что требуется разбор. Узкая фраза не сужает широкую галочку. Для ограничения «этот счёт» сервису нужен именно такой вариант права или подтверждение конкретной операции.

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

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

Первоисточники