federAIfederAI
Entrar
Volver a Explorar
PatrónTécnicoIdentidad y CVIntermedio

did:web — DIDs vía dominio

8 minVerificado · 2026-05-18

did

es uno de los métodos DID más simples y prácticos: no requiere blockchain, no requiere infraestructura especial; solo necesita un dominio web y la capacidad de servir un JSON específico en una ruta predecible.

Es el método elegido por una mayoría creciente de proyectos que necesitan DIDs estables, públicos y fácilmente auditables —especialmente para emisores institucionales como gobiernos, universidades y empresas.

La sintaxis

Un did

tiene la forma:

did:web:salta.gob.ar
did:web:registro.federai.ar:provincias:salta
did:web:identity.universidad.edu.ar:emisores:alumnado

El primer token después de did:web: es el dominio. Los siguientes tokens (opcionales, separados por :) representan path components que se mapean a una ruta URL.

Cómo se resuelve

Resolver un did

significa convertir el identificador en su DID Document —el JSON con las claves criptográficas y endpoints—. El algoritmo es directo:

  1. 1
    Parsear el DID. did:web:salta.gob.ar → dominio salta.gob.ar, sin path.
  2. 2
    Construir la URL. El estándar dice: https://{dominio}/.well-known/did.json para DIDs sin path. Para DIDs con path: https://{dominio}/{path con / en vez de :}/did.json.
  3. 3
    Hacer GET HTTPS. Pedir ese URL al servidor.
  4. 4
    Validar el response. Debe ser JSON válido conforme al W3C DID Core spec. El id del JSON debe coincidir exactamente con el DID consultado.
  5. 5
    Usar las claves. El JSON contiene una o más claves públicas que se pueden usar para verificar firmas hechas con las claves privadas correspondientes.

Ejemplo de DID Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:web:salta.gob.ar",
  "verificationMethod": [
    {
      "id": "did:web:salta.gob.ar#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:web:salta.gob.ar",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "MCowBQYDK2VwAyEA..."
      }
    }
  ],
  "authentication": ["did:web:salta.gob.ar#key-1"],
  "assertionMethod": ["did:web:salta.gob.ar#key-1"],
  "service": [
    {
      "id": "did:web:salta.gob.ar#issuer-svc",
      "type": "CredentialIssuer",
      "serviceEndpoint": "https://issuer.salta.gob.ar"
    }
  ]
}

Si este JSON se sirve en https://salta.gob.ar/.well-known/did.json, entonces el DID did:web:salta.gob.ar está resuelto.

Implementación en un servidor

Implementar did

en un emisor existente es mayormente configuración:

// Hono / Next.js route handler ejemplo
import { Hono } from "hono";
const app = new Hono();

app.get("/.well-known/did.json", async (c) => {
  const didDocument = await getDIDDocument({
    domain: "salta.gob.ar",
    publicKeyJwk: await getPublicKeyJWK(),
  });
  return c.json(didDocument, 200, {
    "Cache-Control": "public, max-age=3600",
    "Access-Control-Allow-Origin": "*",
  });
});

Tres requisitos operativos críticos:

  • HTTPS válido. El certificado TLS del dominio sirve como ancla de confianza. Sin TLS no hay did
    .
  • CORS abierto. Otros sistemas necesitan poder consultar el DID document desde el browser. Sin CORS, las wallets en web no pueden verificar.
  • Cache control consciente. El DID document cambia poco; debe poder cachearse. Pero si se rota una clave, hay que invalidar la caché de los verificadores.

Cuándo usar did

did

es el método correcto cuando:

A favor

  • El emisor tiene dominio web propio y control sobre él
  • Se necesitan DIDs estables y consultables por humanos
  • Auditoría externa esperada (curl https://... resuelve)
  • Costos mínimos: usa infra que ya tenés
  • Adoptable hoy, sin esperar consensos blockchain

En contra

  • El dominio es punto único de falla: si el dominio expira o cambia owner, los DIDs se rompen
  • No es resistente a censura del dominio
  • Para usuarios individuales (no organizaciones) tener un dominio es overkill

Estado de adopción

did

es uno de los métodos con mejor adopción en proyectos institucionales:

  • EUDI Wallet (UE): acepta did
    como método válido para issuers gubernamentales.
  • AAMVA Digital Trust Service: usa principios similares (PKI sobre dominio) para mDLs.
  • Sovra Stack: acepta did
    junto a did
    para emisores institucionales. La mayoría de los gobiernos provinciales sobre Sovra usan did
    en producción.

Es uno de los pocos métodos donde no hay debate abierto sobre adopción —el debate es entre did

y did
(su evolución con historial trazable), no contra did
en general.

Limitaciones conocidas

Dos limitaciones reales que conviene entender:

Para emisores gov institucionales con dominio público y procesos auditables ambas limitaciones son aceptables. Para casos más exigentes hay alternativas (did

, did
, did
con anclaje en blockchain).

Referencias

Relacionados

Tagsdiddid-webdnswebconceptos-tecnicos