Кратко

  • В редакции 08 описаны две разные конструкции: амортизированный VOPRF-пакет с одним доказательством и общий пакет с необязательным ответом на каждой позиции.
  • Свежий nonce нужен для каждого токена, однако HTTP 200, HTTP 206 или верное общее доказательство не сообщают, сколько токенов финализировано и надёжно записано.
  • Операционный квиток должен сверять этапы, не превращая идентификатор пакета в постоянную связь между выдачей и будущим погашением.

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

draft-ietf-privacypass-batched-tokens-08 решает реальную задачу: базовые протоколы RFC 9578 выдают токены по одному, а большим клиентам нужны меньшие накладные расходы. Документ датирован 4 мая 2026 года и передан в IESG как кандидат Standards Track. На дату исследования его состояние — AD Evaluation::Revised I-D Needed; это не RFC. Предлагаемый тип 0x0005 также отсутствует в действующем реестре IANA.

Два пакета означают две модели учёта

В амортизированном варианте клиент отправляет несколько blinded elements одного поддерживаемого приватно проверяемого типа. Издатель вычисляет результат для каждого элемента, но создаёт одно доказательство для списков входов и выходов. Клиент проверяет его до построения отдельных authenticator.

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

Частичная выдача должна вернуть 206, полное отсутствие выдачи — 400. Клиент пропускает пустое место и финализирует остальные ответы по правилам их типов.

Показатель «batch OK» стирает эту разницу. В первом случае есть общий шлюз доказательства. Во втором частичный успех — часть протокольной истины. Для восстановления нужны обе семантики.

Свежий nonce не гарантирует локальную уникальность

Для каждого амортизированного токена клиент выбирает новый 32-байтовый nonce. Вместе с типом, digest challenge и key ID издателя он формирует индивидуальный token input. Общая поездка не делает токены копиями.

Однако реализация должна сопоставить i-й результат с i-м nonce и нужным фрагментом authenticator. Перестановка, усечение или ошибка индекса возможны внутри внешне успешного пакета.

После финализации начинается жизнь в хранилище. Процесс может упасть до commit, записать часть строк, повторить вставку или восстановить из резервной копии уже использованный токен. Требование свежего nonce не подтверждает корректность базы данных.

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

Амортизируется доказательство, а не весь обмен

Сложность BlindEvaluateBatch остаётся линейной по Nr: вычисление выполняется для каждого элемента. Экономия возникает на формировании доказательства. По оценке проекта, при росте пакета практическая стоимость приближается примерно к половине Nr отдельных выдач.

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

Единое доказательство расширяет общую область отказа. Неподдерживаемый тип, неизвестный truncated key ID, превышение лимита или один недесериализуемый blinded element приводят к 422 для амортизированного запроса. Ошибка разбора ответа или проверки доказательства на клиенте завершает протокол.

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

206 — инструкция сверять позиции

В общем режиме 206 означает не «почти ошибку», а точный факт: часть запросов обслужена. В теле есть полезные ответы.

Клиент не должен отбрасывать их из-за отсутствия 200 и не должен учитывать весь request из-за класса 2xx. Он проходит вектор, пропускает пустые позиции, финализирует существующие ответы и пополняет запас только после долговременного commit.

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

Полезная формула:

requested ≠ present ≠ finalized ≠ committed ≠ available ≠ redeemed.

Поле issued следует разделить на наблюдения издателя, клиента и хранилища. Иначе одна метрика будет менять смысл посреди расследования.

Повтор — самостоятельное управленческое решение

После 206 можно повторить только пустые позиции, если сопоставление сохранилось. Повтор всего пакета способен создать дополнительные валидные токены. После сетевого обрыва нельзя знать по одному timeout, выполнил ли издатель работу.

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

Нужно заранее определить допустимые состояния повтора, его единицу, влияние на квоту и владельца неоднозначного результата. Временный позиционный квиток может содержать безопасный digest запроса, тип, key epoch, наличие ответа, финализацию и commit. Он не должен сопровождать bearer token в дальнейшие логи Origin.

Timeout подтверждает потерю наблюдения, а не отсутствие действия.

Лимит пакета распределяет возможности

Издатель устанавливает максимум для амортизированного запроса и может игнорировать общие запросы сверх лимита. Security Considerations рекомендует ограничения по клиенту и ключу.

Большой лимит помогает prefetch и офлайн-работе, но концентрирует bearer value и ущерб от утечки. Малый лимит уменьшает запас и делает издателя более постоянной зависимостью. Во время ротации ключей лимит и смешанные IDs способны вызвать скачок 206.

Это политика, а не безымянная константа. Ей нужны владелец, версия, наблюдение и исключение. Стандарт координирует формат и семантику, но не должен устанавливать универсальную квоту. Локальную abuse-политику тоже нельзя выдавать за требование IETF.

Регистрация не равна внедрению

Редакция 08 просит 0x0005 и четыре media types. В зафиксированном реестре IANA этого значения нет. 20 сентября Security AD попросила уточнить ссылки, allocation и провести ранний HTTPDIR review.

В сообщении отмечено, что замечания должны быть легко устранимы. Это не отказ и не вывод об уязвимости. Это свидетельство незавершённого стандартизационного шага.

Будущая строка IANA докажет координацию номера, не поддержку в коде. Отчёт о реализации не равен interoperability. Interoperability не равна правильному запасу. Shepherd говорит о сильном согласии небольшой WG и сообщениях о реализациях, но не даёт полного перечня.

Нельзя купить аудит ценой корреляции

RFC 9576 отделяет контексты attestation, issuance и redemption, потому что приватность зависит от возможности объединять наблюдения. Размер, время, издатель и key epoch пакета добавляют метаданные.

Постоянный batch ID, связанный с локальными токенами и дальнейшими запросами Origin, восстанавливает трассу. Аудит должен отвечать, сходится ли баланс, а не заранее индексировать будущие действия пользователя.

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

Трёхуровневый квиток

Уровень пакета хранит режим, endpoint, типы, digest challenge/конфигурации, key epoch, число запросов, HTTP status, длину вектора, digest доказательства или ответа, лимит и время.

Уровень позиции временно хранит digest запроса, присутствие ответа, десериализацию, финализацию и commit. Порядок удаляется после выполнения цели.

Уровень запаса ведёт начальный остаток, подтверждённые добавления, карантин, удаления, выбор, подтверждённые погашения, неоднозначность и конечный остаток транзакционно.

Для redemption нужен другой квиток: совместимость challenge, предъявление, replay state, авторизация Origin и эффект приложения. Квиток выдачи не владеет этим выводом.

Цепочка выглядит так:

настроить -> аттестовать -> запросить -> допустить -> ответить -> финализировать -> записать -> выбрать -> погасить -> авторизовать -> наблюдать.

Пакет экономит операции. Он не сокращает границы ответственности.