Resumen

  • RFC 8259 dice que los nombres de un objeto deberían ser únicos porque, si se repiten, algunos receptores conservan el último par, otros fallan y otros exponen todas las apariciones.
  • Después de que un parser reduzca los duplicados a un mapa con un solo valor, validar, registrar o canonicalizar ese mapa no permite reconstruir el miembro descartado.
  • Una frontera segura conserva evidencia del cuerpo recibido, compara nombres una vez resueltos los escapes y rechaza la ambigüedad antes de que intervenga la lógica de negocio.

Un objeto en tránsito no es todavía un mapa

El texto JSON transporta miembros en una secuencia. El programa suele querer un mapa en el que cada nombre apunte a un único valor. Con nombres únicos, ambas vistas parecen equivalentes. Con un nombre repetido, el paso de una a otra exige una política de colisión.

Esa política puede ejecutarse lejos del código que toma la decisión. El servidor web o el middleware construye el objeto; la pasarela consulta un campo; el servicio aplica una regla; el registrador vuelve a serializar el mapa ya reducido. Si cada etapa usa una política diferente, todas pueden declarar éxito y aun así trabajar con conjuntos de afirmaciones distintos.

Por eso “el JSON se analizó bien” es una constatación demasiado débil. Solo dice que cierto parser produjo cierto objeto.

El alcance exacto de RFC 8259

RFC 8259 establece que los nombres de un objeto DEBERÍAN ser únicos. No los prohíbe con una exigencia absoluta dentro de la gramática base. Un texto con repeticiones puede, por tanto, ser aceptado como JSON y seguir siendo inadecuado para un protocolo que necesita un significado estable.

La advertencia de interoperabilidad es explícita. Cuando los nombres son únicos, las implementaciones receptoras coinciden en las asociaciones de nombre y valor. Cuando no lo son, el comportamiento es impredecible: muchas devuelven solo el último par, algunas informan de error o no analizan el objeto, y otras entregan todos los pares. También varían al decidir si el orden de los miembros queda visible para el programa.

El problema deja de ser académico cuando la primera etapa autoriza con una aparición, la última ejecuta con otra y el registro guarda únicamente el superviviente. La evidencia posterior puede ser coherente consigo misma y no mostrar la afirmación que influyó en la decisión inicial.

I-JSON convierte la recomendación en frontera

RFC 7493 define un perfil restringido. En un mensaje I-JSON, los objetos NO DEBEN tener miembros con nombres duplicados. La igualdad se evalúa después de procesar los caracteres escapados: grafías distintas en el cuerpo pueden convertirse en la misma secuencia Unicode.

Esto impide delegar la tarea a un filtro que solo busca cadenas visibles. El detector necesita observar cada nombre decodificado antes de que se construya el mapa ordinario. I-JSON permite que un receptor rechace o descarte lo que no cumpla el perfil, y que un protocolo de seguridad ordene no confiar en ese mensaje.

Si la comprobación recibe un mapa que ya aplicó “gana el último”, no verá ningún duplicado. La protección debe residir en un modo de parser que notifique repeticiones o en una capa de tokens que mantenga todas las apariciones hasta decidir su admisión.

El primer parser dicta política sin anunciarlo

Una configuración por defecto puede terminar eligiendo qué valor llegará a autorización, precios, enrutamiento o persistencia. Esa biblioteca adquiere autoridad normativa aunque su diseño solo pretendiera ofrecer una estructura de datos cómoda.

La entrada defendible asigna un dueño a la transición. Limita tamaño y profundidad, decodifica los nombres con una sola regla, comprueba colisiones tras interpretar escapes y detiene el flujo antes de cualquier efecto. Además conserva por separado los octetos recibidos, o su resumen criptográfico según una política de privacidad y retención.

Serializar de nuevo el mapa no reemplaza esa evidencia. La nueva representación cuenta qué eligió el parser, no todo lo que recibió el sistema.

La regla de JWS no es una licencia general

RFC 7515 impone que los nombres de los parámetros del encabezado JOSE sean únicos. Un parser JWS debe rechazar las repeticiones o usar un parser JSON que devuelva solo el último miembro duplicado en el orden léxico. Es una regla concreta para una estructura concreta.

No significa que toda API JSON deba aceptar “gana el último”. Tampoco extiende automáticamente la regla a cualquier carga útil. Verificar una firma JWS demuestra una relación criptográfica con los bytes protegidos y la clave; no concede por sí mismo autorización para ejecutar la operación representada.

Incluso una excepción especificada falla operativamente si pasarela, verificador, servicio y observabilidad no aplican la misma semántica. La uniformidad entre componentes es parte del contrato.

Canonicalizar no devuelve lo que ya se perdió

RFC 8785 define el esquema JCS para obtener una representación determinista. Antes de ordenar propiedades y serializar primitivas, exige que los datos se adapten a I-JSON; los objetos no pueden exhibir propiedades duplicadas.

El orden es esencial. Si un parser tolerante elimina primero una de las apariciones y JCS opera después sobre el mapa, el resultado puede ser totalmente determinista. Pero solo fija la proyección del parser. No demuestra que el cuerpo original contuviera una única aparición ni recupera la alternativa borrada.

En aplicaciones de firma, JCS exige analizar y verificar la conformidad I-JSON, validar las convenciones del ecosistema y después comprobar la firma; cualquier fallo obliga a abortar. Admisibilidad sintáctica, corrección del dominio y autenticidad criptográfica siguen siendo controles separados.

Probar el recorrido completo

La arquitectura debería nombrar cinco estados: octetos recibidos, flujo de tokens decodificados, objeto admitido sin duplicados, modelo de dominio validado y, cuando corresponda, representación canónica o sobre firmado. Cada transición necesita responsable y salida de error.

Las pruebas deben insertar repeticiones en distintos niveles y usar nombres que solo colisionen tras resolver escapes. Deben atravesar la pasarela real, los middlewares, la ruta de firma y el registro. No basta con comprobar el código de respuesta: no debe producirse ningún efecto, la causa debe quedar clasificada y la evidencia debe corresponder al cuerpo original.

Una actualización de runtime, parser o gateway puede cambiar el tratamiento de colisiones sin modificar el esquema de negocio. Un juego común de vectores de conformidad permite detectar esa deriva antes del despliegue.

Fuentes