Summary

  • Индивидуальный Internet-Draft Selo от 31 октября описывает архитектуру соглашений о доступе между юридическими лицами, условия которых обсуждают агенты. Это обсуждаемое предложение, а не принятый стандарт IETF.
  • Подписать соглашение позволяет отдельный детерминированный проверяющий механизм в рамках мандата, подписанного владельцем. Рабочий доступ открывается после подписи обеих сторон и взаимных проверок.
  • Смена платёжных реквизитов требует новой подписанной версии, согласия человека с финансовой ролью, прямого сообщения людям плательщика в обход агентов и подтверждения плательщиком до первого перевода на новый счёт.

Подмена реквизитов проходит через договор

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

Версию соглашения с новым счётом должен одобрить человек, отвечающий за финансы. Люди плательщика получают уведомление непосредственно, по каналу, который не проходит через двух агентов. Прежние реквизиты остаются в силе на период ожидания, когда любая сторона вправе отменить изменение. Перед первым платежом по новым данным человек у плательщика подтверждает их. Указанные в тексте 72 часа — пример такого периода, а не обязательный срок.

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

На каждом вызове шлюз поставщика сверяет краткоживущий токен, привязанный к соглашению и ключу вызывающей стороны, с действующей версией, разрешёнными операциями, полями и лимитами. Свои системные ключи поставщик не передаёт клиенту. Такой контроль помогает остановить лишний вызов API. Он не заменяет решение людей о том, куда уходит платёж.

Никакого реального случая мошенничества этот пример не документирует. Selo не переводит деньги. В реестре IETF текст значится индивидуальным черновиком без формального статуса в процессе стандартизации; автор предлагает обсудить, где такая работа вообще должна вестись.

Официальные источники