Кратко

  • Первая проверка AIP подтверждает подпись предъявленным ключом и тем самым владение им; вторая сверяет ключ с привязкой к agentDid в реестре проверяющей стороны или разрешённом DID-документе.
  • Версия 03 разводит полномочия провайдерского did:web и экосистемного did:opena2a. Заявленные самим агентом тип, цель и возможности не создают разрешения.

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

Отказ не означал, что подпись поддельна. Она точно доказала владение закрытым ключом, парным предъявленному открытому. Она не ответила, почему именно этот ключ вправе выступать от имени указанного agentDid.

На этом различии построена версия 03 OpenA2A Agent Identity Protocol (AIP). Она опубликована 2 октября 2026 года как индивидуальный Internet-Draft и истекает 3 апреля 2027 года. Это не RFC, не документ рабочей группы, не консенсус IETF и не свидетельство внедрения. Заявленный Standards Track — намерение авторов, а не полученный статус.

Подписано не всё сообщение

Проверяющая сторона формирует вызов: 32 случайных байта challenge, заявленный agentDid, 16-байтовый nonce, issuedAt, expiresAt и issuerDid. Время записывается в UTC по RFC 3339, окно составляет пять минут.

Агент подписывает строку:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

Ответ дополнительно несёт publicKey, keyId, signedAt и algorithm. Эти четыре поля в подписанную строку не входят. Вложенный ключ годится для проверки владения, но не может сам удостоверить своё полномочие. Любой создатель пары ключей способен корректно подписать под собственным ключом.

Поэтому результат первого шага должен звучать узко: «подпись действительна под предъявленным ключом». До внешней привязки это ещё не «агент аутентифицирован».

Два правила отвечают на разные вопросы

Сначала AIP проверяет подпись ключом из ответа. Затем этот ключ сравнивается с ключом, заранее привязанным к agentDid в реестре проверяющей стороны или DID-документе. Черновик прямо запрещает доверять одному лишь встроенному publicKey.

Свежесть, одноразовый nonce и доверенный issuerDid — отдельные барьеры. Они не создают принадлежность. Свежий, не повторённый ответ от непривязанного ключа остаётся ответом от непривязанного ключа.

Раздельность нужна и в эксплуатации. Сервис подписи может работать, когда резолвер недоступен, выдаёт старый документ или скомпрометирован. Верный DID-документ не исправит неверную подпись. Один флаг verified уничтожает происхождение решения и мешает расследованию.

Метод DID назначает центр власти

Версия 03 отдаёт провайдерские идентификаторы методу did:web; DID-документ публикует провайдер. Контроль домена, TLS, публикации, кэша и восстановления становится частью идентификационной власти.

did:opena2a предназначен для экосистемного масштаба, и провайдер личности не обслуживает такие документы. Прежняя форма did:aip:aim_ объявлена устаревшим псевдонимом. Идентификатор следует считать непрозрачным и передавать подходящему резолверу, а не выводить доверие из знакомого префикса.

Это распределение управления, а не правка строки. did:web наследует доступность и восстановление провайдера. Экосистемный вариант требует иной процедуры обновления, управления и споров. Незаметный fallback позволяет одной области доверия говорить за другую.

В черновике отмечено, что на 8 сентября 2026 года эталонный резолвер отвечал только на старый псевдоним. Это не доказывает нынешнее состояние производства, но показывает миграционный разрыв между указанным методом и методом, который понимает код. Аудит должен хранить фактические метод, резолвер и документ.

Самоописание не выдаёт доступ

type агента информативен и не должен участвовать в решениях безопасности. Необязательный declaredPurpose может дать контекст идентичности или аттестации, но его отсутствие не основание для отказа, а наличие не вход авторизации.

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

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