Кратко

  • В draft-ietf-oauth-status-list-21 Referenced Token указывает URI и индекс в сжатом списке. Защищённый Status List Token может нести для множества токенов значения VALID, INVALID, SUSPENDED либо прикладные статусы. Редакция 21 одобрена IESG и находится в очереди RFC Editor, но пока остаётся Internet-Draft, а не RFC.
  • По умолчанию запись описывает состояние, заявленное при выпуске списка. iat, exp и ttl задают время выпуска, допустимости и кэширования, но автоматически не сохраняют момент перехода, полномочного инициатора, причину, первое появление у Provider или решение relying party.
  • Daniel Kade предлагает минимальный внепротокольный акт: отпечатки токена и списка, URI/индекс, проверку эмитента, четыре раздельных времени, декодированную семантику, локальный предел свежести, действие и последующую коррекцию. Это редакционная рекомендация, не требование IETF и не основание для постоянного профилирования предъявлений.

Token Status List полезен именно потому, что не превращает каждую проверку в персональный запрос о конкретном credential. Много токенов делят один битовый массив. Проверяющая сторона получает защищённый объект, читает названную позицию и может использовать кэш в установленных пределах. Снижаются объём передачи и возможность эмитента сразу определить, какой именно токен интересует проверяющего.

Эта экономия не является обещанием вести историю каждого отзыва. Ошибка управления возникает позже, когда краткое «мы прочли такой статус» начинает заменять вопрос «что именно система знала, когда приняла долговечное решение?». Между источником состояния, выпуском списка, его доставкой и прикладным действием находятся разные полномочия и часы.

Одобренный проект всё ещё называется проектом

Datatracker указывает редакцию 21 от 21 июня 2026 года как Standards Track Internet-Draft рабочей группы OAuth. История фиксирует одобрение редакции 20 IESG 4 июня, переход в очередь RFC Editor, публикацию редакции 21 21 июня и состояние RFC Production Center Awaiting First editor 13 августа. Документ одобрен и находится на продвинутой стадии, но на момент исследования ещё не стал RFC.

Текст редакции 21 истекает 23 декабря 2026 года. Официальный diff 20→21 закрепляет нужную версию. Стадия редактирования не доказывает распространённость или качество реализаций. OAuth Working Group отвечает за спецификацию, а не за гипотетические сервисы в примерах.

Документ охватывает токены, защищённые JOSE или COSE, включая JWT, SD-JWT, CWT и применения ISO mdoc. RFC 7515 о JWS и RFC 7519 о JWT дают основу JSON; RFC 8392 о CWT и RFC 9052 о COSE — основу CBOR. Status List Token не копирует исходный credential, а отдельно говорит о состоянии, способном измениться после выпуска.

Координата находит ячейку, но не распоряжение

Механизм помещает в Referenced Token объект status_list с uri и idx. URI называет Status List Token, неотрицательный индекс — место чтения. Координата отвечает, где искать заявление, но не сообщает, кто, почему и когда изменил источник.

Status Issuer выбирает один, два, четыре или восемь битов на Referenced Token, выдаёт отдельные индексы, упаковывает значения от младшего бита к старшему внутри байта и сжимает массив DEFLATE в формате ZLIB. RFC 1951 и RFC 1950 задают эти слои. Массив встраивается в JWT или CWT и защищается подписью либо MAC.

Архитектура различает Issuer, Status Issuer и Status Provider. Первый выпускает Referenced Token. Второй получает информацию о состоянии и создаёт защищённый список. Третий его отдаёт. Одна организация может исполнять все роли, либо доставка может идти через внешнего оператора или CDN без передачи права менять подписанные байты.

Отсюда следует важное различие доказательств. Криптографическая проверка подтверждает происхождение и целостность списка. Наблюдение HTTP-ответа подтверждает доставку конкретного объекта в конкретное время. Ни одно само по себе не устанавливает, когда закрыли учётную запись или кто санкционировал приостановку.

Начальный реестр присваивает 0x00 значению VALID, 0x01INVALID, 0x02SUSPENDED, а некоторые диапазоны оставляет приложению и будущей регистрации. Если на токен выделено несколько битов, вся группа выражает одно значение, а не несколько событий.

Кроме того, VALID не отменяет правила самого Referenced Token. Формат, подпись, обязательные claims, срок и иные ограничения проверяются первыми. Истёкший токен остаётся истёкшим при VALID в списке. После чтения состояния relying party применяет собственную политику. Проверка credential, проверка списка, декодирование статуса и авторизация — четыре разных вывода.

У события, списка, доставки и решения разные часы

Первые часы принадлежат источнику. Они отмечают реальный или административный переход: отзыв, приостановку, восстановление. Редакция 21 не определяет этот upstream-процесс. Компактное значение не обязано содержать его автора, основание или время.

Вторые часы принадлежат выпуску. Обязательный iat называет время выпуска Status List Token. Рекомендуемый exp показывает, когда Status Issuer считает объект истёкшим. Это границы защищённого заявления, но не время индивидуального отзыва.

Третьи часы принадлежат доставке и fetch. Внешний Provider может раздавать ранее подписанный объект. Время получения доказывает наблюдение, а не создание списка и не изменение в исходной системе.

Четвёртые часы принадлежат прикладному решению. Оно может произойти немедленно, после очереди или в пакетной обработке. Здесь локальная политика соединяет возраст кэша, статус и остальные условия с разрешением, отказом или дополнительной проверкой.

ttl управляет кэшем, но не объединяет эти часы. Проект описывает обновление после «время fetch + ttl», распределяющее нагрузку, и проверку около iat + ttl для критичных применений с небольшим запасом на выпуск и доставку. Если HTTP-заголовки расходятся с защищёнными claims, приоритет имеют exp и ttl Status List Token. RFC 9110 задаёт HTTP-семантику; допустимую свежесть выбирают профиль и relying party.

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

Исторический снимок не является журналом причины

Обычный режим предоставляет самую свежую информацию. Опционально клиент добавляет time=<timestamp>. Поддерживающий сервер может вернуть список, действовавший в указанный момент, либо ошибку. Если статический хостинг игнорирует параметр и выдаёт текущий файл, клиент должен отвергнуть его, когда запрошенное время не попадает в защищённое окно iat/exp.

Два снимка ограничивают переход. VALID в 10:00 и INVALID в 10:15 показывают, что новое заявление появилось ко второй выдаче. Они не доказывают, что человек принял решение в 10:02, источник записал его в 10:07, а Provider показал в 10:14. Авторитет и причина остаются в другом журнале, если он вообще существует.

Историческая функция несёт риск приватности. Документ рекомендует не включать её без веской причины и оценки последствий. Relying party, сохранивший URI/индекс и регулярно проверяющий их, может построить профиль состояния. Внешний наблюдатель может архивировать списки и оценивать объёмы либо частоту отзывов. Объяснение одного решения не требует постоянной истории обо всех.

Herd privacy заканчивается на метаданных

Один список для множества Referenced Tokens затрудняет Issuer определение интересующего токена по единичному запросу. Проект называет это herd privacy. Больший список расширяет множество анонимности и одновременно увеличивает передачу.

Уникальный URI на токен, очень маленькая или необычно размерная список уменьшают защиту. HTTP-запрос может показать адрес relying party. Пара URI/индекс сама коррелируема, и сотрудничающие проверяющие способны узнать предъявления одного токена. RFC 9901 даёт контекст выборочного раскрытия SD-JWT; RFC 9458 определяет Oblivious HTTP как возможную relay-технику.

Среди мер — внешнее размещение, случайные или псевдослучайные индексы, фиктивные записи, несколько списков, одноразовые партии и новый индекс при перевыпуске. Семантика тоже раскрывает сведения. SUSPENDED сообщает о временной фазе больше, чем простой результат допуска; прикладные значения могут быть ещё чувствительнее.

Решенческий акт должен соблюдать ту же минимизацию. Во многих случаях достаточно отпечатков и времён. Полная копия credential, IP и каждое предъявление создают новый центр наблюдения. Исторический запрос фиксируется только если реально участвовал в решении.

Декодирование — часть доказательства

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

Порядок должен быть восстанавливаем: сначала проверка Referenced Token; затем разрешение URI; проверка типа, подписи/MAC и claims Status List Token; связь subject с URI; применение iat, exp, ttl и локальной свежести; декомпрессия; чтение индекса; толкование зарегистрированного значения; прикладное решение.

Индекс за пределами массива означает, что заявление о статусе невозможно, и Referenced Token должен быть отвергнут. Неудача проверки списка также оставляет статус без заявления, а проект рекомендует отказ. Это не INVALID: там Status Issuer выразил состояние, здесь пригодного доказательства нет.

Два отпечатка и четыре времени

Предложенный Daniel Kade акт начинает с минимального отпечатка Referenced Token и точного хеша использованного Status List Token. Он хранит URI/индекс, Status Issuer, наблюдённого Provider, разрешение ключа, результат подписи или MAC и относящуюся к выводу версию декодера либо тестов.

Затем отдельно записывается время перехода в источнике, только если оно известно; иначе — неизвестно. Сохраняются iat, exp, ttl, время fetch, возраст кэша при применении и время решения. Указываются текущий или исторический запрос, timestamp, числовое значение, зарегистрированный смысл, локальный предел, бизнес-правило, действие и последующее исправление или закрытие.

Это не расширение Token Status List, а пропорциональный локальный контроль для долговечных последствий. Предпочтительны хеши, короткие ссылки, ограниченный доступ и срок. The Policy Mirror даёт дисциплину сравнения правила и наблюдаемого решения, Running-Code Primacy — внимание к реально исполненному пути, Reality, Not Advocacy — запрет превращать неизвестное в факт. Эти тексты не доказывают реальный OAuth-инцидент.

Источники