# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Patterns and Their Classification
(4.4) _Pairwise DIDs_ (e.g., did:peer) should be used for peer-to-peer, private interactions between a small number of entities, and (4.5) _Static DIDs_ (e.g., did:key) should be used for single, ephemeral interactions that do not require updating and deactivating DID documents, (4.3) require anchoring DIDs on the VDR, a shared registry that provides a public source of truth and allows arbitrary entities to resolve DIDs to an endpoint and keys. On the other hand, (4.4) and (4.5) are entirely off-chain. Regardless of the type of identifier, \begin{table}
\begin{tabular}{p{142.3 pt} p{284.5 pt}} \hline \hline
**Design Pattern** & **Summary** \\ \hline Multiple Registration & Each entity can create (and register) an unlimited number of unique identifiers (DIDs) and corresponding cryptographic keys for each relationship (i.e., every identity) it has [2,14]. \\ \hline Blockchain and Social Media Account Pair & Establishing a bidirectional link between a social media profile and a blockchain-based identity can increase trust in social networks and the identifier stored on the blockchain [2,14]. \\ \hline Public DIDs or Anywise DIDs & Utilise anywise, public DIDs that require the use of a verifiable data registry (for the execution of CRUD operations) when identifiers need to be available and resolvable by anyone/strangers publicly [7,16,55,56]. \\ \hline Pairwise DIDs (and N-wise DIDs) & Utilise pairwise (and N-wise) private DIDs in personal, confidential interactions between a small number of entities. Such DIDs do not require anchoring to a verifiable data registry, as they are exchanged peer-to-peer [7,57]. \\ \hline Static DIDs & Utilise static DIDs for single, ephemeral interactions that do not require updating and deactivating DID documents [55,56,57,58]. \\ \hline Dual Resolution or DID Resolution & Entities engaged in a mutual interaction have to acquire each other’s DID and resolve it to DID documents to access the information necessary for authentication (e.g., public key) and communication (e.g., service endpoints for provided services) [2,14]. \\ \hline Delegate List & Each entity can maintain a list of delegates or proxies in the DID document who can update a DID document and help recover the identifier in case of lost or compromised keys [2,14]. \\ \hline DID Controller & Entities can designate one or multiple DID controllers (in the DID document) who can control the DID and modify the DID document [7]. \\ \hline Master and Sub Key Generation & Each entity has a master key for managing a set of sub-keys used to sign transactions for different purposes or identity accounts (verification relationships) [2,14]. \\ \hline Key Shards & Entities can split cryptographic keys into several different pieces and recover them with a sufficient number of parts [2,14]. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: SSI design patterns, classified into the Decentralised Identifiers and Cryptographic Keys category. entities have to identify and verify each other before engaging in mutual interaction and exchanging information. (4.6) _Dual Resolution or DID Resolution_ allows them to obtain DIDs and resolve them to DID documents to access the information necessary for authentication (e.g., a public key) and communication purposes (e.g., service endpoints). Each DID is managed by a private key, which is used to prove ownership of the identifier. If the key is lost, stolen, or compromised, patterns (4.7) _Delegate List_ and (4.10) _Key Shards_ can be used to retrieve ownership. Both patterns provide approaches for solving problems related to identity recovery, which is crucial for maintaining ownership and control over identifiers, related identity data, and assets in decentralised settings. The _Delegate List_ allows the identity holder to determine a list of delegates who can help to recover his/her identity if private keys are lost or compromised. The identifier and their keys can be replaced and updated in a DID document after a sufficient number of trustees/delegates vouch for the DID owner.