Кратко

  • draft-wei-aic-jwt-01 опубликован 8 сентября 2026 года как активный индивидуальный Internet-Draft. Это не принятая работа IETF, не утверждённый стандарт и не свидетельство внедрения; Experimental — лишь заявленная автором цель.
  • Полный профиль вкладывает подписанный принципалом JWT DelegationAuthorization в AIC-JWT, подписанный эмитентом. Внутренняя подпись защищает разрешение и agent_id; внешняя охватывает точную строку DA и claim cnf.
  • Редакция 01 говорит, что нынешний DA связывает делегирование с идентичностью агента. Привязка открытого ключа внутри DA оставлена будущей версии; сегодня ключ доказательства владения указан во внешнем cnf.
  • Квитанция о привязке ключа должна хранить утверждение каждого подписанта, а не только результат «обе подписи верны». Это предложение Daniel Kade, а не требование черновика.

Новая редакция не означает решения IETF

Объявление I-D датирует версию 01 8 сентября, 14:48 UTC. Datatracker относит её к Individual Submissions и показывает I-D Exists; у документа нет RFC stream, ответственного Area Director и даты telechat. Internet-Draft может подать любой человек. Надпись «Intended status: Experimental» сообщает желаемое направление автора, но не доказывает принятие, консенсус, одобрение или рабочее развёртывание.

При этом изменение существенно. AIC-JWT задуман как прикладное представление модели отдельного X.509 AIC-черновика для HTTP, веба и OAuth. JWT и JWS служат контейнером. Смысл полномочий, схемы capabilities и локальная политика исполнения остаются вне них.

Официальное сравнение показывает переход DA claim set с версии 1 на 2, добавление полей RFC 7523 и требование закрыто отклонять старый формат. Важнее для управления то, что текст прямо разделяет идентификатор уполномоченного агента и ключ, которым тот доказывает владение токеном.

Внутренняя подпись фиксирует содержание разрешения

В описанном PKI-процессе агент генерирует пару ключей и формирует запрос с capabilities, режимом делегирования, ограничениями и nonce. Принципал проверяет запрос, подписывает DA JWT и возвращает его. Агент передаёт DA центру сертификации. В режиме OAuth AS тот же DA предъявляется token endpoint как JWT bearer authorization grant по RFC 7523.

В DA находятся iss, sub, aud, exp, jti, а также agent_id, привязка принципала, причина, полномочия, режим, ограничения, запрошенный срок, время и nonce. Ключ проверки обязан соответствовать привязке принципала; jti равен nonce. Тип aic+da+jwt отделяет внутренний документ от внешнего aic+jwt.

Claim da переносит точную compact-строку. Проверяющая сторона не должна заново сериализовать её. Эмитент не может изменить capability, аудиторию, режим или agent_id, не разрушив подпись принципала. Но и ключа принципала недостаточно для внешнего токена: его подписывает эмитент.

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

Нынешний ключ находится во внешнем cnf

Обязательный claim cnf связывает токен с proof-of-possession-ключом агента. RFC 7800 определяет эту семантику; рекомендуется JWK thumbprint jkt из RFC 7638. При DPoP он обязан совпасть с ключом proof. В mTLS его можно сравнить с ключом клиентского сертификата.

Редакция 01 повторяет границу в PKI и OAuth-процессах. Привязка ключа непосредственно в DA зарезервирована для будущего claim set. В нынешней версии предъявляемый ключ связывает cnf во время использования. Поскольку cnf расположен во внешнем payload, его вместе с неизменённым DA покрывает подпись эмитента.

Это не даёт эмитенту права свободно выбирать ключ. В описанном потоке ключ создаёт агент, а принципал проверяет запрос. CA или AS обязаны проверить DA, ключ принципала, аудиторию, срок, уникальность nonce и ограничения. Внешний токен не может жить дольше подписанного grant.

Разница нужна ретроспективно. Две зелёные проверки показывают: принципал подписал agent_id, эмитент подписал конкретный cnf. Они не превращают второе утверждение в часть первой подписи. Если интерфейс показывал ключ принципалу и получил подтверждение, этот факт должен иметь отдельную запись выдачи.

Само наличие cnf тоже не равно проверке владения. Черновик предупреждает, что AIC-JWT не sender-constrained автоматически. Без DPoP или аналога украденный токен может работать как bearer credential до истечения срока. cnf называет ожидаемый ключ; решение verifier подтверждает, что предъявитель действительно доказал владение.

Квитанция должна оставить четыре решения раздельными

Я предлагаю сохранять точный хеш и версию DA, идентификатор ключа принципала, agent_id, эмитента, хеш внешнего токена, метод cnf и отпечаток ключа, политику выдачи, результат расходования nonce, эффективный срок, метод proof of possession и решение verifier. Явное подтверждение ключа принципалом должно быть отдельным событием.

Нужны две строки для replay. DA nonce расходуется при первой выдаче и не должен породить второй внешний токен. Но уже выданный access token может предъявляться несколько раз в пределах срока. За защиту каждого запроса отвечает DPoP proof jti или эквивалент. Запись «nonce использован» не подтверждает одноразовость предъявления.

Квитанцию необязательно публиковать. Постоянные отпечатки и связи между принципалом и агентом создают риск корреляции. Авторизованному аудитору можно раскрывать commitment, результат политики или ссылку на закрытую запись. Минимизация не требует забыть владельца решения.

Policy Mirror Хэн Лу показывает распределение: принципал выбирает идентичность и capabilities; эмитент принимает DA и подписывает текущую привязку ключа; verifier применяет доказательство владения и локальную политику; владелец ресурса получает результат действия. Одна зелёная иконка стирает именно эту цепочку.

Источники