Estándares abiertos: interoperar para no depender

Cuando una institución educativa decide digitalizar sus certificados, la primera pregunta suele ser técnica: ¿qué plataforma contratamos?

La segunda pregunta suele ser comercial: ¿cuánto cuesta y qué soporte incluye?

La tercera pregunta —cuando se hace— es estratégica: ¿qué pasa si queremos cambiar de plataforma en cinco años?

Esta tercera pregunta es, con mucho, la más importante. Y su respuesta depende de una variable que rara vez se evalúa con el rigor que merece: la adopción de estándares abiertos.

Este artículo explica qué son los estándares abiertos en el contexto de las credenciales verificables, por qué constituyen una decisión de soberanía institucional y no una mera preferencia técnica, y cómo distinguir entre una plataforma que realmente los adopta y otra que solo los invoca como etiqueta comercial.

1. El problema de fondo: la dependencia como costo oculto

Toda plataforma tecnológica genera algún grado de dependencia. El software se aprende, los procesos se ajustan, los datos se acumulan, las personas se capacitan. Cambiar de sistema requiere tiempo, recursos y decisiones políticas que ninguna institución toma a la ligera.

Este fenómeno —conocido como vendor lock-in o cautividad tecnológica— no es necesariamente patológico. Puede ser el resultado natural de una relación de largo plazo con un proveedor que cumple satisfactoriamente sus funciones.

El problema surge cuando la dependencia es irreversible. Cuando los datos no pueden exportarse en formatos utilizables. Cuando las credenciales emitidas solo son verificables dentro del ecosistema del proveedor. Cuando cambiar de plataforma implica perder la capacidad de verificar lo emitido en el pasado.

En ese escenario, la institución ya no elige: está cautiva. Y lo que parecía una decisión administrativa se revela como una cesión de soberanía institucional [^1].

Los estándares abiertos son la principal —a menudo la única— defensa contra este riesgo.

2. ¿Qué es un estándar abierto?

Un estándar abierto es, en su definición más operativa, una especificación técnica que cumple cuatro condiciones:

1. Está desarrollada mediante un proceso colaborativo, transparente y orientado al consenso, generalmente en el seno de organizaciones internacionales de estandarización (W3C, IMS Global, ISO).

2. Está publicada y disponible de forma gratuita para cualquier persona u organización que desee implementarla.

3. Puede ser implementada por cualquier proveedor, sin restricciones de patentes, licencias o regalías.

4. Es mantenida en el tiempo por la comunidad que la desarrolló, con mecanismos claros de evolución y versionado.

En el ámbito de las credenciales digitales verificables, los estándares abiertos de referencia son:

• Modelo de Datos para Credenciales Verificables (W3C VC) : define la estructura de datos y el mecanismo criptográfico de las credenciales [^2].

• Open Badges 3.0 (IMS Global) : especificación para insignias digitales, completamente alineada con el modelo W3C VC [^3].

• DID (Decentralized Identifiers) : estándar para identidades emisoras verificables, controladas por la institución y no por un proveedor [^4].

• VP (Verifiable Presentations) : formato para que el titular presente sus credenciales de forma selectiva y controlada.

Ninguno de estos estándares es propiedad de una empresa. Todos pueden ser implementados por cualquier desarrollador, en cualquier plataforma, en cualquier país.

3. La diferencia entre "usar" y "adoptar" un estándar

Una de las estrategias comerciales más frecuentes en el mercado de la certificación digital consiste en declarar compatibilidad con estándares abiertos sin adoptarlos realmente.

Esta distinción es sutil pero crucial:

Un símil útil: una plataforma que "usa" PDF puede abrir documentos PDF, pero los edita en su propio formato interno. Una plataforma que "adopta" PDF trabaja directamente sobre el formato estándar, sin capas de traducción ni pérdidas.

La diferencia no es visible para el usuario durante la operación normal. Se revela en el momento de la migración. Y en ese momento, muchas instituciones descubren que lo que creían estándar era, en realidad, una interpretación propietaria [^5].

4. ¿Qué está en juego cuando se adopta un estándar abierto?

Para una institución educativa, la adopción genuina de estándares abiertos en certificación digital no es una decisión técnica. Es una decisión de gobierno institucional por cuatro razones:

1. Determina la portabilidad de las credenciales.
Si las credenciales emitidas hoy están en un formato estándar, podrán ser verificadas dentro de diez años por sistemas que aún no existen. Si están en un formato propietario, su verificabilidad futura dependerá de la continuidad comercial del proveedor.

2. Determina la autonomía del egresado.
Una credencial en formato estándar puede ser almacenada en cualquier wallet compatible, no solo en la aplicación del proveedor. El egresado puede elegir cómo y dónde resguardar sus logros.

3. Determina la capacidad de negociación institucional.
Una institución cuyos datos están en formato estándar puede cambiar de proveedor sin perder su historia de emisión. Puede negociar condiciones, migrar a mejores soluciones o incluso desarrollar capacidades internas. Una institución cautiva no puede.

4. Determina la sostenibilidad archivística.
Los formatos propietarios mueren con sus empresas. Los estándares abiertos sobreviven a sus creadores. Para instituciones que emiten credenciales con validez perpetua —títulos profesionales, grados académicos—, esta diferencia es existencial.

5. Objeciones frecuentes (y sus respuestas)

Objeción 1: "Los estándares abiertos son más lentos y menos innovadores."

Respuesta: La experiencia acumulada en tres décadas de desarrollo de software muestra exactamente lo contrario. Los estándares abiertos maduran más lentamente, pero evitan que la innovación de un proveedor se convierta en una jaula para sus clientes. La velocidad sin interoperabilidad no es innovación; es especulación con la dependencia ajena.

Objeción 2: "Nuestro proveedor nos asegura que cumple con los estándares."

Respuesta: Solicite una prueba concreta: exporte un lote de credenciales en formato W3C VC nativo e impórtelas en una wallet de otro proveedor. Si la operación falla o requiere transformaciones, el cumplimiento declarado no es adopción real.

Objeción 3: "No tenemos capacidad interna para gestionar estándares abiertos."

Respuesta: Esa es exactamente la función de un proveedor institucional. Una plataforma como Veristall no exige que la institución se convierta en experta en estándares; exige que la institución exija que la plataforma los adopte de forma nativa. La capacidad se contrata; la soberanía se exige.

Objeción 4: "Nuestro contexto regulatorio no exige interoperabilidad."

Respuesta: El contexto regulatorio rara vez anticipa necesidades estratégicas. La interoperabilidad no se exige hoy porque los sistemas cerrados son la norma. Pero cuando la movilidad académica o la verificación transfronteriza se conviertan en prioridad —y se convertirán—, las instituciones con credenciales en formatos propietarios descubrirán que su cumplimiento normativo actual no las protege de la obsolescencia funcional.

6. El caso de los identificadores descentralizados (DID)

Un capítulo aparte merecen los DID (Decentralized Identifiers) . Un DID es, en esencia, un identificador que la institución controla directamente, sin depender de una autoridad de registro central ni de un proveedor específico.

A diferencia de un dominio web —que se alquila y puede expirar— o de un certificado de firma electrónica —que se compra a una autoridad de certificación—, un DID bien construido puede ser perpetuo, portable y verificable sin intermediarios.

Cuando una institución emite credenciales utilizando su propio DID:

• La identidad emisora viaja con la credencial, no con la plataforma.

• La verificación no requiere consultar ninguna base de datos central.

• El control sobre la identidad emisora es ejercido directamente por la institución.

Los DID no son un requisito para la adopción de estándares abiertos, pero son su expresión más madura. Representan el punto en el cual la institución deja de ser un cliente de un sistema de identidad y se convierte en soberana de su propia identidad digital [^4].

7. La pregunta institucional

Una vez que una institución comprende qué son los estándares abiertos y qué implican para su soberanía, la pregunta relevante ya no es técnica:

"¿Qué plataforma debemos contratar?"

Sino institucional:

"¿Estamos dispuestos a transferir a un tercero el control sobre nuestra identidad emisora y la verificabilidad futura de nuestras credenciales?"

Esta pregunta no tiene una respuesta universal. Algunas instituciones valorarán la simplicidad de una solución cerrada por encima de la soberanía que sacrifican. Otras considerarán que la dependencia es un riesgo aceptable a cambio de menores costos iniciales.

Lo que ya no es admisible es no hacerse la pregunta.

Porque la decisión sobre estándares abiertos no es una decisión técnica que pueda delegarse en áreas de TI. Es una decisión estratégica que determina si las credenciales emitidas hoy seguirán siendo verificables dentro de diez, veinte o treinta años.

Ningún proveedor —ninguno— puede garantizar que su plataforma propietaria existirá en tres décadas. Pero un estándar abierto, sostenido por una comunidad global, no necesita garantías: su permanencia es intrínseca a su naturaleza.