Bridge protocols — interop entre frameworks

Cuando dos sistemas SSI operan con estándares distintos (AnonCreds vs SD-JWT VC, o W3C VC vs ISO 18013-5), no se entienden directamente. Para interoperar, hay que construir bridges — sistemas intermedios que traducen entre frameworks.

A 2026, los bridges son una capa emergente del ecosistema SSI.

El problema en una frase

Hay varios frameworks de credenciales en producción. Wallets serias soportan algunos pero no todos. Verifiers están en distintos. Sin bridges, los sistemas operan en silos.

Los pares de frameworks a brigear

Tres pares importantes:

Cada par requiere bridge específico.

Las 4 estrategias de bridging

Cuatro aproximaciones técnicas:

Re-emisión — la estrategia más limpia

El issuer original emite la credencial en múltiples formatos al mismo tiempo:

Issuer → Holder Wallet:
  - SD-JWT VC version
  - W3C VC JSON-LD version  
  - ISO 18013-5 mDoc version

El holder elige cuál presentar según el verifier.

Pros:

• Cada credencial es nativa, sin overhead.
• Las firmas son auténticas del issuer (no de un bridge).
• Sin punto único de falla.

Contras:

• Issuer mantiene múltiples implementaciones.
• Cada formato tiene su propia revocación.

Translation gateway — la estrategia pragmática

Un servicio intermediario convierte entre formatos:

Verifier (acepta SD-JWT VC) 
  ← Gateway 
  ← Holder (presenta AnonCreds)

El gateway:

1. Recibe la presentación en formato A.
2. Verifica criptográficamente.
3. Reemite en formato B.
4. Manda a verifier.

Pros:

• Holder no necesita múltiples credenciales.
• Verifier no necesita soportar múltiples formatos.

Contras:

• Gateway debe ser confiable (es punto de control).
• Posible compromiso de privacy si gateway loggea.
• Latency adicional.

Cross-format verifier — el camino futuro

Verifiers que soporten múltiples formatos nativamente:

Verifier (multi-format):
  - Detecta formato de la presentación
  - Verifica nativamente cada uno
  - No requiere bridge

Pros:

• Sin intermediarios.
• Mejor performance.
• Privacy preservada.

Contras:

• Verifier es más complejo.
• Mantenimiento de múltiples paths verification.

A 2026, este es el camino que las wallets ciudadanas serias están tomando. Sovra Wallet ya soporta SD-JWT VC + ISO 18013-5 nativamente.

Wrapping — el caso especial

Una credencial de un formato puede ser envuelta dentro de otra:

W3C VC outer wrapper
  ├── proof: bbs+ signature
  └── credentialSubject:
      └── credential_proof: AnonCreds inner credential

El verifier W3C VC ve la estructura outer; el verifier AnonCreds-aware puede acceder al inner.

Útil en: transición progresiva de un framework a otro sin romper compatibilidad con verifiers viejos.

Los bridges entre ecosystems

A 2026, hay bridges concretos siendo construidos:

Estos son proyectos abiertos por foundations + governments + privates.

El stack Sovra

Sovra Wallet implementa multi-formato nativo. Soporta:

• SD-JWT VC (default).
• ISO 18013-5 mDoc (para licencias).
• W3C VC JSON-LD (compatibilidad).
• AnonCreds (legacy, opcional).

No requiere bridges externos para los casos comunes. Solo necesita bridges para integración con sistemas que usen formatos no soportados.

Los anti-patrones de bridging

La regla práctica

Para una provincia argentina diseñando SSI en 2026:

1. 1
   Default: multi-format wallet (SD-JWT VC + ISO 18013-5).
2. 2
   Solo si necesario: bridges para integración con ecosystems específicos.
3. 3
   Nunca: depender de un solo bridge para casos críticos.

Referencias

• EBSI Diploma Bridge
• AAMVA + EUDI Wallet Interop Studies

Relacionados

• Matriz de decisión — qué formato usar — qué formato usar
• Internacionalización — acuerdos cross-país — el contexto político
• Matriz de decisión — OID4VC vs DIDComm vs mDL — qué protocolo usar