Self-Sovereign Assets

9 July 2021

Both industry1,2 and governmental agencies3 are working on infrastructure that handles digital assets. TNO, for example, is involved in multiple projects, such as FEDeRATED and Spark! Living Lab. Real life assets can be managed by managing their respective digital twins. Beside these efforts, work is underway on solutions for digital management of personal identity and credentials, under the banner of self-sovereign identity (SSI). Up to now, digital asset platforms do not support individuals, and SSI does not support assets. Both are needed: A combined solution for digital asset and identity management would enable full coverage of the needs in value chain management. In this post, we identify four paths to integrating digital assets with SSI solutions.

SSI platforms are in general more (publicly) mature and offer privacy/confidentiality-preserving qualities by default. Therefore, we took SSI as a starting point. Can physical assets be represented on SSI platforms and can their digital twins benefit from the sovereign implementations by SSI platforms? In value chains, many identities can interact with the same asset. For example in logistics, one party might load a goods container onto a ship, then another party ships the container to a port, et cetera. At each such interaction, the asset can be enriched with metadata about that interaction. Can metadata of assets be translated to SSI credentials and attributes, for example with a credential issuer being the entity loading a container? We examine this by looking at one of the most popular SSI-platforms: Hyperledger Indy (contributed by the Sovrin foundation).

Implementing assets in Indy

Indy requires two pieces of software to run. The first is the network, connecting nodes to each other and keeping a distributed ledger of identities, attribute schemas and revocation lists. The second is the wallet software, which can be either cloud-based or running as an application on a computer or, more often, a smartphone. We chose VON-Network for our network, as it is convenient to set up. For our wallet software, we picked the cloud-based Aries Cloud Agent-Python wallet. ACA-Py is the most popular open source wallet at the time of writing. We identified a couple of options to implement physical assets as digital twins in the Hyperledger Indy ecosystem. Specifically, we aimed to simulate a digital twin handover, such as a shipping container changing hands at a port. The handover should entail either a transfer of ownership of the container, or at least the recipient should be granted the rights to handling the container. Below, we go over various options for implementing this.

Option 1: Native assets
There is no specification or implementation for assets on Indy/Aries yet. We do not expect native support to become standardized within Indy in the near future, as the community prefers to focus on identity⁴.

Option 2: Multi-client or multi-wallet
One way to achieve our goal would be to give each asset its own identity that can be expressed using SSI technologies. The owner of the asset would provide private keys to the entity that has custody over the asset. This is not a workable option, because it cannot be guaranteed that the previous holder deletes the keys. Alternatively, the owner of the asset could provide the asset with a credential identifying the current holder. This is currently not an option either. No Aries implementations support starting multiple wallets at once with shared computational resources. Ideally, a multi-client or multi-wallet solution would share all resources except private keys and have a shared mapping of credentials to wallets. Without this, it would be near impossible to allocate enough computational resource allocation for all assets that an enterprise handles at a time. To give an impression of the scale that is required, we note that the port of Rotterdam handles 12000 incoming containers daily on average⁵, among other assets.

Option 3: Administrator + forwarding
Implementations to support many identities in custody mode are being implemented. In these models, a ‘router’ acts as a forwarder of messages. This way, wallets can go offline and be spun up only when a message is ready for them. This is a workaround for the lack of multi-client support. Unfortunately, the implementations are not yet finished, and we were unable to get any implementation up and running.

Option 4: Guardianship / custodianship
The concept of having one identity be a guardian over others could provide a good way to avoid sharing private keys, or having to deal with custom credentials that signify the real owner of an asset. Instead, standardized rights and duties could be defined and controlled by SSI assurance communities. Guardianship is a hot topic within the SSI community^6,7, but so far no guardianship schemes have seen implementation.

Conclusion

We consider SSI platforms, specifically Hyperledger Indy, as a good basis for self-sovereign assets. Any of the four options above would be a big step into implementing SSA in practice. Short of native assets implementation, those interested in assets on Indy should keep a close eye on multi-wallet implementations of the Aries (cloud) agents. Short-lived credentials created by the assets themselves could then indicate ownership or a right-to-handle.

Erik de Graaf & Jeroen Breteler (TNO Data Ecosystems)