Кратко

  • 28 сентября 2026 года появилась первая версия индивидуального Internet-Draft о client_instance_id. Удостоверяющая сторона может сохранять этот идентификатор при подтверждённой смене ключа той же регистрации. Это не RFC, не решение рабочей группы и не свидетельство внедрения.
  • Проект не перепривязывает ранее выданные токены обновления. По умолчанию базового проекта токен связан с прежним ключом, поэтому запрос с новым ключом не проходит проверку даже при совпадении инстанса, если иной применимый профиль не изменил правило.
  • Сервер авторизации отдельно сверяет текущую проверенную аттестацию с Source Instance Identity, записанной для разрешения. Совпадение идентичности не заменяет проверку владения ключом и условий токена.

Два правдоподобных ответа на один запрос

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

Первый проект К. Макгиннесса в разделе 5.1 проводит чёткую границу. Профиль описывает идентичность одного инстанса через проверенную смену ключа; он не создаёт разрешений, привязанных к инстансу, и не переносит привязку существующего токена. Базовый проект аутентификации клиента по аттестации по умолчанию связывает токен обновления с Client Instance Key. Поэтому запрос с новым ключом проваливает проверку старого токена. Другое реально применимое правило могло бы задать иную привязку, но одно лишь новое имя инстанса таким правилом не служит.

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

Похожая копия не обязательно правопреемник

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

Область идентификатора по умолчанию ограничена одним Receiver. Это не универсальный постоянный номер устройства во всех службах. Клиенту и аттестеру следует осознанно разделять области и ключи; сам получатель не может по своей аттестации проверить поведение в других областях. Проект также прямо запрещает выводить из идентичности клиента полномочия пользователя или представителя: она сама по себе не задаёт sub, не продлевает цепочку act и не отменяет доказательства владения ключом. Необязательный контекст client_instance в токене или ответе интроспекции сообщает об установке, а не о новом праве.

Когда разрешение создано по предложенному профилю, сервер авторизации сохраняет Source Instance Identity. При обновлении он проверяет новую аттестацию и сравнивает идентификатор с записью. Несовпадение рушит условие непрерывности. Совпадение не устраняет отдельный вопрос о привязке токена к ключу. Для разбора отказов полезно видеть оба результата, иначе единая отметка «аттестация действительна» скроет, какая именно дверь осталась закрыта.

Запись Datatracker называет документ первым индивидуальным Internet-Draft в состоянии I-D Exists. Намерение автора двигаться к Standards Track не равно принятию рабочей группой или публикации RFC. В изученных первичных материалах нет независимого подтверждения эксплуатации системы, совместимости реализаций либо происшествия. Обсуждаемая здесь граница — свойство предлагаемого механизма.

Источники