# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Patterns and Their Classification
\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline \hline
**Design Pattern** & **Summary** \\ \hline Public Institution Registry & A register containing information about public entities such as companies, organisations, and institutions, their accreditations, authorisations, etc. [31]. \\ \hline Trusted Schemas Registry & A registry that contains data schemas (templates) of data objects (DIDs, VCs, semantic context) and allows their reuse [32]. \\ \hline Status Registry & The registry contains information required for the verification of (i) verifiable credentials, or (ii) verifiable presentation validity [33]. \\ \hline DID Registry & A registry for the storage of public DIDs that provides a binding between an entity’s identifier(s), public key(s), and other metadata such as service endpoints, etc. Thus, it serves as a decentralised public-key infrastructure (DPKI) [33]. \\ \hline Identifier-Attribute Registry & A registry that maintains a mapping between an identifier and the location, i.e., the address of identity attributes for off-chain storage (e.g., a name and profile picture of an entity) [2,14]. \\ \hline Blockchain Anchor & A registry for storing evidence in the form of hashed data values. Instead of recording all the data on-chain, only a hashed value of the data is recorded on-chain, which can be used for verifying the authenticity of data stored outside the blockchain [2,14]. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: SSI design patterns, classified into the Trusted Registries category. Category _Verifiable Credentials and Presentations_ (Table 3) includes patterns that support data exchange through the VC data format. Patterns (3.1) _Verifiable ID (V-ID)_, (3.2) _Verifiable Attestation (VA)_, (3.3) _Verifiable Mandate (VM)_, (3.4) _Verifiable Accreditation (VAcc)_, and (3.5) _Verifiable Authorisation (VAuth)_ support different scenarios and use cases. Although they are all technically the same VC generic data format they provide an important distinction, as different scenarios have various purposes and (functional/legal) requirements regarding the level of assurance (LoA), which has implications for the credential issuance process and the attributes contained, etc. Each of the data formats thus has its complex issuance and verification requirements in technical, as well as organisational/management, terms. (3.1) A _V-ID_ should be used for identification and authentication purposes, e.g., a natural person receives a signed VC of type V-ID from his/her administrative unit, which acts as a digital ID card, holding the minimally required information for an ID card, defined through a specific schema ((1.2) _Trusted Schemas Registry_). It should be noted that, due to various regulations and legislations, different administrative units can have different templates, and, thus, schemas for the same generalised ID card. Additionally, V-IDs are not only bound to formal documents, but can also be applied to less formal or informal ones, e.g., student cards, library cards, etc. (3.2) A _VA_ should be used for proving certain attributes/properties and permits/attestation/authorisation to access services. Examples of such attestations are, again, more formal documents such as diplomas or driving licences, proving the holder has finished some form of education or has gained some knowledge and thus has gained some rights, such as applying to a specific job posting or driving a car. However, the attestations can also be less formal or informal, such as proof of attending an event, proof of achieving first place at a sports competition, etc. As with the V-ID, each of the aforementioned scenarios or use cases for VA could have its own schema defined (i.e., not mandatory). (3.3) A _VM_ should be used for transferring authority and/or access from one entity to another. An example of such a mandate is indirect identity controls, such as those of delegation, as well as guardianship and/or controllership. Each of these use cases has its own complexity and rules.