Delegate List

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Each party maintains a list of delegates that can help him/her to recover an identity.

Context

Each party has an identity and a corresponding public-private key pair to authenticate transactions by means of digital signatures.

Problem

A private key may be lost or compromised/stolen by a malicious hacker. A compromised private key results in the loss of ownership of the corresponding identifier and its assets. Alternatively, an identifier and its assets cannot be controlled if the private key is lost.

Forces:

• Lost key – Private keys are usually long and hard to remember. Also, many blockchain platforms do not provide a sound mechanism to recover a lost or compromised key. Thus, it results in permanent loss of control over the related identifier and its assets.
• Non-reusability – A compromised identity can be revoked. However, its owner has to spent extra time, money, and energy to re-register a new identifier and rebuild all corresponding relationships. Further, some of the former transaction paties may not be aware that the compromised identity has not been revoked.

Solution

We could leverage the web of trust architecture to resolve this issue. In web of trust, a party trusts a set of other parties. Each of those parties may trust another set of parties. Therefore, both direct and indirect trust could be leverage to establish various forms of trust relationships such as validation or reputation of an identifier. In this context, the identity owner can designate a set of trustees to assist in recovering the identity when necessary.

First, deploy an identifier registry smart contract to keep track of decentralised identifier documents (DDOs). A DDO can contain a tuple consisting of (identifier, owner, {deligate}, updateThreshold). The recovery delegate lists the set of identifiers that are entrusted to recover the lost or compromised identifier. These delegates can be individuals (e.g., family members or friends) or organisations (e.g., banks). The updateThreshold indicates the number of recovery delegates that need to vote/vouch to recover an identifier. Second, record each party’s identifier, delegate list, updateThreshold, etc., on the identity registry.

If a key loss happens, the original identifier owner needs to first create a new identity and the corresponding public-private key pair. It then needs to collect endorsements off-chain from the minimum number of recovery delegates as specified by the updateThreshold. A delegate can vouch that the original owner also owns the new identifier by preparing an endorsement including the new identifier and then signing the endorsement with its private key. The original owner can then submit an update transaction to the identifier registry including the new identifier, list of delegates, and their endorsements. This transaction must be signed with the new private key. When the identifier registry can successfully validate the list of signed delegates, their endorsements, and the number of endorsements matches or exceeds the updateThreshold, it can update the DDO entry to include the new identifier. When there are enough endorsements/confirmations (i.e., reaching the threshold) for the new identifier, the ownership is updated and thus the identity is recovered.

Instead of the original owner collecting endorsements off-chain from recovery delegates, we could also leverage the voting pattern to provides the endorsements on-chain. A time-lock period can be specified to prevent an attacker who tries to compromise an identity owner’s key and immediately change the owner’s identity records, including his/her designated trustees to prevent identifier ownership recovery.

Benefits

• Tolerance to lost key – This pattern can guarantee recovery by maintaining a group of delegates who can confirm a new identifier of the original owner before replacing the lost or compromised identifier.
• Reusability – The ownership of a compromised identity can be recovered and then put into use again, which mitigates the burden of rebuilding another identity and reestablishing relationships.

Drawbacks

• Cost – Recovering an identity requires setting up a delegate list in advance, and sending update requests/votes after the identity is compromised. Each operation sends a transaction to the blockchain.

Related patterns

• Delegates related to a specific identifier are stored in the identifier registry.
• When integrated into the wallet applications using hot and cold wallet storage pattern, predefined delegates can replace key ownership if a key is compromised.
• The key shards pattern presents a way to restore a lost key, while this pattern aims to replace a compromised key with a new one.
• The voting pattern could be used to provides the endorsements on-chain.

Known uses

• In uPort, the user’s mobile device is the only place that stores the private key that controls a uPortID. To avoid the key loss issue caused by loss or theft of the mobile devices, users must nominate a group of delegates who can vote to replace the public key. Once a quorum is achieved by the delegates on the newly proposed public key, the lost public key is replaced with the new public key.
• Sovrin provides a key recovery mechanism that relies on the user selecting a group of delegates. When the user requests the delegates to assist key recovery, a specified quorum of delegates must sign a new identity record transaction that validator nodes must verify.
• Baidu Cloud implemented its self-sovereign identity solution via Quorum, an Ethereum-based DLT. In each user’s DDO, a “recovery” attribute defines a list of public keys to recover the on-chain identity.