# Towards a Catalogue of Self-Sovereign Identity Design Patterns
## 3 Self-Sovereign Identity Design Patterns and Their Classification
### Example of a Verifiable Mandate Pattern
However, they must include a _holder_ property that describes a subject called holder (delegate) and includes (i) a _role_ property that defines the role(s) the holder plays in the permission scheme of the delegator;  
(ii) _permissions_, i.e., actions or grants that can be performed by the VM holder;  
(iii) _constraints_ that limit the scope of the delegated authority. Constraints may include properties such as _startTime_, _endTime_, _location_, _boundaries_, _circumstances_, _pointOfOrigin_, _and radiusKm_[64]; (iv) _PolicySchemaURI_ with reference to the policy validation script that can be registered on the verifiable data registry (in trusted policy registry) and contains available roles, permissions, and constraints. Moreover, it should be accompanied by the credentials required for carrying out the delegated task(s), either in the VM itself or separately. **Example**  
Listing 1 presents an example of an issued credential (JSON) utilising the verifiable mandate that was issued by delegator (VM issuer) _did:ebsi:ztZgP4 NGDZgo GRqHpaxQkfX_ to delegate (VM holder), _did:key:z6 MxUthikikPAdwzs18 AExS4 GFr6t40 vy HFRrLEdpRScZDd_[43]. By obtaining the aforementioned VM, the delegate is entitled to enrol a delegate to a Master's degree in Slovenia, whereby the application has the same degree of validity as if the delegate had performed the process by himself/herself. **Resulting Context**  
1. Indirect identity control use cases (i.e., delegation processes) can be supported. 2. Entities (delegators) can delegate (part of) their work/responsibilities to other entities (delegates), who can act on the delegator's behalf with the same level of validity while remaining in full control of their identity (identifiers and keys). 3. An entity (delegator) who delegates (part of) work/responsibilities to another entity (delegate) is in charge of defining the roles, permissions, and constraints that limit the delegate from exceeding his/her authority. Therefore, the VM provides flexibility and even more control to identity holders, as it supports complex use-cases that cannot be supported by utilising a general VC. 4. The VM can be used as proof that an entity (VM holder) can act on behalf of another entity (VM issuer). Thus, during the identification/authentication phase, an entity can also present a VM showing that he/she can act on behalf of another entity within the corresponding limitations. **Related Patterns**  
1. The Trusted Schema Registry: VM schema can be defined, stored and maintained in the TSR by entities (verifiers) who support delegation scenarios. 3. Blockchain Anchor: VM issuance can be anchored on the BC (as proof) to preserve the integrity of the data. 4. Status Registry: The VM can contain a reference to a status registry, allowing delegators to suspend or revoke the validity of VMs. 5. Verifiable ID and Verifiable Attestation: The VM is complementary to V-ID and VA, and is usually presented together with a V-ID and/or VA.  
6. Patterns connected to the Verifiable Credentials category: A VM pattern can be utilised together with Time-Constrained Access, One-Off Access, Expiration Time and Validity Time patterns that enhance the flexibility of the pattern. **Known use**  
The Hyperledger Aries RFC 0103 proposed a technical solution, including proxy credentials for supporting various indirect control use cases, such as delegation, guardianship, and controllership [64; 65; 66]. The proposed solution is currently under investigation for implementation into various pilots and proofs of concept, e.g., [67]. The EBSI ESSIF specified three distinct types of VCs aligned with the W3C VC Standard [45; 68], including the VM, which was also addressed in the project collaboration by Netis, Walt.id, and the Faculty of Electrical Engineering and Computer Science of the University of Maribor [43].