# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Patterns and Their Classification
Identity and other identity attributes are a dynamic concept, so some of the information in the issued credentials may change; there may be errors in the issuance of the credential, devices, or private key(s) may be lost, or the credential may be misused. Thus,  
Figure 4: Life-cycle of three main SSI objects (VCs, DIDs, and keys) and patterns connected to their states or transitions, built on the work of [PERSON] et al. [2,14]. issues must be able to revoke or suspend credentials, while verifiers must have the means to check the validity of presented credentials without contacting the issuers. (1.4) The _DID Registry or Identifier Registry_ pattern serves as a decentralised public-key infrastructure (DPKI), and provides a binding between the entity's identifier(s) and associated public key(s), service endpoint, and other metadata. It is essential for providing a means for discovery, identification, and authentication, and provides trust and integrity. To ensure compliance with the GDPR and prevent disclosure of identity, the Registry should not contain any personally identifiable information of a natural person, since, in the majority of cases, decentralised storage or ledgers will be used for the registries. (1.5) The _Identifier-Attribute Registry_ maintains mappings between an identifier and the correlated data or its location (off-chain storage URI). The identity data of a natural person should never be stored on-chain due to privacy and security reasons. On the other hand, there may be limitations to the storage capacity of blockchain. Thus, data can be stored off-chain on decentralised file systems such as IPFS, Ceramic Network, etc., and referenced on-chain [14]. (1.6) The _Blockchain Anchor_ pattern can be used to preserve the integrity of off-chain stored data and maintain the entity's privacy. Instead of storing everything on-chain, only hashed values of off-chain data can be anchored on the blockchain. The pattern solves problems related to blockchain storage capacity limitations and GDPR implications, as personally identifiable information should never be stored on-chain and takes into account transaction fees [14]. The _Onboarding_ category (Table 2) includes two patterns, (2.1) _Onboarding or DID Registration_, and (2.2) _Linking onboarding with credential issuance_, to interact with other entities within decentralised identity ecosystem and identity management frameworks such as those of EBSI, which is also utilising its own permissioned ledger, where a public entity must first (2.1) _onboard/register_ through an onboarding service to obtain writing and updating permissions, and store at least one DID and correlated public key on the DID Registry. However, _onboarding_ should be linked with VC issuance, as it requires identification, and regulations demand sufficient justification when requesting and processing personal data. The mere reason for identification is not sufficient. On the other hand, _linking VC issuance with the DID registration_ process provides an adequate justification. Moreover, entities usually do not have a profound interest in merely registering DIDs, but have an interest in collecting their data (VCs), building a digital identity and acquiring access to the services. Therefore, isolated DID registration is unreasonable.