Кратко

  • В пятой редакции индивидуального проекта IETF появился пример: агент делает заказы еды, поездок и товаров для дома по дневному разрешению, где каждая операция ограничена 30 долларами, а весь день — 100 долларами. Поездка за 38 долларов требует отдельного решения человека.
  • Каждая служба видит свой чек. Общий предел требует узнаваемого для всех разрешения, единого учёта, прекращения всей цепочки полномочий и проверки при исполнении. Проект формулирует потребность, но не даёт готового межсервисного счётчика.

Касс три, бюджет один

Ужин обходится в 24 доллара. Поездка за 38 долларов упирается в предел на одну операцию и ждёт прямого исключения от владельца денег. Покупка для дома стоит 18 долларов. Эту последовательность авторы поместили в новый раздел «Daily Small-Amount Orders» пятой редакции проекта о полномочиях агентов. Ни магазины, ни поездки здесь не являются наблюдаемыми транзакциями. Числа придуманы для проверки идеи. Идея сразу натыкается на реальную кассовую проблему: откуда третья служба узнает, сколько уже списали первые две?

Ограничение в 30 долларов можно применять в каждом отдельном сервисе. Он сравнит собственную цену с разрешённым максимумом. Для дневных 100 долларов такой местной проверки мало. Службы еды, поездок и домашнего обслуживания могут принадлежать разным компаниям. У них должен быть общий способ опознать одно разрешение и узнать, сколько по нему уже потрачено до принятия следующего заказа. Красиво напечатанная сумма на экране согласия не превращает разрозненные кассы в общую бухгалтерию.

Карточка IETF Datatracker и объявление от 27 октября описывают пятую редакцию как индивидуальный Internet-Draft. В четвёртой редакции этого случая не было. Авторы предлагают один раз пройти сильное подтверждение личности, дать агенту ограниченный по времени мандат и затем не будить пользователя ради каждого небольшого заказа. Комфорт одного утреннего решения покупается круглосуточной дисциплиной всех исполнителей.

Одно «да» не разрешает переписать цифры

Разрешение должно быть структурированным: просматривать варианты, подготовить заказ и заплатить — разные действия. В нём перечисляются допустимые приложения, максимум операции, общий дневной максимум и обязательное время окончания. Агент не вправе сам продлить срок или поднять предел. Каждое действие должно криптографически относиться к конкретному разрешению. Иначе выписка покажет действие агента, но не покажет, какое именно человеческое решение дало ему силу.

Поездка за 38 долларов проверяет исключения отдельно от общего бюджета. Даже если после ужина остался запас до 100 долларов, поездка превышает лимит в 30 долларов на операцию. В примере её задерживают до явного одобрения Дейва. Честная форма исключения должна показывать эту поездку, её цену и исходное разрешение. Кнопка «разрешить поездки» для всех будущих заказов дала бы агенту больше власти, чем точечное решение. Размер кнопки тут мало что говорит о размере уступки.

В полночь мандат истекает. Человек может отозвать его раньше одним действием, вместе со всеми созданными на его основе допусками. Если приложение еды перестало принимать свой токен, а приложение поездок продолжило принимать свой, пользователь отозвал только половину обещания. Связь каждого токена и заказа с общим мандатом необходима и для подсчёта, и для закрытия доступа.

Авторы указывают, что OAuth authorization code flow годится для первоначальной выдачи, Rich Authorization Requests — для передачи структурированных параметров, DPoP — для привязки токена к предъявителю, а отзыв токена закрывает отдельный токен. Их перечень пробелов включает общие значения лимитов расходов, отзыв всей выдачи и путь, по которому независимые сервисы будут применять ограничения в момент действия. Проект не показывает развернутую систему такого учёта и не приводит измерений. Следующая инженерная работа должна распределить обязанности, а не переименовать существующие токены.

Первичные документы