Кратко

  • Предлагаемый client_instance_id может сохраниться после проверенной смены ключа, однако его доказательная сила исходит из регистрационного журнала аттестатора, а не из строки.
  • Непрерывность инстанции, привязка ключа, полномочия аттестатора, связь с grant, отображение в токене и установление текущего предъявителя — отдельные решения.
  • Защищаемая модель требует типизированной квитанции: issuer, регистрация, гранулярность, Receiver Scope, старый и новый ключи, событие, свежесть, Consumer Scope и доказательство предъявителя.

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

Но новый ключ ничего не знает о старом. Непрозрачный ID не сообщает, было ли обновление на месте, переустановка, клонирование, восстановление снапшота или появление второго претендента. Главное решение было принято вне нового артефакта: кто-то признал нынешнего владельца преемником прошлой регистрации и сохранил основания этого признания.

Ревизия 00 draft-mcguinness-oauth-client-instance-id опубликована 28 сентября 2026 года. Это активный индивидуальный Internet-Draft, текст которого заявляет предполагаемый Standards Track, но в Datatracker нет статуса рабочей группы, ответственного AD, даты telechat или RFC stream. Он заменяет прежний проект отдельного client-instance assertion. Связанный базовый документ attestation-based client authentication является работой OAuth WG на стадии Working Group Last Call, но этот статус не означает принятия индивидуального профиля. Зафиксированные источники не доказывают реализацию, совместимость, внедрение или практический результат.

Настоящее владение не доказывает историческую преемственность

Базовый механизм отвечает на вопрос, владеет ли разрешённая Client Instance конкретным ключом. Профиль добавляет иной вопрос: та ли это инстанция, которую Receiver видел раньше? После ротации свежая аттестация сама по себе не отличает продолжающуюся установку от новой.

client_instance_id даёт устойчивую ссылку, но точная Source Instance Identity — пара (iss, client_instance_id). Совпавшая строка под другим Issuer не означает ту же историю. Logical Client, заданный client_id, шире: к нему могут относиться многие ноутбуки, контейнеры или агентские процессы. Авторизационный субъект — ещё одна сущность.

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

Идентификатор указывает на доказательства, но не заменяет их

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

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

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

Удаление журнала непрерывности поэтому означает новую регистрацию. Стабильный сигнал платформы не может в одиночку воспроизводить старый ID: иначе переустановка воскресит уже закрытую идентичность. Реальный продукт — не постоянная строка, а управляемый автомат состояний.

Receiver Scope существует, хотя его нельзя прочитать

По умолчанию идентификатор попарно ограничен одним Receiver. Однако Receiver Scope — административный вход регистрации или выпуска, а не OAuth-параметр и не audience аттестации. Receiver не может проверить предполагаемую область по самой строке.

Аттестатор обязан выдавать разные ID для разных Receivers, если явное соглашение не устанавливает общую область. Клиент также должен применять разные Client Instance Keys между областями, которые требуется разделить. Общий ключ способен вернуть корреляцию, от которой защищали парные идентификаторы.

Если scoped-аттестация попадёт не тому Receiver, он не увидит нарушение в ID. Соблюдение зависит от конфигурации клиента и аттестатора, не описанной внутри артефакта. Поэтому операционная квитанция должна содержать выбранную область, версию политики и систему, отвечавшую за её применение.

Это и есть компромисс приватности. Парные ID уменьшают корреляцию между Receivers, зато аттестатор узнаёт Receiver Scope. Широкая общая область может скрыть отдельного получателя от аттестатора, но позволит получателям сопоставлять инстанцию. Повторное использование instance- или DPoP-ключей разрушает оба варианта.

Полномочия аттестатора задаёт доверительная связь

Receiver должен связать разрешённого Attester Issuer с ключами валидации и Logical Clients, за которых тот вправе отвечать. Строка iss, proof of possession или metadata, опубликованные самим клиентом, такой власти не создают. Client Attester Endorsement может быть одним из входов для authorization server, но ресурсный сервер при прямой проверке всё равно нуждается в настроенной связи.

Это два независимых одобрения. Аттестатор утверждает, что предъявитель продолжает конкретную регистрацию. Receiver решает, уполномочен ли этот аттестатор говорить за данного Logical Client по данной политике. Верная подпись неизвестного issuer недостаточна. Разрешённый issuer, в свою очередь, может быть скомпрометирован или преувеличить качество evidence.

Самодекларация, проверка платформой и аппаратный корень не равноценны. Без независимого сигнала скопированные ключи и регистрационное состояние могут быть неотличимы от оригинала. Автоматизация обязана сохранять класс доказательства, а не сводить всё к флагу «valid».

Стабильная личность не переносит привязку refresh token

Профиль позволяет регистрации пережить подтверждённую ротацию. Из этого не следует, что существующий refresh token автоматически привязывается к новому ключу. По умолчанию он остаётся связан с прежним Client Instance Key, если другой разрешённый профиль не определил rebinding.

При refresh сервер проверяет два инварианта отдельно: совпадает ли Source Instance Identity с записанной идентичностью и удовлетворяет ли текущий proof ключевой привязке grant либо разрешённой процедуре переноса. Первое касается исторической преемственности, второе — права использовать grant сейчас.

Такой подход полезен далеко за пределами OAuth. Сохранить строку базы и сменить сертификат — не значит перенести все полномочия. Нужно указать, какое решение разрешило переход credential именно для этого grant, по какой политике и с каким актуальным подтверждением владения.

У приостановки несколько часов

Аттестатор должен прекратить выпуск для suspended или retired регистрации. Authorization server может отозвать grants или объявить токены неактивными. Но согласованность не наступает мгновенно.

Ранее выданная аттестация остаётся приемлемой до истечения срока и clock skew. Access token живёт по своему таймеру. Локальный отзыв не сообщает ничего offline resource server; распространение статуса не входит в профиль. Новая регистрация или иной Receiver Scope могут создать идентичность, которую Receiver не свяжет с заблокированной.

Следовательно, containment имеет временной бюджет и границу admission. Слово «suspended» без решившего органа, времени вступления, затронутой регистрации, множества токенов и охвата уведомления описывает лишь локальную запись.

Downstream-отображение создаёт вторую власть над идентичностью

Необязательный объект client_instance позволяет token issuer передать resource server проверенный контекст. Это не обязательно сырой ID аттестатора. Issuer отображает Source Instance Identity в собственную пару (iss, id) внутри Consumer Scope, определённого audience.

У отображения свои обязательства. Оно обязано разделять разные инстанции, сохраняться при renewal и подтверждённой ротации и быть воспроизводимым, пока действуют связанные grants или tokens. Если карту больше нельзя восстановить, контекст следует опустить, а не назначить новый. Токен без audience или с audiences из разных Consumer Scopes не имеет единственного корректного отображения. Клиент introspection за пределами области не должен его получать.

Итак, возникают два журнала: у аттестатора — от enrollment к Source Identity, у token issuer — от источника к consumer identity. Их владельцы и сроки хранения различаются. Потеря допустимо приводит к отсутствию контекста; тихая замена ложным значением переписывает историю.

Участие в выпуске не устанавливает нынешнего предъявителя

Instance Context не даёт полномочий. Без consuming profile и проверенного sender constraint он сообщает только, какая инстанция участвовала в получении токена. Он не доказывает, что та же инстанция отправила текущий HTTP-запрос.

DPoP, mutual TLS или иной определённый механизм может связать предъявителя при прямом выпуске. Общий binding key не различает отдельные инстанции. Bearer token не поддерживает такую атрибуцию. Если она обязательна, а issuer не может дать связь, контекст нужно исключить, а consumer должен отклонить запрос.

Token exchange усложняет provenance. Валидация input token подтверждает высказывания его issuer, а не каждую более раннюю власть внутри сохранённого контекста. Consuming profile обязан определить, относится ли ID к нынешней или upstream-инстанции, и как доказываются association, preservation и remapping. Контекст — ссылка на одну инстанцию, не actor chain и не отдельный токен.

Типизированная квитанция непрерывности

Практическая квитанция начинается с Attester Issuer, ключа проверки, Logical Client, enrollment, гранулярности, Receiver Scope и версии trust policy. Для перехода она соединяет fingerprints прежнего и нынешнего ключей, событие жизненного цикла, custody evidence, проверки непрерывности, свежесть, время и исход: сохранено, новая регистрация, retired, suspended или forked.

Для grants она отдельно хранит Source Instance Identity, key binding и возможный профиль rebinding. Для downstream — token issuer, вход карты, Instance Context, Consumer Scope, audience, эпоху хранения и происхождение сохранения или переназначения. Для каждого запроса — sender constraint и локальное решение resource server.

Последнее ребро связывает защищённую операцию с наблюдаемым результатом. Успешная ротация закрывает лишь названный переход. Она не закрывает текущую целостность ПО, авторизацию, предъявителя, исполнение или эффект.