When someone presents a digital document issued by another country, proving that the document is authentic is only the beginning.

Suppose Inés, a Brazilian accountant, moves to Montevideo and needs to complete a procedure through a Uruguayan government portal. She has a digital identity issued by Brazil and a digital university degree issued by a Brazilian university.

Uruguay can verify the signatures on those documents. But before accepting them, it needs to know something else: who is behind that signature, and why should Uruguay trust that institution?

It also needs to know whether the way Brazil verified Inés’s identity meets Uruguay’s requirements, and how the systems in both countries can exchange the information they need.

Until now, much of this work has been handled through agreements between governments and institutions, specific integrations, and lists of recognized authorities. Verifiable credentials allow part of that trust to become digital infrastructure. This is where Propia comes in.

In April, we explained how an organization can verify a credential without contacting the organization that issued it. Now we take that one step further: what does a government need to know before accepting a credential issued outside its own system, and how can that trust become something systems can query directly?

1. First, you need to know who can issue

Start with Inés’s degree.

Her university can issue a digital credential stating that she earned her accounting degree. The university digitally signs the credential using a key it controls.

When Inés presents it in Uruguay, the receiving organization can verify that the signature is valid and that the document has not been altered.

But that still leaves a fundamental question:

How does Uruguay know that the key actually belongs to a university authorized to issue degrees?

The traditional answer is an agreement or a trusted list. Uruguay could maintain a list of Brazilian universities it recognizes, or the two countries could agree on which authorities are valid.

The problem emerges as this model has to scale. There are more countries, more institutions, more issuers, and more keys. Maintaining trust relationships one by one becomes difficult.

Propia proposes turning this information into a trust layer that systems can query directly.

Instead of requiring every verifier to maintain its own list, Propia proposes a public registry where systems can check which issuers are recognized and which credentials they are authorized to issue.

So when Uruguay receives Inés’s degree, it can verify not only that the signature is valid, but also that the institution behind the signature is recognized as a valid issuer.

2. Then, you need to know what “verified” actually means

Inés’s identity presents a different problem.

Brazil and Uruguay may use different procedures to establish that someone is who they claim to be. One country may verify an identity entirely online, while another may require an in-person appearance, official documents, or biometric checks.

That is why it is not enough to say that Brazil “verified” Inés. Uruguay needs to know what checks she had to pass.

Identity systems address this through assurance levels. Each level represents a set of requirements a person must meet for the system to consider their identity sufficiently trustworthy.

When two countries want to recognize each other’s identities, they need to establish which assurance levels they accept.

Uruguay and Brazil have already done this. According to Agesic, Uruguay considers Brazil’s highest level, known as gold, equivalent to its own advanced level.

This allows people with a Brazilian gold-level identity to access more than 400 digital services in Uruguay, under the assurance conditions agreed between the two countries.

In this case, recognition remains a government-to-government agreement. Propia addresses another part of the problem: trust in credentials and in the institutions that issue them.

Its model uses public registries to make it possible to check who is authorized to issue, which key the issuer controls, and the current status of a credential.

The result is that trust does not have to depend entirely on a direct integration between the system that issued a document and the system that receives it.

3. Finally, the systems need to be able to talk to each other

There is a third piece: even if Uruguay knows who issued the credential and trusts that issuer, the systems still need a way to exchange it.

This is where interoperability protocols come in.

When Inés signs in using her Brazilian digital identity, the systems in both countries need common rules for requesting and exchanging the information they need.

Her university degree can follow a different path. Inés can store it in a wallet and present it directly to the Uruguayan government organization.

In that case, the wallet and the organization need compatible protocols to request, receive, and verify the credential.

Among the most widely used standards are OpenID4VCI, for issuing credentials, and OpenID4VP, for presenting them. In September, the OpenID Foundation announced the first implementations to pass its public conformance tests.

Sovra builds on these standards so credentials can move between wallets, issuers, and verifiers without every integration having to define its own rules. SovraID enables the issuance and verification of credentials, SovraWallet lets people store and present them, and Propia provides the trust layer for verifying issuers and their credentials.

How it works with Sovra

Let’s go back to Inés’s degree.

1. The university issues the credential.
   With SovraID, the university issues the degree as a digital credential signed with its own key. Its status can be updated later, for example if the credential needs to be revoked.

2. Inés stores the credential.
   She stores it in SovraWallet, where she controls her credentials and decides when to present them.

3. Uruguay receives and verifies the degree.
   The government organization initiates the presentation through a QR code and cryptographically verifies the credential’s signature. It does not need to contact the university every time Inés presents the degree.

4. Uruguay verifies trust in the issuer.
   This is where Propia comes in. The organization can query its registries to check that the university is recognized as an issuer for that type of credential, that the key associated with the issuer remains valid and under its control, and that the credential has the expected status.

The distinction matters.

Credential verification answers: “Is this document authentic?” Propia adds: “Why should I trust the institution that issued it?”

And it does so without turning that trust layer into a database of people. The registries do not need to store Inés’s personal data or record where she presented her degree.

From system-to-system agreements to trust infrastructure

For Inés to complete the procedure in seconds, several pieces have to work together: her identity has to be recognized, the institution that issued her credential has to be trusted, and the systems need to be able to exchange and verify that information.

Government agreements still matter because they determine which identities and authorities each country recognizes. But not everything has to be solved through a direct integration between every pair of systems. An architecture like Propia allows part of that trust to become open, queryable infrastructure, without requiring every organization to build and maintain its own lists and integrations.

That is the shift: the credential can travel with the person, while the information needed to trust it can be available to whoever needs to verify it.

Keep reading

• [PODCAST] Ep. 11 with Héctor Saravia: how Peru’s civil registry chose to stay out of every verification of its digital ID.

• Digital Credential Wallets: What Changes When They Go Into Production: what a government wallet needs when its documents start circulating to other institutions.

Keep the conversation going

Our knowledge center at sovra.io/knowledge explains verifiable credentials, trust registries, and digital identity standards in plain language, from the basic concepts to the systems already in production.

How does your country decide which foreign identities it accepts? Reply and tell us. We read every response, and if someone on your team works on interoperability, send them this edition.

Subscribe to The Identity Brief, published weekly.

Cuando una persona presenta un documento digital de otro país, comprobar que el documento es auténtico es solo el comienzo.

Supongamos que Inés, una contadora brasileña, se muda a Montevideo y necesita hacer un trámite en un portal público uruguayo. Tiene una identidad digital emitida por Brasil y un título universitario digital emitido por una universidad brasileña.

Uruguay puede comprobar la firma. Pero antes de aceptarlos necesita saber algo más: ¿quién está detrás de esa firma y por qué debería confiar en esa institución?

También necesita saber si la forma en que Brasil verificó la identidad de Inés alcanza para Uruguay y cómo pueden intercambiar información los sistemas de ambos países.

Hasta ahora, buena parte de ese trabajo se resolvía con acuerdos entre instituciones y gobiernos, integraciones específicas y listas de autoridades reconocidas. Las credenciales verificables permiten llevar una parte de esa confianza a la infraestructura digital. Ahí es donde aparece Propia.

En abril explicamos cómo un organismo puede verificar una credencial sin consultar al organismo que la emitió. Ahora vamos un paso más allá: qué necesita saber un gobierno para aceptar una credencial emitida fuera de su sistema y cómo esa confianza puede convertirse en algo que los sistemas consultan directamente.

1. Primero hay que saber quién puede emitir

Empecemos por el título de Inés.

Su universidad puede emitir una credencial digital que diga que obtuvo el título de contadora. La universidad firma esa credencial digitalmente con una clave que controla.

Cuando Inés la presenta en Uruguay, el organismo puede comprobar que la firma es válida y que el documento no fue modificado.

Pero eso todavía no responde una pregunta fundamental:

¿cómo sabe Uruguay que esa clave pertenece realmente a una universidad autorizada para emitir títulos?

La respuesta tradicional es un acuerdo o una lista de confianza. Uruguay puede mantener una lista de universidades brasileñas que reconoce, o los dos países pueden acordar qué autoridades son válidas.

El problema aparece cuando este modelo tiene que crecer. Hay más países, más instituciones, más emisores y más claves. Mantener relaciones de confianza una por una se vuelve difícil.

Propia plantea convertir esa información en una capa de confianza que los sistemas puedan consultar directamente.

En lugar de que cada verificador tenga que mantener su propia lista, Propia propone un registro público donde se pueda comprobar qué emisores están reconocidos y qué credenciales están habilitados a emitir.

Así, cuando Uruguay recibe el título de Inés, puede verificar no solo que la firma es correcta, sino también que la institución que firmó está reconocida como un emisor válido.

2. Después hay que saber qué significa “verificada”

La identidad de Inés presenta otro problema.

Brasil y Uruguay pueden tener procedimientos diferentes para comprobar quién es una persona. Un país puede verificar una identidad completamente online y otro puede requerir una comparecencia presencial, documentos oficiales o datos biométricos.

Por eso no alcanza con decir que Brasil “verificó” a Inés. Uruguay necesita saber qué controles tuvo que superar.

Los sistemas de identidad resuelven esto mediante niveles de garantía. Cada nivel representa un conjunto de requisitos que una persona tuvo que cumplir para que el sistema considere confiable su identidad.

Cuando dos países quieren reconocer identidades entre sí, tienen que establecer qué niveles aceptan.

Uruguay y Brasil ya lo hicieron. Según Agesic, Uruguay considera el nivel más alto de Brasil, llamado oro, equivalente a su propio nivel avanzado.

Eso permite que una persona con una identidad brasileña de nivel oro acceda a más de 400 servicios digitales uruguayos, bajo las condiciones de garantía acordadas entre ambos países.

En este caso, el reconocimiento sigue siendo un acuerdo entre gobiernos. Propia resuelve otra parte del problema: la confianza en las credenciales y en quienes las emiten.

Su modelo propone registros públicos que permiten comprobar quién está autorizado a emitir, qué clave controla ese emisor y cuál es el estado de una credencial.

El resultado es que la confianza deja de depender solamente de una integración directa entre el sistema que emitió el documento y el sistema que lo recibe.

3. Finalmente, los sistemas tienen que poder hablar

Hay una tercera pieza: incluso si Uruguay sabe quién emitió la credencial y confía en ese emisor, los sistemas tienen que poder intercambiarla.

Ahí entran los protocolos de interoperabilidad.

Cuando Inés inicia sesión utilizando su identidad brasileña, los sistemas de ambos países necesitan reglas comunes para pedir y entregar la información necesaria.

Su título universitario puede seguir un recorrido diferente. Inés puede tenerlo guardado en una wallet y presentarlo directamente al organismo uruguayo.

En ese caso, la wallet y el organismo necesitan protocolos compatibles para solicitar, recibir y verificar la credencial.

Entre los estándares más utilizados están OpenID4VCI, para emitir credenciales, y OpenID4VP, para presentarlas. En septiembre, la OpenID Foundation publicó las primeras implementaciones que pasaron sus pruebas públicas.

Sovra trabaja sobre estos estándares para que las credenciales puedan circular entre wallets, emisores y verificadores sin que cada integración tenga que inventar sus propias reglas. SovraID permite emitir y verificar credenciales, SovraWallet permite que las personas las almacenen y presenten, y Propia aporta la capa de confianza para verificar a los emisores y sus credenciales.

Cómo funciona con Sovra

Volvamos al título de Inés.

1. La universidad emite la credencial.
   Con SovraID, la universidad emite el título como una credencial digital firmada con su propia clave. Su estado puede actualizarse posteriormente, por ejemplo si necesita ser revocada.

2. Inés guarda la credencial.
   La almacena en SovraWallet, donde ella controla sus credenciales y decide cuándo presentarlas.

3. Uruguay recibe y verifica el título.
   El organismo inicia la presentación mediante un código QR y verifica criptográficamente la firma de la credencial. No necesita llamar a la universidad para comprobar el documento cada vez que Inés lo presenta.

4. Uruguay verifica la confianza en el emisor.
   Ahí entra Propia. El organismo puede consultar sus registros para comprobar que la universidad está autorizada para emitir esa credencial, que la clave asociada al emisor sigue siendo válida y está bajo su control.

La diferencia es importante.

La verificación de la credencial responde “¿el documento es auténtico?”. Propia agrega “¿por qué debería confiar en quien lo emitió?”.

Y lo hace sin convertir esa capa de confianza en una base de datos de personas. Los registros no necesitan guardar los datos personales de Inés ni registrar dónde presentó su título.

De acuerdos entre sistemas a infraestructura de confianza

Para que Inés pueda hacer el trámite en segundos, distintas piezas tienen que funcionar juntas: su identidad tiene que ser reconocida, la institución que emitió su credencial tiene que ser confiable y los sistemas tienen que poder intercambiar y verificar esa información.

Los acuerdos entre gobiernos siguen siendo importantes porque determinan qué identidades y qué autoridades reconoce cada país. Pero no todo tiene que resolverse mediante una integración directa entre cada par de sistemas. Una arquitectura como Propia permite llevar una parte de esa confianza a una infraestructura abierta y consultable, sin que cada organismo tenga que construir y mantener sus propias listas e integraciones.

Ese es el cambio: la credencial puede viajar con la persona, mientras que la información necesaria para confiar en ella puede estar disponible para quien tiene que verificarla.

Para seguir leyendo

• [PODCAST] Ep. 11 con Héctor Saravia: cómo el registro de Perú eligió quedar fuera de cada verificación de su DNI digital.

• Billeteras de credenciales digitales: qué cambia cuando entran en producción: lo que necesita una billetera de gobierno cuando sus documentos empiezan a circular hacia otras instituciones.

Sigamos la conversación

Nuestro centro de conocimiento en sovra.io/knowledge explica en lenguaje simple las credenciales verificables, los registros de confianza y los estándares de identidad digital, desde los conceptos básicos hasta los sistemas que ya están en funcionamiento.

¿Cómo decide tu país qué identidades extranjeras acepta? Respóndenos y cuéntanos. Leemos cada respuesta, y si alguien de tu equipo trabaja en interoperabilidad, reenvíale esta edición.

Suscríbete a The Identity Brief, publicado cada semana.

Perú ya emite su documento de identidad, el DNId, como credencial verificable: una versión del DNI firmada digitalmente que vive en una billetera en el celular llamada Perú Pass, y que cualquiera puede comprobar sin contactar a la oficina que la emitió. La billetera ya salió en Android con 63 millones de credenciales entre DNI, partidas de nacimiento y actas de matrimonio.

En la práctica, el DNId tiene el mismo valor legal que el DNI físico y es gratuito durante 2026. Para usarlo, el ciudadano muestra desde Perú Pass un código QR que se genera en el momento, elige qué datos compartir y, si pierde el celular, puede revocarlo en línea. Ya hay más de 22 instituciones que lo aceptan en programas de vivienda, becas, inclusión financiera y transporte, y según CDPI sirve incluso para renovar la licencia de conducir o entrar a Machu Picchu. La norma además deja la puerta abierta a otras billeteras que cumplan los mismos estándares, no solo a la del Estado.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Héctor Saravia, Director de Certificación y Servicios Digitales de RENIEC. Antes de llegar al registro en 2023, Héctor pasó años en el sector privado intentando usar el DNI electrónico con sus clientes, así que conoce el problema desde el otro lado del mostrador: sabe lo que un banco necesita de un documento porque durante mucho tiempo fue quien lo pedía.

Lo que vas a escuchar

1. Por qué el DNI con chip no alcanzó. Perú tiene un DNI electrónico con chip desde 2013, pero casi nadie lo usó: el DNI tradicional se siguió emitiendo y era más barato. Además, bancos y empresas nunca recibieron las herramientas para leer el chip, así que para confirmar la identidad de un cliente seguían consultando a RENIEC. Héctor lo describe como un modelo de desconfianza, en el que el registro queda en el medio de cada trámite y los datos de los ciudadanos terminan copiados en muchas empresas, casi siempre desactualizados.

2. Cómo arrancó el proyecto. En 2024 el equipo empezó a estudiar otros modelos, como el europeo eIDAS 2 y el de India, pero no tenía presupuesto para construir algo nuevo. El giro llegó en un evento en El Salvador, donde Héctor conoció a Manuel Aguilera, del Centre for Digital Public Infrastructure (CDPI), una organización que ayuda a los países a implementar estos sistemas. Manuel contó su parte de la historia en nuestra conversación con Manuel Aguilera. De ese encuentro salió un piloto sobre Inji, la herramienta de código abierto de MOSIP para emitir credenciales, con el apoyo de Co-Develop y de la plataforma filantrópica VélezReyes+. El Estado puso el equipo de personas, y el proyecto tardó unos ocho meses, sobre todo por los controles de seguridad internos de RENIEC.

3. La prueba en la Amazonía. Para probar el DNId en condiciones reales, el equipo viajó en avión, en auto y en lancha río arriba hasta una zona de la selva sin conectividad, con su propia antena satelital. Ahí trabajan productores de cacao que le venden a compradores suizos, y esos compradores les entregan una credencial verificable que prueba que su tierra no fue deforestada. El sector de microfinanzas también usa su propia billetera de credenciales en la zona, y la idea era ver si el DNId funcionaba junto a ella. El obstáculo fue identificar a los productores, porque la verificación de huella fallaba: el trabajo a mano y el cordel de pesca les habían gastado las huellas. El equipo la reemplazó por biometría facial, los productores recibieron su DNId en el celular y las dos billeteras funcionaron juntas.

4. La decisión clave: la verificación no pasa por RENIEC. RENIEC emite el DNId y la prueba de autenticidad viaja dentro de la credencial, así que un banco o un comercio puede verificarla por su cuenta, sin consultar al registro. Héctor lo resume diciendo que RENIEC queda “ciego y sordo” cada vez que alguien muestra su DNI digital. Con eso se recupera la privacidad del documento físico, porque el registro nunca supo cuándo mostraste tu DNI para comprar una botella de vino, y se respeta el consentimiento que exige la ley de protección de datos personales. Explicamos cómo funciona en detalle en verificar sin consultar al emisor.

5. Qué cambia para bancos y comercios. Si RENIEC ya no responde cada consulta, la prueba de cada verificación queda en manos de quien verifica y en la billetera del ciudadano. Es lo que más cuesta explicar, y por eso RENIEC organiza bootcamps para verificadores. A cambio, el costo baja: un amigo de Héctor del sector financiero calcula que podría reducir al menos un 80% sus costos de verificación, porque pasa de pagar consultas todo el tiempo a hacer una integración una sola vez. Los trámites también se simplifican: si alguien se muda o se casa, RENIEC revoca la credencial anterior y emite una nueva, sin imprimir otra tarjeta. Lo explicamos en cómo funciona la revocación.

6. Cómo se sostiene el modelo. RENIEC cobra por las consultas, así que un sistema sin consultas obliga a buscar otros ingresos. La apuesta de Héctor es sumar verificadores: una lista de confianza que el ciudadano pueda reconocer, transacciones más rápidas para quienes estén en ella y una convocatoria abierta para que empresas de tecnología lleven la verificación a sus propios clientes. Una segunda fase, con apoyo del Banco Interamericano de Desarrollo (BID), apunta a una versión 2.0 del DNId.

Frases destacadas

“Nos encantó ese concepto de que nosotros seamos ciegos y sordos cada vez que haya una presentación de un DNI digital. Eso es lo que crearía realmente un sistema de confianza, porque nadie está metiéndose entre mi verificador y yo.”

“Ahora la carga de la prueba ya no va a estar en RENIEC, va a estar en el propio verificador y en la billetera del ciudadano.”

“El DNI digital es la solución, les vamos a hacer una biometría facial. Y nos fuimos a la selva y funcionó.”

“No perdamos el miedo al open source. Te puede dar un poco más de soberanía también a ti como país.”

Sobre el invitado

Héctor Saravia es Director de Certificación y Servicios Digitales de RENIEC, la institución que administra la identidad, el registro civil y el padrón electoral de Perú. Asumió el cargo en febrero de 2023, después de una larga trayectoria en el sector privado trabajando con clientes que querían construir sobre el DNI electrónico. Su dirección lideró el proyecto del DNI digital y de Peru Pass junto a MOSIP, CDPI, Co-Develop y VélezReyes+. Su mirada es valiosa porque estuvo en los dos lados del mostrador: sabe lo que una empresa necesita de un documento de identidad y hoy dirige el área del Estado que lo emite.

Más de Sovra

• 🎧 [PODCAST] Ep. 9: LATAM tiene todo para ganar en infraestructura digital (con Manuel Aguilera) · el lado de CDPI en esta historia: cómo Brasil e India construyeron rieles compartidos y por qué la región puede reutilizarlos.

• 🎧 [PODCAST] Ep. 10: Cómo 24 jurisdicciones argentinas construyen una agenda digital común (con Mauro Solano) · la reutilización como argumento presupuestario, contada desde las provincias.

• 📖 La Privacidad No Se Negocia · cómo un verificador comprueba una credencial sin contactar al emisor, la propiedad sobre la que RENIEC construyó su diseño.

• 📖 El ciclo de vida completo de una credencial verificable · emisión, presentación, estado y revocación, los pasos detrás del ejemplo del cambio de domicilio.

Sigamos la conversación

Conocé los estándares y los componentes detrás de estas ideas en sovra.io/knowledge, nuestro centro de conocimiento sobre identidad digital y credenciales verificables. En Sovra construimos esta capa para gobiernos: SovraID para emitir y verificar credenciales, SovraWallet para el lado del ciudadano y SovraGov para los servicios que se construyen encima. Entre todos los despliegues, ese stack ya atiende a más de 8 millones de ciudadanos, con más de 1,5 millones de identidades en más de 20 gobiernos.

Leemos cada respuesta: contanos cómo funciona la verificación en tu país hoy, ¿cada control sigue volviendo al registro? Y reenviale esta edición a alguien que trabaje en identidad en un registro civil o en un banco.

Suscribite a The Identity Brief, publicado semanalmente.

🎧 Escuchá el episodio completo en YouTube

Peru now issues its national ID, the DNI, as a verifiable credential: a digitally signed version of the ID that lives in a phone wallet called Peru Pass, and that anyone can check without contacting the office that issued it. According to Biometric Update, the wallet went live on Android with 63 million credentials across the national ID, birth certificates and marriage certificates.

The decision that shapes the whole project is something RENIEC, Peru’s national registry of identity and civil status, chose to stop doing. Until now, a bank that received a customer’s ID card queried the registry to confirm it. With the digital ID, the bank checks the credential itself and the registry never learns the ID was shown, which gives the digital document the same privacy a plastic card always had.

In this episode of Sovra Podcast, Lucas Jolías speaks with Héctor Saravia, Director of Certification and Digital Services at RENIEC. Héctor spent years in the private sector as a would-be user of Peru’s electronic ID before joining the registry in 2023, which gives him an unusual view of the problem: he knows what a bank needs from an ID because he used to be the one asking for it. The conversation covers where the project came from, the international partners who made it possible, and the design decision at its center.

What You Will Hear

1. Why a chip in the card was never enough Peru has had an electronic ID with a cryptographic chip since 2013, and few people used it. Héctor explains why: the conventional card kept being issued and was cheaper, and the public and private sectors never received the components to read the chip directly. So every bank that received a customer’s ID still queried RENIEC to confirm the person was who the card said. A registry that answers every check becomes the center of every transaction, and Héctor describes how that pattern left copies of citizens’ data spread across companies, most of it out of date.

2. Looking east, and a meeting in El Salvador At the start of 2024 the team studied the credential model behind US mobile driver’s licenses, then turned to Europe’s eIDAS 2 framework and to India. Peru’s new personal data protection rules were also narrowing how registry data could be supplied. The budget did not cover a new build. The turning point came at a digital identity event in El Salvador, where Héctor heard Manuel Aguilera of the Centre for Digital Public Infrastructure (CDPI) explain how CDPI helps countries implement digital public infrastructure with verifiable credentials, a story Manuel told from his side in our conversation with Manuel Aguilera of CDPI.

3. The design decision: verification does not go through RENIEC This is the idea Lucas singles out and the one Héctor calls the part the team loved from the beginning. RENIEC issues the credential, and the proof travels inside it, so a shop or a bank can confirm the ID is authentic and current without asking the registry. Héctor’s phrase for it is that RENIEC becomes “blind and deaf” to each presentation. It restores the privacy of the physical card, where the registry never learned that you showed your ID to buy a bottle of wine, and it lines up with the consent principle in Peru’s data protection law. We walked through the mechanics of verification that never calls the issuer in an earlier edition, which explains how a verifier checks the signature and the credential’s status on its own.

4. Open source, a pilot, and a partner network RENIEC’s first contact was with MOSIP, the open-source identity platform, and the pilot ran on Inji, MOSIP’s open-source credential stack. The team challenged the Inji side to use RENIEC’s existing authenticator instead of its own, which cut cost, and they made it work across time zones and a language gap. CDPI brought in Co-Develop and the philanthropic platform VélezReyes+ to fund and support the build. Héctor is candid that the eight months it took were mostly spent on RENIEC’s own security protocols, which is the kind of internal work that makes a platform fit to be treated as a critical service.

5. The burden of proof moves When the registry stops answering every query, the evidence of a verification lives with the verifier and in the citizen’s wallet. Héctor admits this is the hardest idea to teach: RENIEC runs bootcamps for verifiers, and businesses ask what their new responsibilities are. The answer he gives them is a model with lower costs. A friend in the financial sector told him that identifying customers this way could cut his recurring verification costs by at least 80%, because the work becomes a one-time integration. Updates change shape too: when a citizen moves house or marries, RENIEC can revoke the old credential and issue a new one instead of printing a new card, a pattern we explain in how revocation works.

6. Sustainability through verifiers RENIEC’s traditional income comes from charging for queries, so a design that removes queries forces a new plan. Héctor’s plan is to grow the number of verifiers: a trust list of registered verifiers that citizens can recognize, faster transactions for the businesses on it, and an open call so private technology companies can bring the verification components to their own clients under the same technical documentation and standards. Phase two, with support from the Inter-American Development Bank, is meant to take the platform from a first version that covers the basics to a second one.

Key Quotes

“We loved the idea that we would be blind and deaf every time a digital ID is presented. That’s what would really create a system of trust, because nobody is getting in between my verifier and me.”

“Now the burden of proof is no longer going to be on RENIEC. It’s going to be on the verifier itself and on the citizen’s wallet.”

“The digital ID is the solution. We’ll do facial biometrics. And we went to the rainforest and it worked.”

“Let’s lose our fear of open source. It can give you a bit more sovereignty as a country too.”

About the guest

Héctor Saravia is Director of Certification and Digital Services at RENIEC, the Registro Nacional de Identificación y Estado Civil, which runs Peru’s national identity, civil registry and electoral roll. He was appointed in February 2023 after a long career in the private sector, where he worked with clients who wanted to build on Peru’s electronic ID. His directorate led the DNI digital project and Peru Pass, working with MOSIP, CDPI, Co-Develop and VélezReyes+. His perspective is valuable because he has sat on both sides of the counter: he knows what a business needs from an identity document, and he now runs the part of the state that issues it.

More from Sovra

• 🎧 [PODCAST] Ep. 9: Latin America Has Everything to Win at Digital Infrastructure (with Manuel Aguilera) · the CDPI side of this story: how Brazil and India built shared rails, and why the region can reuse them instead of building alone.

• 🎧 [PODCAST] Ep. 10: The Provinces Are Not Waiting (with Mauro Solano) · how Argentina’s 24 jurisdictions coordinate a digital agenda, and why reuse makes infrastructure affordable.

• 📖 Privacy Is Not a Trade-Off · how a verifier checks a credential without contacting the issuer, the property RENIEC built its design on.

• 📖 The full lifecycle of a verifiable credential · issuance, presentation, status and revocation, the steps behind Héctor’s address-change example.

Continue the conversation

Explore the standards and building blocks behind these ideas at sovra.io/knowledge, our hub for digital identity and verifiable credentials. Sovra builds this layer for governments: SovraID for issuing and verifying credentials, SovraWallet for the citizen side, and SovraGov for the services built on top. Across deployments, that stack already serves 8M+ citizens with 1.5M+ identities across 20+ governments.

We read every response, so reply and tell us how verification works in your country today: does every check still go back to the registry? Forward this to someone working on identity in a civil registry or a bank.

Subscribe to The Identity Brief, published every week.

🎧 Listen to the full episode on YouTube

A digital credential wallet can look simple from the user’s perspective: the government issues a document, the person stores it on their phone, and presents it when needed.

But behind that simple interaction is a complex infrastructure. Once a credential leaves the system that issued it, another government agency, bank, or university needs to be able to recognize who issued it, verify that it is authentic, and check that it is still valid.

That is the circuit we operate at Sovra. SovraID issues verifiable credentials. SovraWallet lets people store and present them. SovraGov manages the procedures that produce them. And Propia, built with LambdaClass and Aligned, provides a public trust layer so that credentials can be recognized across systems, without exposing personal data or recording their use. All of this is supported by SovraChain.

In Nuevo León, this is already in production. NLínea allows people to carry official documents on their phones and present them as digital credentials, within a state ecosystem with more than 700 procedures and services.

The wallet integrates with NLínea’s Expediente Único, allowing documents such as birth certificates, permits, and contracts to move from a government procedure into a format the person can keep on their device. The document no longer stays only inside the digital service window: it also stays with the citizen.

What Changes After Issuance

The first step is getting documents into the wallet. The next is making sure they remain useful outside it.

In Nuevo León, the starting point is the documents already contained in Expediente Único. As new documents and new verification points are added, the same credential can be used across more procedures and services.

This also changes how integrations work. Instead of every agency having to reconstruct the document or query the system that originally issued it, the credential can carry the information needed to be verified. For this to work across different systems, Propia provides the public registries needed to recognize authorities, keys, and credential status.

The Launch Is the Beginning

Having NLínea in production marks a concrete change: official documents can reach a person’s phone and be presented from there.

The next step is for those documents to be accepted in more places, without requiring people to return to the original government procedure every time they need to prove something.

That is why deploying a wallet is not measured only by how many documents it can store. It also depends on how far those documents can travel once they are in the hands of the person.

Keep the Conversation Going

If your institution is working on modular service architectures, get in touch.

Concepts explained in simple language: sovra.io/knowledge.

Subscribe to The Identity Brief, published weekly.

Keep Reading

• The Full Lifecycle of a Verifiable Credential

• How the Mobile Driver’s License Works

• How a Verifiable Credential Outlives Its Issuer

• Inside Propia: Three Public Trust Registries

Una billetera de credenciales digitales puede parecer simple desde el punto de vista de la persona: el Estado emite un documento, la persona lo guarda en el teléfono y lo presenta cuando lo necesita.

Pero detrás de ese gesto hay una infraestructura compleja. Cuando una credencial sale del sistema que la emitió, otro organismo, un banco o una universidad tiene que poder reconocer quién la emitió, verificar que es auténtica y comprobar que sigue vigente.

Ese es el circuito que operamos en Sovra. SovraID emite credenciales verificables. SovraWallet permite a las personas guardarlas y presentarlas. SovraGov gestiona los trámites que las producen. Y Propia, construida con LambdaClass y Aligned, aporta una capa pública de confianza para que esas credenciales puedan reconocerse entre sistemas, sin exponer datos personales ni registrar su uso. Todo esto se apoya en SovraChain.

En Nuevo León, esto ya está en producción. La billetera NLínea permite llevar documentos oficiales en el teléfono y presentarlos como credenciales digitales, dentro de un ecosistema estatal con más de 700 trámites y servicios.

La billetera se integra con el Expediente Único de NLínea, de modo que documentos como actas, permisos y contratos pueden pasar del trámite a un formato que la persona conserva en su dispositivo. El documento ya no queda solamente dentro de la ventanilla digital: también acompaña al ciudadano.

Acá te dejamos un video realizado por el gobierno de Nuevo León para mostrar su funcionamiento:

Qué cambia después de la emisión

La primera etapa es conseguir que los documentos lleguen a la billetera. La siguiente es conseguir que sean útiles fuera de ella.

En Nuevo León, el punto de partida son los documentos que ya forman parte del Expediente Único. A medida que se incorporan nuevos documentos y nuevos puntos de verificación, la misma credencial puede participar en más trámites y servicios.

Eso también cambia la lógica de las integraciones. En lugar de que cada organismo tenga que reconstruir el documento o consultar nuevamente al sistema que lo generó, la credencial puede llevar consigo la información necesaria para ser verificada. Para que esto funcione entre sistemas distintos, Propia aporta los registros públicos necesarios para reconocer autoridades, claves y estado de las credenciales.

El lanzamiento es el comienzo

Que NLínea esté en producción marca un cambio concreto: los documentos oficiales pueden llegar al teléfono de una persona y volver a presentarse desde ahí.

El paso siguiente es que esos documentos puedan ser aceptados en más lugares, sin obligar a la persona a volver al trámite original cada vez que necesita demostrar algo.

Por eso, el despliegue de una billetera no se mide solamente por cuántos documentos puede guardar. También por qué tan lejos pueden viajar esos documentos una vez que están en manos de la persona.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios, no dudes en ponerte en contacto.

Conceptos explicados en lenguaje simple: sovra.io/knowledge.

Suscribite a The Identity Brief, se publica semanalmente.

Para seguir leyendo

• El ciclo completo de una credencial verificable

• Cómo funciona una licencia de conducir cuando vive en el teléfono

• Qué mantiene verificable un documento cuando cambia la institución que lo emitió

• Dentro de Propia: tres registros públicos de confianza

La Lotería de Río Negro y la Lotería La Neuquina registran digitalmente sus resultados para que cualquier persona pueda comprobar que el documento publicado es exactamente el que fue emitido después del sorteo. La Lotería de San Juan será la próxima en incorporarse. Río Negro también extendió el sistema a la certificación de premios de monto alto.

Desde Sovra implementamos Sovra Trace en estos sistemas, una capa de certificación que permite registrar estos documentos y convertir los certificados de premio en credenciales digitales verificables: documentos firmados por una institución que pueden comprobarse sin tener que volver a consultar al emisor.

El documento de cada sorteo

Todas las noches, las loterías provinciales hacen sus sorteos y publican un extracto, (la lista oficial de los números ganadores). En Argentina, donde la quiniela se juega todos los días, ese documento se convierte en la referencia para revisar resultados, pagar premios y resolver reclamos.

Río Negro fue la primera lotería de Sudamérica en certificar sus resultados de esta manera y opera el sistema desde 2024. La Neuquina cuenta además con un verificador público, por lo que comprobar un sorteo no requiere pedir acceso a la institución. La Lotería de San Juan incorporará el mismo sistema próximamente.

La idea es sencilla: si alguien necesita comprobar un resultado mañana, dentro de un año o dentro de diez, puede hacerlo por su cuenta.

Cómo funciona la certificación

El extracto es un archivo. Antes de publicarlo, el sistema calcula una huella digital, llamada hash. Es una especie de identificador del archivo: si el contenido no cambia, la huella es siempre la misma. Si alguien cambia un número, una palabra o una coma, la huella cambia.

La lotería registra esa huella en SovraChain, junto con la fecha y la hora. El extracto completo sigue estando publicado por la propia lotería. En la red pública queda la huella y el momento en que fue registrada.

Para verificarlo, cualquiera puede descargar el extracto, calcular nuevamente su huella y compararla con la que quedó registrada. Si coinciden, el archivo es exactamente el mismo que se registró originalmente.

Registrar esa huella en una red pública agrega algo que una base de datos propia no puede garantizar por sí sola: el registro no depende de la infraestructura de la institución. Si con los años cambia el sistema, cambia el proveedor tecnológico o se reorganiza el organismo, el registro externo sigue existiendo y puede ser consultado por terceros.

Qué permite comprobar

La certificación tiene un alcance concreto: permite comprobar que el resultado publicado es el mismo que fue registrado y que ese registro ya existía en una fecha determinada.

La seguridad del sorteo sigue dependiendo de la máquina utilizada, los controles técnicos, el protocolo y los funcionarios responsables. Esta capa verifica lo que ocurre después: que el resultado que llegó al público no fue modificado respecto del que quedó registrado.

Si una lotería necesita corregir un resultado, registra una nueva versión con su propia huella y su propia fecha. La versión anterior no desaparece, por lo que el historial completo queda registrado y puede consultarse.

De un sorteo a un certificado de premio

Río Negro extendió el mismo mecanismo a los premios de monto alto, en juegos como Quini 6, Loto 5, Telebingo Patagónico y Pozo de la Quiniela. La persona que gana recibe un certificado y puede presentarlo ante un banco, una escribanía o un registro de la propiedad, que pueden comprobarlo por su cuenta, sin tener que comunicarse con la lotería.

El documento funciona entonces como una credencial verificable, igual que un título universitario, una matrícula profesional o una licencia de conducir digital.

Qué cambia cuando el documento es verificable

Al final, el problema es bastante simple: un documento oficial debería poder seguir demostrando lo que decía cuando fue emitido, aunque pasen los años y cambien los sistemas que lo rodean.

Río Negro ya lo aplica a resultados y certificados de premios. Neuquén, a sus resultados. San Juan está incorporándose al mismo esquema. Tres loterías, distintos usos y una misma necesidad: que la prueba quede registrada y pueda ser verificada por terceros cuando haga falta.

La confianza deja de depender de que alguien recuerde dónde estaba el documento, qué sistema lo guardaba o a quién había que llamar para comprobarlo. La prueba simplemente queda ahí.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios, no dudes en ponerte en contacto.

Conceptos explicados en lenguaje simple: sovra.io/knowledge.

Suscribite a The Identity Brief, se publica semanalmente.

Para leer esta semana

• Lotería de Río Negro: la ampliación de la certificación a premios de monto alto en Quini 6, Loto 5, Telebingo Patagónico y Pozo de la Quiniela.

• Lotería La Neuquina: su verificador público y las preguntas frecuentes sobre cómo comprobar un sorteo.

• Cómo funciona una licencia de conducir digital: qué cambia cuando una credencial puede llevarse en una billetera y verificarse directamente.

• El ciclo de vida de una credencial verificable: cómo se emite, se presenta y se revoca una credencial digital.

• Los tres registros públicos de Propia: cómo se comprueba la autoridad del emisor, el control de sus claves y el estado de una credencial.

• Por qué construir una infraestructura pública de confianza en abierto: el razonamiento detrás de Propia y su modelo de infraestructura abierta.

Lotería de Río Negro and Lotería La Neuquina register their results digitally so that anyone can confirm that the published document is exactly the one issued after the draw, and Lotería de San Juan is the next to join. Río Negro also extended the system to certifying high-value prizes.

At Sovra we implement Sovra Trace, the certification layer that makes it possible to register these documents and to turn prize certificates into verifiable digital credentials: documents signed by an institution that can be checked without having to query the issuer again.

A document issued every night

Every night the provincial lotteries run their draws and publish an extracto, the official list of winning numbers. In Argentina, where the quiniela is played daily, that document is the reference for checking results, paying prizes and resolving claims.

Río Negro was the first lottery in South America to certify its results this way and has been running the system since 2024. La Neuquina also has a public verifier, so checking a draw requires no access request to anyone. Lotería de San Juan will adopt the same system, launching shortly.

The idea is simple. If someone wants to check a result tomorrow, in a year or in ten years, they can do it on their own.

How it is built

The ‘extracto’ is a file. Before publishing it, the system computes its digital fingerprint, known technically as a hash: a short string derived from the entire contents of the file. Over the same document it always gives the same result, and if someone changes a number, a word or a comma, it changes.

The lottery registers that fingerprint on SovraChain, the public network this layer runs on, together with the moment of registration. The full extracto stays published by the lottery itself; what remains on the network is the fingerprint and the date it was registered.

Verifying is direct: download the published extracto, recompute its fingerprint, and compare it with the registered one.

Registering on a public network adds a property an internal database does not give: the record does not depend on the infrastructure the institution administers. If over the years the system changes, the technology provider changes or the organisation is restructured, the external record still exists. It is the same problem facing any document that has to stay verifiable for years.

What it lets you confirm

Certification has a specific scope: it makes it possible to confirm that the published result matches the one that was registered and that the record existed at a given moment.

The security of the draw still depends on the machine used, the technical controls, the protocol and the officials responsible. This layer adds a confirmation about what happens afterwards: that the document which reached the public is the same one that was registered.

If a lottery needs to correct a result, it registers the new version with its own fingerprint and its own moment of registration. The previous entry remains, and the full history stays available.

From a draw to a prize certificate

Río Negro extended the same mechanism to high-value prizes, in games such as Quini 6, Loto 5, Telebingo Patagónico and Pozo de la Quiniela. The person who wins receives a certificate and can present it to a bank, a notary or a property registry, which check it on their own without contacting the lottery.

The document then works as a verifiable credential, under the same model as a university degree, a professional licence or a digital driving licence. That is where the same problem appears as with any digital credential: whoever receives the document needs to be able to confirm who issued it, whether they were authorised to do so, whether it belongs to the person presenting it, and whether it is still valid.

Answering those questions takes pieces beyond the document itself: a standard for issuing and presenting it, a way to carry and use it, and registries that make it possible to check the issuer’s authority, the control of their keys and the status of the credential.

A concrete case for a broader infrastructure

A lottery has an interesting characteristic for this kind of infrastructure: it produces official documents very frequently, each one tied to a specific moment and to a clearly identified institution. That makes it possible to test in production something that can later be applied to many other public documents.

In the case of the draws, the question is how to demonstrate that a result published today is still the same result tomorrow. In the case of a prize certificate, the question shifts slightly: how can a bank, a notary or any other institution check a document without having to call the organisation that issued it.

The same needs appear in both cases: being able to confirm the integrity of the document, knowing who issued it, verifying its status, and having an infrastructure that keeps that information available to third parties.

That pattern can extend well beyond lotteries. A university degree, a professional licence, a driving licence or a certificate from a public programme all face the same problem when they need to be used far from the system that issued them.

The experience of these three lotteries shows something concrete: a trust infrastructure can start with a small and very specific problem, such as a document issued every night that a third party can verify on their own. From there, the same pieces can extend to many other documents and many other relationships between institutions.

Let’s continue the conversation

If your institution is working on modular service architectures, let’s talk. Get in touch with our team.

To get a better grip on these concepts, visit sovra.io/knowledge, where we explain them in plain language.

And if you want to keep following these conversations, subscribe to The Identity Brief. We publish a new edition every week.

Worth reading this week

• Lotería de Río Negro: the extension of certification to high-value prizes in Quini 6, Loto 5, Telebingo Patagónico and Pozo de la Quiniela.

• Lotería La Neuquina: its public verifier and the FAQ on how to check a draw.

• How a digital driving licence works: what changes when a credential can be carried in a wallet and verified directly.

• The lifecycle of a verifiable credential: how a digital credential is issued, presented and revoked.

• Propia’s three public registries: how issuer authority, key control and credential status are checked.

• Why build public trust infrastructure in the open: the reasoning behind Propia and its open infrastructure model.

Bogotá has started building its SuperApp, a single platform from which residents will reach the district’s procedures, services and benefits.

Sovra runs the identity layer: the citizen wallet, the issuance of verifiable digital credentials, digital documents signed by an institution that can be checked without calling whoever issued them (how a credential is issued, presented and revoked end to end), and the open protocol that holds them up.

A common platform for a diverse district

Bogotá has 62 district entities and more than 1,400 procedures. Integrating that diversity calls for an architecture that can take on new services without each one having to solve the same technical problems all over again.

That’s why the SuperApp is designed as a modular platform. Each service can run as a MiniApp, a module that plugs into the ecosystem through standardized APIs and SDKs and inherits shared capabilities for authentication, security, analytics and user experience.

That design lets the platform evolve step by step. The first version doesn’t need to hold every district procedure to start generating value: it can ship specific capabilities, put them into operation, and add new services as the ecosystem grows.

The architecture also includes a service orchestrator, responsible for coordinating flows between the platform’s modules, the digital wallet, and each entity’s systems. Integration becomes a shared capability instead of a series of one-off connections.

How it’s built

The SuperApp runs on open standards that let different institutions issue, share and verify digital credentials securely. Sovra integrates that infrastructure so identity can be used across services, without depending on a single platform or a one-off integration.

The project is also framed by district regulation on interoperability and digital authentication, which lets entities connect under shared rules and lets the solution grow with new services and use cases.

The person’s control over their data is a set of concrete system functions: voluntary presentation, explicit consent with traceability of use and access, revocation under each issuer’s rules, and event logging and audit. The platform also embeds Chatico, the district’s virtual assistant, meets WCAG 2.1 AA accessibility or above, and includes biometric validation with liveness detection plus in-person authentication for vulnerable populations, the same design goal behind the mobile driver’s licence’s offline, cached-verification pattern: digital identity can become public infrastructure that works for more people, regardless of the device they have or their connectivity.

Verifiable credentials for reaching opportunities

The first operational module will focus on economic inclusion. Through verifiable credentials, institutions will be able to issue trustworthy digital information that people keep in their wallet and present whenever they need to access a program, service or opportunity.

This model cuts down on repeated procedures, makes it easier to validate information, and gives people more control over their data.

Infrastructure built to grow

The solution is built on open self-sovereign identity and verifiable-credential standards, with APIs, privacy by design, and the capacity to add new issuers, verifiers and use cases. It also allows for, at a future stage, credential portability between Bogotá and Cali.

It’s the same kind of architectural bet that, each in its own way, Estonia, India and Denmark have made: how to get a person’s identity to work across institutions, not only inside one.

With Sovra, Bogotá’s SuperApp gets a trust infrastructure that connects institutions, services and citizens, making a digital experience possible that’s simpler, more interoperable, and centered on people.

Continue the conversation

If your institution is working on modular service architectures or verifiable credentials for social programs, let’s talk. Get in touch with our team.

To explore these concepts in simple language, visit sovra.io/knowledge.

And if you want to follow the conversation, subscribe to The Identity Brief. A new edition every week.

Worth reading this week

• Introducing Propia: why we build shared verification infrastructure instead of one-off integrations.

• sovra.io/case-studies: the other governments already running this identity stack in production.

• The Latin America Identity Index: where the region’s digital identity programs stand today.

• Bogotá’s SuperApp accelerates with CAF’s backing: the district’s own account of the program.

• Verifiable credentials, explained: the Centre for Digital Public Infrastructure’s technical primer on how these credentials work.

Bogotá empezó a construir su SuperApp, una plataforma única desde la que la ciudadanía va a acceder a los trámites, servicios y beneficios del Distrito.

Desde Sovra ejecutamos la capa de identidad: la billetera ciudadana, la emisión de credenciales digitales verificables, documentos digitales firmados por una institución que se pueden comprobar sin llamar a quien los emitió (cómo se emite, se presenta y se revoca una credencial de principio a fin), y el protocolo abierto que las sostiene.

Una plataforma común para un Distrito diverso

Bogotá cuenta con 62 entidades distritales y más de 1.400 trámites. Integrar esa diversidad requiere una arquitectura capaz de incorporar nuevos servicios sin que cada uno tenga que resolver otra vez los mismos problemas tecnológicos.

Por eso la SuperApp se plantea como una plataforma modular. Cada servicio puede funcionar como una MiniApp, un módulo que se integra al ecosistema mediante APIs y SDK estandarizados y que hereda capacidades comunes de autenticación, seguridad, analítica y experiencia de usuario.

Este enfoque permite que la plataforma evolucione de forma progresiva. La primera versión no necesita contener todos los trámites del Distrito para empezar a generar valor: puede incorporar capacidades concretas, ponerlas en operación y sumar nuevos servicios a medida que el ecosistema crece.

La arquitectura también contempla un orquestador de servicios, encargado de coordinar los flujos entre los módulos de la plataforma, la billetera digital y los sistemas de cada entidad. Así, la integración se vuelve una capacidad compartida en lugar de una serie de conexiones aisladas.

Cómo está construido

La SuperApp se apoya en estándares abiertos que permiten que distintas instituciones emitan, compartan y verifiquen credenciales digitales de forma segura. Desde Sovra, integramos esta infraestructura para que la identidad pueda utilizarse en diferentes servicios, sin depender de una única plataforma.

El proyecto también se enmarca en la normativa distrital sobre interoperabilidad y autenticación digital, permitiendo que las entidades se conecten bajo reglas comunes y que la solución crezca con nuevos servicios.

El control de la persona sobre sus datos se traduce en presentación voluntaria, consentimiento explícito, revocación y trazabilidad. La plataforma integra además Chatico, cumple WCAG 2.1 AA o superior, e incorpora validación biométrica con prueba de vida y autenticación presencial para población vulnerable.

Así, la identidad digital se convierte en una infraestructura pública útil para más personas, independientemente del dispositivo o sus condiciones de conectividad.

Credenciales verificables para acceder a oportunidades

El primer módulo operativo estará enfocado en la inclusión económica. A través de credenciales verificables, las instituciones podrán emitir información digital confiable que las personas podrán conservar en una wallet y presentar cuando necesiten acceder a un programa, servicio u oportunidad.

Este modelo permite reducir la repetición de trámites, facilitar la validación de información y dar a los ciudadanos mayor control sobre sus datos.

Una infraestructura preparada para crecer

La solución se basa en estándares abiertos de identidad autosoberana y credenciales verificables, con APIs, privacidad desde el diseño y capacidad de incorporar nuevos emisores, verificadores y casos de uso. También contempla la futura portabilidad de credenciales entre Bogotá y Cali.

Es el mismo tipo de apuesta arquitectónica que atravesaron, cada uno a su manera, Estonia, India y Dinamarca: cómo hacer que la identidad de una persona funcione entre instituciones, no solo dentro de una.

Con Sovra, la SuperApp de Bogotá incorpora una infraestructura de confianza que conecta instituciones, servicios y ciudadanos, y hace posible una experiencia digital más simple, interoperable y centrada en las personas.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios o en credenciales verificables para programas sociales, conversemos. Ponete en contacto con nuestro equipo.

Para entender mejor estos conceptos, visitá sovra.io/knowledge, donde los explicamos en lenguaje simple.

Y si querés seguir estas conversaciones, suscribite a The Identity Brief. Publicamos una nueva edición cada semana.

Vale la pena leer esta semana

• Presentamos Propia: por qué construimos infraestructura de verificación compartida en lugar de integraciones puntuales.

• sovra.io/case-studies: los otros gobiernos que ya corren este mismo stack de identidad en producción.

• El Índice de Identidad de Latinoamérica: dónde está parada hoy la identidad digital en la región.

• La transformación digital de Bogotá se acelera con respaldo de CAF: el relato oficial del Distrito sobre el programa.

• Verifiable credentials, explained: la explicación técnica del Centre for Digital Public Infrastructure sobre cómo funcionan estas credenciales.

A week ago, we published Propia, a public trust layer for verifiable digital credentials, and explained why we are building it as open infrastructure.

In short: institutions verify the same facts over and over. Verifiable credentials make those verifications reusable, but for that to work, a verifier needs to know who is authorized to issue a credential, which keys control that identifier, and whether the credential is still valid.

Propia provides that trust layer through public, independently verifiable registries.

To see how it works, let’s follow one situation from beginning to end: someone walks up to a rental car counter and presents a digital driver’s license on their phone.

What can the counter verify?

The verifier checks five things:

• Integrity. The signed credential has not been modified.

• Issuer authority. The signing key belongs to an issuer authorized to issue that type of credential under the relevant trust framework.

• Holder binding. The person presenting the credential satisfies the binding method defined by the credential.

• Temporal validity. The credential is within its defined validity period.

• Status. The credential has not been suspended or revoked.

A digital signature proves that a particular key signed the credential. But that alone does not establish whether the key was authorized to issue a driver’s license, whether it is still the key recognized for that institution, or whether the license remains valid.

Those are the questions answered by Propia’s three public registries.

1. Issuer Registry: who can issue what

The first registry answers a basic question: who is authorized to issue a particular credential, and within what scope?

A transport authority may be authorized to issue driver’s licenses in one jurisdiction without being authorized to issue university degrees or licenses elsewhere.

That authorization comes from the relevant trust framework: the legal, policy, governance, and operational rules under which institutions issue and accept credentials.

Propia records that authorization so it can be independently verified.

The governance authority controls who can update issuer authorizations. This matters because permissionless self-registration would only prove that an entity controls a cryptographic key. It would not establish the institutional authority required to issue a regulated credential.

Reading the registry remains open, and changes to authorization state are auditable.

2. Identifier Registry: who controls the keys

An institution may change its keys without invalidating credentials it has already issued.

Devices are replaced, responsible staff change, and identifiers may need to be recovered. Credentials, meanwhile, can remain valid for years.

The Identifier Registry records the information needed to manage that continuity: current verification methods, who controls an identifier, and the rules under which that control can change.

Key rotation and recovery therefore become explicit, verifiable state transitions.

This also affects credential continuity. A credential bound to a stable identifier may remain usable after an authorized key update. A credential bound directly to a device key may require re-issuance.

Propia does not require a proprietary identifier format. Credential profiles may use W3C DIDs or another compatible identifier scheme, provided that control state and authorized changes can be independently resolved and verified.

3. Status Registry: what remains valid

A driver’s license can be valid today and suspended or revoked tomorrow.

The Status Registry allows issuers to publish that change in a compact form. Verifiers can check current status without making a private callback to the issuer every time a credential is presented.

This also supports scenarios with limited connectivity. Status can be cached, provided there is an explicit policy defining how long that information remains trustworthy.

Just as importantly, the registry records the credential’s status, not where or when the credential was presented.

The same logic, across institutions

The rental car example is only one case.

A government may issue a foundational identity credential. A university can verify it and issue a diploma. A professional body can verify both before issuing a license. An employer, bank, or public agency can then verify the credentials it needs.

The institutions do not need access to each other’s databases. Each verifies a standardized presentation, applies its own legal and administrative rules, and may issue another credential.

This is where composability comes in: the signed output of one institutional process can become a verifiable input to another.

Instead of starting from zero, an institution can build on a verification that another institution has already performed.

This reduces repeated verification, document handling, fraud review, and bilateral integrations. It also allows new wallets, verification services, and applications to participate without relying on a central operator.

What stays outside Propia

For this infrastructure to remain public, it also matters what is not made public.

Credential payloads, claims, and personal data remain under the holder’s control. Propia’s public registries do not contain names, addresses, dates of birth, photographs, document numbers, or biometrics.

They also do not record presentation requests, responses, or usage histories.

What becomes public is the information different verifiers need to establish trust: issuer authorizations, identifier control, and credential status.

This allows independent participants to verify against the same accepted trust state without routing every presentation through an issuer’s server or a central operator.

Why public infrastructure?

These registries could simply be implemented as a database operated by a single provider. That would create a common interface, but the provider would control availability, update ordering, and retained history.

Propia uses blockchain to avoid that dependency on a privileged operator.

Ethereum serves as the settlement layer, recording accepted state commitments and allowing the resulting state and its governing rules to be independently verified.

For population-scale operation, Propia proposes an Ethereum Layer 2 validium, where many operations can be executed and batched before settlement on Ethereum. Validity proofs allow Ethereum to verify that those state transitions follow the protocol rules.

The data required to reconstruct the Layer 2 state remains outside Ethereum. This reduces the cost of publishing large amounts of data, while making data availability an explicit responsibility of each deployment.

Blockchain does not create institutional authority. A government remains responsible for deciding who may issue a national identity credential, and a university remains responsible for its degrees.

Propia represents that trust state. It does not create it.

The objective

The objective is not to put identity on a blockchain.

It is to separate two things that are often coupled today: the private data contained in a credential and the public state required to verify that credential.

Open credential standards make credentials portable across systems. Propia adds the public trust layer needed to independently verify issuer authority, identifier control, and credential status.

A credential issued after one institution completes a verification process can then become a reusable input to another institution’s process.

The goal is simple: institutions should be able to build on prior verification instead of starting from zero.

Further reading

• The Propia whitepaper: the complete protocol specification.

• The Full Lifecycle of a Verifiable Credential: from issuance to revocation.

• How the Mobile Driver’s License Works: what happens behind a digital driver’s license.

• W3C Verifiable Credentials Data Model 2.0: the credential standard underlying the model.

Keep the conversation going

If your institution is working on credential issuance, verification, or revocation, reply to this email and tell us where the difficult parts are.

Subscribe to The Identity Brief, published every week.

Hace una semana publicamos Propia, una capa pública de confianza para credenciales digitales verificables, y contamos por qué la estamos construyendo como infraestructura abierta.

En resumen: hoy las instituciones vuelven a comprobar las mismas cosas una y otra vez. Las credenciales verificables permiten que una institución pueda confiar en una credencial que otra ya emitió. Pero para hacerlo necesita poder responder tres preguntas: ¿quién la emitió?, ¿estaba autorizado para hacerlo? y ¿sigue siendo válida?

Propia hace que esas respuestas estén disponibles públicamente y puedan ser verificadas por cualquiera.

Para entender cómo funciona, sigamos una situación concreta: alguien llega al mostrador de una empresa de alquiler de autos y muestra su licencia de conducir digital en el teléfono.

Qué puede comprobar el mostrador

El verificador, en este caso la persona detrás del mostrador, necesita comprobar cinco cosas:

• Integridad. La credencial no fue modificada después de ser firmada.

• Autoridad del emisor. La institución que la emitió estaba autorizada para emitir ese tipo de credencial.

• Vínculo con el titular. La persona que la presenta es quien recibió la credencial.

• Validez temporal. La credencial todavía está dentro de su período de validez.

• Estado. La credencial no fue suspendida ni revocada.

La firma digital permite comprobar que la credencial fue firmada por una determinada clave y que no fue modificada. Pero eso no alcanza para saber si esa clave pertenece a un emisor autorizado, si sigue siendo la clave válida de esa institución o si la credencial continúa vigente.

Esas son las preguntas que responden los registros públicos de Propia.

1. Registro de emisores: quién puede emitir qué

El primer registro responde una pregunta simple: ¿quién está autorizado a emitir una determinada credencial?

Una autoridad de transporte puede estar autorizada a emitir licencias de conducir en una jurisdicción, pero no títulos universitarios ni licencias en otra.

Esa autorización depende del marco de confianza correspondiente, es decir, las reglas que determinan qué instituciones pueden emitir y bajo qué condiciones.

Propia registra esas autorizaciones para que cualquiera pueda verificarlas.

La autoridad de gobernanza es quien puede modificar este registro. Esto es importante: tener una clave criptográfica no significa tener autoridad para emitir una credencial. Un registro donde cualquiera pudiera anotarse como emisor solo demostraría que controla una clave, no que está legalmente autorizado a emitir.

Leer el registro es abierto, y todos sus cambios quedan registrados y pueden auditarse.

2. Registro de identificadores: quién controla las claves

Las instituciones cambian de claves. Pueden reemplazar un dispositivo, cambiar al responsable de firmar o recuperar el control de un identificador. Eso no debería invalidar las credenciales que ya emitieron.

El registro de identificadores permite saber qué claves controla cada institución y bajo qué reglas pueden cambiar.

Así, una credencial vinculada a un identificador estable puede seguir siendo válida aunque cambie la clave que lo controla. Si está vinculada directamente a una clave de dispositivo, puede ser necesario emitirla de nuevo.

Propia puede trabajar con DIDs u otros identificadores compatibles, siempre que su control pueda verificarse de forma independiente.

3. Registro de estado: qué sigue vigente

Una licencia puede ser válida hoy y ser suspendida o revocada mañana.

El registro de estado permite que el emisor publique ese cambio. El verificador puede consultar si la credencial sigue vigente sin tener que preguntarle al emisor cada vez que se presenta.

El estado también puede mantenerse en caché para funcionar con conectividad limitada, siempre que exista una regla clara sobre cuánto tiempo sigue siendo confiable.

Y hay una diferencia importante: el registro muestra si una credencial está vigente, pero no registra dónde ni cuándo fue presentada.

La misma lógica, en otros mostradores

El alquiler de autos es solo un ejemplo. Un gobierno puede emitir una credencial de identidad, una universidad usarla para emitir un título y un colegio profesional verificar ambos antes de emitir una matrícula. Después, un empleador, un banco o un organismo público puede verificar las credenciales que necesita.

Cada institución aplica sus propias reglas, pero puede construir sobre una verificación que otra ya hizo, sin acceder a sus bases de datos ni pasar por un operador central.

Ahí aparece la composabilidad: las credenciales se convierten en piezas reutilizables de procesos institucionales, reduciendo verificaciones, manejo de documentos, revisión de fraude e integraciones.

Qué datos no se publican

Para que esta infraestructura sea pública, también importa qué información no se publica.

Las credenciales, sus claims y los datos personales permanecen bajo el control del holder. Los registros de Propia no contienen nombres, direcciones, fechas de nacimiento, fotografías, números de documento ni datos biométricos.

Tampoco registran qué credencial se presentó, dónde ni cuándo.

Lo que sí queda en el registro público es lo que cualquier verificador necesita para comprobar una credencial: quién puede emitirla, qué claves controla ese identificador y si sigue vigente.

Así, distintos verificadores pueden consultar el mismo estado público sin que cada presentación tenga que pasar por el emisor o por un operador central.

Por qué hacerlo como infraestructura pública

Si estos registros fueran una base de datos administrada por una empresa, esa empresa controlaría su disponibilidad, las actualizaciones y el estado que conserva.

Propia usa blockchain para evitar esa dependencia de un operador central.

Ethereum funciona como capa de settlement: registra los compromisos del estado aceptado y permite verificar que las actualizaciones siguieron las reglas del protocolo.

Para operar a escala, Propia propone una Layer 2 validium, que agrupa muchas actualizaciones antes de asentarlas en Ethereum y utiliza pruebas de validez para verificar que fueron ejecutadas correctamente. Los datos necesarios para reconstruir ese estado permanecen fuera de Ethereum, lo que reduce costos pero hace que su disponibilidad sea una responsabilidad de cada despliegue.

Blockchain no crea la autoridad institucional. Un gobierno sigue decidiendo quién puede emitir una credencial, y una universidad sigue siendo responsable de sus títulos. Propia representa ese estado de confianza; no lo crea.

El objetivo

El objetivo no es poner la identidad en una blockchain, sino separar los datos privados de una credencial del estado público necesario para verificarla.

Los estándares hacen que las credenciales puedan viajar entre sistemas. Propia agrega los registros públicos que permiten verificar quién puede emitirlas, qué claves controla cada identificador y si siguen vigentes.

Así, una verificación puede convertirse en un insumo para otra institución, en lugar de volver a empezar de cero.

Sigamos la conversación

Si tu institución está trabajando en emisión, verificación o revocación de credenciales digitales, respondé este correo y contanos dónde se pone difícil.

Suscribite a The Identity Brief, que se publica semanalmente.

Para seguir leyendo

• El whitepaper de Propia: la especificación completa del protocolo.

• The full lifecycle of a verifiable credential: cómo funciona una credencial desde su emisión hasta su revocación.

• How the mobile driver’s license works: qué hay detrás de una licencia de conducir digital.

• W3C Verifiable Credentials Data Model 2.0: el estándar de credenciales sobre el que se apoya el modelo.

Propia es una capa pública de confianza para credenciales digitales verificables, desarrollada en colaboración entre Sovra, LambdaClass y Aligned.

El whitepaper se encuentra publicado en inglés en propia.id/whitepaper. Versión en español disponible acá:

Propia Whitepaper (Español)

540KB ∙ PDF file

Download

Descargá el whitepaper de Propia y conocé su arquitectura y propuesta para la verificación abierta de credenciales digitales.

Download

El whitepaper describe cómo funciona Propia. Este artículo explica por qué creemos que hace falta.

Por qué estamos publicando Propia

A medida que los gobiernos digitalizan identidad, licencias, títulos, registros y otros documentos oficiales, aparece un problema que no se resuelve solamente con mejores credenciales: cada institución necesita una forma confiable de saber quién puede emitirlas, bajo qué autoridad y si siguen siendo válidas.

Hoy, esa confianza suele resolverse mediante consultas directas, integraciones entre sistemas o acuerdos entre instituciones. Es un modelo que puede funcionar en pequeña escala, pero que se vuelve cada vez más difícil de sostener cuando participan cientos de organismos, distintos proveedores y múltiples jurisdicciones.

Propia parte de una tesis sencilla: las instituciones no necesitan compartir sus bases de datos ni adoptar las mismas reglas para poder confiar unas en otras. Necesitan una infraestructura común que permita verificar esa confianza de forma independiente.

A partir de esa idea, Propia propone una arquitectura abierta para que gobiernos e instituciones puedan mantener su propia autoridad y sus propios sistemas, mientras comparten una forma común de verificar emisores, credenciales y estado.

El problema de fondo

Las instituciones verifican los mismos hechos una y otra vez. Una persona que ya fue identificada por el Estado puede tener que presentar información similar ante una universidad, un banco, un empleador o cualquier otro organismo, y cada verificación puede requerir nuevas integraciones, consultas al emisor y copias de datos.

Las credenciales verificables permiten reutilizar esa verificación. Una institución autorizada puede comprobar un hecho y emitir una credencial firmada que luego puede ser presentada ante otros verificadores, quienes pueden comprobar su autenticidad, el emisor y su estado actual sin volver a consultar al emisor en cada ocasión.

Pero para que esto funcione a escala queda una pregunta fundamental: ¿cómo sabe un verificador que una institución está autorizada para emitir una determinada credencial y que esa autorización sigue vigente?

Una infraestructura común, sin centralizar la autoridad

Los estándares abiertos ya definen cómo emitir, firmar y presentar credenciales. Lo que no resuelven por sí solos es cómo verificar quién está autorizado a emitirlas, bajo qué reglas, qué claves controla y cuál es su estado actual.

Propia proporciona esa infraestructura común. Las credenciales y los datos personales permanecen entre emisores, titulares y verificadores, mientras el estado público permite comprobar de forma independiente las autorizaciones, las claves y el estado de las credenciales.

Esto reduce la dependencia de consultas directas al emisor, evita integraciones duplicadas y permite que una institución pueda utilizar una credencial emitida por otra sin acceder a sus sistemas internos.

Interoperabilidad sin perder soberanía

Una jurisdicción no necesita adoptar las reglas de otra para que sus credenciales puedan verificarse fuera de sus fronteras. Un gobierno puede emitir una credencial de identidad, una universidad utilizarla para emitir un título y un organismo regulador utilizar ambas para emitir una habilitación, mientras cada institución mantiene sus propios criterios y responsabilidades.

La infraestructura común permite que esas credenciales puedan componerse en procesos de otras instituciones sin crear una nueva integración para cada relación.

Diseñada como infraestructura abierta

Una infraestructura que puede permanecer en uso durante décadas no debería depender de un proveedor, una aplicación o una administración.

Por eso Propia plantea especificaciones e implementación abiertas, verificación independiente, derecho de salida y gobernanza transparente. La blockchain se utiliza para hacer verificable el estado común de los registros, no para almacenar credenciales ni datos personales.

El código se publica próximamente: cualquiera podría auditarlo, ejecutarlo y comprobar por sí mismo que la implementación cumple con lo especificado.

Propia se publica como una propuesta abierta, no como un producto cerrado. Queremos discutirla, mejorarla y construir sobre ella junto a los gobiernos, organismos públicos, universidades, reguladores y proveedores que van a emitir y verificar las credenciales del futuro.

Ponete en contacto!

Para seguir leyendo

• El ciclo de vida completo de una credencial verificable — emisión, presentación y revocación, de punta a punta.

• Cómo una credencial verificable sobrevive a su emisor — el problema de continuidad que atienden los registros.

• Cómo funciona la licencia de conducir móvil — el perfil ISO 18013-5 en la práctica.

• Muchos de estos conceptos explicados en lenguaje simple: sovra.io/knowledge.

Propia is a public trust layer for verifiable digital credentials, developed through a collaboration between Sovra, Lambda and Aligned.

The whitepaper is published at propia.id/whitepaper.

Why we are publishing Propia

The whitepaper describes how Propia works. This article explains why we believe it is needed.

As governments digitalize identity, licences, diplomas, records and other official documents, a problem appears that better credentials alone do not solve: every institution needs a reliable way to know who is allowed to issue them, under whose authority, and whether they are still valid.

Today, that trust is usually established through direct queries, system-to-system integrations or bilateral agreements between institutions. It is a model that can work at a small scale, and one that becomes progressively harder to sustain once hundreds of agencies, several vendors and multiple jurisdictions are involved.

Propia starts from a simple thesis: institutions do not need to share their databases or adopt the same rules in order to trust one another. What they need is common infrastructure that lets them verify that trust independently.

Building on that idea, the whitepaper proposes an open architecture in which governments and institutions keep their own authority and their own systems, while sharing a common way to verify issuers, credentials and status.

That is the problem this piece sets out to explore.

The underlying problem

Institutions verify the same facts over and over. Someone already identified by the state may have to submit similar information to a university, a bank, an employer or any other agency, and each verification can require new integrations, callbacks to the issuer and additional copies of personal data.

Verifiable credentials make that verification reusable. An authorized institution can establish a fact and issue a signed credential, which can then be presented to other verifiers, who are able to check its authenticity, its issuer and its current status without going back to the issuer on every occasion.

But for this to work at scale, one fundamental question remains: how does a verifier know that an institution is authorized to issue a given credential, and that the authorization still holds?

Common infrastructure, without centralizing authority

Open standards already define how credentials are issued, signed and presented. What they do not settle on their own is how to verify who is authorized to issue them, under which rules, which keys they control, and what their current status is.

Propia provides that common infrastructure. Credentials and personal data remain between issuers, holders and verifiers, while the public state allows authorizations, keys and credential status to be checked independently.

This reduces the reliance on direct callbacks to the issuer, avoids duplicated integrations, and allows one institution to rely on a credential issued by another without any access to its internal systems.

Figure 2 of the whitepaper — private credential exchange and public trust settlement remain separate.

Interoperability without giving up sovereignty

One jurisdiction does not need to adopt the rules of another for its credentials to be verifiable beyond its borders. A government can issue an identity credential, a university can rely on it to issue a diploma, and a regulator can rely on both to issue a licence, while each institution keeps its own criteria and its own responsibilities.

Common infrastructure allows those credentials to compose into the processes of other institutions without building a new integration for every relationship.

Designed as open infrastructure

Infrastructure that may remain in use for decades should not depend on a single vendor, a single application or a single administration.

That is why Propia commits to open specifications and open implementation, independent verification, exit rights and transparent governance. Blockchain is used to make the common state of the registries verifiable, not to store credentials or personal data.

Propia is published as an open proposal, rather than a closed product. We want to discuss it, improve it and build on it together with the governments, public agencies, universities, regulators and vendors that will issue and verify the credentials of the future.

Read the whitepaper →

Worth reading

• The Full Lifecycle of a Verifiable Credential — issuance, presentation and revocation, end to end.

• How a Verifiable Credential Outlives Its Issuer — the continuity problem the registries address.

• How the Mobile Driver’s Licence Works — the ISO 18013-5 profile in practice.

• Concepts explained in plain language: sovra.io/knowledge.

Subscribe to The Identity Brief, published every Thursday.

When a government team starts designing a digital identity program, the reference cases arrive quickly and all at once: Estonia is held up as the model, India as the proof that it works at scale, the Nordics as the example of a system people actually use every day. All three are genuinely successful, and the useful observation is that they disagree with each other on nearly every design decision that matters.

That disagreement is the interesting part. Each country answered a different question first, and the answer to that first question determined everything downstream — who issues the identity, who operates the infrastructure, who pays for it, and what happens to a citizen who does not want to participate. Understanding which question each country answered first is far more useful than importing any one of them wholesale.

Estonia: the state issues, and the state runs the rails

Estonia made identity a state obligation and built the exchange layer to match. The electronic ID card has been mandatory for citizens and residents since 2002, and roughly 99% of the population holds one. Around 90% of Estonians use e-services regularly, about 98% of tax declarations are filed online, and effectively the whole catalogue of public services is available around the clock.

The part that gets copied less often, and matters more, is X-Road — the data exchange layer that lets agencies query each other’s registries directly, with every request logged and attributable. It is what makes the once-only principle enforceable rather than aspirational: because the tax office can ask the population registry directly, nobody has to carry a certificate between counters. X-Road is now deployed in more than twenty countries, which makes it the single most portable component of the Estonian model.

The bet: that a small, high-trust country can mandate a state credential and get near-universal adoption without a fight.

What it cost: mandatory participation is politically expensive, and it is the piece that transfers worst. It also assumes a population registry clean enough to build on, which is a much larger precondition than it sounds.

The transferable lesson is architectural rather than political, and it is one we explored with Gustavo Giorgetti in our conversation on federalism as an interoperability advantage: what makes X-Road work is not that Estonia is centralized, but that the exchange layer carries institutional trust. Argentina’s provinces are building comparable ecosystems without a unitary state to impose them.

India: solve for scale first, layer the rest on top

India inverted the order. Rather than start with a credential and a legal framework, it started with the largest possible base of unique, verifiable identity and treated everything else as a layer to be added afterward. Aadhaar now covers more than 1.44 billion residents, and authentication runs at a volume with no real precedent: over 27 billion authentication transactions in a single fiscal year.

That base became the floor for India Stack: payments (UPI, which processed 21.7 billion transactions in January 2026 alone), paperless document exchange (DigiLocker, eSign), and consented data sharing. The design principle is that identity is infrastructure rather than a product — a public rail that private services build on, which is precisely why the payments layer scaled the way it did.

The bet: that reaching everyone first, with the thinnest possible credential, unlocks more value than a richer credential that reaches fewer people.

What it cost: the privacy and exclusion debates that follow a centralized biometric database are real and ongoing, and much of the later architectural work has been about adding consent, minimization, and purpose limitation to a system that did not start with them. Sequencing scale ahead of governance means retrofitting governance.

The transferable lesson is the layering discipline: identity, payments, and data exchange as separate public rails that anyone can build on. Manuel Aguilera of the Centre for Digital Public Infrastructure made exactly this argument for the region in why Latin America should stop building alone — Brazil’s PIX is the clearest regional proof that the layered model travels.

Denmark: the banks were already there

Denmark answered a different question: where do citizens already prove who they are, every week, without being asked twice? The answer was online banking, so the Danish system was built as a public-private partnership with the banks. MitID has around 5.5 million registered users, roughly 87% of Danish adults use it at least weekly, and the app averaged 3.3 million monthly active users in June 2026. It works for taxes, health records, and public services, and equally for private banking and insurance, which is why it is used weekly rather than annually.

Denmark is now taking the next step. In June 2026 it launched AltID, one of the first official digital identity wallets in the EU, holding an ID card and an age certificate locally on the device rather than in a central store. Adoption is early — roughly 230,000 downloads by late July, about 4% of the MitID base — and the direction is what matters, because it moves proof of age and identity to the phone with the citizen holding the data. That shift is the subject of our June edition on privacy-preserving age verification.

The bet: that adoption follows daily utility, so the fastest path to a national identity is the one that runs through where people already are.

What it cost: shared governance with private institutions, and a dependency on a banking sector concentrated and cooperative enough to act as one counterpart. In a market with hundreds of fragmented institutions, the same partnership is far harder to assemble.

What travels to Latin America, and what does not

Travels well: the exchange layer. Every one of these systems works because agencies can query each other rather than making the citizen carry documents between them. This is the single highest-value component, it is politically far cheaper than a mandatory national credential, and it is the piece a province or a municipality can start on without national legislation.

Travels well: layering identity as public infrastructure. Treating identity, payments, and document exchange as separate rails that private services can build on is what turned India’s investment into an ecosystem. Brazil demonstrated the same effect with PIX.

Travels well: designing for daily use. Denmark’s lesson is the cheapest to apply and the most often ignored. A credential used once a year for taxes never becomes infrastructure, so the question worth asking early is which weekly interaction the system can attach itself to.

Travels badly: the mandate. Estonia’s near-universal adoption rests on a legal obligation and a level of institutional trust that cannot be legislated into existence elsewhere. Programs that copy the mandate without the trust get the compliance costs and none of the adoption.

Travels badly: centralizing biometrics first and governing later. The retrofit is expensive and the political cost compounds. The region has the advantage of arriving after this lesson was learned, and the current generation of standards makes it avoidable: a credential the citizen holds, presented selectively, with the issuer verifiable and the personal data never pooled.

The genuinely new option is that none of these three models has to be copied. All three were built before verifiable credentials matured into ratified standards, and each one solved with centralization or with legal mandate what can now be solved cryptographically. A jurisdiction starting today can get Estonia’s once-only principle without Estonia’s mandate, and India’s reach without India’s central database, because the credential travels with the citizen and any office can verify it independently. That compounding is the subject of how the layers of a trust stack build on each other.

Worth reading this week

The EU digital identity wallet deadline is the story to watch for the rest of the year. Every member state must offer at least one certified wallet by 24 December 2026, and current readiness assessments put fewer than a third of them on track. Denmark’s AltID is one of the first live examples, which makes its adoption curve the most informative public data point available on how citizens take up a wallet when it is genuinely offered.

The OECD Digital Government Outlook 2026 measures 36 members on the same progression these three countries illustrate: the average Digital Government Index rose from 0.61 to 0.70 between 2023 and 2025, with 74% of core digital public infrastructure components now in place. Its central recommendation — that governments require or strongly incentivize the use of shared building blocks instead of siloed agency projects — is the Estonian architectural lesson stated as policy.

The UN E-Government Knowledgebase remains the best free way to place any country against two decades of comparable survey data before deciding which model to borrow from.

Continue the conversation

More on verifiable credentials, document management, and digital public infrastructure — including case studies and reference architectures — is at sovra.io/knowledge.

Subscribe to The Identity Brief, published every week.

Cuando un gobierno empieza a diseñar un programa de identidad digital, los mismos casos aparecen una y otra vez: Estonia como modelo, India como prueba de escala, los países nórdicos como ejemplo de un sistema que la gente usa todos los días.

Los tres funcionan. Y, sin embargo, toman decisiones muy distintas sobre casi todo lo que importa: quién emite la identidad, quién opera la infraestructura, quién la financia y qué ocurre con quien decide no usarla.

Ahí está lo interesante. No hay un modelo único que copiar. Cada país decidió qué problema resolver primero, y esa decisión terminó definiendo el resto del sistema.

Por eso, entender qué priorizó cada uno puede ser mucho más útil que intentar importar cualquiera de estos modelos entero.

Estonia: el Estado emite y el Estado opera las vías

Estonia convirtió la identidad en una obligación estatal y construyó la capa de intercambio a la medida. La cédula electrónica es obligatoria para ciudadanos y residentes desde 2002, y la tiene cerca del 99% de la población. Alrededor del 90% de los estonios usa servicios digitales de manera habitual, el 98% de las declaraciones de impuestos se presenta online y prácticamente todo el catálogo de servicios públicos está disponible las 24 horas.

Lo que menos se copia, y más importa, es X-Road: la capa de intercambio que permite a los organismos consultar directamente los registros de los demás, con cada consulta registrada y atribuible. Gracias a eso el principio de una sola vez se vuelve exigible en lugar de quedar en declaración: si la agencia tributaria le consulta al registro de población, nadie tiene que llevar un certificado de un mostrador a otro. Hoy X-Road está desplegado en más de veinte países, y es el componente más fácil de trasladar de todo el modelo estonio.

La apuesta: un país chico y con alta confianza institucional puede imponer una credencial estatal y aun así conseguir adopción casi universal.

Lo que costó: obligar sale caro en términos políticos, y es justamente la pieza que peor se exporta. Además da por sentado un registro de población lo bastante prolijo como para construir encima, que es un punto de partida mucho más exigente de lo que parece.

La lección que sí se traslada es arquitectónica antes que política, y la conversamos con Gustavo Giorgetti en nuestro episodio sobre el federalismo como ventaja de interoperabilidad: si X-Road funciona no es porque Estonia sea centralizada, sino porque la capa de intercambio transporta institucionalidad. Las provincias argentinas están armando ecosistemas equivalentes sin un Estado unitario que los imponga.

India: primero la escala, después las capas

India invirtió el orden. En vez de arrancar por una credencial y un marco legal, arrancó por la base más grande posible de identidad única y verificable, y dejó todo lo demás como capas para sumar después. Aadhaar ya cubre a más de 1.440 millones de residentes, y la autenticación corre a un volumen sin antecedentes: más de 27.000 millones de operaciones en un solo ejercicio fiscal.

Esa base terminó siendo el piso de India Stack: pagos (UPI, que movió 21.700 millones de operaciones solo en enero de 2026), circulación de documentos sin papel (DigiLocker, eSign) y datos compartidos con consentimiento. El criterio de diseño es tratar la identidad como infraestructura y no como producto: una vía pública sobre la que construyen servicios privados, y por eso la capa de pagos escaló como escaló.

La apuesta: llegar a todos con la credencial más liviana posible rinde más que una credencial más completa que alcanza a menos gente.

Lo que costó: los debates de privacidad y exclusión que arrastra una base biométrica centralizada siguen abiertos, y buena parte del trabajo posterior consistió en agregarle consentimiento, minimización y límites de propósito a un sistema que no nació con eso. Cuando la escala va antes que la gobernanza, la gobernanza se termina instalando a los golpes.

La lección que sí se traslada es la disciplina de capas: identidad, pagos e intercambio de datos como vías separadas sobre las que puede construir cualquiera. Manuel Aguilera, del Centre for Digital Public Infrastructure, planteó exactamente eso para la región en por qué América Latina tiene todo para ganar si deja de construir sola, y PIX en Brasil es la prueba más clara de que el modelo por capas funciona acá.

Dinamarca: los bancos ya estaban ahí

Dinamarca se hizo otra pregunta: ¿dónde prueba la gente quién es, todas las semanas, sin que haya que insistirle? La respuesta fue el home banking, así que el sistema danés nació como alianza público-privada con los bancos. MitID tiene unos 5,5 millones de usuarios registrados, cerca del 87% de los adultos daneses lo usa al menos una vez por semana y la app promedió 3,3 millones de usuarios activos por mes en junio de 2026. Sirve para impuestos, historia clínica y servicios públicos, y también para banca y seguros privados: por eso se usa todas las semanas y no una vez al año.

Ahora Dinamarca está dando el paso siguiente. En junio de 2026 lanzó AltID, una de las primeras billeteras oficiales de identidad digital de la Unión Europea, que guarda la cédula y un certificado de edad en el propio dispositivo y no en un repositorio central. La adopción recién arranca —unas 230.000 descargas a fines de julio, cerca del 4% de la base de MitID— y lo que importa es hacia dónde va, porque mueve la prueba de edad y de identidad al teléfono, con el dato en manos del ciudadano. De ese cambio hablamos en nuestra edición de junio sobre verificación de edad sin exponer la identidad.

La apuesta: la adopción viene detrás de la utilidad cotidiana, así que el camino más corto a una identidad nacional pasa por donde la gente ya está.

Lo que costó: compartir la gobernanza con instituciones privadas, y depender de un sector bancario lo bastante concentrado y cooperativo como para sentarse en la mesa como una sola contraparte. Donde hay cientos de instituciones dispersas, esa alianza es mucho más difícil de armar.

Qué sirve en América Latina y qué no

✅ Sirve: la capa de intercambio. Los tres sistemas funcionan porque los organismos se consultan entre sí en lugar de mandar al ciudadano a hacer de cadete. Es el componente de mayor valor, cuesta mucho menos en términos políticos que una credencial nacional obligatoria, y una provincia o un municipio puede empezar sin esperar una ley nacional.

✅ Sirve: pensar la identidad como infraestructura por capas. Tratar identidad, pagos e intercambio documental como vías separadas sobre las que construyen servicios privados fue lo que convirtió la inversión india en un ecosistema. Brasil consiguió el mismo efecto con PIX.

✅ Sirve: diseñar para el uso cotidiano. La lección danesa es la más barata de aplicar y la que más se pasa por alto. Una credencial que se usa una vez al año para impuestos nunca llega a ser infraestructura, así que conviene preguntarse temprano a qué trámite semanal puede engancharse el sistema.

❌ No sirve: copiar la obligatoriedad. La adopción estonia se apoya en una obligación legal y en un nivel de confianza institucional que no se consigue por decreto. Copiar la obligación sin la confianza deja los costos de cumplimiento y ninguna de las ventajas.

❌ No sirve: centralizar biometría ahora y gobernar después. Arreglarlo más tarde sale caro y el costo político se acumula. La región tiene la ventaja de llegar cuando esa lección ya está aprendida, y la generación actual de estándares permite esquivarla: una credencial que porta el ciudadano, que se presenta de a partes, con el emisor verificable y sin amontonar datos personales en ningún lado.

Lo verdaderamente nuevo es que ninguno de estos tres modelos hace falta copiarlo. Los tres se construyeron antes de que las credenciales verificables maduraran como estándares ratificados, y cada uno resolvió con centralización o con obligación legal lo que hoy se resuelve con criptografía. Una jurisdicción que arranca hoy puede tener el “una sola vez” estonio sin la obligatoriedad estonia, y el alcance indio sin la base central india, porque la credencial viaja con el ciudadano y cualquier oficina la verifica por su cuenta. De ese efecto acumulativo hablamos en cómo se potencian entre sí las capas de un stack de confianza.

Vale la pena leer esta semana

El plazo de la billetera de identidad digital europea es la historia a seguir de acá a fin de año. Cada Estado miembro tiene que ofrecer al menos una billetera certificada antes del 24 de diciembre de 2026, y las evaluaciones actuales ubican a menos de un tercio en condiciones de cumplirlo. AltID, en Dinamarca, es uno de los primeros casos en vivo, así que su curva de adopción es hoy el mejor dato público disponible sobre cómo responde la gente cuando le ofrecen una billetera de verdad.

El Digital Government Outlook 2026 de la OCDE, primera edición del informe, mide a 36 países con la misma progresión por etapas que ilustran estos tres casos: el Digital Government Index promedio subió de 0,61 a 0,70 entre 2023 y 2025, con el 74% de los componentes centrales de infraestructura pública digital ya implementados. Su recomendación principal —exigir o incentivar con fuerza el uso de bloques compartidos en lugar de proyectos aislados por organismo— es la lección arquitectónica estonia convertida en política pública.

La Base de Conocimiento de Gobierno Electrónico de la ONU sigue siendo la mejor forma gratuita de ubicar a cualquier país contra dos décadas de datos comparables antes de decidir de qué modelo conviene tomar prestado.

Continuá la conversación

Más sobre credenciales verificables, gestión documental e infraestructura pública digital, con casos y arquitecturas de referencia, en sovra.io/knowledge.

Si en tu jurisdicción están eligiendo entre estos modelos ahora mismo, respondé este mail y contanos hacia cuál los están empujando y por qué.

Suscribite a The Identity Brief, sacamos ediciones todas las semanas.

Un acto administrativo, una resolución, un permiso o una notificación, es la unidad de trabajo del Estado. Si el término te resulta nuevo, hace poco publicamos una guía sobre qué es un expediente electrónico y cómo se implementa.

Cuando presentamos la arquitectura de registros estructurados y firmados sobre la que está construido GDE2 de SovraGov, explicamos por qué los gobiernos deberían dejar atrás el PDF como formato nativo.

En esta edición vamos un paso más abajo: qué se almacena realmente, dónde vive esa información, cómo se busca, cómo se verifica y qué hace posible que el sistema funcione a escala de gobierno.

El acto como texto firmado

En GDE2, un acto administrativo se almacena como texto estructurado firmado, no como un PDF. Cada acto es un documento Markdown liviano con el contenido, sus metadatos y una firma digital separada del documento.

La firma se calcula sobre una versión normalizada del texto, de modo que cualquier modificación invalida la firma. Los funcionarios firman desde su billetera de identidad digital utilizando la misma infraestructura de certificados X.509 que los gobiernos ya utilizan.

El documento con validez legal es el texto firmado. Cuando una norma requiere un PDF, GDE2 lo genera a demanda. El PDF pasa a ser una representación; el texto firmado sigue siendo el original.

Dónde vive la información

GDE2 utiliza PostgreSQL 18 para almacenar los metadatos, el estado del expediente, la trazabilidad y el hash SHA256 de cada acto. El documento firmado se guarda en un almacenamiento de objetos y se referencia mediante ese hash. El PDF solo se genera cuando hace falta.

Todas las operaciones se ejecutan dentro de una única transacción. Escribir el acto, registrar la firma, actualizar el expediente y vincular documentos ocurre todo junto o no ocurre en absoluto.

El resultado es un registro confiable donde el contenido y los metadatos pueden consultarse directamente.

Una búsqueda que lee todo el archivo

Como los actos administrativos están almacenados como texto, su contenido completo puede indexarse y buscarse de forma nativa. Encontrar cláusulas, montos o expedientes relacionados lleva segundos, incluso sobre años de archivo.

GDE2 también incorpora búsqueda semántica, que recupera documentos por significado y alimenta al asistente de redacción con antecedentes y normativa relevante.

Una verificación que no depende del sistema original

Un documento administrativo no debería depender de que el sistema que lo creó siga existiendo para poder ser verificado.

Cada acto en GDE2 incorpora una firma digital CAdES sobre un hash SHA256. Cualquier persona con el documento, la firma y la cadena de certificados puede comprobar su integridad y autoría de manera independiente.

Cuando se requiere una prueba de existencia a largo plazo, el acto firmado también puede anclarse en SovraChain mediante una marca de tiempo verificable públicamente.

Esto permite que el documento conserve sus propiedades de confianza incluso cuando cambian las plataformas tecnológicas.

La verificabilidad independiente resulta especialmente importante en un país federal, donde cada jurisdicción toma sus propias decisiones tecnológicas. Lo conversamos con Mauro Solano al analizar cómo las 24 jurisdicciones argentinas construyeron una agenda digital compartida: un documento que cualquier sistema puede verificar por sí mismo es, por definición, un documento interoperable.

Diseñado para operar a escala de gobierno

Los sistemas públicos tienen una característica particular: no funcionan con una carga constante. Los picos de demanda aparecen alrededor de vencimientos, campañas o eventos específicos.

GDE2 está diseñado para soportar millones de operaciones concurrentes sin perder capacidad de respuesta.

El entorno de ejecución aísla fallas, ejecuta tareas secundarias de forma independiente y mantiene toda la infraestructura versionada y reproducible. Esto permite despliegues más confiables y previsibles.

Pero una arquitectura no se valida solo en un diagrama.

Por eso medimos GDE2 sobre expedientes reales de producción, comparando las mismas operaciones bajo ambos modelos.

El resultado fue consistente: 10 veces más rendimiento, con los mismos actos administrativos, las mismas firmas digitales y la misma validez jurídica, pero sobre una base mucho más eficiente.

Sigamos la conversación

La transformación central de GDE2 no es solamente reemplazar PDFs. Es cambiar la unidad fundamental del sistema: pasar de archivos que se almacenan a documentos que pueden entenderse, buscarse y verificarse.

Cuando un acto administrativo nace como información estructurada, el Estado puede hacer más con los mismos datos: mejorar la búsqueda, automatizar procesos, aplicar inteligencia artificial con contexto y construir interoperabilidad entre jurisdicciones.

Ese es el cambio de arquitectura detrás de GDE2.

Más sobre firmas digitales, credenciales verificables y anclaje en blockchain en sovra.io/knowledge.

Si estás evaluando la modernización de tu sistema documental o de expedientes, contáctanos.

Suscríbete a The Identity Brief, publicado todos los jueves.

An administrative act (a resolution, a permit, a notification) is the unit of work of government. If the term is new to you we published a primer on what an electronic case file is and how one gets implemented.

When we introduced the signed, structured architecture behind SovraGov's GDE2, we explained why governments should move beyond PDFs. This edition looks underneath that architecture: what is actually stored, where it lives, how it is searched and verified, and what makes it perform at government scale.

The act as signed text

In GDE2, an administrative act is stored as signed structured text instead of a PDF. Each act is a lightweight Markdown document containing the content, metadata such as jurisdiction, case number and signers, and a detached digital signature.

The signature is computed over a canonicalized version of the text, ensuring that even the smallest change invalidates the signature while identical content always produces the same result. Officials sign through their digital identity wallet, using the same X.509 certificate infrastructure governments already trust.

The legally binding record is the signed text itself. When a regulation or an external system requires a PDF, GDE2 renders one on demand from the signed source, so the PDF becomes a view and the signed text remains the record itself.

Where it lives

Storing administrative acts as text only matters if the underlying architecture is designed around it.

GDE2 uses PostgreSQL 18 as the durable registry: it holds each act’s metadata, its workflow state and its full traceability, together with the SHA-256 hash that binds the row to its content. The document body itself is persisted in a decoupled object store and referenced from the database by that hash, with the PDF generated on demand from the sealed source rather than stored as a second heavy artifact.

Every operation is executed as a single transaction, ensuring that writing the act, recording the signature, updating the case file and linking related documents either all succeed together or none do. The result is a reliable, searchable registry where both content and metadata can be queried directly.

Search that reads the whole archive

Because administrative acts are stored as text, PostgreSQL can index their full content natively. Officials can search clauses, amounts or related proceedings across years of archives in seconds instead of relying only on titles or metadata.

GDE2 also adds semantic search using embeddings, allowing the system to retrieve documents by meaning rather than exact wording. This powers the drafting assistant, which surfaces relevant precedents and regulations as context while keeping every decision under human review and digital signature.

Verification that outlives the system

Every act in GDE2 carries a standard CAdES digital signature over a SHA-256 hash. Anyone with the record, the signature and the certificate chain can independently verify its integrity and authorship, without connecting to the original system.

When long-term proof of existence is required, the signed act can also be anchored on SovraChain, adding a publicly verifiable timestamp. The result is a record that remains trustworthy and interoperable, even as systems evolve or are replaced.

Independent verifiability matters most in a federal reality where each jurisdiction chooses its own technological path, a landscape we explored in our conversation with Mauro Solano about how 24 jurisdictions built a common digital agenda: a record that any system can verify on its own is a record that interoperates by construction.

Built for government-scale workloads

GDE2 is designed to handle millions of concurrent operations without sacrificing responsiveness. This makes it well suited to government systems, where usage often spikes around filing deadlines instead of growing steadily.

The runtime isolates failures so that if one process encounters an error, the rest of the system continues operating normally. Background tasks such as notifications, PDF generation and external integrations run independently, while the infrastructure is fully versioned and reproducible, making deployments reliable and predictable.

Architecture arguments are easy to make on a whiteboard, so we measured this one on real production case files, running the same operations on both foundations. The result was consistent across every test: ten times the performance, with the same acts, the same signatures and the same legal validity, on a foundation built to hold them.

Continue the conversation

More on digital signatures, verifiable credentials and blockchain anchoring at sovra.io/knowledge.

If you are evaluating the modernization of your document or case-file system, contact us.

If this was useful, forward it to a colleague who has to answer for a records system.

Subscribe to The Identity Brief, published every Thursday.

Worth reading this week

• UNCITRAL Model Law on Electronic Signatures: the legal foundation: validity lives in properties of the signature, never in a file format.

• eIDAS Regulation (EU 910/2014): the European framework for electronic identification and trust services.

• PostgreSQL Full-Text Search documentation: how a relational engine indexes and ranks document text natively, the capability a text record unlocks.

En la mayoría de los países federales, los servicios que marcan la vida diaria de un ciudadano dependen de gobiernos subnacionales. En Argentina, salud, educación y seguridad están en manos provinciales, lo que significa que la calidad de la administración provincial impacta de manera directa en cómo viven decenas de millones de personas. Cuando la conversación gira hacia la transformación digital, sin embargo, la atención suele concentrarse en plataformas nacionales, y el nivel de gobierno más cercano a esos sistemas críticos suele ser el último en recibir coordinación, financiamiento o una hoja de ruta compartida.

Las provincias argentinas decidieron construir esa coordinación por su cuenta. FederAI reúne a las 23 provincias y la Ciudad de Buenos Aires alrededor de una agenda común de transformación digital, convocada desde el tercer sector con la academia, organismos internacionales y el ecosistema govtech en la misma mesa. Su premisa toma la lógica central de la infraestructura pública digital: los sistemas fundamentales para prestar servicios, identidad, intercambio de datos y pagos, funcionan mejor y cuestan menos cuando se construyen para ser compartidos, la tesis que nuestro Ep. 9 con Manuel Aguilera exploró a escala regional.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Mauro Solano, Director Ejecutivo de Espacios Políticos y coordinador de la secretaría técnica de FederAI. Politólogo que pasó años dentro de la administración de la provincia de Buenos Aires, dirigió el INAP (Instituto Nacional de la Administración Pública) durante más de tres años y lideró el programa de Estado y Gobierno de CIPPEC, Mauro conoce la capacidad provincial desde adentro, desde el nivel nacional y desde la sociedad civil. Ese triple punto de vista hace que su relato de la transformación subnacional sea inusualmente concreto: habla en mesas de trabajo, estándares y ciclos de quince días antes que en manifiestos.

Lo que vas a escuchar

1. Por qué las provincias son donde la transformación digital más importa

El punto de partida de Mauro es estructural: los grandes sistemas públicos que más afectan la vida de las personas, salud, educación y seguridad, son responsabilidad provincial en Argentina. Que esas administraciones funcionen bien o mal recae directamente sobre los ciudadanos. Su carrera volvió una y otra vez a las provincias, desde la secretaría de modernización bonaerense que lanzó las primeras guías de trámites y sistemas de pago, hasta una red federal de capacitación construida desde el INAP que conectó a los responsables de innovación y empleo público de todas las jurisdicciones. Esa red fue la semilla de lo que hoy es FederAI.

2. Un espacio de coordinación sin primus inter pares

Argentina tuvo consejos federales donde las provincias alineaban su agenda de modernización, primero el COFEFUP (Consejo Federal de la Función Pública) y luego el COFEMOD. Cuando ese espacio dejó de funcionar, las provincias quedaron sin lugar de encuentro. FederAI recrea la función con otra arquitectura: convocado desde el tercer sector, cada jurisdicción se sienta como propietaria en pie de igualdad de la agenda, y la secretaría técnica trabaja detrás de escena para que sean las propias provincias las que definan las prioridades. La membresía también es deliberadamente más amplia, con la Universidad de Buenos Aires, el laboratorio de inteligencia artificial y desarrollo humano de la UNSAM, CAF, el CLAD, el sector privado y el ecosistema govtech. Una coordinación multisectorial de este tipo sigue siendo rara en América Latina, y funciona con un ritmo de trabajo concreto: reuniones cada quince días, entregables puntuales, quick wins.

3. Construir lo que está debajo de la IA

Las tres primeras mesas de trabajo surgieron de lo que las provincias efectivamente pedían: interoperabilidad e integrabilidad, inteligencia artificial y simplificación administrativa. Lo valioso es la secuencia. Todos los gobiernos querían hacer algo con IA, y el primer movimiento del grupo fue mirar la capa de abajo: gobernanza de datos, interoperabilidad y la forma en que se diseñan los trámites. Después llegaron dos mesas más, una que fusionó simplificación con identidad digital (donde participa Sovra) y otra de ciberseguridad junto a la Fundación Sadosky. Es la misma dependencia que mapeamos en What Agentic Government Requires: la inteligencia en la superficie presupone infraestructura debajo.

4. La advertencia: no tecnologizar la buropatología

La frase más filosa de Mauro nombra un modo de falla que todo veterano de la modernización conoce. Si un estado agrega tecnología a procesos que funcionan mal, solo consigue que la disfunción corra más rápido. La simplificación, en su planteo, viene antes que la automatización: revisar cómo administra el estado antes de cablearle inteligencia encima. Las mesas de trabajo tratan los mejores y peores experimentos provinciales con IA como material de aprendizaje compartido, para que cada jurisdicción pueda ver cuándo conviene un caso de uso, y con qué resguardos, antes de gastar.

5. La reutilización cambia la conversación presupuestaria

La objeción clásica a la innovación pública es que no hay plata. La respuesta de la DPI es la reutilización. Hoy varias provincias construyeron cada una su propio sistema de identidad digital, y un ciudadano validado en una provincia arranca de cero en la siguiente, una experiencia que el Ep. 8 con Gustavo Giorgetti recorrió a nivel del intercambio de datos. Infraestructura compartida significa que la inversión de la provincia A se convierte en el punto de partida de la provincia B, en lugar de su gasto duplicado. Mauro enmarca el argumento de fondo en clave constitucional: el federalismo argentino se fundó en pactos preexistentes entre provincias, y acordar estándares mínimos de identidad digital, pagos e intercambio de datos honra esa lógica original. El ciudadano nunca debería cargar con la complejidad institucional, porque en todas las encuestas la conclusión es la misma: para el ciudadano, el estado es uno solo.

6. Las dos tensiones de los próximos años

Consultado sobre hacia dónde van las provincias, Mauro primero aclara lo heterogéneos que son sus puntos de partida, y después nombra dos tensiones compartidas. La primera es transformarse en medio de la aceleración: los estados provinciales acumularon capas de administración patrimonial, burocracia weberiana y nueva gerencia pública, y hoy enfrentan ciudadanos cuyas expectativas las fijaron interacciones mucho más ágiles con el sector privado y el tercer sector. La segunda es la brecha creciente de confianza entre ciudadanía y estado, visible en cualquier encuesta nacional o internacional. Su argumento optimista es que ambas tensiones se pueden atacar con el mismo movimiento, usando la infraestructura pública digital como diagonal, un catalizador que mejora capacidades y reconstruye legitimidad a la vez. Debajo de eso, señala la cuestión del talento: cómo los estados provinciales atraen, retienen y forman personas para un mundo donde el cambio es la constante.

Citas destacadas

“Los grandes sistemas de gestión pública que afectan la vida de los ciudadanos, salud, educación y seguridad, están en manos de las provincias. Es ahí donde se juega gran parte de la suerte de la vida de las personas.”

“No estaríamos haciendo otra cosa que tecnologizar la buropatología: hacer que lo que funciona mal lo haga además más rápido con la tecnología.”

“Las provincias se encuentran convocadas desde el tercer sector sin un primus inter pares. Todas en pie de igualdad, todas igual de propietarias de la agenda.”

“Para el ciudadano, el estado es uno solo. Es muy difícil pretender que ande pensando si se enfrenta al estado municipal, provincial o nacional, y qué credencial llevar para cada uno.”

“En esa necesidad de transformarse y de achicar esa brecha, la infraestructura pública digital es una oportunidad enorme para tomar una diagonal, hacer de catalizador y empezar a resolver esas dos tensiones a la vez.”

Sobre el invitado

Mauro Solano es Director Ejecutivo de Espacios Políticos y coordina la secretaría técnica de FederAI, el foro que reúne a las 23 provincias argentinas y la Ciudad de Buenos Aires alrededor de una agenda común de transformación digital. Politólogo, pasó años en la administración de la provincia de Buenos Aires trabajando en modernización del estado, dirigió el INAP durante más de tres años, donde creó el programa federal de capacitación pública, y lideró el programa de Estado y Gobierno de CIPPEC. Su mirada es distintiva porque manejó la maquinaria que hoy ayuda a coordinar: lee la transformación subnacional como una cuestión de capacidades, secuencia y confianza entre pares, anclada en lo que los equipos provinciales pueden ejecutar de verdad.

Más de Sovra

• 🎧 [PODCAST] Ep. 9: América Latina tiene todo para ganar en infraestructura digital (con Manuel Aguilera) — la versión regional de este argumento: la DPI como rieles compartidos que toda la economía reutiliza.

• 🎧 [PODCAST] Ep. 8: De Estonia a Argentina (con Gustavo Giorgetti) — la capa de interoperabilidad en la práctica: cómo las provincias argentinas se federaron con X-Road.

• 📖 What Agentic Government Requires — la dependencia que descubrieron las mesas de Mauro: la IA en la superficie necesita infraestructura debajo.

• 📖 The Full Lifecycle of a Verifiable Credential — la mecánica de emitir una vez y verificar en todas partes, el patrón del que depende la reutilización de identidad entre provincias.

Sigamos la conversación

Explorá los estándares y componentes detrás de estas ideas en sovra.io/knowledge, nuestro hub de identidad digital y credenciales verificables. Sovra construye la capa que esta conversación señala todo el tiempo: SovraID para credenciales verificables que permiten que la validación de una provincia viaje a la siguiente, y SovraGov para la capa de servicios encima. Entre despliegues, ese stack ya sirve a 8M+ ciudadanos con 1.5M+ identidades en 20+ gobiernos.

Leemos todas las respuestas, así que contanos cómo funciona la coordinación entre jurisdicciones donde operás. Reenviá esta edición a alguien que trabaje en gobierno provincial o estadual.

Suscribite a The Identity Brief, publicado todos los jueves.

🎧 Escuchá el episodio completo en YouTube

The Identity Brief es publicado semanalmente por Sovra, el Digital Identity Stack para el mundo institucional.

In most federal countries, the services that shape a citizen’s daily life are run by subnational governments. Health, education, and security sit in provincial hands in Argentina, which means the quality of provincial administration has a direct effect on how tens of millions of people live. When the conversation turns to digital transformation, however, attention usually flows to national platforms, and the level of government closest to those critical systems is often the last to receive coordination, funding, or a shared roadmap.

Argentina’s provinces decided to build that coordination themselves. FederAI brings together the country’s 23 provinces and the City of Buenos Aires around a common digital transformation agenda, convened from the third sector with academia, international organizations, and the govtech ecosystem at the same table. Its premise borrows the core logic of digital public infrastructure: the foundational systems for delivering services, identity, data exchange, and payments, work better and cost less when they are built to be shared, a thesis our own Ep. 9 with Manuel Aguilera explored at the regional scale.

In this episode of Sovra Podcast, Lucas Jolías speaks with Mauro Solano, Executive Director of Espacios Políticos and coordinator of FederAI’s technical secretariat. A political scientist who spent years inside the Buenos Aires provincial administration, directed Argentina’s INAP (the National Institute of Public Administration) for over three years, and led the Estado y Gobierno program at CIPPEC, Mauro has seen provincial capacity from the inside, from the national level, and from civil society. That triple vantage point is what makes his account of subnational transformation unusually concrete: he speaks in working tables, standards, and fifteen-day work cycles rather than in manifestos.

What You Will Hear

1. Why the provinces are where digital transformation matters most Mauro’s starting point is structural: the large public systems that most affect people’s lives, health, education, and security, are provincial responsibilities in Argentina. Whether those administrations work well or badly lands directly on citizens. His career kept returning to the provinces, from the Buenos Aires modernization secretariat that shipped the province’s first procedure guides and payment systems, to a federal training network built from INAP that connected innovation and public-employment officials across every jurisdiction. That network became the seed of what FederAI is today.

2. A coordination space with no primus inter pares Argentina once had federal councils where provinces aligned on modernization, first COFEFUP (the Federal Council of Public Administration) and later COFEMOD. When that space wound down, the provinces were left without a place to meet. FederAI recreates the function with a different architecture: convened from the third sector, every jurisdiction sits as an equal owner of the agenda, and the technical secretariat works behind the scenes so the provinces themselves define the priorities. The membership is also deliberately wider, including the University of Buenos Aires, UNSAM‘s laboratory on artificial intelligence and human development, CAF, CLAD, the private sector, and the govtech ecosystem. Multi-sector coordination of this kind remains rare in Latin America, and it runs on a working rhythm: meetings every fifteen days, concrete deliverables, quick wins.

3. Build what is underneath the AI The first three working tables emerged from what provinces actually asked for: interoperability and integrability, artificial intelligence, and administrative simplification. The sequencing lesson is the valuable part. Every government wanted to do something with AI, and the group’s first move was to look at the layer below it: data governance, interoperability, and the way procedures are designed. Two more tables followed, one fusing simplification with digital identity (where Sovra participates), and one on cybersecurity with Fundación Sadosky. It is the same dependency we mapped in What Agentic Government Requires: intelligence at the surface presupposes infrastructure underneath.

4. The warning: do not technologize the bureaupathology Mauro’s sharpest phrase names a failure mode every modernization veteran has seen. If a state adds technology to processes that work badly, it simply makes the dysfunction run faster. Simplification, in his framing, comes before automation: review how the state administers before wiring intelligence into it. The working tables treat the best and worst provincial AI experiments as shared learning material, so each jurisdiction can see when a use case is worth pursuing, and with which safeguards, before spending.

5. Reuse changes the budget conversation The classic objection to public innovation is that there is no money. The DPI answer is reuse. Today several provinces have each built their own digital identity systems, and a citizen validated in one province starts from zero in the next, an experience Ep. 8 with Gustavo Giorgetti traced at the level of data exchange. Shared infrastructure means province A’s investment becomes province B’s starting point instead of province B’s duplicate expense. Mauro frames the deeper argument constitutionally: Argentina’s federalism was founded on pre-existing pacts between provinces, and agreeing on minimum standards for digital identity, payments, and data exchange honors that original logic. The citizen should never have to carry the institutional complexity, because in every survey the conclusion is the same: for the citizen, the state is one.

6. The two tensions of the next few years Asked where the provinces are heading, Mauro first notes how heterogeneous their starting points are, then names two shared tensions. The first is transforming amid acceleration: provincial states accumulated layers of patrimonial administration, Weberian bureaucracy, and new public management, and now face citizens whose expectations were set by far more agile private and third-sector interactions. The second is the widening trust gap between citizens and the state, visible in every national and international survey. His case for optimism is that both tensions can be addressed with the same move, using digital public infrastructure as a diagonal, a catalyzer that upgrades capacity and rebuilds legitimacy at once. Beneath those, he flags the talent question: how provincial states attract, retain, and train people for a world where change is the constant.

Key Quotes

“The big public management systems that affect citizens’ lives, health, education, and security, are in the provinces’ hands. It is there that a large part of people’s fortunes is decided.”

“We would be doing nothing more than technologizing the bureaupathology: making what already works badly simply run faster with technology.”

“The provinces sit convened from the third sector with no primus inter pares. All of them on equal footing, all of them equally owners of the agenda.”

“For the citizen, the state is one. It is very hard to expect people to keep track of whether they are facing the municipal, provincial, or national state, and which credential to carry for each.”

“In that need to transform and to close the trust gap, digital public infrastructure is an enormous opportunity to take a diagonal, to act as a catalyst, and to begin resolving both tensions at once.”

About the guest

Mauro Solano is Executive Director of Espacios Políticos and coordinates the technical secretariat of FederAI, the forum that brings Argentina’s 23 provinces and the City of Buenos Aires together around a common digital transformation agenda. A political scientist, he spent years in the Buenos Aires provincial administration working on state modernization, directed INAP for over three years, where he created the federal public-sector training program, and led the Estado y Gobierno program at CIPPEC. His lens is distinctive because he has run the machinery he now helps coordinate: he reads subnational transformation as a question of capacity, sequencing, and trust between peers, grounded in what provincial teams can actually execute.

More from Sovra

• 🎧 [PODCAST] Ep. 9: Latin America Has Everything to Win at Digital Infrastructure (with Manuel Aguilera) — the regional version of this argument: DPI as shared rails the whole economy reuses.

• 🎧 [PODCAST] Ep. 8: From Estonia to Argentina (with Gustavo Giorgetti) — the interoperability layer in practice: how Argentine provinces federated through X-Road.

• 📖 What Agentic Government Requires — the dependency Mauro’s working tables discovered: AI at the surface needs infrastructure underneath.

• 📖 The Full Lifecycle of a Verifiable Credential — the mechanics of issuing once and verifying everywhere, the pattern provincial identity reuse depends on.

Continue the conversation

Explore the standards and building blocks behind these ideas at sovra.io/knowledge, our hub for digital identity and verifiable credentials. Sovra builds the layer this conversation keeps pointing at: SovraID for verifiable credentials that let one province’s validation travel to the next, and SovraGov for the service layer on top. Across deployments, that stack already serves 8M+ citizens with 1.5M+ identities across 20+ governments.

We read every response, so reply and tell us how coordination works between jurisdictions where you operate. Forward this to someone working in provincial or state government.

Subscribe to The Identity Brief, published every Thursday.

🎧 Listen to the full episode on YouTube

The Identity Brief is published weekly by Sovra, the Digital Identity Stack for the Institutional World.