Capa de identidad soberana en blockchain

La autenticación responde quién controla una clave en ese momento. La identidad agrega continuidad: cómo una parte rota las claves, demuestra autoridad para actuar, recibe una credencial, limita a un agente y se recupera después de la pérdida de un dispositivo. Una capa de identidad soberana coordina esas funciones sin que el inicio de sesión en la plataforma sea la única raíz de confianza.

La palabra soberano no significa anónimo por defecto o exento de política. Significa que el sujeto o un controlador explícitamente autorizado tiene un control criptográfico significativo. Una buena implementación puede respaldar a un individuo privado, una organización regulada, un validador, un dispositivo de IoT, un contrato inteligente o un agente de IA, mientras cada uno utiliza una política de divulgación y credenciales adecuada.

Cuatro capas son fáciles de separar en una revisión de arquitectura. El identificador nombra al sujeto. El documento DID publica métodos de verificación y puntos finales de servicio. Las credenciales llevan declaraciones firmadas por los emisores. Un tiempo de ejecución de billetera o agente contiene claves privadas y solicita consentimiento antes de una presentación. La combinación de estos trabajos crea sistemas frágiles y una amplia exposición de datos.

También hay una prueba operativa. Una capa de identidad necesita una respuesta documentada para claves comprometidas, revocación, disponibilidad de resolución, confianza del emisor, riesgo de correlación, almacenamiento de datos personales y migración de billetera. Una cadena de bloques puede hacer que el estado público sea evidente; no puede decidir por sí solo si se debe confiar en un emisor o si una reclamación divulgada es proporcionada.

W3C publicó Identificadores descentralizados v1.0 como estándar web oficial el 19 de julio de 2022. El estándar define un DID como un URI en el formato did:method:method-specific-id, un modelo de datos de documento DID común e interfaces de resolución abstracta y desreferenciación. Deja deliberadamente el registro subyacente y las reglas operativas a cada método DID.

Un documento DID tiene una propiedad de nivel superior requerida, id. Las propiedades opcionales comunes incluyen controller, verificationMethod, relaciones de autenticación y aserción, acuerdo de claves, capacidades delegadas y puntos finales de servicio. Las claves privadas no pertenecen al documento DID.

La Recomendación de 2022 registró 103 especificaciones del método experimental DID, 32 implementaciones de controladores experimentales y 46 implementaciones enviadas a su conjunto de conformidad. Esos recuentos de la especificación W3C son una señal histórica útil: una sintaxis estándar mejora la interoperabilidad, pero no borra las opciones de diseño de cientos de métodos.

"Los identificadores descentralizados (DID) son fundamentales para garantizar una Web más segura y el tipo de experiencias de consumidor empoderadas que estamos permitiendo en Avast".

La resolución es el puente entre un identificador y un material de verificación utilizable. Un solucionador aplica las reglas de lectura del método y devuelve un documento DID más metadatos. Eso hace que la elección del método sea trascendental: un identificador did:web depende del alojamiento web y el control de dominio, un método anclado al libro mayor depende de la disponibilidad y el modelo de tarifas de esa red, y un método derivado de clave tiene diferentes compensaciones de actualización y recuperación.

Para obtener una imprimación más profunda orientada a Autheo, consulte Preguntas frecuentes sobre identificadores descentralizados y Preguntas frecuentes sobre el cumplimiento de W3C DID Core. Ambos deben leerse como el contexto de la hoja de ruta para TheoID, no como una afirmación de que TheoID está disponible hoy.

Ethereum tiene un rico ecosistema de identidad porque las cuentas, las firmas, los contratos y el estado público se pueden componer. No prescribe una capa de identidad para toda la red. En cambio, los desarrolladores combinan control de direcciones, firmas de billeteras, cuentas de contrato, nombres, métodos DID, bibliotecas de credenciales y políticas de aplicaciones según el problema que están resolviendo.

ENS es la capa de nombres más conocida en ese ecosistema. Su documentación describe la creación de aplicaciones con identidad auto-soberana descentralizada y cubre la búsqueda de direcciones, registros de texto, avatares, nombres principales, registros, resolutores y resolutores entre cadenas. Un nombre ENS puede ser un identificador legible por humanos y una superficie de descubrimiento, pero un nombre por sí solo no constituye un sistema de ciclo de vida de credenciales completo.

ERC-1056, también conocido como Ethereum Identidad ligera especifica un registro común Ethereum DID para la gestión de claves y atributos. Su diseño trata las cuentas Ethereum como identidades, admite delegados y atributos ilimitados y permite la rotación de claves mientras el identificador principal permanece estable. La creación de identidad no requiere ninguna transacción de registro por separado porque la cuenta en sí es el punto de partida.

Esa flexibilidad es la fortaleza de Ethereum y su costo de integración. Un producto puede utilizar ENS para descubrimiento, Sign-In with Ethereum para autenticación de sesión, herramientas ERC-1056 o did:ethr para documentos DID y una pila de credenciales verificables independiente para reclamaciones. Cada componente puede ser excelente, pero el equipo debe definir los límites de interoperabilidad, costo de transacción, privacidad, recuperación y soporte.

Explore el Comparación de Autheo y Ethereum existente para obtener una vista de infraestructura más amplia. La conclusión relevante aquí no es que Ethereum carezca de innovación en identidad. Es que Ethereum admite múltiples enfoques de identidad, mientras que los sistemas diseñados específicamente hacen diferentes concesiones en torno al diseño del registro y la privacidad de las credenciales.

Hyperledger Indy tomó la dirección arquitectónica opuesta: un libro de contabilidad público, autorizado y sin token, diseñado específicamente para credenciales verificables que preservan la privacidad. Su revisión anual de 2024 describe el proyecto como estable y robusto, toma nota de los adoptantes existentes y las nuevas implementaciones privadas, y dice que el interés de la comunidad se centra en la identidad y las credenciales descentralizadas en lugar de la arquitectura del libro mayor.

Indy sigue siendo relevante porque hizo que los flujos de DID, registros de revocación, AnonCreds y verificador-titular-emisor sean concretos para muchos equipos. El proyecto también informó que el Indy SDK heredado quedó obsoleto a fines del primer trimestre de 2024, y el ecosistema avanza hacia los componentes compartidos Aries Askar, Indy VDR y Hyperledger AnonCreds. Ésa es una lección del ciclo de vida: un sistema de identidad debe planificar la migración criptográfica y del cliente, no sólo la emisión inicial.

Sovrin usó Hyperledger Indy para una red de identidad pública autorizada. En febrero de 2025, Fundación Sovrin dijo que se estaba preparando para el probable cierre de su libro de contabilidad MainNet el 31 de marzo de 2025 o antes después de siete años, citando una evaluación de la sostenibilidad de la red. Eso no invalida las ideas que propuso, pero sí muestra por qué la continuidad, la financiación, las operaciones de administración, las rutas de exportación y las contingencias de resolución pertenecen a un modelo de amenaza a la identidad.

Los sistemas diseñados específicamente pueden ofrecer un fuerte enfoque en el dominio y primitivas de privacidad cuidadosamente diseñadas. También pueden crear una concentración operativa en torno a una red y una pila de software específicas. El ensamblaje estilo Ethereum ofrece una amplia capacidad de composición pero transfiere más coordinación a la aplicación. Ninguno de los modelos elimina la necesidad de gobernanza de emisores, investigación de usabilidad y recuperación de claves resilientes.

Autheo mantiene un DID y página de comparación de identidades y un Historial de red Sovrin detallado. Para obtener una comparación actual y detallada de la hoja de ruta, consulte Autheo, Indy, Sovrin y uPort.

TheoID es la capa de identidad soberana planificada de Autheo. No está disponible en Autheo hoy y aún no está integrado en el sistema en vivo. Las tarifas de apuesta y transacción están vigentes hoy; La identidad, la computación, el almacenamiento, la inferencia de IA y THEO AI siguen en desarrollo y se están implementando en fases.

A medida que se implemente, TheoID pretende alinearse con W3C DID y conceptos de credenciales verificables para que las personas, organizaciones, dispositivos, validadores y agentes puedan usar identificadores interoperables y reclamos firmados. El modelo planificado se centra en identidad portátil, autorización de alcance, gestión del ciclo de vida de credenciales y una base de identidad compartida para aplicaciones creadas alrededor de Autheo.

La hoja de ruta también describe el soporte criptográfico poscuántico, pero esa protección no está activa y aún no está integrada en el sistema. Los equipos deben evaluar sus controles de seguridad actuales en función de lo que está operativo hoy, no de los planes de integración futuros. El Página de hoja de ruta TheoID es la referencia canónica Autheo para el estado actual.

Para el diseño de agentes de IA, la idea importante es la delegación limitada. Un agente debe recibir una credencial o capacidad limitada por propósito, recurso, cantidad, tiempo y condiciones de revocación, en lugar de una copia de la amplia autoridad de billetera de un ser humano. Esa arquitectura es parte de la dirección prevista de TheoID, no una característica de producción disponible en la actualidad.

Autheo se ejecuta en Proof of Autheo, un modelo de consenso Hybrid PoA/PoS. Ese mecanismo de consenso y una capa de identidad resuelven diferentes problemas: uno coordina la elegibilidad del validador y la producción de bloques ponderados por participación, mientras que el otro está diseñado para representar y autenticar a los sujetos y su autoridad delegada.

Comience con la pregunta de la parte dependiente, no con una preferencia en cadena. ¿Qué debe saber el verificador? ¿Quién puede emitir el reclamo? ¿Puede el titular presentar un comprobante mínimo? ¿Cómo se descubre la clave del emisor y qué sucede después de un compromiso o una revocación? Las respuestas determinan si es apropiado un DID, una credencial, un mensaje firmado o una cuenta federada convencional.

Luego mida la ruta operativa. Pruebe la rotación de claves, la migración de dispositivos, la recuperación de dispositivos perdidos, la revocación de emisores, las interrupciones de la resolución, la caducidad de credenciales y la escalada de soporte. Un diseño de identidad que funciona sólo para una billetera nueva en una demostración no es una capa de identidad soberana en la práctica.

Por último, mantenga los datos personales fuera de los libros públicos a menos que exista una razón convincente y una base legal. Los libros de contabilidad pueden anclar hashes, claves públicas, referencias de revocación o transiciones de estado. La credencial en sí, los atributos confidenciales y el registro de consentimiento a menudo necesitan controles de divulgación y almacenamiento que preserven la privacidad.