Кратко

  • Принципал подписывает компактную Delegation Authorization; в ver=3 она содержит SPKI-хеш ключа агента в agent_key_binding, а издатель подписывает внешний токен с этой точной строкой.
  • Проверяющий сопоставляет ключ cnf с подписанной привязкой. Действительная внешняя подпись не разрешает замену, а повторная выдача требует новой DA и nonce.

Система увидела две правильные подписи и всё равно отказала. Издатель удостоверил внешний токен, принципал — внутреннюю делегацию, агент доказал владение ключом. Но ключ из cnf не совпал с тем, чей отпечаток подписал принципал.

Так работает граница в редакции 02 AI Agent Identity Certificate (AIC) JSON Web Token Profile. Это активный индивидуальный Internet-Draft от 2 октября 2026 года с заявленным Informational-статусом и сроком до 5 апреля 2027 года. Он не RFC, не консенсус или одобрение IETF и не доказательство внедрения.

Подписанные байты и разные роли

Принципал создаёт DA как компактный JWT и подписывает её. Агент или издатель переносит всю строку в поле da внешнего AIC-JWT. Внешняя подпись покрывает точную внутреннюю сериализацию. Нельзя разобрать её и собрать «эквивалентно»: иной порядок JSON или кодирование означает другие подписанные байты. Аудит хранит исходную строку и digest.

Внутренняя подпись доказывает авторство делегации, внешняя — ответственность издателя за носитель. Доверенный издатель не вправе переписать грант, а подлинная DA не делает доверенным любого издателя. Оба ключа должны проверяться по настроенной политике и иметь якоря в одном принятом домене доверия. Разные typ не позволяют принять DA как самостоятельный AIC-JWT или access token.

Ключ, выбранный принципалом

В ver=3 обязателен agent_key_binding: хеш DER SubjectPublicKeyInfo публичного ключа агента по указанному алгоритму. Он находится внутри подписи принципала. Внешний cnf привязывает выданный токен к ключу proof-of-possession. Проверяющий обязан установить их совпадение.

Каждый элемент может быть валиден отдельно, но комбинация — нет. Ошибка устройства, посредник или скомпрометированный издатель могут подставить другой ключ, не ломая внешнюю подпись. Версия 2 связывает только agent_id и допустима лишь с описанными мерами против подмены; версию 1 надо отклонять, новые DA используют версию 3.

kid лишь выбирает кандидата из уже доверенного набора. x5c и x5t тоже не создают доверие фактом присутствия. Заголовок указывает путь проверки, но не является её корнем.

Продление как новое согласие

Издатель может сократить срок, но внешний exp - iat и дата окончания не могут превысить ограничения DA. Nonce DA одновременно служит её jti, расходуется при первой выдаче и не может породить второй внешний токен. Для продления нужна новая подписанная DA со свежим nonce.

Это не то же самое, что повтор запроса. Один access token допустимо предъявлять многократно; повтор proof контролирует, например, jti DPoP. Digest DA, расход nonce, идентификатор токена и proof запроса должны учитываться отдельно.

Полный профиль также сверяет принципала, capabilities, режим, ограничения и расположение subject/actor. Несовпадение требует отказа, а не скрытого сокращения прав. Затем локальная политика решает допустимость действия. Криптография не доказывает выполнение или внешний результат. Облегчённый consumer profile может в разрешённом малорисковом режиме не иметь DA, но тогда у него нет той же аттестации принципала.