FederAI · Mesa Federal de Infraestructura Pública Digital

En SSI moderno, una presentación rara vez consiste en una sola credencial. El ciudadano típicamente combina credenciales de múltiples emisores en una sola presentation a un verifier.

Este patrón es central pero técnicamente sutil. Esta guía cubre cómo funciona.

El concepto

Imaginá un caso de uso:

Para abrir cuenta bancaria, el banco pide:
- Identidad ciudadana (emitida por RENAPER)
- Constancia de domicilio (emitida por gob provincial)
- Constancia de no-deudor (emitida por AFIP)

Sin SSI, el ciudadano debe llevar tres documentos físicos o digitales separados. Con SSI, presenta una Verifiable Presentation que contiene las tres credenciales firmadas por sus respectivos emisores.

La estructura

Una Verifiable Presentation multi-credencial:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "holder": "did:key:z6Mk...",
  "verifiableCredential": [
    {
      "issuer": "did:web:renaper.gob.ar",
      "type": ["VerifiableCredential", "IdentityCredential"],
      ...
    },
    {
      "issuer": "did:web:salta.gob.ar",
      "type": ["VerifiableCredential", "DomicileCredential"],
      ...
    },
    {
      "issuer": "did:web:afip.gob.ar",
      "type": ["VerifiableCredential", "NoDeudorCredential"],
      ...
    }
  ],
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:key:z6Mk...#key-1",
    "challenge": "abc123",
    ...
  }
}

El holder firma la presentation completa (con su clave privada), demostrando que controla las tres credenciales y autoriza su combinación.

Las verificaciones del verifier

El verifier (banco) debe hacer cuatro chequeos:

1
Verificar la firma del holder sobre la presentation. Confirma que la presentation viene del legítimo holder.
2
Verificar las firmas de cada credencial individual. Cada uno debe ser válida.
3
Verificar que cada emisor es reconocido. El banco consulta su trust framework para confirmar que RENAPER, Gob Salta y AFIP son issuers válidos para sus respectivas credenciales.
4
Verificar revocation status de cada credencial. Que ninguna esté revocada.

Solo si las cuatro pasan, la presentation es aceptada.

El key binding

Un detalle técnico crítico: cada credencial está vinculada al holder por su DID. La presentation incluye prueba criptográfica de que el holder controla ese DID.

Sin key binding, alguien podría presentar credenciales que no son suyas. Con key binding, las credenciales solo pueden ser presentadas por su legítimo holder.

Selective disclosure cross-credencial

Una capacidad poderosa: el holder puede revelar selectivamente atributos de cada credencial.

Ejemplo:

De IdentityCredential: revelar solo nombre + DNI, sin fecha de nacimiento.
De DomicileCredential: revelar solo provincia, sin domicilio exacto.
De NoDeudorCredential: revelar solo "no deudor", sin monto.

Todos revelados en una sola presentation, con privacy preservada.

La complejidad emergente

Multi-emisor introduce complejidad técnica nueva:

El patrón en la práctica

Cómo se ve en una wallet ciudadana:

1
Ciudadano abre la wallet.
2
Recibe request del banco con presentation definition.
3
Wallet evalúa qué credenciales matchean los requirements.
4
Wallet muestra al ciudadano: "El banco pide estas tres credenciales: identidad + domicilio + no-deudor. Estos son los atributos que se van a compartir".
5
Ciudadano confirma con biométrica + PIN.
6
Wallet arma la presentation + la envía al banco.

UX para el ciudadano es una sola confirmación, no tres por credencial.

La revocación cruzada

Si una de las credenciales de la presentation es revocada, ¿qué pasa con la presentation?

La presentation, una vez emitida, no se "revoca". Es un evento temporal.
Pero el verifier debe verificar revocation en el momento de cada uso futuro.
Si una de las credenciales se revoca, las próximas presentations basadas en ella fallarán.

Credenciales multi-emisor — combinando atributos