Identificadores descentralizados
Un identificador descentralizado, o DID, es una URI asociada con un sujeto y resuelta mediante un método DID. El documento DID resultante puede publicar métodos de verificación, relaciones entre claves y finalidades, e información de servicios utilizada para interacciones confiables.
En UbID, un DID es un identificador y una fuente de material público de verificación. No es un perfil personal completo, una credencial, una sesión web autenticada ni una prueba de que todos los claims asociados con el sujeto sean verdaderos.
El problema que resuelven los DID
Los identificadores tradicionales con frecuencia solo tienen significado dentro de la base de datos de la organización que los creó. Un DID ofrece un modelo común de identificador que puede ser resuelto por sistemas compatibles y admitir prueba de control mediante métodos criptográficos de verificación.
Esto permite que un emisor, servicio del titular, verificador o agente autorizado se refiera a un endpoint de identidad sin obligar a todos los participantes a compartir un mismo directorio de cuentas.
DID, método DID y documento DID
Estos conceptos están relacionados, pero son distintos:
| Concepto | Significado |
|---|---|
| DID | El identificador en sí, expresado como URI. |
| Método DID | Reglas para crear, resolver, actualizar y desactivar identificadores de un tipo concreto. |
| Documento DID | Datos resueltos asociados con el DID, como métodos de verificación y referencias de servicio. |
| DID URL | Referencia a un recurso, clave o servicio particular asociado con un DID. |
| Controlador | Entidad capaz de realizar cambios autorizados o demostrar control según el método DID. |
UbID utiliza did:web cuando el gobierno del dominio web y el discovery HTTPS estándar proporcionan un modelo institucional de confianza apropiado. La elección del método no implica que se publiquen datos personales o llaves privadas en la Web.
Métodos y relaciones de verificación
Un documento DID puede identificar material criptográfico público e indicar las finalidades para las que puede utilizarse. Entre las relaciones de verificación se incluyen autenticación, assertion, key agreement y finalidades relacionadas con capabilities.
Un verificador no debe tratar todas las claves de un documento DID como válidas para toda operación. La relación declarada, el estado de la clave, la política de algoritmos, el perfil de credencial y el contexto de verificación son relevantes.
Resolución no equivale a confianza
Una resolución DID satisfactoria solo demuestra que un resolver obtuvo un documento conforme a un método y proceso de resolución. No demuestra automáticamente que:
- el sujeto haya sido sometido a proofing de identidad;
- el controlador esté autorizado para emitir una credencial particular;
- el dominio resuelto esté aprobado por el verificador;
- la clave esté permitida para la finalidad solicitada;
- una credencial esté vigente o sea aceptada por la política;
- el titular tenga derecho al servicio solicitado.
La confianza se establece combinando resolución con gobierno del emisor, verificación criptográfica, estado, contexto, assurance y política.
Rotación y continuidad
Los identificadores y las claves tienen ciclos de vida diferentes. Un DID estable puede referenciar nuevo material de verificación tras una rotación, mientras que la evidencia histórica puede necesitar validarse contra el estado y las reglas aplicables cuando se creó.
Una implementación controlada debe definir:
- procedimientos de actualización autorizados;
- estados de activación y retiro de claves;
- solapamiento durante la rotación;
- comportamiento de caché y refresh;
- tratamiento de desactivación o fallo de resolución;
- evidencia necesaria para investigar firmas históricas.
La documentación pública no divulga los procedimientos operacionales de rotación ni identificadores productivos de claves de UbID.
Consideraciones de privacidad
Los DID pueden mejorar la portabilidad, pero un único identificador persistente utilizado en contextos no relacionados también puede crear riesgo de correlación. Por ello, UbID favorece identificadores acotados y divulgación específica por finalidad cuando el ecosistema lo permite.
Un documento DID no debe convertirse en un directorio de atributos personales, inventarios de credenciales, datos biométricos, participantes de recuperación ni historial de transacciones.
Relación con credenciales y sesiones
- Un DID identifica y publica material controlado de verificación.
- Una credencial verificable contiene claims formulados por un emisor.
- SD-JWT puede respaldar la divulgación selectiva de claims.
- OpenID Connect establece una sesión autenticada de aplicación.
- OAuth autoriza acceso acotado a APIs.
- DIDComm protege mensajes vinculados a identidad.
Estas capas se complementan; ninguna debe sustituirse por otra sin un perfil explícito.
Posición de UbID
DID Core y did:web forman parte de la baseline implementada y de referencia para discovery de identidad y emisores en UbID. Los métodos, relaciones de verificación, tipos de clave y entradas de servicio exactos se gobiernan por producto y entorno.
Esta página no afirma que todo participante de UbID exponga un DID ni que toda credencial dependa del mismo método DID.
Estándares fuente
Consulta Credenciales verificables y SD-JWT y DIDComm.