# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Example of a Verifiable Mandate Pattern  
As mentioned in the previous section, the result of the research is a documentation of 35 design patterns defined using the Alexander template, whereby an example of (3.3) the _Verifiable Mandate_ pattern is given below. The pattern addresses indirect identity control. Precisely, it provides a solution for delegation use cases where there are not just one, but multiple identity holders that delegate tasks/permissions from one to another, as presented in Figure 5. The remaining patterns have been defined in the same way, and are available at [30]. \begin{table}
\begin{tabular}{p{142.3 pt} p{284.5 pt}} \hline \hline
**Design Pattern** & **Summary** \\ \hline Hot and Cold & Each entity can store keys in two wallets. It stores frequently used keys in a hot wallet with an internet connection and rarely used keys in a cold wallet without an internet connection [2; 14]. \\ \hline Local (Private) & Local (off-chain) storage of identifiers, keys, verifiable credentials, and other personal data that can be accessed only by an identity holder or wallet controller [62; 63]. \\ \hline External/Remote (Cloud) Storage & External (off-chain) cloud storage for storing identifiers, keys, verifiable credentials, and other personal data [62]. \\ \hline \hline \end{tabular}
\end{table} 
Table 6: SSI design patterns, classified into the Wallet and Off-Chain Storage category. Figure 5: The Verifiable Mandate pattern enables delegating tasks and transferring permissions from one identity holder to another. **Name: Verifiable Mandate (VM)**  
**Summary: Use a verifiable mandate (VM) as evidence/proof that an entity (delegate) can act on behalf of another entity (delegator). **  
**Problem**  
1. Verifiable credentials represent credentials with or without a physical equivalent, and can contain various information supporting various use cases. Hence, different scenarios/use cases have distinct purposes and (functional/legal) requirements regarding the level of assurance, attributes contained, etc. 2. There are cases where an entity (delegate) has to act on behalf of another entity (delegator) in order to achieve a particular goal. Therefore, the delegate must be able to prove that he/she has the required permissions, and can act in a particular situation on behalf of the delegator. Such situations require consideration of permissions and constraints that must be integrated into credentials. 3. Credentials must address constraints to prevent overuse and abuse of delegation by a delegate. **Context**  
In some cases, authority and/or access need to be transferred from one entity to another, which is especially evident in the work environment with superior-subordinate relationships. Superiors usually delegate tasks to subordinates, who are responsible for carrying out the tasks on their behalf. **Forces**  
1. Flexibility: Identity holders (delegators) can transfer part of their tasks to other entities (delegates). After obtaining the VM, delegates can act on behalf of the delegator, which allows flexibility and supports various scenarios. 2. Control: Holders can obtain greater control in digital interactions. 3. Security: There are some risks associated with determining constraints to prevent the overuse and abuse of delegated rights. 4. Privacy: The VM should contain the minimum amount of data necessary for delegates to carry out tasks on behalf of delegators. **Solutions**  
A special type of VC, a verifiable mandate (VM), can be used for the delegation of authority and access. The VM should contain claims that may serve as evidence of permission/authorisation transfer from one entity to another. Therefore, such a credential allows an entity (VM holder) to act on behalf of another entity (the VM issuer). The VM should be built on existing standards, namely, the W3C Verifiable Credentials Data Model and date time format. Therefore, the VM data model is a VC, with additional properties that depend on the use case and are contained within the _credentialSubject_ object.