Comparativa de métodos DID

Existen decenas de métodos DID registrados en el DID Method Registry del W3C. La mayoría son experimentales o sirven para casos muy específicos. En producción real, cinco métodos cubren el 95% de los casos. Esta es la guía para elegir.

Los 5 métodos relevantes en 2026

Método	Resolución	Costos	Caso típico
did	Local (cero red)	Cero	Holders (ciudadanos) en wallet
did	HTTPS GET al dominio	Costo dominio + HTTPS	Issuers institucionales
did	HTTPS GET + log append-only	Costo dominio + storage	Issuers con auditoría histórica
did	QuarkID L1 (Polygon)	Gas pequeño por update	Sovra stack, casos con anchor a blockchain
did	ION network (Bitcoin sidetree)	Gas + nodo ION	Microsoft Entra, alta resistencia a censura

Matriz de decisión

Cuatro propiedades fundamentales para comparar:

Propiedad	did	did	did	did	did
Rotación de clave	❌	✅	✅	✅	✅
Endpoints de servicio	❌	✅	✅	✅	✅
Historial auditable	❌	❌	✅	✅	✅
Resistencia a censura	Alta (no hay infra)	Baja	Media	Media-Alta	Muy Alta
Resolución offline	✅	❌	❌	⚠️ (con cache)	⚠️ (con cache)
Costos operativos	Cero	Bajo	Bajo	Bajo	Medio
Madurez ecosistema	Alta	Alta	Media	Media (Sovra)	Media

Reglas prácticas

Cinco reglas que se aplican en el 95% de los casos:

1. 1
   Holders ciudadanos: did

   . Siempre. Es el patrón estándar en wallets EUDI, Sovra Wallet, Microsoft Authenticator, Apple Wallet.
2. 2
   Issuers gubernamentales con dominio propio: did

   . El dominio del organismo es la ancla de confianza natural. La PKI estatal (intermediate CAs) puede sostener trust framework.
3. 3
   Issuers que necesitan trazabilidad histórica: did

   o did

   . Auditoría regulatoria, casos donde se debe poder demostrar "qué clave usé el 14 de marzo".
4. 4
   Casos con anchor a blockchain por requerimiento explícito: did

   (en stack Sovra) o did

   (en stack Microsoft). Solo cuando hay razón concreta para anclar, no por preferencia técnica.
5. 5
   Verificadores: No tienen DID propio en la mayoría de casos. Acceden a las credenciales del holder y verifican firmas. Solo necesitan DID si ellos también emiten algo (típico en flujos de confianza cruzada).

Cuándo NO usar blockchain

did

y did usan blockchain (Bitcoin sidetree e Polygon respectivamente). Hay tres casos donde no conviene ese anchor:

did

— el método emergente

Mención especial para did

(Trusted Did Web) porque está en crecimiento rápido en 2026. Es did + un log append-only de cambios, ambos servidos desde el mismo dominio.

Características clave:

• Mantiene la simplicidad de did
  (HTTPS GET).
• Suma historial verificable sin necesidad de blockchain.
• Adoptado por la BC.gov de Canadá y varios proyectos europeos.
• Compatible con eIDAS 2.0.

Si did

es la elección actual, did es probablemente la evolución natural en 2-3 años para issuers institucionales que necesitan trazabilidad sin pagar gas blockchain.

El patrón Sovra en producción

En el stack Sovra Wallet + SovraID, la convención es:

Rol	Método DID
Ciudadano holder	did
Issuer institucional (gobierno provincial)	did sobre dominio del organismo
SovraID workspace canonical	did con ancla L1
Verificador con DID propio	did (típicamente)

Esta combinación cubre todos los casos sin imponer un solo método. El sistema acepta credenciales firmadas por did

, did y did sin distinguir.

Referencias

• DID Method Registry — W3C
• did
  spec
• QuarkID

Relacionados

• ¿Qué es un DID? — el concepto base
• did
  — DIDs vía dominio — el método más usado para issuers gov
• did
  — DID inline sin infraestructura — el método para holders
• did
  — el método con anclaje L1 — el método con anclaje L1 del stack Sovra