did:key — DID inline sin infraestructura

did

es el método DID más simple: el DID es la clave pública, codificada en un formato compacto que cualquier verificador puede parsear sin necesitar resolución externa. No hay servidor, no hay blockchain, no hay dominio web — el DID se autocontiene.

Es el método estándar para los DIDs del holder (el ciudadano) en la mayoría de wallets, incluyendo Sovra Wallet y la EUDI Wallet de la UE.

La sintaxis

Un did

tiene la forma:

did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH

Después de did:key: viene una cadena codificada en multibase (típicamente base58 con prefijo z) que incluye el algoritmo criptográfico + la clave pública. Cualquier resolver puede decodificar esta cadena para obtener:

• El tipo de clave (Ed25519, P-256, secp256k1, etc.).
• La clave pública en bytes.

Y con eso, construir el DID Document sobre la marcha, sin consultar nada externo.

Resolución en una línea

A diferencia de did

que necesita un fetch HTTPS, did se resuelve localmente:

import { DIDResolver } from "@digitalcredentials/did-key";

const did = "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH";
const { didDocument } = await new DIDResolver().resolve(did);

// didDocument se construye desde el DID mismo,
// sin red, sin caché, sin estado.
console.log(didDocument.verificationMethod[0].publicKeyJwk);

Esa autocontención es la propiedad clave del método: cualquier sistema con la librería correcta puede convertir el string DID en la clave pública correspondiente, sin depender de servidores externos.

DID Document generado

A partir de did:key:z6Mk..., el resolver construye algo así:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
  "verificationMethod": [
    {
      "id": "did:key:z6Mk.../z6Mk...",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:key:z6Mk...",
      "publicKeyMultibase": "z6Mk..."
    }
  ],
  "authentication": ["did:key:z6Mk.../z6Mk..."],
  "assertionMethod": ["did:key:z6Mk.../z6Mk..."]
}

Notá que la clave aparece codificada en id, en verificationMethod[0].id, en verificationMethod[0].publicKeyMultibase y en las referencias de authentication. Todo derivado de la misma fuente: el string original.

Cuándo usar did

did

es ideal para tres casos:

Cuándo NO usar did

did

tiene tres limitaciones que lo descartan para emisores institucionales:

Por eso la regla operativa: did

para holders + did (o did) para issuers.

El patrón Sovra

En el stack Sovra Wallet, el patrón es:

1. 1
   Cada credencial nueva tiene su propio did

   . No se reutiliza el mismo DID entre credenciales para reducir correlación entre verificadores.
2. 2
   Las claves se generan en el celular con la curva Ed25519 (rápida y compacta).
3. 3
   Las claves privadas no salen nunca del enclave seguro (Secure Enclave en iOS, StrongBox en Android cuando está disponible).
4. 4
   El did

   se incluye en el JWT proof cuando la wallet pide una credencial al issuer (vía OID4VCI).

Este patrón se llama "DID-per-credential" y es lo que evita que un solo verificador pueda correlacionar todas las presentaciones de un mismo ciudadano si recibe varias credenciales en momentos distintos.

Comparado con did

Una tabla rápida que diferencia los dos métodos más comunes:

Característica	did	did
Resolución	Local, sin red	HTTPS GET al dominio
Rotación de clave	No (genera otro DID)	Sí (mismo DID, distinta key)
Endpoints de servicio	No	Sí
Historial	No	Limitado (sin did )
Usuario típico	Holder (ciudadano)	Issuer (organización)
Infraestructura	Cero	Dominio + HTTPS

Referencias

• W3C did
  Method Specification
• Multibase encoding spec

Relacionados

• ¿Qué es un DID? — el concepto general
• did
  — DIDs vía dominio — el método para emisores institucionales
• Comparativa de métodos DID — tabla comparativa completa