Resumo

  • As variantes Base64 sloppy de RFC 9741 deixam de verificar se os bits não utilizados são zero. O controle .json descreve o valor decodificado, sem exigir uma única representação textual.
  • O efeito de um alias sobre aprovação, cache ou cobrança depende das chaves e ligações efetivamente usadas. Bytes iguais, isoladamente, não demonstram fraude, repetição proibida ou faturamento incorreto.
  • Representação aceita, identidade de negócio e entrada criptográfica precisam de definições próprias. A compatibilidade deve ser avaliada pela unidade vendida e pelo trabalho de conciliação que transfere entre equipes.

A API mudou; o contrato não necessariamente mudou com ela

Imagine que um serviço passe a aceitar mais de uma grafia para uma referência de conteúdo. Para o cliente antigo, a mudança parece pequena: não é mais preciso corrigir a saída. Para a recepção, cresce a taxa de solicitações válidas. Para a equipe que concilia aprovação e cobrança, porém, pode surgir uma pergunta nova: quais registros distintos agora apontam para o mesmo dado?

Este é um cenário hipotético, não um relato de incidente. O serviço tem equipes separadas para recepção, aprovação, recursos e contas. A primeira decodifica o texto e verifica os bytes; a segunda registra a grafia recebida; o cache e a cota usam identificadores próprios; o faturamento aproveita parte dessas informações.

Se a nova regra de recepção reconhece duas grafias como o mesmo valor, ela não altera automaticamente o sentido dos registros de negócio. Uma solicitação pode continuar sendo uma solicitação distinta, mesmo que o recurso armazenado seja o mesmo. Uma autorização pode valer para uma operação e finalidade específicas, não para qualquer uso de bytes iguais.

O desafio, portanto, não é encontrar uma chave que elimine toda diferença. É declarar quais diferenças importam em cada decisão. O cliente que envia o mesmo conteúdo duas vezes pode consumir trabalho duas vezes. Clientes diferentes não ganham os mesmos direitos por terem dados iguais. Uma regra de compatibilidade que apaga essas distinções pode resolver a rejeição na entrada e criar um problema mais caro adiante.

Uma diferença real numa parte sem conteúdo útil

RFC 9741, de Carsten Bormann, foi publicado em março de 2025 na trilha de padrões do IETF e acrescenta controles CDDL para conversão e processamento de texto. .b64u e .b64u-sloppy tratam de Base64url sem preenchimento; .b64c e .b64c-sloppy, de Base64 clássico com preenchimento. As variantes sloppy omitem a verificação de zero nos bits adicionais não utilizados, não as demais regras. O controle .json também não fixa espaços insignificantes ou ordem de serialização de entradas de mapa. O status do RFC não comprova implementação por uma ferramenta.

Considere Zg e Zh. Seus primeiros oito bits são 01100110, ou 0x66; os quatro bits restantes do segundo grupo de seis bits são 0000 e 0001. Essa é uma derivação manual da disposição de bits, não um teste de conformidade executado em um validador CDDL. Para o mesmo valor de controle que permite esse byte, a diferença relevante entre o controle estrito e sloppy aparece nessa sobra. As formas clássicas correspondentes são Zg== e Zh==.

RFC 4648, seção 3.5, exige que codificadores conformes usem zero nos bits de preenchimento e explica a decisão de rejeição dos decodificadores conforme a especificação que os referencia. Quatro bits variáveis produzem dezesseis grafias com os mesmos bits úteis nesse arranjo de um byte. Isso não significa que qualquer token, com qualquer comprimento, tenha sempre dezesseis aliases.

Uma entrada estrita pode exigir a forma canônica; uma fronteira de compatibilidade pode aceitar essa variação delimitada. Não se pode ler sloppy como licença para misturar alfabetos, ignorar qualquer espaço ou recuperar truncamentos. A tolerância só permanece uma regra verificável se sua extensão for precisa.

O formulário pode passar sem ter uma grafia única

Um exemplo familiar usa JSON:

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

Os textos mantêm os mesmos membros e valores, com uma cadeia fixa e o inteiro pequeno 1. Só mudam espaços insignificantes e ordem dos membros; não há nomes duplicados. RFC 8259 fornece o contexto sintático. RFC 7493, sobre I-JSON, exclui problemas como nomes repetidos e esclarece que a ordem dos membros não muda o significado da mensagem.

O controle .json usa a conversão padrão de JSON para CBOR de RFC 8949, seção 6.2. Ele descreve o valor resultante, não uma emissão textual única. Assim, validar o formulário não equivale a emitir uma chave estável para localizar uma aprovação ou contar recursos.

A equivalência desse exemplo é limitada. Precisão numérica, escolhas de representação e modelos de números em cadeias de texto exigem análise separada. Reordenar uma lista ou inserir nomes duplicados não é a mesma experiência. As restrições do aplicativo precisam aparecer no controle; a conversão não as inventa. Também não se deve presumir que todos os números que parecem iguais a um leitor resultem no mesmo valor sob qualquer conversão.

Outros controles mostram escolhas igualmente específicas: representações hexadecimais distinguem políticas de maiúsculas, enquanto a forma decimal não admite zeros iniciais arbitrários. O RFC oferece maneiras de definir relações entre texto e valor, não um procedimento universal para limpar todas as chaves.

Três unidades que não devem virar um único “duplicado”

O serviço pode vender processamento de solicitações, capacidade por recurso lógico ou execução de operações. Cada unidade pede evidência diferente.

Na cobrança por solicitação, receber e validar o mesmo conteúdo duas vezes pode gerar dois custos legítimos. Na cobrança por recurso, um segundo alias pode não justificar um segundo item de armazenamento. Na cobrança por operação, é necessário identificar o ato e a mudança de estado, não apenas comparar grafias ou hashes de conteúdo.

O cache pode reduzir armazenamento sem eliminar recepção, filas e auditoria. A aprovação pode limitar uma operação sem mudar a identidade do recurso. Por isso, duas linhas de cobrança e um único conteúdo não comprovam erro por si sós. É preciso verificar a unidade contratada, o alcance do contador, a ligação aos registros e o resultado faturado.

O mesmo cuidado vale para alegações de segurança. Para demonstrar um desvio de aprovação, é necessário mostrar a regra que deveria impedir o ato e como a grafia alterou sua decisão ou associação. Para demonstrar repetição proibida, é necessário identificar o ato e o estado que permitiu repeti-lo. O par de textos revela a questão a investigar, não a resposta de uma investigação.

Contexto também faz parte da identidade. Cliente, finalidade, operação, versão do perfil e identidade da solicitação podem limitar uma associação. Fundir globalmente registros de bytes iguais pode unir o que precisava permanecer separado. Deduplicação de recurso não substitui isolamento entre clientes nem amplia autorizações.

A assinatura pode preservar a diferença que o cache descarta

Uma representação pode ser irrelevante para armazenamento e essencial para autenticação. No JWS comum com carga codificada em Base64url, RFC 7515 define a entrada de assinatura com cabeçalho protegido codificado, ponto e carga codificada. A igualdade depois da análise de JSON não permite substituir essa entrada por uma nova serialização e tratá-la como a mesma prova autenticada.

O aplicativo pode escolher expressamente uma representação canônica do modelo para operações criptográficas. JCS, RFC 8785, oferece determinismo dentro de suas restrições de entrada, mas é um RFC informativo da via independente, não uma obrigação implícita de .json. Este artigo não generaliza o JWS comum para extensões de carga não codificada ou para todas as outras formas de assinatura.

“Normalizar antes de usar” é uma orientação incompleta. Antes de qual uso, sob qual definição e depois de preservar qual entrada? A política desejada para o cache não concede autoridade para reescrever o material exigido pela verificação. A grafia original pode ser justamente o que o emissor autenticou.

A fronteira técnica deve dizer o que ainda não decidiu

Na discussão de Lu Heng sobre especificação comum mínima, regras determinísticas compartilhadas são separadas de arranjos de negócio e decisões posteriores dos operadores. Essa é uma lente analítica útil: tornar precisa a admissão sem transformar conformidade em autoridade sobre preço e aprovação. Não se trata de uma avaliação dele sobre RFC 9741 nem de uma exigência contábil do IETF.

Seu argumento sobre a primazia do código em funcionamento distingue publicação de adoção efetiva. No serviço hipotético, devem ser seguidas as chaves usadas pelas equipes, não apenas uma declaração de suporte ao RFC. A reflexão sobre camadas de realidade e poder simbólico também funciona como perspectiva: um comprovante de validação representa um controle, não toda a operação.

RFC 8610, seção 5, já alerta contra depender apenas da correção da especificação CDDL e de seu mecanismo de correspondência sem outras defesas. Definir bem texto e valor torna mais fácil reconhecer as decisões que pertencem a outros responsáveis. A aceitação de um alias pode ser correta; tratá-la como conciliação concluída é que deixa trabalho sem dono.