Кратко

  • В редакции 01 документа Using KYAPay Tokens от 2 октября 2026 года потребитель токена переименован из «verifier» в «recipient». Текст прямо отделяет идентификацию от допуска: валидный токен передаёт аутентифицированный контекст, но разрешить, ограничить, запросить дополнительную проверку или отказать должен получатель.
  • Успешная проверка не доказывает последующие события. Bearer-токен не подтверждает владение закрытым ключом, разрешение в момент выпуска — непрерывный человеческий контроль, а PAY — принятие платежа продавцом или окончательный расчёт.

В системах доверия опасно не только ложное утверждение. Не менее опасно истинное утверждение, которому незаметно приписали лишние полномочия. draft-skyfire-oauth-using-kyapay-tokens-01 проводит эту границу одним точным изменением роли: сторона, читающая токен, теперь называется получателем.

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

KYA связывает утверждения о человеке, платформе агента и конкретном экземпляре агента. PAY добавляет контекст платежа. Такой набор лучше догадок по IP-адресу и User-Agent. Но он отвечает на вопрос о том, кого эмитент связывает с запросом. Он не содержит приказа приложению выполнить операцию.

Редакция 01 прямо говорит: identification отличается от admission. Токен поступает в локально настроенный механизм политики. Тот может пропустить запрос, ограничить частоту, потребовать новый фактор или отказать. Универсальная зелёная метка «проверенный агент» стёрла бы как уровни уверенности, так и риск конкретного действия.

Институциональный статус тоже нельзя расширять догадкой. Оба документа KYAPay остаются индивидуальными Internet-Draft. Зафиксированные карточки Datatracker не показывают stream, уровень стандарта или принятие рабочей группой. Список OAuth — место обсуждения, не свидетельство консенсуса. Предложенные поля HTTP и claims JWT становятся выделенными только тогда, когда появляются в действующих реестрах IANA.

Полезная проверка — это цепочка отдельных результатов. Получатель сначала выбирает доверенных эмитентов, затем проверяет заголовок JOSE и подпись, exp, iat, jti, aud и среду. Он определяет тип токена и по отдельности оценивает гарантии для человека, платформы и агента. Само наличие KYAPay-Token не доказывает присутствие человека в текущий момент.

По умолчанию описывается bearer-токен. Тот, кто скопировал его, может предъявить его в пределах срока. TLS, короткая жизнь, узкая audience и хранилище повторов уменьшают риск. Однако они не показывают, что отправитель владеет закрытым ключом агента.

Сопутствующая редакция формата 02 допускает claim cnf. Он может указывать ключ подтверждения и участвовать в sender constraint, если внешний протокол требует реального proof, а получатель его проверяет. Ссылка на ключ внутри подписанного объекта сама не является доказательством. Результат подписи и результат владения ключом нужно сохранять раздельно.

Полномочие со временем устаревает. Валидный токен, по формулировке проекта, подтверждает, что человек разрешил работу агента в момент выпуска. После выпуска хост могут скомпрометировать, платформу — снять с регистрации, а мандат — отозвать. Механизм revocation редакцией 01 не задан. Чем выше последствия, тем нужнее свежий challenge или независимый контроль.

Доверие к эмитенту остаётся политикой получателя. Корректная подпись говорит, какой ключ подписал объект, но не оценивает качество проверки личности, регистрации агента или контроля платформы. Сам проект называет масштабируемое доверие между эмитентами открытой задачей и указывает на нынешние внепротокольные отношения. Версия списка доверия поэтому является частью квитанции решения.

PAY не заменяет платёжную книгу. Привязка получателя, суммы и валюты, транзакционный credential и одноразовая криптограмма усложняют повторное применение и помогают сравнить условия. Они не подтверждают принятие продавцом, авторизацию сетью, клиринг, окончательность расчёта, отсутствие возврата или доставку.

Защитимая квитанция хранит точные версии draft и profile; эмитента и набор ключей; evidence и уровень assurance; неизменяемый hash токена; результаты подписи и claims; audience и среду; решение о повторе; bearer или proof ключа; версию политики и step-up; окончательное действие приложения. Для платежа отдельно связываются авторизация, клиринг, расчёт и reversal.

Минимальная начальная спецификация Heng Lu подсказывает архитектуру: общими должны быть лишь необходимые claims и инварианты, а политика последствий должна оставаться локальной. Примат работающего кода требует смотреть на реально исполненное действие. Слои реальности не позволяют склеить утверждение эмитента, криптографию, владение ключом, политику и видимый результат в одно слово «разрешено».

Поэтому recipient — не косметическая замена. Эмитент утверждает, токен переносит, валидатор проверяет. Получатель управляет собственной границей, а приложение оставляет свидетельство того, что действительно сделало.

Источники