# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Patterns and Their Classification
The category _Decentralised Identifiers and Cryptographic Key_ (Table 4) includes patterns (4.1) _Multiple Registration_, (4.2) _Blockchain and Social Media Account Pair_, (4.3) _Public DIDs or Anywise DIDs_, (4.4) _Pairwise DIDs_ (_and N-wise DIDs_), (4.5) _Static DIDs_, (4.6) _Dual Resolution or DID Resolution_, (4.7) _Delegate List_, (4.8) _DID Controller_, (4.9) _Master and Sub-Key Generation_, \begin{table}
\begin{tabular}{p{142.3 pt} p{284.5 pt}} \hline \hline
**Design Pattern** & **Summary** \\ \hline Verifiable ID & Use verifiable ID (VI-D) as evidence/proof of an entity’s identity for identification and authentication purposes [36; 37; 38]. \\ \hline Verifiable & Use verifiable attestation (VA) as evidence/proof of specific identity attributes or compliance with certain conditions for nonidentification and non-verification-related scenarios [8; 39; 40; 41; 42]. \\ \hline Verifiable & Use a verifiable mandate (VM) as evidence/proof that an entity (delegate) can act on behalf of another entity (delegator) [43; 44; 45]. \\ \hline Verifiable & Use verifiable accreditation (VAcc) as evidence/proof to demonstrate the appropriate/required accreditations of legal entities to perform particular tasks, such as issuance of certain types of credentials [46; 47; 48; 49; 50; 51]. \\ \hline Verifiable & Use verifiable authorisation (VAuth) to authorise entities to interact with permissioned ledgers and access resources/services [52]. \\ \hline Selective Content & Creating a customised credential according to the identity holder’s specific requirements for credential attributes/contents (interaction between the issuer and the identity holder) [2; 14]. \\ \hline Selective Content & Creating a customised presentation according to the verifier-specific requirements for credential attributes/contents (interaction between the identity holder and the verifier) [2; 14; 53]. \\ \hline Time- & Generate and forward a time-limited credential link to allow the verifier access only within the specified time window [2; 14]. \\ \hline One-Off Access & Generate and forward a time-limited credential link to allow the verifier to access it only once [2; 14]. \\ \hline Expiration Time & Include information that restricts the time of the credential validity/usage [8; 54]. \\ \hline Effective Time & Differentiate between the issuance date and the date when the credential becomes valid [39; 54]. \\ \hline \hline \end{tabular}
\end{table} 
Table 3: SSI design patterns, classified into the Verifiable Credentials and Presentations category. and (4.10) _Key Shards_ patterns, dealing mainly with solving problems connected to identification, authentication, and management of DIDs, DID documents, and cryptographic keys. (4.1) The _Multiple Registrations_ pattern enables entities to create and register multiple unique identifiers and correlated cryptographic keys, separate for every relationship they have. Each identifier can be used in different interactions (relationships) to preserve privacy, minimise the possibility of correlation and increase security [14]. (4.2) The _Blockchain and Social Media Account Pair_ provides a solution for establishing a bidirectional binding between social media accounts and a decentralised identity, which can enhance the trustworthiness of social media accounts and allows for building a digital reputation [14]. (4.3) _Public DIDs or Anywise DIDs_, (4.4) _Pairwise DIDs (and N-wise DIDs)_, and (4.5) _Static DIDs_ allow entities to identify and authenticate. Each pattern supports different types of relationships and their requirements, as some identifiers and interactions should remain private, while others require public availability. Therefore, (4.3) _Public DIDs_ (e.g., did:ebsi for legal entities, did:ehr, did:sov) should be utilised when DIDs need to be available publicly and resolvable by anyone.