📝 Trust registry docs (#1135)

* add mermaid to recommended

* add image_url to actor example

* add TR cred_def flow

* add TR credentials issuance flow

* add Proof request TR flow

* some minor edits

* 🎨

* refine Trust Registry documentation for application flows and interactions

* 🎨 Update docs and reduce charts to 1 for issuer and 1 for verifier

* 🎨

---------

Co-authored-by: ff137 <[email protected]>
Co-authored-by: Mourits de Beer <[email protected]>

.vscode/extensions.json

@@ -1,5 +1,6 @@
 {
   "recommendations": [
+    "bierner.markdown-mermaid",
     "editorconfig.editorconfig",
     "esbenp.prettier-vscode",
     "ms-python.black-formatter",

docs/Trust Registry.md

@@ -30,7 +30,8 @@ retrieved from requesting the endpoint. Their structures are as follows:
       ],
       "did": "did:sov:XfbLjZFxgoznN24LUVxaQH",
       "id": "test-actor-0.26703024264670694",
-      "didcomm_invitation": null
+      "didcomm_invitation": null,
+      "image_url": "https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png"
     },
     ...
 }
@@ -56,3 +57,74 @@ where `"z5Bug71M7Sj7cYpbVBDmN:2:test_schema:0.3"` represents the schema ID, name
 > **_NOTE_**: In a production environment, this should not be exposed to the internet or interacted with directly.
 > It's advisable to either avoid exposing this to the internet or set up a separate security layer for the trust
 > registry. This is because it's crucial to prevent unauthorized individuals from making changes to the trust registry.
+
+## Trust Registry Interactions
+
+Below, we outline where and how the Trust Registry is consulted to verify that Issuers, Verifiers, and Schemas are
+compliant.
+
+### Issuer Actions
+
+When a user/tenant initiates any issuer-related action, the Trust Registry is used to verify the following:
+
+1. Issuer Verification:
+   - For **creating credential definitions**, **creating credential offers**, and **issuing credentials**:
+     Confirms that the tenant is registered with the role of an issuer.
+   - For **accepting credentials**: Confirms that the tenant is receiving a credential from a registered issuer.
+2. Schema Validation: Ensures that the referenced schema is valid and registered within the Trust Registry.
+
+If either step fails, the operation is blocked, and an appropriate error message is returned to the user.
+The operation is logged and able to be reviewed by an administrator.
+
+```mermaid
+---
+title: Trust Registry called during issuer operations
+---
+flowchart LR
+    App(Issuer Action:<br>Credential Operations) -->|Consults| TR[Trust Registry]
+    subgraph Trust Registry Checks
+      TR -->|Validates| Check1{Issuer Verification}
+      Check1 -->|If Unauthorized| Block[⨯ Block Operation]
+      Check1 -->|If Authorized| Check2{Schema Validation}
+      Check2 -->|Not on TR| Block
+    end
+    Check2 -->|If Registered| Continue[✓ Proceed with Operation]
+
+    style TR fill:#a8d1ff,stroke:#1e88e5,color:black
+    style Block fill:#ffcdd2,stroke:#e53935,color:black
+    style Continue fill:#c8e6c9,stroke:#43a047,color:black
+```
+
+---
+
+### Verifier Actions
+
+When a tenant initiates any verifier-related action (sending proof requests or receiving proof presentations),
+the Trust Registry is used to verify the following:
+
+1. Verifier Verification:
+   - For **sending proof requests**: Confirms that the tenant sending the request is registered as a verifier.
+   - For **accepting proof requests**: Validates that the proof is being presented to a registered verifier.
+2. Schema Validation: Ensures that the attributes being requested are associated with schemas registered
+   within the Trust Registry.
+
+If either step fails, the operation is blocked as a bad request, with an appropriate error message returned to the user.
+
+```mermaid
+---
+title: Trust Registry called during proof requests
+---
+flowchart LR
+  Start(Verifier Action:<br>Proof Request Operations) -->|Consult| TR[Trust Registry]
+  subgraph Trust Registry Checks
+    TR -->|Validates| Check1{Verifier Verification}
+    Check1 -->|If Unauthorized| Block[⨯ Block Operation]
+    Check1 -->|If Authorized| Check2{Schema exists on TR}
+    Check2 -->|Not on TR| Block
+  end
+  Check2 -->|If Registered| Continue[✓ Proceed with Operation]
+
+  style TR fill:#a8d1ff,stroke:#1e88e5,color:black
+  style Block fill:#ffcdd2,stroke:#e53935,color:black
+  style Continue fill:#c8e6c9,stroke:#43a047,color:black
+```