De la redacción
El Buen Tono

Un nuevo modelo de identidad digital plantea cambiar la manera en que los sistemas informáticos reconocen a los usuarios y autorizan sus operaciones, al separar la autenticación de los permisos para modificar información o controlar servicios.

La propuesta, denominada Digital Space Identity (Identidad del Espacio Digital), fue presentada por Sui Gn en una publicación de CodeX, en Medium, el 21 de agosto de 2026. El desarrollo se encuentra en una etapa inicial de implementación dentro de Netget, una infraestructura tecnológica que conecta dominios, servicios, procesos locales y tráfico público.

El planteamiento parte de una debilidad de los sistemas tradicionales: considerar que una persona identificada como administrador tiene autorización automática para ejecutar prácticamente cualquier operación.

El nuevo esquema busca eliminar esa concentración de privilegios mediante pruebas criptográficas, identidades verificables y permisos específicos para cada acción.

Una nueva estructura para la identidad digital

El modelo introduce el concepto de espacio digital, en el que la información, los usuarios, los dispositivos y los permisos se administran como elementos independientes.

Para explicar su funcionamiento, el autor utiliza la siguiente expresión matemática:

I = (path, ciphertext, T, A, C)

Cada elemento representa una característica del espacio digital:

• path: ubicación donde se encuentra la información.
• ciphertext: contenido protegido mediante cifrado.
• T: topología, es decir, los nodos que almacenan o replican los datos.
• A: audiencia, que determina quién puede acceder a la información legible.
• C: capacidad, que establece qué operaciones están permitidas.

Esta estructura busca demostrar que almacenar información, tener acceso para leerla y contar con autorización para modificarla son facultades diferentes.

Por ejemplo, un servidor puede almacenar información cifrada sin que necesariamente tenga autorización para descifrarla. De igual manera, un administrador puede identificarse correctamente, pero no tener permiso para modificar determinada configuración.

Los códigos que permiten verificar cada operación

Uno de los componentes centrales del desarrollo es el uso de solicitudes firmadas digitalmente.

Cuando un usuario intenta realizar una operación, el sistema construye un desafío criptográfico con cinco elementos:

{
  method,
  path,
  bodyHash,
  nonce,
  timestamp
}

Cada campo cumple una función:

• method: identifica el método HTTP utilizado, como GET o POST.
• path: establece la dirección o recurso al que se dirige la solicitud.
• bodyHash: contiene la huella digital del contenido enviado.
• nonce: utiliza un valor único para impedir que una solicitud sea reutilizada.
• timestamp: registra el momento en que se genera la operación.

La solicitud se firma utilizando el material criptográfico de la identidad .me, vinculado al dominio de la puerta de enlace mediante Cleaker.

Posteriormente, OpenResty verifica la firma a través del componente técnico me_sig.lua.

El sistema comprueba que el método, la dirección y el contenido coincidan con los datos firmados, además de verificar que la marca de tiempo sea válida y que el identificador único no haya sido utilizado anteriormente.

El código que demuestra que ser administrador no significa tener todos los permisos

Una de las pruebas más importantes del proyecto consiste en rechazar operaciones incluso cuando la identidad del usuario ha sido autenticada correctamente y cuenta con reconocimiento de administrador.

El autor resume este comportamiento mediante la siguiente expresión:

valid signed proof + admin identity
- explicit capability => 403

El código HTTP 403 representa una respuesta de acceso prohibido.

Esto significa que una identidad puede ser legítima, demostrar que firmó una solicitud y estar reconocida como administradora, pero aun así recibir una negativa si no cuenta con la autorización específica para ejecutar esa operación.

El sistema también utiliza el siguiente permiso:

gateway:write:domain-metadata

Esta capacidad permite modificar los metadatos descriptivos de un dominio, pero no autoriza cambios en el enrutamiento del tráfico, la configuración de certificados ni otros componentes de infraestructura.

Cuando una identidad intenta modificar esa información sin contar con el permiso correspondiente, el sistema devuelve:

CAPABILITY_DENIED
required: gateway:write:domain-metadata

Con esta respuesta se identifica el motivo del rechazo y la capacidad que se necesita para realizar la operación.

Una prueba que también detectó errores técnicos

La implementación inicial permitió identificar un problema en OpenResty relacionado con el funcionamiento del código Lua.

Durante las pruebas, las solicitudes rechazadas provocaban fallos en la conexión debido a la manera en que se ejecutaba el middleware.

El problema estaba relacionado con el uso de dofile() dentro de un bloque access_by_lua_block, donde se producía un conflicto con el manejo de ngx.exit().

La corrección consistió en utilizar:

loadfile()()

Este cambio permitió resolver el problema detectado durante las pruebas de seguridad.

Además, el equipo incorporó verificaciones para impedir solicitudes repetidas, marcas de tiempo vencidas y modificaciones no autorizadas en el método, la dirección o el contenido de las peticiones.

Qué está demostrado y qué falta desarrollar

El proyecto ya cuenta con pruebas funcionales que demuestran varios aspectos de su arquitectura:

• Verificación de identidades mediante firmas digitales.
• Vinculación de solicitudes con métodos, direcciones y contenidos específicos.
• Protección contra la reutilización de solicitudes.
• Separación entre autenticación y autorización.
• Rechazo de operaciones sin permisos explícitos.
• Registro de pruebas para evitar modificaciones parciales cuando una operación es denegada.

Sin embargo, el propio desarrollador reconoce que todavía existen limitaciones.

Entre los pendientes se encuentran la implementación completa de la audiencia de control mediante claves protegidas por .me, la incorporación de más capacidades, la generalización de los mecanismos de revocación y delegación, así como el cifrado de los registros.

También permanece un problema de transición entre el almacenamiento heredado SQLite y el nuevo sistema respaldado por el núcleo .me.

La intención es que Lua se encargue de verificar y transmitir las pruebas de identidad, mientras que el servicio principal determine los permisos y ejecute las modificaciones autorizadas.

La propuesta representa un cambio en la arquitectura de seguridad digital: en lugar de confiar en una cuenta por el simple hecho de estar identificada como administradora, cada operación deberá demostrar quién la solicita y por qué tiene autorización para realizarla.

Aunque todavía no constituye un sistema terminado, su primera implementación demuestra que es posible separar técnicamente la identidad, la autenticación y los privilegios dentro de una misma infraestructura.