Explora IOTA Identity 1.0 en IOTA y Shimmer Now
TL;DR:
IOTA Identity 1.0 proporciona una implementación SSI estable para redes habilitadas para Stardust, lo que permite una fácil integración para aplicaciones nuevas y existentes que desean maximizar la autonomía digital y la privacidad de los usuarios.
En septiembre pasado, cuando se introdujeron la actualización del protocolo Stardust y su marco de tokenización en nuestra red de preparación, Shimmer, aprovechamos estos avances para mejorar IOTA Identity, nuestra herramienta de identidad descentralizada. Tras su lanzamiento en Shimmer, la siguiente versión de IOTA Identity se sometió a pruebas y refinamientos exhaustivos. Ahora, con la integración exitosa de la actualización Stardust en IOTA, estamos entusiasmados de presentar IOTA Identity 1.0 con sus capacidades mejoradas a la red IOTA más amplia.
Introducido por primera vez en 2018, IOTA Identity es un método de identidad descentralizada (DID), identificado como did:iota, junto con una biblioteca asociada. Estos componentes aprovechan los atributos únicos del libro mayor de IOTA, facilitando la integración perfecta de identidades digitales en aplicaciones nuevas y existentes. Si bien esta publicación proporciona un resumen de la información publicada junto con el debut de IOTA Identity 1.0 en Shimmer (ver la publicación del blog aquí), también destaca las últimas mejoras basadas en nuestros conocimientos sobre identidad desde septiembre del año pasado.
La renovación técnica
Para alinear IOTA Identity con la versión Stardust del protocolo, hemos repensado por completo cómo se deben crear, actualizar y resolver las identidades. Aprovechando las capacidades del libro mayor de Stardust, hemos adaptado Alias Outputs para representar identidades, permitiendo interacciones con otras entidades de Capa 1, como tokens fungibles y no fungibles (NFT).
A nivel técnico, los documentos DID ahora se almacenan en el campo de metadatos de estado de Alias Outputs, lo que los hace accesibles para su resolución en todos los nodos. Este enfoque utiliza mecanismos de control de acceso de Capa 1 para la gestión de propiedad y permisos.
Alias Outputs proporciona cuatro capacidades para alojar identidades:
- Identificador único global: Los ID de alias no se pueden cambiar después de su creación, lo que se alinea perfectamente con la naturaleza inmutable de los identificadores DID. El DID contiene el ID de alias, lo que permite una conversión perfecta entre los dos. Un ejemplo simple: la última parte del DID (el identificador específico del método) corresponde al ID de la salida de alias (did:iota:0x0a6cf67b1faff3c4c9097ce91d84b1df490917b39a64a5b6ef30476ce4c528d3).
- Almacenamiento de datos: Las salidas documentos pueden almacenar datos arbitrarios, como DID, en sus metadatos de estado.
- Gestión del controlador: Solo el controlador de estado puede modificar la salida de alias, convirtiéndose efectivamente en el controlador DID y alineándose con la terminología DID.
- Capacidades extendidas: Un DID dentro de una salida de alias hereda todas las capacidades de esa salida, incluidas las transacciones de tokens y la acuñación de activos nativos. Exploramos estos casos de uso con más detalle a continuación.
También hemos implementado un mecanismo de revocación en cadena que puede integrarse en la identidad de la parte emisora. Esto garantiza una alta disponibilidad durante la verificación de credenciales y simplifica los procesos al reutilizar los mismos mecanismos de control de acceso que utilizan los emisores para actualizar sus identidades.
Liberando nuevas posibilidades
Representar identidades a través de alias de salida en la Capa 1 abre interesantes interacciones con otras entidades de la Capa 1, lo que lleva a casos de uso innovadores. Para cada interacción, se proporcionan ejemplos en la biblioteca, disponibles aquí:
- JavaScript/Mecanografiado: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm/examples
- Óxido: https://github.com/iotaledger/identity.rs/tree/main/examples
Identidades que controlan identidades
Las salidas de alias pueden controlar otras salidas de alias, lo que permite que una identidad gobierne a otra. Esto nos permite crear jerarquías de identidades y modelar situaciones como filiales de empresas o custodios humanos. En este contexto, el control se divide entre dos partes: el gobernador y el contralor estatal. El gobernador decide quién puede realizar actualizaciones de una identidad asignando un controlador estatal, mientras que el controlador estatal determina cómo se representa la identidad realizando cambios en el documento DID.
Por ejemplo, imagine un fabricante de teléfonos inteligentes llamado Phonemkr y sus subsidiarias: Phoneshop, donde la gente puede comprar teléfonos y Phoneshippr, que envía los teléfonos. Phoneshop gestiona la identidad de Phoneshippr, pero el fabricante (Phonemkr) quiere el control definitivo sobre ambos.
Esto se logra estableciendo la dirección de la salida de alias de una identidad como condición de desbloqueo del controlador de estado o gobernador de otra identidad. Hoy en día, Alias Output solo puede tener un único controlador de estado, pero tenemos la intención de permitir múltiples controladores con futuras actualizaciones de protocolo. Entonces, en nuestro ejemplo, Múltiples controladores permitirían tanto a Phonemkr como a Phoneshop realizar actualizaciones de la identidad, lo que brindaría más flexibilidad.
autenticar transacciones
Las identidades pueden recibir, retener y enviar tokens. Esto permite identificar al remitente y al receptor de los fondos, brindando mayores garantías a todos los involucrados.
Debido a que una salida de alias puede contener tokens, cualquier DID se puede convertir en una dirección. Por ejemplo, si Alice intercambia DID con Bob y quiere enviarle fondos, Bob autentica su DID ante Alice. Cuando Alice envía fondos a la dirección de salida de alias de Bob, puede estar seguro de que quien controle la identidad de Bob (normalmente el propio Bob) tendrá acceso a los fondos.
Por el contrario, si alguien recibe fondos de una salida de alias que contiene un DID, puede autenticar el origen de los fondos, lo que potencialmente respalda los esfuerzos contra el lavado de dinero. Los observadores pueden rastrear los movimientos de fondos, por lo que es recomendable utilizar diferentes identidades para diversos casos de uso en lugar de una única identidad para todas las interacciones.
La dirección de una Salida Alias puede servir como Condición de Desbloqueo de cualquier salida, permitiendo que la Salida Alias controle la Salida Básica y sus fondos. Los fondos se transfieren mediante la creación de una Salida Básica controlada por la Salida de Alias del receptor. Esta configuración proporciona un identificador permanente para recibir fondos y al mismo tiempo cumple con las mejores prácticas de seguridad, como la rotación de claves, lo que permite la transferencia de fondos a DID en la Capa 1.
DID que emiten NFT
Con la actualización del protocolo Stardust, los NFT ahora se pueden acuñar y transferir en la Capa 1 a través de Salidas NFT dedicadas, y los DID pueden ayudar a probar la identidad del emisor del NFT.
Por ejemplo, Phonemkr quiere emitir pasaportes de productos digitales en forma de NFT para cada teléfono que vende. Phonemkr crea su identidad en una salida de alias y vincula de manera demostrable su DID a su sitio web, phonemkr.com. Si Phonemkr emite NFT con su identidad como emisor, demuestra que phonemkr.com emitió esos NFT.
De manera similar a las transferencias de fondos, los NFT pueden ser propiedad de los DID y transferirse a ellos, ya que la condición de desbloqueo de una salida NFT puede ser una salida de alias que representa un DID, lo que brinda garantías sobre de quién recibe o envía NFT.
Además, las NFT pueden desbloquear (léase “propias”) identidades. Esto podría beneficiar a numerosas entidades u organizaciones representadas y comercializadas a través de NFT (aunque generalmente no se recomiendan para humanos). Esto permite la transferencia de propiedad de una entidad u organización y su correspondiente identidad en una única interacción atómica.
DID que emiten tokens nativos
Cuando un DID sirve como emisor de tokens nativos, brinda mayores garantías y confianza a los poseedores de tokens. Con esta información, los poseedores de tokens pueden verificar el origen de los tokens nativos y validar las afirmaciones realizadas por el emisor de activos.
Esto es posible porque los tokens nativos se crean a través de una salida de Foundry controlada por una única salida de alias. Incrustar una identidad en esta salida de alias permite resolver la identidad del minter.
Autenticar cadenas de contratos inteligentes
La actualización del protocolo Stardust permitirá que el estado de las cadenas de Contratos Inteligentes (ISC) de IOTA se ancle en Alias Outputs en el libro mayor. Con identidad IOTA, cadenas de contratos inteligentes se puede demostrar que están vinculados a identidades.
Como se mencionó anteriormente, las identidades se pueden organizar jerárquicamente, lo que permite que una única identidad cree y controle Múltiples alias de salida. Esto significa que una identidad dentro de una Salida de Alias puede gobernar la Salida de Alias de una cadena ISC. Esto permite a los usuarios identificar al gobernador de una cadena y les ayuda a decidir si quieren confiar e interactuar con la cadena. También permite a observadores externos verificar y demostrar quién tiene el control final de la cadena.
JSON web de tokens
A medida que el ecosistema SSI converge en estándares y formatos comunes, nos esforzamos por elegir las tecnologías más capaces e interoperables. Siguiendo ese razonamiento, hemos hecho la transición a la codificación JSON Web Token (JWT) para credenciales y presentaciones. Esto se alinea con las últimas propuestas y recomendaciones de proyectos regulatorios en la UE. Las credenciales y presentaciones ahora están integradas en JWT (un formato ampliamente utilizado para intercambiar atributos y permisos) y deben almacenarse y transmitirse en este formato.
Hemos construido la biblioteca de tal manera que los formatos de credenciales alternativas, como el muy prometedor Borrador de integridad de datosse puede implementar junto con el formato actual en el futuro.
Mejoras clave en el almacenamiento
Modificamos la interfaz de almacenamiento para permitir a los implementadores desarrollar sus propias soluciones para almacenar material clave confidencial. Para requisitos avanzados, la nueva interfaz debería facilitar significativamente la adaptación de la biblioteca a las soluciones de administración de claves existentes que ofrecen el más alto nivel de seguridad y durabilidad. Para lograr la flexibilidad necesaria, hemos dividido la interfaz en dos partes: una manija el almacenamiento y las operaciones de claves, mientras que la otra maneja el estado específico de la biblioteca.
Como antes, enviamos una implementación predeterminada de la interfaz utilizando Stronghold for Rust, lo que permite a los implementadores trabajar de forma rápida y segura. La implementación predeterminada permite a los implementadores administrar las claves, utilizadas para acceder al libro mayor, y las identidades que se almacenarán (y respaldarán) en el mismo archivo instantáneo de Stronghold, lo que mejora la ergonomía de la administración de claves.
Verificacion de dominio
Una nueva característica importante en 1.0 es la Verificación de Nombre de Dominio, un proceso que vincula de manera verificable un dominio a una identidad. El vínculo se puede descubrir partiendo del dominio o de la identidad.
Un ejemplo de partir de la identidad es verificar la minter de un NFT. Al inspeccionar un NFT de capa 1 de IOTA, puede descubrir qué salida de alias lo acuñó. A su vez, la salida de alias puede contener una identidad que se puede vincular a un dominio. Al resolver el dominio, un verificador puede confirmar el enlace criptográfico y tener confianza en que la entidad que controla el dominio también emitió el NFT, confirmando así la autenticidad del NFT.
Por el contrario, un ejemplo que comienza desde el dominio es cuando descubre identidades vinculadas a una página de inicio y establece una conexión Web3 a un punto final al que se hace referencia en la identidad vinculada. A través de este enlace, puedes empezar desde una página de inicio confiable y descubrir identidades corporativas vinculadas para futuras interacciones dentro y fuera de la cadena.
Es importante tener en cuenta que la información publicada en cadena debe evaluarse cuidadosamente para satisfacer las necesidades individuales de anonimato y cumplimiento de las leyes de privacidad de datos. Si bien las corporaciones pueden optar por vincular su página de inicio a su identidad digital, las personas pueden preferir no crear dichos vínculos a su página de inicio personal.
Para maximizar la interoperabilidad, nuestra implementación sigue una propuesta desarrollada por la Fundación Identidad Descentralizada (DIF). La propuesta hace que el enlace de una identidad a una página de inicio sea opcional, permitiendo a las identidades decidir qué tan visible quieren que sea el enlace. Para establecer un vínculo, el propietario del dominio debe cargar una credencial firmada por la identidad vinculada a su dominio. Tanto el dominio como la identidad pueden contener múltiples enlaces, creando una red de relaciones confiables entre Múltiples dominios (por ejemplo, membresía en organizaciones profesionales y sin fines de lucro, pasatiempos, clubes de fans, etc.) e identidades.
En conclusión: el futuro de la identificación digital
IOTA Identity 1.0 sienta las bases para soluciones de identidad ambiciosas para individuos, organizaciones y objetos. Aprovechando la escalabilidad de IOTA Tangle y la versatilidad del libro mayor de Stardust, hemos creado un ecosistema único para interacciones dentro y fuera de la cadena entre elementos de identidad criptográficos y autosoberanos.
Únase a nosotros en este emocionante viaje mientras continuamos dando forma al futuro de las identidades digitales en IOTA Tangle. Síguenos en Twitter es @iota únete al canal ID en discordia, o contáctenos en identidad@iota.org. Juntos, estamos redefiniendo las posibilidades de verificación de identidad y confianza en el ámbito digital.
Enlaces en este artículo
- Interacción de salidas de alias en la capa 1: Ejemplo de JavaScript/TypeScript
- Interacción de salidas de alias en la capa 1: Ejemplo de óxido
- Artículo de IOTA Wiki: Soporte de cadena de contratos inteligentes
- Borrador de trabajo del WC3: Integridad de datos de credenciales verificables 1.0
- Fundación de identidad descentralizada propuesta