# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 4 Discussion  
This study resulted in an SSI design patterns' collection, grouping 35 patterns into six representative categories that enable a better understanding of patterns and their relation to each other. The patterns were grouped into (1) _Trusted Registries_, (2) _Orbarding_, (3) _Verifiable Credentials and Presentations_, (4) _Decentralised Identifiers and Cryptographic Keys_, (5) _Qualified Electronic Certificates_, and (6) _Wallet and Off-Chain Storage_ categories, as presented below.  
1. _Trusted Registries_ 1.1 Public Institution Registry 1.2 Trusted Schemas Registry 1.3 Status Registry 1.4 DID Registry or Identifier Registry 1.5 Identifier-Attribute Registry 1.6 Blockchain Anchor
2. _Onboarding_ 2.1 Onboarding or DID Registration 2.2 Linking onboarding with VC issuance
Patterns are related to the state transitions in lifecycles of the main SSI objects, namely, decentralised identifiers (DIDs), cryptographic keys, and verifiable credentials (VCs). In addition, they are also interconnected with patterns from the same or distinct categories. Figures 6 and 7 show the relationships between patterns, where patterns from the same category are represented by the same colour, and the grey lines illustrate their interconnections. While Figure 6 depicts the broader angle of pattern connection, Figure 7 focuses on patterns from the Verifiable Credential category.  
Each pattern is related in some way to patterns from the same category, whereby a pattern may either be (i) equivalent, or used (ii) in combination with another pattern within the category. For example, (i) 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)_ are equivalents that can be used independently of one another, each supporting a different use case with distinct issuance and verification requirements in technical and organisational terms. (ii) On the other hand, the remaining patterns in the category ((3.6) _Selective Content Generation_, (3.7) _Selective Content Disclosure_, (3.8) _Time-Constrained Access_, (3.9) _One-Off Access_, (3.10) _Expiration Time_ and (3.11) _Effective Time_) can provide flexibility and control over identity data, and can be seen as an extension of patterns 3.1-3.5. Thus, they can be used in combination with different types of VCs. Alternatively, patterns are also related to patterns in other categories. For example, VC schemas are stored in the (1.3) _Trusted Schemas Registry_, whereby the VC contains a reference to the registry. Similarly, the VC can reference the (1.3) _Status Registry_, containing information about the VC's validity. It can serve as a trust anchor that allows verifiers to check whether the respective VC is still valid, or has been revoked or suspended. Moreover, a hashed VC, or evidence of a VC's issuance/reception/sharing, can be anchored on the VDR as proof/evidence (1.6 _Blockchain Anchor_). Furthermore, to enlist the legal value of a VC, (i) the VC can be signed with a qualified electronic signature (QEC) instead of cryptographic keys correlated to the entities' DID (5.1 _Qualified Verifiable Credentials_), or (ii) the VC can be linked with QEC (5.2 _Binding VCs and QEC_).