Кратко

  • draft-mcguinness-oauth-client-attesters-00 предлагает метаданные client_attesters, где для аттестатора указываются точные issuer и jwks_uri. Редакция 00 — индивидуальный Internet-Draft, а не RFC или принятый стандарт.
  • Одобрение издателя и доверие authorization server независимы: первое отвечает, кто может говорить за клиента, второе — следует ли верить и откуда брать ключи.
  • Удаление одобрения после обновления кэшей блокирует новые проверки, но не отзывает существующие grants и tokens и не меняет прямые проверки на resource server.

В отчёте об инциденте легко написать: «аттестатор удалён». Но эта фраза ничего не говорит о токене, выпущенном час назад, о свежем кэше метаданных или о resource server с собственной конфигурацией доверия. Изменение публикации и прекращение доступа — разные события.

Проект OAuth 2.0 Client Attester Endorsement закрывает пробел ATTEST. Базовый механизм описывает утверждение Client Attester о Client Instance и ключе, но не устанавливает, кто дал ему право говорить за конкретный client_id. Новый параметр помещает такую связь в авторитетные метаданные клиента.

Каждая запись связывает значение iss через точный issuer с HTTPS-адресом JWK Set. Это заявление издателя о допустимом представителе. Оно не является trust anchor, не аутентифицирует экземпляр само по себе, не выражает делегирование пользователя и не предоставляет ресурс.

Нужна общая часть двух множеств

Сервер принимает аттестацию, только если выбранные метаданные сейчас одобряют issuer и локальная политика разрешает эту пару клиент—аттестатор вместе с методом доверия к ключам. Сервер может сузить опубликованный список, но не расширить его. Издатель может убрать представителя, но не навязать доверие.

В режиме publisher-authorized key selection сервер заранее разрешает издателю выбирать аттестатора и источник ключей. Он получает указанный jwks_uri с ограничениями HTTPS, origin, пути и сети. Это удобно в крупной системе, однако assurance не независимо от издателя: контролирующий CIMD может указать собственный аттестатор.

В режиме AS-configured attester trust сервер сам задаёт источник для точного issuer. Опубликованный URI должен совпасть с ним или явным alias и не становится запасным адресом. Несогласие означает отказ.

Приоритет распространяется шире одного клиента. Если configured trust существует для issuer хотя бы где-то, он управляет этим issuer для всех клиентов. Удаление записи не передаёт выбор издателям автоматически. Alias также действует на весь issuer, поэтому локально выглядящее изменение может иметь общий blast radius.

Порядок проверки закрепляет происхождение ключа

Сначала выбирается один авторитетный источник metadata для client_id; регистрация и CIMD не объединяются. Затем находятся запись issuer == iss, политика связи, источник ключей и ровно один подходящий асимметричный ключ для kid.

Ключ связан сразу с client, issuer, source и policy. Один kid или общий набор ключей нескольких записей этого не обеспечивает. Заголовки jku, x5u, x5c, jwk не выбирают ключ. После этого проверяются подпись, proof, точное sub == client_id и остальные условия ATTEST. Решение о grant и доступе принимается отдельно.

Отзыв состоит из нескольких процессов

Издатель удаляет endorsement, но свежий cache может использовать его до конечного настроенного срока. Проект не задаёт общий максимум; измеримая граница должна быть частью trust agreement. Увиденные 404 или 410 прекращают использование старого документа, а timeout или 5xx не отменяют ещё свежую копию.

Ротация ключа требует перекрытия: опубликовать новый, дождаться кэшей, начать подпись и сохранить старый до истечения аттестаций. Новое расположение требует также обновления client metadata, а в configured-режиме — согласования с оператором.

Главное: withdrawal действует на будущую аутентификацию. Он не отзывает уже выданные grants, access tokens или refresh tokens. Для прекращения нужны отдельный revocation, запрет refresh, inactive в introspection и учёт локально проверяемых токенов до их истечения.

Resource server, напрямую принимающий Client Attestation, использует настроенное доверие. Этот профиль не определяет для него discovery endorsement. Значит, удаление на стороне authorization server туда не распространяется.

Нужна квитанция о решениях

Операционная запись сохраняет client_id, единственный metadata source, hash, время получения, состояние cache и срок; точный endorsement и полномочие издателя; trust mode и причину приоритета; source, aliases, hash и свежесть JWK Set; kid, алгоритм и единственный ключ.

Отдельно фиксируется, была ли attestation обязательной. Само наличие client_attesters не делает её обязательной: при optional signal политика может продолжить другую аутентификацию. Grant decision получает собственную строку.

При withdrawal добавляются время первого наблюдения, convergence, последняя успешная проверка, истечение аттестаций, token revocation, refresh, introspection, offline window и прямые verifier. Это операционная модель Daniel Kade, а не нормативное требование проекта.

Публичная ошибка invalid_client_attestation намеренно скрывает причину. Внутренняя телеметрия должна различать отсутствие endorsement, конфликт источников, неоднозначный kid и временный fetch failure. Новая аттестация не исправит конфликт политики.