Resumen
- La carta vigente, adoptada en 2024 y prorrogada hasta el 28 de octubre de 2026, incorporó DID Resolution como entregable de la Recommendation Track. El trabajo de agosto no carece de mandato institucional.
- El 6 de agosto W3C publicó un Candidate Recommendation Snapshot. Ese Patent Review Draft abrió una oportunidad de exclusión hasta el 5 de octubre y fijó pruebas de salida por función; no convirtió el texto en Recommendation ni en aval del W3C.
- El 10 de agosto comenzó el refinamiento público de una carta de continuidad. Sin embargo, el borrador y su cabecera de repositorio del 27 de agosto siguen diciendo Working Draft, última publicación 10 de julio y Exclusion Draft de noviembre de 2024.
- El historial oficial añade un Candidate Recommendation Draft el 28 de agosto. Es el texto integrado más reciente, pero no sustituye automáticamente al Snapshot como cuerpo de referencia para la política de patentes.
- La revisión del Advisory Committee debería recibir una hoja de relevo que una carta activa, CR Draft, Snapshot, periodo de exclusión, estado «at risk» y evidencia de implementación fechada. Su función sería conservar límites, no abrir otra puerta de aprobación.
El problema no es la falta de información
W3C ya publica casi todas las piezas necesarias. La historia del estándar enumera las versiones. La página IPR identifica la oportunidad de exclusión. La página del grupo muestra cuándo termina la carta actual. El informe de implementación declara la hora de su ejecución. El repositorio de la nueva carta deja ver el texto y sus cambios.
No estamos ante una caja negra. Estamos ante varias ventanas que muestran horas distintas porque miden fenómenos distintos.
La publicación técnica tiene como último hito un Candidate Recommendation Draft del 28 de agosto. La política de patentes conserva como referencia el Candidate Recommendation Snapshot del 6 de agosto. La matriz de pruebas muestra una ejecución del 27 de marzo. La autoridad del grupo procede de la carta de 2024, aún prorrogada hasta el 28 de octubre. La nueva carta sigue en refinamiento, con final previsto aproximadamente a mediados de septiembre.
Si una síntesis utiliza la palabra «actual» sin decir a cuál de esas funciones se refiere, puede equivocarse aunque cada enlace individual sea correcto. Esa es la clase de fallo que una hoja de relevo resuelve mejor que un párrafo más largo.
La carta de 2024 sigue siendo la fuente de autoridad
DID Resolution entró en la Recommendation Track porque la carta aprobada en abril de 2024 lo adoptó como nuevo entregable. Esa carta debía terminar en abril de 2026, pero W3C la extendió hasta el 28 de octubre. La página del grupo reproduce esa vigencia.
Por eso no es correcto imaginar un vacío entre la vieja carta y el trabajo de agosto. Tampoco es correcto atribuir efectos jurídicos o institucionales a la carta futura antes de que supere refinamiento, AC Review, decisión y Call for Participation.
El issue 562 de Strategy describe el proyecto con franqueza. Se trata de recharter de un grupo existente; no anuncia cambios sustantivos y explica que hace falta más tiempo porque el consenso sobre DID Resolution tardó más de lo esperado.
Esa continuidad no rebaja la exigencia documental. Al contrario. Cuando una carta nueva cambia misión y alcance, el cambio atrae atención por sí mismo. Cuando solo promete continuidad, los detalles heredados pueden cruzar sin que nadie pregunte en qué estado estaban. ¿Qué versión se hereda? ¿Qué periodo de patentes está abierto? ¿Qué función sigue en riesgo? ¿Qué prueba pertenece a qué texto? El acta debe responder antes de que el término «mantenimiento» lo cubra todo.
No se trata de afirmar que una propuesta sea ya un mandato. Se trata de preparar una recepción exacta para el día en que pueda convertirse en carta aprobada.
Snapshot y Draft no son dos etiquetas intercambiables
El parecido lingüístico es peligroso. Candidate Recommendation Snapshot y Candidate Recommendation Draft pertenecen a la misma fase, pero W3C les asigna tareas diferentes.
El Snapshot del 6 de agosto es un punto estable de revisión. El Process Document lo considera Patent Review Draft. Su publicación desencadenó el Call for Exclusions y dejó el 5 de octubre como fecha final de la oportunidad.
El Draft del 28 de agosto hace visible otro tipo de movimiento. Su aviso de estado dice que integra cambios que el grupo pretende incluir en un Snapshot posterior. Sigue siendo trabajo en curso, susceptible de actualización o sustitución. El Process aclara que un CR Draft no abre por sí mismo otra oportunidad de exclusión.
De modo que «más reciente» necesita apellido:
- para leer los cambios integrados: CR Draft del 28 de agosto;
- para identificar el cuerpo estable de revisión de patentes: Snapshot del 6 de agosto;
- para conocer el plazo vigente: página IPR y Call for Exclusions hasta el 5 de octubre;
- para anunciar un nuevo cuerpo de referencia: solo un futuro Snapshot, si llega a publicarse.
Confundirlos perjudica a todos. Un implementador podría probar un texto distinto del que cree estar evaluando. Un participante podría tomar el Draft más nuevo por el cuerpo frente al cual debe comparar una exclusión. Un comentarista podría tratar el Snapshot como texto técnicamente inmóvil cuando el grupo ya ha integrado cambios.
La hoja de relevo no elige ganador. Conserva los dos papeles.
La historia de patentes está viva y es trazable
El borrador de carta aún cita el Working Draft de 28 de noviembre de 2024 como Exclusion Draft y el periodo que terminó en abril de 2025. Es una fotografía antigua dentro de un documento que todavía se está refinando.
La página IPR no comete ese atraso. Muestra la nueva oportunidad de DID Resolution entre el 6 de agosto y el 5 de octubre y mantiene la anterior como historial. El mensaje del Call for Exclusions explica además que la oportunidad nueva se limita a materia que no estaba presente o aparente en el cuerpo previo.
La conclusión justa es muy acotada: el mecanismo especializado funciona, pero el borrador de relevo aún no lo refleja. No hay base para afirmar que se ocultó el periodo, que se perdió una obligación o que existe un conflicto de patentes.
De hecho, la misma página informa que no se han presentado divulgaciones de patentes para las especificaciones del grupo. Una ventana de exclusión es una condición procesal, no una predicción de litigio ni una señal de que alguien vaya a excluir una reivindicación.
El registro común solo necesita enlazar el Snapshot, el cuerpo anterior, la apertura, el cierre y la página IPR. No necesita interpretar posiciones privadas ni convertir la carta en tratado de patentes.
Las pruebas se cuentan por función, no por logotipo
El Snapshot solicita implementaciones experimentales y establece condiciones precisas para avanzar. Cada función debe tener al menos dos implementaciones independientes e interoperables, comprobadas mediante suites abiertas. Las declaraciones normativas que una máquina puede verificar necesitan dos implementaciones conformes por función; las demás, dos demostraciones. También deben existir al menos dos métodos DID con especificación abierta, cada uno interoperablemente implementado por más de una de las implementaciones independientes.
El informe público tiene varias columnas de implementadores. Ese número no basta para decidir si se cumplen las condiciones. Una tabla con cuatro nombres puede contener una función cubierta por dos, otra por uno y otra todavía no aplicable. La unidad de prueba es la función vinculada a declaraciones normativas concretas.
El encabezado del informe indica que las pruebas se ejecutaron el 27 de marzo a las 14:16 UTC. Eso merece una conexión explícita con el estándar de agosto. No demuestra que todo resultado sea viejo: una función puede no haber cambiado. Tampoco permite declarar que el estándar ha aprobado o suspendido la salida con solo mirar celdas aisladas.
Un recibo útil debe nombrar la versión de la especificación, commit de la suite, hora de ejecución, mapa de declaraciones por función, dos pruebas calificadas, criterio de independencia, métodos DID empleados, excepciones y responsable de actualización.
Así el orden institucional sigue la realidad técnica: propuesta, implementación, prueba abierta, observación de interoperabilidad y después descripción de madurez. Una carta puede exigir evidencia; no puede producirla mediante su etiqueta.
La función «at risk» debe cruzar con su pregunta abierta
El Snapshot señala el DID URL dereferencing como función en riesgo y dice que probablemente cambiará o será retirada. El grupo pide a los implementadores información sobre su valor. También advierte que issues abiertos de clase 1, 2 o 3 pueden modificar la especificación.
No es una confesión de fracaso. Candidate Recommendation sirve precisamente para que la experiencia de implementación cambie una propuesta antes de Recommendation. La etiqueta acota una incertidumbre y permite retirarla sin fingir que siempre fue definitiva.
Lo que no debería ocurrir es que «maintain DID Resolution» se lleve el nombre del entregable y pierda la incertidumbre que lo acompaña. El relevo debe conservar el identificador de la función, la pregunta, la evidencia solicitada, el órgano que decidirá y la resolución futura. Si luego se modifica o elimina, el estado anterior debe seguir siendo reconstruible.
El registro no tiene que decidir la calidad técnica del dereferencing. Debe impedir que la transición administrativa borre la pregunta técnica.
El borrador todavía está a tiempo
La nueva carta se llama DRAFT y tiene fechas de inicio y fin sin completar. Eso no es una infracción. El inicio dependerá del futuro Call for Participation; el refinamiento existe para recibir revisión, resolver issues y preparar una decisión.
El propio texto dice que el campo «Draft state» representa el estado del entregable en el momento de aprobación y enlaza la página de publicaciones para información actualizada. Ese es un compromiso razonable: la carta no necesita actualizarse con cada commit del estándar, pero sí llegar a aprobación con un inventario verdadero.
Al cierre de esta investigación, el head fusionado el 27 de agosto todavía decía Working Draft, 10 de julio y Exclusion Draft de 2024, pese a que el Snapshot tenía tres semanas. Un día después apareció el CR Draft del 28 de agosto. La diferencia es visible y corregible.
Declarar inválida la carta por un dato durante refinamiento sería confundir borrador y decisión. Dejar el dato igual hasta la aprobación sería desaprovechar el refinamiento.
Una hoja de relevo suficientemente pequeña
No hace falta duplicar todas las páginas del W3C. El registro compartido puede limitarse a lo que debe ser común:
- Autoridad: carta vigente, periodo, commit de la propuesta, fase y futura decisión.
- Texto: último informe técnico legible y Snapshot de referencia en campos diferentes.
- Patentes: Patent Review Draft, periodo, cuerpo anterior y enlace IPR.
- Implementación: versión probada, suite, ejecución, cobertura por función e independencia.
- Revisión: función at risk, issues, revisión horizontal, comentarios y disposición.
- Custodia: responsable, ruta de corrección y evento de sustitución.
Cada cambio debería añadir un estado, no borrar el anterior. Una tabla humana y una representación estructurada pueden compartir la misma identidad.
El enlace temático con identity and access management tampoco debe engordar el mandato. La carta excluye protocolos de autenticación o autorización, API de navegador y el proyecto de «resolver la identidad» en la Web. DID Resolution puede importar al campo amplio de identidad sin que W3C certifique cada producto IAM, método DID o régimen jurídico.
La precisión documental es también contención institucional.
Fuentes
- W3C — anuncio del Candidate Recommendation Snapshot de DID Resolution, 6 de agosto de 2026
- W3C — Candidate Recommendation Snapshot de DID Resolution v1
- W3C Patent Policy — Call for Exclusions de DID Resolution v1
- W3C — página IPR del DID Working Group
- W3C — inicio del refinamiento de la carta DID, 10 de agosto de 2026
- W3C — borrador de carta del Decentralized Identifier Working Group
- w3c/did-wg-charter — commit revisado
a840d21c6f8fac431ee1662d1bedb05940834623 - w3c/strategy — issue 562 sobre la carta DID
- W3C — carta vigente del DID Working Group, 25 de abril de 2024
- W3C — página del DID Working Group
- W3C — historial de publicación de DID Resolution v1
- W3C — Candidate Recommendation Draft de DID Resolution v1, 28 de agosto de 2026
- W3C — informe de implementación de DID Resolution
- W3C Process Document, 18 de agosto de 2025
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance