Resumen

  • La página del W3C asigna w3.org/2026/08/xmldsig-more# a XML Security, pero enlaza la vista de la última versión del borrador y no una revisión con huella propia.
  • -08 aún empleaba w3.org/tbd#; -09, publicada dos días después de la fecha de la página del W3C, introdujo el namespace real junto con otros cambios.
  • La guía del propio W3C pide indicar cómo se pueden definir o retirar nombres y quién puede hacerlo. La página nueva no contiene esa política; el silencio no demuestra que el conjunto sea mutable ni inmutable.
  • Una constitución de cambios debe unir asignación, revisión y hash; clasificar los cambios permitidos antes de congelar; nombrar la autoridad de congelación; y separar los estados de W3C, IETF e IANA.
  • No hay base para alegar una asignación inválida, aprobación de algoritmos, adopción por el IETF o retraso de IANA. El problema es de trazabilidad pública.

Una URL estable puede contener un vocabulario provisional

La página del namespace del W3C afirma que el prefijo fue asignado a XML Security, lo relaciona con el borrador RFC 9231bis mediante un enlace al Datatracker y señala que Simone Onofri la revisó por última vez el 19 de agosto de 2026.

La página cumple una función útil: ofrece un punto persistente. Asignar un URI antes de que termine toda la discusión permite sustituir marcadores temporales, evitar colisiones y realizar pruebas entre especificaciones. Nada obliga a interpretar esa infraestructura como aprobación del contenido técnico.

El problema aparece cuando se quiere reconstruir el alcance de la autorización. El enlace conduce siempre al borrador más reciente. No muestra qué número de revisión o qué hash se evaluó, quién autorizó el prefijo, qué ediciones posteriores caben en el permiso o qué suceso lo convierte en una generación congelada.

La coordinación pública dejó de ser un taller y pasó a ser un seguimiento

El issue 484 de W3C Strategy nació el 17 de noviembre de 2024 como propuesta de un taller sobre criptografía poscuántica para XML Signature y XML Encryption. Su historial demuestra una conversación abierta, no una decisión normativa.

El 21 de noviembre de 2024, el autor del borrador individual se ofreció a incorporar algoritmos. El 14 de junio de 2025, una actualización enumeró HSS/LMS, ML-DSA, SLH-DSA y ML-KEM, y sugirió que el issue quizá bastara en lugar del taller. Una oferta de autor y una lista de trabajo pueden impulsar la colaboración sin constituir consenso del W3C ni adopción por el IETF.

El 17 de agosto de 2026 se indicó que -08 ya contenía las cuatro familias seguidas y que -09 preparaba material adicional. La página del namespace lleva fecha 19. La publicación de -09 se anunció el 21. El 26 de agosto, el issue fue descrito ya no como preparación de un taller, sino como seguimiento de las necesidades de actualización.

La secuencia no prueba desorden ni fracaso. Muestra un mecanismo de trabajo que se adapta. Precisamente por eso la autorización del namespace necesita sobrevivir a cambios de foro, de participantes y de contenido.

El expediente del borrador no debe leerse como un voto

El Datatracker mostraba -09 como Internet-Draft individual activo, con estado IESG I-D Exists, sin stream RFC definido y sin Area Director responsable. Publicar un borrador individual es una acción documental legítima y abierta; no equivale a que el IETF lo haya adoptado.

El encabezado del texto dice “Independent”, “Obsoletes: 9231 (if approved)”, declara como intención el Standards Track y fija su vencimiento el 22 de febrero de 2027. Esas frases describen el destino solicitado y un efecto condicional. Los metadatos describen el estado institucional atribuible. No son versiones rivales de una misma afirmación.

La -08 archivada, del 26 de mayo, todavía construía los identificadores nuevos bajo w3.org/tbd#. Su SHA-256 es cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

La -09 archivada, del 21 de agosto, reemplaza esos marcadores por w3.org/2026/08/xmldsig-more#, añade un esquema para esa generación y contiene más cambios. Su SHA-256 es 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

El historial del Datatracker confirma ambas fechas. No registra hasta el corte una adopción de Working Group, un stream o un Area Director.

La prueba permite afirmar que la página del W3C precede dos días a la primera revisión archivada que emplea el prefijo. No permite afirmar qué bytes concretos revisó el W3C. Tampoco permite negar la existencia de registros internos. Lo ausente es una unión pública y verificable.

Hay tres custodios para tres decisiones distintas

El RFC 9231 sigue siendo la referencia aprobada. Además de documentar la generación anterior, separa el identificador de cualquier estatus oficial del algoritmo ante W3C o IETF.

El registro XML Security URIs de IANA sigue apuntando correctamente al RFC 9231 y usa la política Specification Required con expertos designados. Que no haya copiado un borrador no aprobado es el comportamiento esperado, no una demora.

W3C administra un URI dentro de su espacio. El proceso documental del IETF puede desarrollar y, llegado el caso, aprobar un RFC. IANA aplica la política de registro. El autor edita el borrador, pero no adquiere por ello potestad sobre la política de namespace del W3C. W3C asigna una dirección, pero no aprueba con ello un RFC. IANA registra valores, pero no ordena que un operador los despliegue.

Un registro de traspaso debe mostrar cuándo y cómo una responsabilidad pasa de una superficie a otra sin fingir que todas son un único semáforo.

La política general ya existe; falta aplicarla al caso

La guía de namespaces del W3C reconoce los formatos fechados y atribuye a @w3c/transitions la asignación y autorización mediante pull requests en w3c/ns. También explica que la estabilidad durante la discusión es una ventaja y que asignar no significa respaldar.

La misma guía pide que los grupos declaren con claridad cómo cambiarán o no cambiarán los espacios que controlan. Esa declaración debería estar en el documento del namespace o enlazada claramente desde él.

El finding del TAG concreta la obligación: si el namespace no es inmutable, la especificación debería decir cómo se definen o eliminan nombres y quién puede hacerlo. Sin una declaración explícita, no cabe inferir inmutabilidad.

Por tanto, la ausencia de una regla no habilita a llamar congelado al conjunto de -09, pero tampoco concede una licencia abierta para cambiarlo.

La política de persistencia de URI protege los recursos fechados, aunque contempla modificaciones y archivo de estados anteriores. Mantener la dirección no responde si un nombre local puede desaparecer o cambiar de significado.

Nada de esto demuestra un incumplimiento. Puede haber una decisión válida y documentación no enlazada. La propuesta es hacer visible la regla en el punto público que ya representa la asignación.

Las generaciones pasadas no se congelaron por intuición

La revisión -09 llama “Frozen by W3C” al prefijo de 2000 y vincula la congelación de los prefijos de 2001, 2007 y 2021 a los RFC 4051, 6931 y 9231. La congelación es un suceso con procedencia histórica.

Para 2026 faltan las respuestas operativas. ¿Puede añadirse un nombre antes del RFC? ¿Quién puede retirarlo? ¿Se conserva un nombre ya citado? ¿La aprobación de un RFC congela automáticamente el prefijo o hace falta un acto del W3C? ¿La ampliación posterior debe recibir otra fecha?

No es necesario decidir esas preguntas desde fuera. Sí es necesario evitar que cada implementador las conteste a partir de su propia dependencia.

Un nombre de algoritmo no es un certificado de algoritmo

XML Signature 1.1 y XML Encryption 1.1 muestran la importancia práctica de identificadores interoperables. No convierten cada identificador futuro en una recomendación técnica.

El RFC 8126 explica la política Specification Required: especificación pública y permanente más revisión experta. Ese umbral sirve para gobernar entradas; no es una certificación general de seguridad ni de despliegue.

Este análisis no evalúa ninguna familia criptográfica. No afirma seguridad, inseguridad, madurez, interoperabilidad o adopción. El problema institucional sería el mismo para cualquier vocabulario persistente cuyo documento definitorio continúa cambiando.

El registro que falta

Una constitución de cambios puede caber en una sola página versionada. Debe identificar el URI, la clase fechada, el actor y la fecha de asignación, y el pull request o acto público que la autoriza. Debe fijar la revisión y el hash que se consideraron al asignar, y mostrar por separado la revisión actualmente enlazada.

Después debe distinguir clases de cambio: añadir, corregir, renombrar, retirar y marcar como obsoleto. Para cada una, quién propone, quién decide y qué protección reciben las referencias existentes.

Debe nombrar el evento de congelación y su autoridad. La regla posterior decidirá si una extensión usa el mismo prefijo, una revisión experta, una errata, un RFC sucesor o una nueva fecha.

La página debe conservar en columnas distintas al custodio W3C; la clase, grupo, stream, adopción y Area Director del documento IETF cuando existan; y el estado y política del registro IANA. Debe separar la fuente que define la sintaxis del identificador de la que define la semántica del algoritmo, y registrar correcciones, sucesión y próxima revisión.

Así se mantienen separadas seis acciones: asignar el namespace, publicar un borrador, adoptarlo o asignarlo en IETF, aprobar un RFC, actualizar IANA y desplegar una tecnología. Ninguna sustituye a la siguiente.

No se pide publicar deliberaciones privadas. Basta con conservar versión, autoridad, clase de cambio y fecha.

Coordinar bien no exime de dejar recibo

El expediente público ofrece razones para confiar en el proceso: conversación abierta, revisiones preservadas, URI persistente, registro IANA todavía correcto y advertencias explícitas contra el respaldo implícito. No aparece mala fe ni una acción inválida.

Precisamente por ello, la mejora es pequeña. El enlace a “latest” debe seguir sirviendo para descubrir el texto actual. A su lado, un recibo versionado debe servir para saber qué se autorizó y cuándo cambió.