IOTA Identity 1.0 is Here

Explore IOTA Identity 1.0 on IOTA and Shimmer Now

TL;DR:

IOTA Identity 1.0 provides a stable SSI implementation for Stardust-enabled networks. allowing easy integration for existing and new apps that want to maximize digital autonomy and privacy for users.

Last September, when the Stardust protocol upgrade and its tokenization framework were introduced to our staging network, Shimmer, we leveraged these advancements to enhance IOTA Identity – our decentralized identity tool. Following its launch on Shimmer, the next iteration of IOTA Identity underwent thorough testing and refinement. Now, with the successful integration of the Stardust upgrade on IOTA, we’re excited to introduce IOTA Identity 1.0 with its enhanced capabilities to the broader IOTA network.

First introduced in 2018, IOTA Identity is a decentralized identity (DID) method, identified as did:iota, along with an associated library. These components leverage the unique attributes of the IOTA ledger, facilitating the seamless integration of digital identities into both new and existing applications. While this post provides a summary of information released alongside the debut of IOTA Identity 1.0 on Shimmer (see the blog post here), it also highlights the latest enhancements based on our insights into Identity since September of last year.

The technical revamp

To align IOTA Identity with the Stardust version of the protocol, we have completely rethought how identities should be created, updated, and resolved. Leveraging the Stardust ledger’s capabilities, we’ve adapted Alias Outputs to represent identities, enabling interactions with other Layer 1 entities such as fungible and non-fungible tokens (NFTs).

On a technical level, DID documents are now stored in the state metadata field of Alias Outputs, making them accessible for resolution across all nodes. This approach utilizes Layer 1 access control mechanisms for ownership and permissions management.

Alias Outputs provide four capabilities for hosting identities:

• Globally Unique Identifier: Alias IDs can’t be changed after creation, aligning perfectly with the immutable nature of DID identifiers. The DID contains the Alias ID, allowing seamless conversion between the two. A simple example: The last part of the DID (the method-specific identifier) corresponds to the ID of the Alias Output (did:iota:0x0a6cf67b1faff3c4c9097ce91d84b1df490917b39a64a5b6ef30476ce4c528d3).
• Data Storage: Outputs can store arbitrary data, such as DID documents, in their state metadata.
• Controller Management: Only the state controller can modify the Alias Output, effectively becoming the DID controller, and aligning with DID terminology.
• Extended Capabilities: A DID within an Alias Output inherits all the capabilities of that output, including token transactions and native asset minting. We explore these use cases in more detail below.

We’ve also implemented an on-chain revocation mechanism that can be embedded in the issuing party’s identity. This guarantees high availability during credential verification and simplifies processes by re-using the same access control mechanisms issuers use to update their identities.

Unlocking new possibilities

Representing identities via Alias Outputs on Layer 1 opens up exciting interactions with other Layer 1 entities, leading to innovative use cases. For each interaction, we’ve provided examples in the library, available here:

• JavaScript/TypeScript: https://github.com/iotaledger/identity.rs/tree/main/bindings/wasm/examples
• Rust: https://github.com/iotaledger/identity.rs/tree/main/examples

Identities controlling identities

Alias Outputs can control other Alias Outputs, enabling one identity to govern another. This enables us to create hierarchies of identities and model situations like company subsidiaries or human custodians. In this context, control is divided between two parties: the governor and the state controller. The governor decides who can make updates to an identity by assigning a state controller, while the state controller determines how the identity is represented by making changes to the DID document.

For example, imagine a smartphone manufacturer called Phonemkr and its subsidiaries: Phoneshop, where people can buy phones, and Phoneshippr, which ships the phones. Phoneshop manages the identity of Phoneshippr, but the manufacturer (Phonemkr) wants ultimate control over both.

This is achieved by setting the address of an identity’s Alias Output as the state controller or governor unlock condition of another identity. Today, the Alias Output can only have a single state controller, but we intend to allow multiple controllers with future protocol updates. So in our example, multiple controllers would allow both Phonemkr and Phoneshop to make updates to the identity, providing more flexibility.

Authenticating transactions

Identities can receive, hold, and send tokens. This enables the sender and receiver of funds to be identified, providing stronger assurances to everyone involved.

Because an Alias Output can hold tokens, any DID can be converted into an address. For instance, if Alice exchanges DIDs with Bob and wants to send him funds, Bob authenticates his DID to Alice. When Alice sends funds to Bob’s Alias Output address, she can be confident that whoever controls Bob’s identity – typically Bob himself – will access the funds.

Conversely, if someone receives funds from an Alias Output containing a DID, they can authenticate the origin of the funds, potentially supporting anti-money laundering efforts. Observers can track fund movements, making it advisable to use different identities for various use cases instead of a single identity for all interactions.

An Alias Output’s address can serve as the Unlock Condition of any output, allowing the Alias Output to control the Basic Output and its funds. Funds are transferred by creating a Basic Output controlled by the receiver’s Alias Output. This setup provides a permanent identifier to receive funds while adhering to security best practices like key rotation, enabling the transfer of funds to DIDs on Layer 1.

DIDs issuing NFTs

With the Stardust protocol upgrade, NFTs can now be minted and transferred on Layer 1 through dedicated NFT Outputs, and DIDs can help prove the identity of the NFT’s issuer.

For example, Phonemkr wants to issue digital product passports in the form of NFTs for each phone it sells. Phonemkr creates its identity in an Alias Output and provably links its DID to its website, phonemkr.com. If Phonemkr issues NFTs with its identity as the issuer, it proves that phonemkr.com issued those NFTs.

Similar to fund transfers, NFTs can be owned by and transferred to DIDs, since the Unlock Condition of an NFT Output can be an Alias Output representing a DID, providing assurances about whom you receive NFTs from or send NFTs to.

Furthermore, NFTs can unlock (read “own”) identities. This could greatly benefit entities or organizations represented and traded through NFTs (though isn’t generally recommended for humans). This allows the transfer of ownership of an entity or organization and its corresponding identity in a single atomic interaction.

DIDs issuing native tokens

When a DID serves as the minter of native tokens, it provides greater assurances and trust to token holders. With this information, token holders can verify the origin of native tokens and validate claims made by the asset issuer.

This is made possible because native tokens are created through a Foundry Output controlled by a single Alias Output. Embedding an Identity into this Alias Output enables the identity of the minter to be resolved.

Authenticating smart contracts chains

The Stardust protocol upgrade will enable the state of IOTA Smart Contract (ISC) chains to be anchored into Alias Outputs in the ledger. With IOTA Identity, smart contract chains can be provably linked to identities.

As mentioned earlier, identities can be organized hierarchically, enabling a single identity to create and control multiple Alias Outputs. This means an identity within an Alias Output can govern the Alias Output of an ISC chain. This lets users identify the governor of a chain and helps them decide whether they want to trust and interact with the chain. It also lets external observers verify and prove who has ultimate control of the chain.

JSON Web Token

As the SSI ecosystem converges on common standards and formats, we strive to choose the most capable and interoperable technologies. Following that reasoning, we’ve transitioned to the JSON Web Token (JWT) encoding for credentials and presentations. This aligns with the latest proposals and recommendations from regulatory projects in the EU. Credentials and presentations are now embedded in JWTs (a widely used format for exchanging attributes and permissions) and need to be stored and transmitted in this format.

We’ve built the library in such a way that alternative credentials formats, like the very promising Data Integrity Draft, can be implemented alongside the current format moving forward.

Key Storage Enhancements

We reworked the storage interface to enable implementers to develop their own solutions for storing sensitive key material. For advanced requirements, the new interface should make it significantly easier to adapt the library to existing key management solutions that offer the highest level of security and durability. To achieve the necessary flexibility, we’ve divided the interface into two parts: one handles key storage and operations, while the other handles library-specific state.

As before, we ship a default implementation of the interface using Stronghold for Rust, allowing implementers to work quickly and securely. The default implementation allows implementers to manage keys, used for access to the ledger, and identities to be stored (and backed up) in the same Stronghold snapshot file, improving the ergonomics of key management.

Domain Verification

A significant new feature in 1.0 is Domain Name Verification, a process that verifiably links a domain to an identity. The link can be discovered either by starting from the domain or the identity.

An example of starting from the identity is verifying the minter of an NFT. By inspecting an IOTA Layer 1 NFT, you can discover which Alias Output minted it. In turn, the Alias Output can contain an identity that can be linked to a domain. By resolving the domain, a verifier can confirm the cryptographic link and have confidence that the entity that controls the domain also issued the NFT, thereby confirming the authenticity of the NFT.

Conversely, an example starting from the domain is when you discover identities linked to a homepage and establish a Web3 connection to an endpoint referenced in the linked identity. Through this link, you can start from a trusted homepage and discover linked corporate identities for future on- and off-chain interactions.

It’s important to note that information published on-chain must be carefully evaluated to fulfill individual needs for anonymity and compliance with data privacy laws. While corporations may choose to link their homepage to their digital identity, individuals may prefer not to create such links to their personal homepage.

To maximize interoperability, our implementation follows a proposal developed by the Decentralized Identity Foundation (DIF). The proposal makes the link from an identity to a homepage optional, allowing identities to decide how discoverable they want the linkage to be. To establish a link, the domain owner needs to upload a credential signed by the linked identity to their domain. Both the domain and the identity can contain multiple links, creating a web of trusted relationships between multiple domains (e.g. membership in professional and non-profit organizations, hobbies, fan clubs, etc.) and identities.

In conclusion: the future of digital ID

IOTA Identity 1.0 lays the foundation for ambitious identity solutions for individuals, organizations, and objects. Leveraging the scalability of the IOTA Tangle and the versatility of the Stardust ledger, we’ve created a unique ecosystem for both on- and off-chain interactions between cryptographic and self-sovereign identity elements.

Links in this article

• Alias Outputs interaction on Layer 1: JavaScript/TypeScript example
• Alias Outputs interaction on Layer 1: Rust example
• IOTA Wiki article: Smart Contract Chain Support
• WC3 Working Draft: Verifiable Credential Data Integrity 1.0
• Decentralized Identity Foundation proposal