Interoperabilidad entre provincias — cómo funciona en la práctica
Que las 24 jurisdicciones argentinas adopten "los mismos estándares" no es suficiente para que sean interoperables. Hace falta un mecanismo concreto que permita: el ciudadano de Salta presenta una credencial emitida por Salta y un sistema en Mendoza la verifica como auténtica, sin contactar a Salta.
Esta es la mecánica operativa que lo hace posible.
Los 3 niveles de interoperabilidad
La interoperabilidad opera en tres capas simultáneas. Las tres tienen que cumplirse para que el sistema funcione:
Sintáctica
Las credenciales tienen el mismo formato (SD-JWT VC, ISO 18013-5). Una wallet diseñada para SD-JWT VC puede leer cualquier credencial SD-JWT VC, sin importar quién la emitió.
Semántica
Los campos tienen el mismo significado. "fecha_nacimiento" significa lo mismo en Salta y en Mendoza. Sin esto, dos credenciales sintácticamente válidas pueden no comunicarse.
De confianza (trust)
El verificador en Mendoza tiene mecanismo para saber que did:web:salta.gob.ar es genuinamente el emisor oficial de Salta. Sin esto, cualquiera podría emitir credenciales fake firmadas con cualquier DID.
Legal
Las normativas provinciales reconocen las credenciales de otras provincias con valor jurídico. Sin esto, técnicamente funciona pero administrativamente no.
El trust framework federal — la capa más crítica
La capa de confianza es la única que requiere infraestructura compartida. Las otras tres son consensos.
El Trust Framework Federal mantenido por la Mesa Federal define:
- Lista de issuers reconocidos (Trust List): qué DID + dominio + claves públicas corresponden a cada autoridad provincial.
- Política de revocación: cómo se actualiza la Trust List cuando una provincia rota claves o cambia issuer.
- Niveles de assurance: equivalencias entre lo que emite cada provincia y los niveles LoA estándar.
La Trust List es un documento firmado por la Mesa Federal, publicado en formato W3C VC, que cualquier verificador puede descargar y consultar. Es el documento que vincula "did:web
.gob.ar" con "Gobierno de la Provincia de Salta, autoridad reconocida para emitir constancias de domicilio".El flujo de verificación cross-provincia
Veamos en concreto cómo se ve una verificación cross-jurisdicción:
- 1Ciudadano de Salta tramita un beneficio en Mendoza. El sistema mendocino le pide presentar constancia de domicilio reciente.
- 2Wallet del ciudadano arma la presentación. La constancia de Salta firmada por
did:web:salta.gob.arse incluye en una Verifiable Presentation. - 3Sistema mendocino recibe la presentación. Necesita validar tres cosas: (a) firma del emisor, (b) que el emisor sea oficial, (c) que la credencial esté vigente.
- 4Validar firma. Resuelve
did:web:salta.gob.ar(HTTPS GET al dominio) y obtiene la clave pública de Salta. Verifica la firma de la credencial. - 5Validar oficialidad. Consulta la Trust List Federal (descargada y cacheada). Confirma que
did:web:salta.gob.arestá en la lista de issuers reconocidos para credenciales de domicilio. - 6Validar vigencia. Consulta el endpoint de revocación (BitstringStatusList de Salta) para confirmar que la credencial no fue revocada.
- 7Aceptar. Si todos los chequeos pasan, la credencial es aceptada como válida.
El paso clave es el paso 5: la Trust List Federal vincula la autoridad técnica (did:web:salta.gob.ar) con la autoridad jurídica (Gobierno de Salta). Sin la Trust List, el sistema mendocino solo sabría "alguien con esta clave firmó, no sé si es Salta o si tiene autoridad para emitir esto".
Las decisiones que la Mesa tiene que tomar
Para que esto funcione operativamente, la Mesa Federal tiene que tomar tres tipos de decisiones:
| Decisión | Ejemplo concreto |
|---|---|
| Vocabularios semánticos | "fecha_nacimiento" se serializa como ISO 8601 YYYY-MM-DD, no DD/MM/YYYY |
| Niveles de assurance por credencial | "Constancia de domicilio = LoA Substantial; Licencia de conducir = LoA High" |
| Política de actualización Trust List | "Trust List se publica mensualmente; updates urgentes con notificación a todos los verificadores" |
Cada decisión es individualmente simple. La complejidad está en el volumen: probablemente 50-100 decisiones de este tipo para tener un sistema operativo.
El caso del verificador no-provincial
Un caso más complejo: un verificador que no es provincial, como un banco, una empresa privada o una autoridad nacional, tiene que verificar credenciales provinciales.
El mecanismo es el mismo: descarga la Trust List Federal, valida según los pasos del flujo anterior. Lo nuevo es: ¿quién garantiza la Trust List?
Tres opciones que la Mesa puede elegir:
- Trust List firmada por la Mesa misma. La autoridad reside en el órgano federado.
- Trust List firmada por un organismo nacional designado. AAIP, ANSV, o un nuevo organismo creado para esto.
- Trust List publicada vía Boletín Oficial. Versión "máxima formalidad", lentitud máxima.
La opción más práctica internacionalmente es la primera, con respaldo formal del nivel nacional. Es el modelo que sigue eIDAS 2.0 europeo.
La capa legal
La interoperabilidad técnica + de confianza es necesaria pero no suficiente. Hace falta capa legal: cada provincia tiene que reconocer normativamente las credenciales de las otras.
Esto se hace con uno de tres mecanismos:
Decreto provincial
Cada provincia publica un decreto reconociendo credenciales de otras provincias adheridas a la Mesa Federal.
Convenio multilateral
Las provincias firman un convenio que se ratifica por todas las legislaturas provinciales.
Ley nacional habilitante
Una ley nacional establece el marco; cada provincia adhiere por decisión propia.
La opción más rápida es el decreto provincial (cada provincia decide individualmente). La más sólida es la ley nacional habilitante. En la práctica, probablemente la implementación argentina combine las tres en distintas etapas.
Riesgos a evitar
Tres riesgos típicos en proyectos federados que conviene anticipar:
El benchmark de eIDAS 2.0
eIDAS 2.0 europeo tardó ~8 años desde concepto inicial (2017) hasta regulación obligatoria (2024-2025). Cada año del proceso fue iterando con casos piloto (Large Scale Pilots financiados por la Comisión Europea).
Argentina tiene oportunidad de moverse más rápido aprovechando lo aprendido en Europa. Plazo razonable para tener interoperabilidad operativa entre 4-6 provincias: 2-3 años desde constitución de la Mesa Federal.
Referencias
Relacionados
- Gobernanza federada — el modelo Mesa Federal — la estructura institucional
- Soberanía vs interoperabilidad — el debate UE — el debate dentro del modelo
- Trust Frameworks — qué son y para qué — los marcos de confianza en general