Lanzamiento de IOTA Identity v0.5

1422

TL;DR:
La versión 0.5 de IOTA Identity contiene una revisión de la API para el framework Rust, con mejoras en la facilidad de uso, seguridad, consistencia y calidad del código. Además, hemos mejorado significativamente los enlaces de JavaScript para estar a la par con el marco de Rust, introduciendo la API de cuentas mucho más fácil de usar, Stronghold para el entorno Node.js, y las otras mejoras de la API.

Estamos orgullosos de anunciar el lanzamiento de la versión 0.5 de IOTA Identity. Con esta actualización, el equipo de IOTA Identity da un paso importante para proporcionar el Marco de Identidad Autosoberana (SSI) más seguro, que preserva la privacidad y es fácil de usar en el mercado. Mientras que anteriormente seguíamos nuestro propio esquema de nomenclatura con «beta-2», ahora hemos vuelto a la versión semántica (major.minor.patch).

Sobre los cambios en la Tangle

La actualización 0.5 contiene importantes mejoras en los mensajes del Identificador Descentralizado (DID) en la Tangle. En primer lugar, los mensajes DID se comprimen ahora utilizando el algoritmo de compresión Brotli, reduciendo alrededor de un 40% del tamaño del mensaje sin tener un impacto significativo en el rendimiento debido a la compresión y descompresión. Debido a esta reducción de tamaño, los mensajes DID requerirán una dificultad de prueba de trabajo (PoW) reducida, reduciendo así también el tiempo de publicación. En un entorno post-Coordicidio, esperamos que esto también se aplique a Mana, reduciendo la cantidad de Mana necesaria para publicar un mensaje DID.

Tras la descompresión, los mensajes DID están ahora también más claramente estructurados en tres objetos separados: «doc», «meta» y «proof». Esta separación facilita la búsqueda de información relevante de los mensajes DID en bruto y sigue más de cerca la especificación del W3C para DID.

Estos cambios no son compatibles con las identidades publicadas con versiones anteriores del marco, lo que significa que esas identidades no pueden resolverse con la nueva versión y viceversa. Para evitar más cambios de ruptura debido a las alteraciones del diseño de los mensajes DID, hemos introducido el versionado. Cada mensaje DID contiene un byte para la versión del diseño del mensaje DID y un byte para el algoritmo de compresión utilizado. Esto hace posible la compatibilidad con versiones anteriores en futuras actualizaciones. Aunque nuestro objetivo es reducir al mínimo los cambios de ruptura y nos gustaría mantener la compatibilidad con versiones anteriores, todavía estamos investigando los detalles exactos de cómo cambiarán los mensajes DID con la actualización de Stardust, lo que podría dar lugar a un cambio de ruptura.

Mejoras en la API

La API de la cuenta ha sufrido varios cambios para mejorar su mantenimiento, flexibilidad y facilidad de uso. Para los desarrolladores que utilizan el marco Rust, esto se traduce sobre todo en una experiencia de desarrollo simplificada en la que proporcionamos una API flexible con valores predeterminados razonables. La API de cuentas está ahora hecha para gestionar una sola identidad, en lugar de varias. Esto elimina la necesidad de hacer un seguimiento del DID después de crear una identidad, ya que los desarrolladores ya no necesitan introducir el DID en cada función de actualización. Como las cuentas ahora sólo gestionan un único DID, también permitimos que las fortalezas se compartan entre las cuentas. Esto evita que los usuarios tengan que establecer nuevas contraseñas para cada nueva identidad.

El equipo también ha añadido soporte para el intercambio de claves X25519 Diffie-Hellman al marco. Esto permite que dos partes establezcan un canal de comunicación seguro, lo que es útil para compartir información sensible, como las credenciales verificables (VC). También permite a IOTA Streams añadir soporte para IOTA Identity.

Por último, la verificación de VCs ha ganado una API mucho más potente. Anteriormente, la API sólo permitía la verificación de la firma y sólo si la clave de firma era todavía válida. Ahora, los desarrolladores pueden elegir qué opciones de verificación consideran importantes. También pueden decidir si permiten que las CV caducadas pasen la verificación y pueden construir fácilmente su propia lógica de verificación personalizada sobre las primitivas de la API de verificación.

Mejoras en JavaScript

Ahora que el marco de trabajo de Rust ha madurado significativamente y nuestra API está en gran forma, hemos centrado la mayor parte de nuestros esfuerzos para la v0.5 en los enlaces de JavaScript. La mayor parte de la adopción proviene actualmente de los desarrolladores de JavaScript, por lo que siempre nos proponemos darles la máxima prioridad. Sin embargo, JavaScript ha resultado ser todo un reto. Estamos muy contentos de tener ahora la paridad de características entre Rust y JavaScript.

La API de cuentas simplifica las cosas para los desarrolladores de JavaScript. Ya no tienen que configurar un cliente, generar claves en una función separada, hacer un seguimiento y establecer PreviousMessageIds, establecer marcas de tiempo o firmar y publicar manualmente una actualización. Esto se traduce sobre todo en una experiencia simplificada para los desarrolladores, a los que proporcionamos una API flexible con valores predeterminados razonables. Esto permite a los desarrolladores saltarse los pasos mundanos en el desarrollo inicial, como elegir una red IOTA, establecer un nodo y un permanode y publicar manualmente todos los cambios. Todavía es posible alterar todo este comportamiento, pero, al proporcionar valores predeterminados sensibles, ofrecemos una experiencia de incorporación de desarrolladores mucho más fácil y requerimos que se entiendan menos conceptos antes de que los desarrolladores sean capaces de utilizar el marco. Además, la nueva API es mucho más compatible con Typescript.

Nuestro mayor reto consistió en añadir la compatibilidad de Stronghold con JavaScript. Creamos una flexibilidad en el marco de trabajo para saber cómo se deben generar, almacenar y utilizar las claves privadas. Esta «API de almacenamiento» puede ser implementada por cualquiera, permitiéndole conectar el framework a su propio sistema de gestión de claves. Por defecto, ofrecemos una implementación de Stronghold para Rust y ahora hemos añadido una implementación de Stronghold para el entorno Node.js. Por desgracia, no podemos garantizar una seguridad similar en el entorno web, donde ahora tenemos un almacén en memoria. El equipo está investigando nuevas API de navegador para ofrecer una solución más segura para la web, pero recomendamos almacenar y gestionar las claves en un entorno nativo.

Futuras versiones

El equipo de IOTA Identity también ha realizado mejoras drásticas en nuestros procesos. Esto puede ser menos brillante y emocionante para la comunidad, pero significa que el equipo tiene ahora un proceso de lanzamiento totalmente automatizado con registros de cambios detallados. Además, nuestras pruebas automatizadas son ahora más rápidas y fiables y cubren más casos importantes.

La versión 0.5 de IOTA Identity fue un gran paso adelante para el equipo, ya que la paridad de características entre JavaScript y Rust hace que sea mucho más fácil hacer actualizaciones más frecuentes. Nuestro trabajo en el Actor de Identidad continúa con la integración de la especificación DIDComm que hemos escrito y estamos empezando a implementar Pruebas de Conocimiento Cero basadas en nuestra investigación con la Fundación LINKS. La próxima actualización de Stardust también ofrece muchas oportunidades para el marco de identidad de IOTA, por ejemplo, permitiéndonos eliminar el permanode como requisito. Esperamos ofrecer actualizaciones aditivas más frecuentes con menos cambios de ruptura, haciendo que el desarrollo de IOTA Identity sea más fácil para los desarrolladores. Sin embargo, mientras estemos antes de la versión 1.0, no podemos prometer que no habrá más cambios de ruptura.

Para hacer uso de la nueva actualización, echa un vistazo a nuestro GitHub, que también tiene registros de cambios detallados tanto para Rust como para JavaScript. Si estás buscando una gran oportunidad para trabajar con IOTA Identity, no te pierdas nuestra Solicitud de Propuestas (RFP) sobre el tema de un Login IOTA, que termina en un par de semanas. La RFP podría ayudarte a asegurar la financiación de un proyecto (siempre que cumpla con los requisitos descritos en la RFP). Para cualquier pregunta sobre la v0.5 o la RFP, únete a nosotros en el canal #identity en Discord.


La imagen de portada está modificada utilizando como base la imagen original del post. 

Comentarios

comentarios

pasarela de pagos con criptomonedas