A prova do lote passou. Quantos tokens entraram no estoque?

Resumo

• O rascunho 08 define dois lotes: um VOPRF amortizado, com uma prova sobre vários elementos, e outro genérico, com resultados opcionais em cada posição.
• Nonces novos preservam entradas individuais, mas HTTP 200, HTTP 206 ou uma prova válida não informam quantos tokens foram finalizados, gravados e mantidos disponíveis.
• O recibo operacional deve reconciliar quantidades sem criar um identificador permanente capaz de ligar emissão e resgate.

O erro começa com uma frase confortável: “o emissor entregou o lote”. Ela pode significar que o servidor aceitou o corpo, avaliou os elementos, produziu uma prova, devolveu algumas respostas ou que o cliente realmente confirmou tokens utilizáveis. Cada sentido pertence a uma etapa diferente.

draft-ietf-privacypass-batched-tokens-08, de 4 de maio de 2026, tenta resolver um gargalo real do RFC 9578: obter muitos tokens um a um repete viagens e trabalho de prova. O documento está submetido ao IESG como proposta de Standards Track, mas, no corte desta pesquisa, permanece em AD Evaluation::Revised I-D Needed. Ainda é Internet-Draft. O registro público da IANA também não contém o tipo sugerido 0x0005.

O mecanismo merece ser avaliado pelo que faz. A etiqueta não deve receber autoridade sobre fatos posteriores.

O lote amortizado é coletivo; os tokens continuam individuais

O cliente cria um nonce aleatório novo de 32 bytes para cada token, combina-o com tipo, resumo do desafio e identificador da chave do emissor e gera os elementos cegados. O emissor avalia cada elemento, porém produz uma prova para as listas completas.

A economia está na prova. A avaliação ainda cresce linearmente com Nr; o rascunho estima que o custo prático se aproxima de metade do custo de Nr emissões separadas quando o lote cresce. Não desaparecem parsing, rede, admissão, finalização ou armazenamento.

O benefício também cria um domínio coletivo de falha. Tipo não suportado, chave truncada desconhecida, lote acima do limite ou qualquer elemento que não possa ser desserializado leva a 422. No cliente, erro na desserialização da resposta ou na prova encerra o protocolo.

Por isso, o tamanho do lote é uma escolha de risco. Quanto maior, menor a repetição de prova; ao mesmo tempo, mais intenções futuras dependem do mesmo parser, da mesma chave, da mesma decisão de admissão e do mesmo ponto de verificação.

O lote genérico conserva o vazio no lugar certo

O modelo genérico empacota TokenRequests comuns e pode misturar tipos registrados. Sua resposta é um vetor de valores opcionais. A ausência em uma posição significa falha ou recusa daquela solicitação, sem cancelar necessariamente as seguintes.

Quando há sucesso parcial, o emissor deve retornar 206 e continuar. Quando não emite nenhum token, retorna 400. O cliente ignora posições vazias, finaliza cada resposta não vazia com a solicitação correspondente e só então sabe quais tokens existem.

O 206 não é um erro genérico nem uma autorização para somar o tamanho do pedido. É um recibo de incompletude. Ele manda examinar o vetor.

A distinção importa em rotação de chave. O texto cita solicitações do mesmo tipo com mais de um truncated_token_key_id como situação possível de 206. Repetir o lote inteiro sem guardar posições pode esconder uma divisão de configuração e consumir nova cota.

Contagem precisa de um caminho, não de um número

Um sistema maduro mantém contadores separados:

requested -> response_present -> finalized -> committed -> available -> redeemed.

Também precisa de uma coluna de resultado ambíguo. Uma queda de rede não mostra se o emissor trabalhou. Uma queda local depois da finalização não mostra se o commit terminou. Forçar essas situações para “sucesso” ou “falha” produz saldo falso.

O nonce novo não resolve a contabilidade. O software ainda precisa associar a saída i à entrada i, evitar registros duplicados, impedir dois consumidores de escolher o mesmo token e restaurar backups sem ressuscitar inventário já gasto.

Somente registros finalizados, não duplicados e confirmados em transação durável devem aumentar o saldo disponível. Resposta 200 e prova válida são pré-condições, não lançamentos contábeis.

Retentar sem estado pode criar mais ativos

Depois de 206, é possível tentar apenas as posições vazias, se o mapeamento estiver preservado. Repetir tudo pode criar novos tokens válidos. Depois de timeout, a mesma ambiguidade aparece: o emissor pode ter concluído a operação antes de a resposta se perder.

Já uma falha no banco após finalização exige recuperar a transação local, não presumir que outra emissão recompõe exatamente o que faltou. O retry precisa de uma constituição: estados permitidos, unidade, impacto em cota, tratamento de chave antiga e responsável por resultados ambíguos.

Um recibo temporário por posição pode conter hash não sensível da solicitação, tipo, época de chave, presença da resposta, resultado de finalização e commit. Ele deve ficar separado do token portador e dos logs futuros do Origin.

Limite de lote é política econômica

O emissor decide quantos tokens aceita em uma operação amortizada. O modo genérico também permite ignorar solicitações acima de um teto. A seção de segurança recomenda limites por cliente e chave.

Teto alto ajuda prefetch e operação offline, mas concentra valor portador e aumenta a perda em caso de vazamento. Teto baixo reduz estoque e mantém o emissor mais próximo de cada uso. Uma alteração sem versão pode parecer defeito criptográfico quando, na verdade, mudou a política de capacidade ou abuso.

Esses limites precisam de dono, justificativa, versão, telemetria e exceção. O padrão coordena o formato e o significado do status; não deve impor uma política universal. O emissor, por sua vez, não deve apresentar sua decisão local como necessidade inevitável do IETF.

A IANA coordena um número, não certifica adoção

O rascunho pede 0x0005 e quatro media types. A captura atual da IANA ainda mostra apenas 0x0001 e 0x0002 como tipos definidos. Em 20 de setembro, a Security AD pediu ajustes de referência, esclarecimento da alocação e revisão inicial do HTTP Directorate.

Os comentários foram descritos como fáceis de tratar. Não representam rejeição nem descoberta de vulnerabilidade. São, contudo, prova de que o texto ainda se move.

Mesmo uma futura alocação IANA só provará coordenação do código. Não comprovará suporte no software, interoperabilidade, acerto do inventário, aceitação pelo Origin ou resultado para o usuário. O shepherd relata implementações e consenso forte em um grupo pequeno, não um censo ou teste universal.

Auditoria pode destruir a separação que pretende proteger

O RFC 9576 distingue os contextos de atestação, emissão e resgate. A privacidade depende de quem consegue juntar as observações. O lote acrescenta metadados de hora, tamanho, emissor e época de chave.

Se o cliente mantiver um batch ID permanente e o anexar a cada token e resgate, cria uma ponte que o protocolo cego não precisava fornecer. Um bom recibo prova saldo sem mapear comportamento futuro.

Prefira totais, hashes unidirecionais, retenção curta do mapa de posições e permissões separadas para emissão e resgate. Não envie identificadores internos ao Origin. Ligações excepcionais devem ter finalidade, aprovação e prazo.

Três camadas de recibo

No nível do lote, registre variante, endpoint, tipos, resumo da configuração/desafio, época de chave, quantidade solicitada, status, comprimento do vetor, hash da prova ou resposta, limite aplicado e tempo.

No nível da posição, registre temporariamente hash da solicitação, resposta presente ou ausente, desserialização, finalização e commit. Preserve ordem somente pelo tempo necessário.

No nível do inventário, mantenha saldo inicial, adições confirmadas, quarentena, exclusões, seleções, resgates confirmados, ambiguidades e saldo final em transações.

O resgate tem outro recibo: compatibilidade com o desafio, apresentação, estado de replay, autorização do Origin e efeito da aplicação. Um comprovante de emissão não pode assinar essa conclusão.

A cadeia correta é:

configurar -> atestar -> solicitar -> admitir -> responder -> finalizar -> gravar -> selecionar -> resgatar -> autorizar -> observar.

O lote barateia alguns elos. Não os funde.