Resumen

  • Las variantes Base64 sloppy de RFC 9741 omiten la comprobación de que los bits no utilizados sean cero; .json describe el valor decodificado, no una única serialización.
  • Dos textos equivalentes solo alteran cuotas, aprobaciones o cargos mediante las claves y conexiones reales del servicio. La igualdad de bytes no demuestra un abuso ni un cobro erróneo.
  • Hay que definir por separado representación admitida, identidad de negocio y entrada criptográfica, y medir la compatibilidad según la unidad que se vende, no solo según solicitudes aceptadas.

Agotar una cuota no significa haber creado más contenido

Un contador puede subir dos veces mientras el almacenamiento conserva un solo recurso. No hay contradicción si el contador mide solicitudes y el almacenamiento mide contenido. Sí hay una pregunta pendiente cuando ambos se presentan al cliente como la misma unidad.

Supongamos un servicio de referencias de contenido dividido entre recepción, aprobación, gestión de recursos y contabilidad. Recepción decodifica un texto y valida los bytes. El registro de aprobación conserva el texto recibido. La caché y la cuota usan sus propias claves, y la factura se construye con parte de esos registros. Es un escenario hipotético, no un incidente ni una evaluación de un producto identificado.

Si dos textos representan el mismo valor, recepción puede aceptar ambos. Eso no decide si son dos solicitudes con coste, un recurso con dos etiquetas o una operación que solo estaba autorizada una vez. La respuesta pertenece a los contratos y a las reglas de estado, no al decodificador.

Tampoco basta con imponer una huella común. Clientes distintos pueden enviar el mismo contenido sin compartir permisos. Un cliente puede realizar operaciones distintas sobre el mismo objeto. Una cuota de recepción puede contar trabajo que la deduplicación de la caché no elimina. Mezclar estas unidades bajo la palabra «duplicado» convierte una comodidad de implementación en una decisión de negocio encubierta.

El alias cabe en una parte que no representa el byte

RFC 9741, de Carsten Bormann, publicado en marzo de 2025 en la vía de estándares del IETF, añade controles CDDL de conversión y tratamiento de texto. Distingue .b64u y .b64u-sloppy, Base64url sin relleno, de .b64c y .b64c-sloppy, Base64 clásico con relleno. Las variantes sloppy omiten el control de cero en los bits adicionales no utilizados; no eliminan las demás reglas. Su .json tampoco fija espacios insignificantes ni el orden de serialización de entradas de mapa. Publicar la norma no prueba su implementación en una herramienta.

La pareja Zg y Zh permite examinar el primer caso. Sus ocho primeros bits son 01100110, el byte 0x66. Los cuatro restantes del segundo grupo de seis bits son 0000 y 0001. Es una deducción manual de la disposición de bits, no una prueba de conformidad ejecutada sobre un validador CDDL. Para el mismo valor de control que admite ese byte, la diferencia pertinente entre el control estricto y sloppy se encuentra en esos bits. Las formas clásicas correspondientes son Zg== y Zh==.

RFC 4648, sección 3.5, exige que los codificadores conformes pongan a cero los bits de relleno y explica la decisión de rechazo del decodificador en relación con la especificación que lo referencia. Cuatro bits variables permiten dieciséis grafías con los mismos bits útiles en este caso de un byte. No es una cifra aplicable a cualquier longitud de identificador.

Una entrada estricta puede rechazar el alias no canónico; una entrada de compatibilidad puede admitir esa variación delimitada. Interpretar sloppy como permiso para ignorar cualquier espacio, mezclar alfabetos o recuperar entradas truncadas ampliaría la norma. La flexibilidad solo es controlable cuando su alcance se puede describir y probar.

La forma del formulario no es la identidad de su aprobación

La misma separación surge con JSON:

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

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

El ejemplo mantiene cadenas fijas y el entero pequeño 1, sin nombres duplicados. Solo varían espacios insignificantes y orden de miembros. RFC 8259 aporta la sintaxis de JSON; RFC 7493 sobre I-JSON excluye, entre otros problemas, los nombres duplicados y aclara que el orden de miembros no cambia el significado del mensaje.

El control .json utiliza la conversión por defecto de JSON a CBOR de RFC 8949, sección 6.2. Describe la relación con el valor, no una emisión textual única. Si aprobación indexa el formulario completo y ejecución usa el valor decodificado, superar la validación no garantiza que ambas encuentren el mismo registro.

La equivalencia del ejemplo no debe extenderse a todos los números que parezcan iguales, a claves repetidas o a matrices reordenadas. La precisión y las elecciones de representación necesitan su propio análisis. Cuando la aplicación usa un modelo de cadenas para números fuera de la precisión interoperable, sus restricciones tienen que aparecer en el control. El conversor no las inventa.

Otros controles tampoco proponen una limpieza universal: las formas hexadecimales permiten elegir el tratamiento de mayúsculas, mientras la forma decimal no admite ceros iniciales arbitrarios. Cada campo puede necesitar una relación de representación diferente. Elegirla no establece por sí solo una relación de autorización.

Hay tres costes que una sola cuenta puede ocultar

El primer coste es recibir y comprobar una solicitud. El segundo es conservar o recuperar un recurso lógico. El tercero es mantener el estado de una operación aprobada y su efecto contable. Un alias puede aumentar el primero sin aumentar el segundo. El tercero depende de qué acto se pretendía ejecutar y con qué autorización.

Una tarifa por solicitud puede cobrar dos envíos del mismo dato. Una tarifa por recurso puede exigir que dos etiquetas no creen dos recursos facturables. Una tarifa por operación necesita identificar la operación y su transición de estado. Ninguna de esas reglas se deduce de que el decodificador haya obtenido bytes iguales.

Para investigar un cargo hay que unir unidad contractual, alcance del contador, identidad registrada y resultado de la factura. Dos textos equivalentes no bastan para afirmar sobrecobro. Para afirmar una elusión de aprobación también hace falta mostrar la regla que debía impedir el acto y cómo el alias modificó su decisión o conexión. Una repetición prohibida requiere pruebas sobre el acto y su estado. El RFC muestra una posibilidad de representación, no esos resultados.

La compatibilidad puede, además, redistribuir trabajo. Evitar que el cliente corrija su salida puede generar conciliación, soporte y excepciones dentro del servicio. Si recepción solo mide tasa de aceptación, su mejora puede coincidir con un aumento de costes en otra área. El contador equivocado hace invisible esa transferencia.

La autenticación conserva una frontera propia

La caché puede querer ignorar una diferencia que la firma necesita conservar. En JWS ordinario con carga codificada en Base64url, RFC 7515 construye la entrada de firma con la cabecera protegida codificada, un punto y la carga codificada. La igualdad después de analizar JSON no autoriza a sustituir esa entrada por otra serialización.

Una aplicación puede elegir expresamente una representación canónica de su modelo para operaciones criptográficas. JCS, RFC 8785, ofrece determinismo dentro de sus restricciones de entrada, pero es un RFC informativo de la vía independiente, no una obligación implícita de .json. Aquí no se generaliza el JWS ordinario a extensiones de carga no codificada ni a todas las envolturas de firma.

Por eso «normalizar antes de usar» deja sin responder el uso y el orden. La transformación adecuada para un índice de recursos no tiene autoridad para reescribir las pruebas que requiere la autenticación. Puede ser necesario conservar el texto original aunque después se utilice otra identidad para almacenamiento.

Un control compartido no debe adjudicar la factura

La reflexión de Lu Heng sobre una especificación común mínima ofrece una perspectiva: separar reglas deterministas compartidas de acuerdos de negocio y decisiones operativas. Aplicada a este caso, implica especificar la recepción con claridad y mantener explícitas las decisiones sobre permiso y precio. No es una revisión suya de RFC 9741 ni una exigencia contable del IETF.

Su argumento sobre la primacía del código en funcionamiento distingue una regla publicada de su adopción real. La investigación del servicio hipotético debe seguir claves y conexiones efectivas, no limitarse a una etiqueta de conformidad. Su discusión de realidad y capas simbólicas sirve aquí como marco analítico: un recibo de validación acredita un control, no la transacción completa.

RFC 8610, sección 5, ya advierte contra depender solo de la corrección de CDDL y su mecanismo de correspondencia sin otras defensas. Cuanto mejor se describe la relación texto-valor, más evidente resulta qué decisiones no ha tomado. La compatibilidad puede ser útil; no debe presentarse como una conciliación ya resuelta.