Что изменилось, когда оформление заказа открылось для агентов
Браузерный агент, завершающий покупку, не кликает по форме. Он реализует делегированные полномочия на расходование средств. Пользователь передал программному процессу возможность выбрать продавца, собрать корзину, выбрать сохранённый способ оплаты и подтвердить итоговую сумму. Это отношение принципала и агента в юридическом смысле, сжатое в траекторию событий DOM и сетевых вызовов.
Продавец, однако, видит сессию. Он видит строку user-agent, cookie, отпечаток устройства и платёжный токен. Он не видит принципала. Пользователь видит результат: подтверждение заказа, списание, оценку доставки. Пользователь не видит договор, который был заключён для получения этого результата. А условия, которые агент принял в середине траектории — текущие условия обслуживания продавца, политика возврата, арбитражная оговорка, условия продления подписки — не видны никому, кроме контекстного окна агента, которое отбрасывается по завершении запуска.
Это структурное изменение. Оформление заказа раньше было кликом: человек читал (или не читал) страницу с условиями и нажимал кнопку. Клик был согласием, а страница — записью. Теперь согласие генерируется моделью, страница, возможно, никогда не отображалась человеку, а запись — это последовательность токенов, которую никто не сохраняет. Проблема согласия переместилась с события пользовательского интерфейса на договор, согласуемый машиной, и артефакты, которые её документировали, не переместились вместе с ней.
Почему переключателя в настройках недостаточно
Обычная институциональная реакция — переключатель в настройках: тумблер в платформе агента, который указывает, может ли агент совершать транзакции, возможно, со списком разрешённых продавцов. Это не модель согласия. Это флаг возможности.
Согласие в коммерции не является глобальным. Оно привязано к транзакции, продавцу и диапазону сумм. Пользователь может разрешить агенту купить сменный фильтр у известного поставщика до скромного потолка и отдельно разрешить разовую покупку у незнакомого продавца на большую сумму после проверки корзины. Один тумблер не может выразить это различие и не может выразить разницу между продлением регулярной подписки и первой покупкой. У разрешения есть форма: принципал, агент, продавец, область действия, потолок, срок действия. У булева значения формы нет.
С отзывом та же проблема. Если единственное представление согласия — тумблер, отзыв означает переключить тумблер и надеяться, что агент это заметит. Но агент в середине запуска может уже собрать корзину, выбрать способ оплаты и ждать шага подтверждения. Отзыв должен быть возможен в середине запуска, что требует, чтобы разрешение было адресуемым объектом — чем-то, что можно назвать, найти и аннулировать, пока траектория выполняется. Тумблер не адресуем. Это состояние, а не запись.
Споры выявляют третий недостаток. Когда списание оспаривается, вопрос не в том, какими были настройки пользователя в прошлом месяце. Вопрос в том, какие условия агент принял в момент принятия и входили ли эти условия в область, предоставленную пользователем. Страницы условий меняются. Продавцы обновляют арбитражные оговорки, сборы за возврат и формулировки о продлении без уведомления. Запись условий на момент последнего визита пользователя не является доказательством того, что было согласовано в оспариваемой транзакции. Без артефакта на каждую транзакцию процессу спора не над чем рассуждать, кроме текущей страницы продавца и воспоминаний пользователя.
Набросок реестра согласий
Механизм, который это решает, — реестр согласий: доступная только для добавления, запрашиваемая запись каждого делегирования полномочий на расходование средств, создаваемая в момент использования разрешения.
Каждая запись должна содержать как минимум следующие поля:
entry_id уникальный, монотонный
principal человек или организация, предоставляющие полномочия
agent_id программная идентичность, использующая их
merchant_id контрагент
scope например, разовая покупка, продление подписки, возврат
amount_ceiling максимальная сумма, которую агент может потратить
currency код ISO
expiry временная метка, после которой разрешение недействительно
terms_hash дайджест условий, представленных при принятии
terms_uri местоположение документа с условиями
timestamp когда была создана запись
parent_entry для отзывов и изменений
Хеш условий — несущее поле. Он не требует хранения полного документа условий, только дайджест, который можно сверить с опубликованной историей версий продавца. Если продавец позже изменит страницу, хеш всё равно идентифицирует версию, которая была активна при принятии. terms_uri даёт процессу спора указатель для её получения.
Записи доступны только для добавления. Отзыв не изменяет исходное разрешение; он создаёт новую запись с parent_entry, указывающим на разрешение, и областью действия revoked. Исходная запись остаётся доступной для запросов. Это важно, потому что спор может потребовать установить не только то, что согласие было отозвано, но и когда, и совершил ли агент транзакцию до того, как отзыв вступил в силу. Журнал, доступный только для добавления, отвечает на этот вопрос; изменяемый флаг стирает его.
Реестр должен быть доступен для запросов двум сторонам с разными интересами. Пользователю нужно видеть в одном представлении каждое делегирование, использованное его агентами, с потолками и сроками действия, и отзывать любые, которые ещё активны. Процессу спора продавца нужно получить хеш условий и область действия для конкретной транзакции, не получая видимости других разрешений пользователя. Это проблема авторизации чтения, а не хранения, и именно эта часть, скорее всего, будет недостаточн
k-network-cables-f7a795-35eb46.jpg)
Конкретное взаимодействие: агент достигает оформления заказа, страница продавца представляет условия, агент вычисляет дайджест и создаёт запись в реестре с продавцом, областью действия, потолком и хешем. Авторизация платежа несёт entry_id. Если пользователь отзывает разрешение, пока агент ждёт шага подтверждения, создаётся запись об отзыве, и следующее чтение реестра агентом возвращает статус revoked, заставляя его прервать траекторию. Если транзакция всё равно расчитывается, реестр показывает порядок: разрешение, отзыв, расчёт. Этот порядок и есть доказательство.
Честный компромисс
Реестр согласий добавляет задержку и зависимость к каждому агентскому оформлению заказа. Создание записи, хеширование условий и проверка отзыва — это сетевые запросы, которых человек, нажимающий кнопку, не оплачивает. Если реестр недоступен, агент либо отказывает в безопасности — отменяя законную покупку, — либо отказывает в открытую, что сводит на нет цель. Дизайн должен выбрать, и ни один выбор не бесплатен. Реестр, запрашиваемый на каждом шаге траектории, замедлит агента; реестр, запрашиваемый только при авторизации, пропустит отзывы в середине запуска. Практический компромисс — записывать при авторизации и опрашивать на предмет отзыва с ограниченным интервалом, принимая окно, в течение которого отозванное разрешение всё ещё может совершить транзакцию. Это окно должно быть указано в записи, а не скрыто.
Есть также цена приватности. Реестр делегирований расходов — это богатая поведенческая запись. Его следует ограничить так, чтобы продавцы видели только записи, относящиеся к их транзакциям, и чтобы пользователь сохранял возможность экспортировать и удалять свои записи с учётом требований сохранения для споров. Доступность только для добавления не означает бессмертие; это означает, что удаление само является записью.
Взаимодействие с коммерческими рисками
Банки и платёжные сети, отмечающие агентскую коммерцию, реагируют не только на уровень мошенничества. Они реагируют на отсутствие артефакта. Модель риска, которая всегда полагалась на присутствие человека в момент авторизации, теперь сталкивается с сессией без принципала, без читаемого согласия и без записи условий. Сигнал мошенничества слаб, потому что законный шаблон и злоупотребительный шаблон выглядят одинаково со стороны сети: сохранённые учётные данные, используемые программным обеспечением, без человека в цикле.
Реестр согласий не устраняет эту неоднозначность, но даёт системам риска то, что можно оценить. Авторизация, несущая entry_id с соответствующим разрешением, правдоподобным потолком и действующим сроком, — это другой объект, нежели авторизация без происхождения. Со временем наличие артефакта становится сигналом сам по себе, а его отсутствие — причиной для отказа. Институты, которые первыми двинутся в этом направлении, не проявляют осторожность к агентам; они строят запись, которая делает агентскую коммерцию понятной для систем, которые уже ею управляют.
Обновление условий — не ответ. Ответ — реестр.