Resumen

  • El borrador de W3C del 1 de octubre incluía un desreferenciador de URL DID en red y ejemplos HTTP(S). Las versiones del 24 y el 26 de octubre retiran esa parte del enlace de red.
  • La resolución de un DID sigue teniendo una vía HTTPS. Para usar la URL completa, el cliente elige el resolutor, interpreta el documento y ejecuta el tratamiento apropiado.

Pedir did:example:123#key-1 y recibir un documento DID se parece a encargar un libro y recibir la biblioteca. Hay material valioso en la entrega; la página exacta sigue esperando al lector.

W3C ha dibujado esa diferencia con más fuerza en su borrador del 26 de octubre. El texto del 1 de octubre daba al desreferenciador de URL DID en red una clase de conformidad y ejemplos de uso por HTTP(S). El 24 de octubre desaparecieron esa clase, la desreferenciación del enlace HTTP y sus ejemplos. La versión vigente también registra la retirada en OpenAPI.

El resolutor conserva un trabajo claro. El borrador define cómo obtener por HTTPS el documento de un DID y sus metadatos. Exige GET a los resolutores conformes y permite POST. El servidor de resolución entrega información que otro componente puede usar; la última operación depende de la URL solicitada y del contexto de la aplicación.

El algoritmo de desreferenciación describe esa operación. El cliente deja que el usuario escoja un resolutor para cada método DID, solicita la resolución y decide qué manejador aplicar. En los ejemplos del propio borrador, el fragmento #key-1 se resuelve en el cliente. Una URL que apunta a un servicio exige otra ruta de tratamiento. Poner todo bajo la etiqueta «resuelto» borraría justamente la decisión que produce el recurso utilizado.

La discusión venía de lejos. Un asunto abierto en marzo en el repositorio del grupo planteó que un servicio remoto no podía completar por sí solo la parte final de los fragmentos. En las actas del 15 de octubre, miembros del grupo debatieron cómo probar un algoritmo abstracto mediante interfaces concretas. El cambio publicado convierte esa pregunta de laboratorio en una tarea de compra y operación: exigir pruebas separadas del resolutor y del recorrido completo de la URL.

El borrador sigue señalando la desreferenciación como función en riesgo durante la fase de Candidate Recommendation. Mientras el texto evoluciona, una respuesta HTTP satisfactoria cubre una estación del viaje. Quien despliegue la aplicación debe saber quién tomó el siguiente tren.