IOTA Identity v0.5 Release

TL;DR:
IOTA Identity version 0.5 contains an overhaul of the API for the Rust framework, with improvements in ease of use, security, consistency and code quality. In addition, we have significantly improved the JavaScript bindings to be on par with the Rust framework, introducing the much easier to use Account API, Stronghold for the Node.js environment, and the other API improvements.

We are proud to announce the release of IOTA Identity version 0.5. With this update, the IOTA Identity team takes an important step towards providing the most secure, privacy-preserving and easy-to-use Self-Sovereign Identity (SSI) framework on the market. While previously following our own naming scheme with “beta-2”, we have now gone back to semantic versioning (major.minor.patch).

On Tangle changes

The 0.5 update contains significant improvements to the Decentralized Identifier (DID) messages on the Tangle. Firstly, DID messages are now compressed using the Brotli compression algorithm, reducing about 40% of the message’s size without having a significant impact on the performance due to compression and decompression. Due to this size reduction, DID messages will require a reduced Proof of Work (PoW) difficulty, thereby also reducing the publication time. In a post-Coordicide setting, we expect this to also apply to Mana, reducing the amount of Mana required to publish a DID message.

After decompression, the DID messages are now also more clearly structured into three separate objects: “doc”, “meta” and “proof”. This separation makes it easier to find relevant information from the raw DID messages and follows the W3C specification for DID more closely.

These changes are not compatible with identities published using older versions of the framework, meaning that those identities cannot be resolved with the new version and vice versa. In order to prevent more breaking changes due to DID message layout alterations, we have introduced versioning. Every DID message contains a byte for the DID message layout versioning and a byte for the compression algorithm used. This makes it possible to support backward compatibility in future updates. While we aim to keep breaking changes to a minimum and would like to maintain backward compatibility, we are still researching the exact details of how DID messages will change with the Stardust update, which could potentially lead to a breaking change.

API improvements

The Account API has undergone several changes to improve maintainability, flexibility and ease of use. For developers using the Rust framework, this translates mostly into a simplified developer experience where we provide a flexible API with sensible defaults. The Account API is now made to manage a single identity, rather than multiple. This removes the necessity for keeping track of the DID after an identity is created, as developers no longer need to enter the DID into every update function. Because accounts now only manage a single DID, we also allow Strongholds to be shared between Accounts. This prevents users from having to set new passwords for each new identity.

The team has also added support for the X25519 Diffie-Hellman Key Exchange to the framework. This allows two parties to set up a secure communications channel, which is useful for sharing sensitive information such as Verifiable Credentials (VCs). It also enables IOTA Streams to add support for IOTA Identity.

Lastly, the verification of VCs has gained a much more powerful API. Previously, the API only allowed the verification of the signature and only if the signing key was still valid. Now, developers can choose which verification options they find important. They can also decide if they allow expired VCs to pass verification and they can easily build their own custom verification logic on top of the verification API primitives.

JavaScript improvements

Now that the Rust framework has significantly matured and our API is in great shape, we have focused most of our efforts for v0.5 on the JavaScript bindings. Most adoption currently comes from JavaScript developers, so we always aim to make them a top priority. However, JavaScript turned out to provide quite the challenge! We are very pleased to now have feature parity between Rust and JavaScript.

The Account API simplifies things for JavaScript developers. They no longer need to configure a client, generate keys in a separate function, keep track of and set PreviousMessageIds, set timestamps or manually sign and publish an update. This translates mostly into a simplified developer experience where we provide a flexible API with sensible defaults. This allows developers to skip the mundane steps in early development such as choosing an IOTA network, setting a node and permanode and manually publishing all changes. It is still possible to alter all of this behavior, but, by providing sensible defaults, we offer a much easier developer onboarding experience and require fewer concepts to be understood before developers are able to utilize the framework. On top of this, the new API also has much wider Typescript support.

Our biggest challenge lay with adding Stronghold support for JavaScript. We created flexibility in the framework for how the private keys should be generated, stored and used. This “storage API” can be implemented by anyone, allowing them to hook up the framework to their own Key Management System. By default, we offer a Stronghold implementation for Rust and have now added a Stronghold implementation for the Node.js environment. Unfortunately, we can’t guarantee similar security in the web environment, where we now have an in-memory store. The team is researching new browser APIs to offer a more secure solution for the web, but we recommend storing and managing keys in a native environment.

Future releases

The IOTA Identity team has also made drastic improvements to our processes. This may be less shiny and exciting for the community, but it does mean that the team now has a fully automated release process with detailed changelogs. In addition, our automated testing has become faster and more reliable and covers more important cases.

Version 0.5 of IOTA Identity was a major step forwards for the team as the feature parity between JavaScript and Rust makes it much easier to do more frequent updates. Our work on the Identity Actor continues with the integration of the DIDComm specification we have written and we are starting to implement Zero-Knowledge Proofs based on our research with the LINKS Foundation. The upcoming Stardust update also provides plenty of opportunities for the IOTA Identity framework, for example by allowing us to drop permanode as a requirement. We expect to deliver more frequent additive updates with fewer breaking changes, making the development of IOTA Identity more developer-friendly. However, as long as we are pre-1.0, we can’t promise that there will be no further breaking changes.

To make use of the new update, check out our GitHub, which also has detailed changelogs for both Rust and JavaScript. If you are looking for a great opportunity to work with IOTA Identity, don’t miss our Request for Proposals (RFP) on the topic of an IOTA Login, which ends in a couple of weeks. The RFP might help you secure funding for a project (as long as it fulfills the requirements described in the RFP). For any questions about v0.5 or the RFP, join us in the #identity channel on Discord.