did:web explicado
Todo credential digital está firmado por alguien, y un verificador tiene que poder consultar quién es y qué claves usa hoy. did:web responde a eso con la pieza de infraestructura que casi toda organización ya tiene: su propio nombre de dominio. El identificador le dice a qué dominio preguntar, la respuesta es un archivo corriente servido por HTTPS, y no hace falta que exista nada más para que funcione.
Qué es did:web en realidad
Una DID es un identificador permanente que cualquiera puede consultar para encontrar las claves públicas de quien la posee. Un método DID es la regla que describe esa consulta, y existen decenas. Unos escriben el asiento en una blockchain, otros en una red construida a propósito, y cada uno obliga al verificador a aprender cómo funciona ese sistema concreto.
did:web toma el camino contrario. La consulta es una petición HTTPS al dominio que aparece en el identificador, y el asiento es un archivo JSON que el propietario del dominio publica y edita como cualquier otra página de su sitio. No hay red a la que unirse, ni registro donde escribir, ni cuota que pagar.
Por eso aparece tan pronto en casi cualquier proyecto. Un equipo capaz de desplegar un archivo en su servidor web puede estar emitiendo y verificando credentials esa misma tarde, y el identificador que obtiene es una DID real que aceptará cualquier wallet o verificador conforme, no un apaño que haya que sustituir después.
Cómo el identificador se convierte en URL
La correspondencia es mecánica, y ahí está la gracia. Un dominio desnudo lleva a un archivo del directorio well-known que los sitios ya usan para metadatos legibles por máquina. Si añade tras el dominio segmentos separados por dos puntos, pasan a ser segmentos de ruta, de modo que una misma organización puede publicar un identificador distinto por departamento, por entorno o por servicio de emisión sin registrar nada nuevo.
Dos detalles se escapan con frecuencia. El número de puerto exige codificar sus dos puntos en porcentaje, porque unos dos puntos simples ya separan las partes del identificador. Y el archivo debe servirse por HTTPS con un certificado que valide, porque el transporte es lo único que se interpone entre un verificador y una respuesta falsificada.
El identificador que alguien le da
did:web:example.com:issuer:euLa URL HTTPS a la que corresponde, sin servicio de búsqueda intermedio
https://example.com/issuer/eu/did.jsonEl DID document que se devuelve, con las claves y los endpoints
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Por qué lo eligen las organizaciones
La primera razón es el reconocimiento. Un verificador que ve un identificador apuntando al dominio de una empresa puede comprobar, de la forma más sencilla que existe, que el nombre del credential coincide con el nombre del sitio web. No hay que explicarle a nadie una consulta al registro ni una cadena de certificados para que eso cale.
La segunda es que operarlo no cuesta nada. El documento vive tras el mismo alojamiento, la misma monitorización y el mismo proceso de cambios que el resto del sitio. No hay un sistema aparte que financiar, mantener disponible o explicar a un auditor, y rotar una clave es un despliegue en lugar de una transacción.
La tercera es la portabilidad. Como todas las bibliotecas de wallet y de verificación lo admiten, did:web es el método con más probabilidades de funcionar frente a un socio con el que nunca ha integrado, lo que lo convierte en la opción natural para pilotos, entornos de prueba y los encuentros de interoperabilidad donde se cruzan las implementaciones europeas de wallet.
Dónde se detiene did:web
Todo lo que el método le da descansa sobre el dominio. Quien controla el registro, los servidores de nombres y el certificado controla el identificador, así que una renovación caducada, una cuenta de DNS secuestrada o un certificado emitido por error bastan para hablar en su nombre. Debajo no hay una segunda firma a la que recurrir.
Tampoco tiene memoria. Un verificador ve el documento tal como está en este momento y no tiene forma de saber qué decía la semana pasada, así que una clave sustituida es indistinguible de una rotada. did:webvh existe justo para eso: el mismo alojamiento web, más un registro firmado de cada cambio al que solo se puede añadir, para que un verificador pueda seguir la historia desde la primera entrada hasta el estado actual.
Y no es una comprobación de identidad. Publicar un documento bajo un dominio demuestra el control de ese dominio y nada más. Cuando un verificador necesita saber que una persona jurídica es quien dice ser, esa garantía viene de una Trusted List, un certificado cualificado o un Trust Framework creado para ello, mientras el método DID solo sostiene las claves por debajo.
Qué significa esto para usted
Emisor
Trate el documento como infraestructura de producción desde el primer día. Póngalo bajo control de cambios, vigile que la URL responda y que el certificado sea válido, y mantenga listada una clave retirada para verificación mientras siga en uso algo que ella firmó.
Parte confiante
Recuperar el documento no es lo mismo que confiar en él. Decida por separado qué dominios acepta, rechace todo aquello cuyo certificado no valide, y use la caché con cuidado: una copia obsoleta mantiene viva una clave revocada, y una copia ausente tumba su servicio junto con el de enfrente.
Titular de la cartera
El dominio que aparece en el identificador de un emisor merece un vistazo. Es la única parte de un credential que puede leer sin herramientas, y un nombre que no coincide con la organización esperada es motivo para detenerse en lugar de continuar.
Términos relacionados
Preguntas frecuentes
¿Necesito software especial para resolver un identificador did:web?
No. El identificador es una receta para construir una URL, y recuperar esa URL por HTTPS devuelve el documento. Cualquier cliente HTTP puede hacerlo, y por eso did:web suele ser el primer método que un equipo pone en marcha. Aun así, en producción conviene usar una biblioteca de resolución genérica, porque aplica las reglas de codificación y las comprobaciones sobre el documento de forma uniforme en lugar de dejarlas en manos de cada llamante.
¿Es did:web menos fiable porque no hay blockchain?
Es fiable de otra manera. Un método basado en un registro distribuido reparte el asiento entre muchas partes, de modo que ninguna puede reescribirlo en silencio. did:web deposita esa responsabilidad en el propietario del dominio y en las autoridades de certificación que hay detrás de su TLS. Para una organización cuyo nombre y sitio web ya son lo que los clientes reconocen, ese suele ser el lugar más honesto para esa confianza, siempre que todos entiendan que el dominio es el punto débil.
¿Qué ocurre con los credentials ya emitidos cuando cambian las claves?
Un verificador recupera el documento tal como está ahora, así que un credential firmado con una clave que ya se ha retirado deja de verificarse. Mantenga una clave retirada en el documento, marcada de forma que pueda verificar pero ya no firmar, al menos mientras sigan siendo válidos los credentials que firmó. Si necesita que un verificador pueda demostrar qué clave estaba vigente en una fecha concreta, ese es el punto en el que did:webvh justifica su complejidad añadida.
Fuentes
Esta página es informativa y no constituye asesoramiento jurídico. Para orientación con valor normativo, consulte directamente las especificaciones del W3C.