feat: add issuance diagram in docs

docs/guides/6_components/keypairoom.md → docs/guides/6_components/generate_keys_keypairoom.md

@@ -1,4 +1,4 @@
-# Keypairoom: (re)generate your secret keys
+# Keypairoom: (re)generate your Secret Keys 
 
 Keypairoom is component to **generate and regenerate a keyring**, containing multiple secret keys (along with the correspondet public keys) in a **deterministic and private way**. 
 

docs/guides/6_components/index.md

@@ -1,10 +1,23 @@
 # 📑 Concepts/Components
 
-**Issuance flow**: TBW
 
-**[Verification flow](./verification.md)**
+## Issuance and Verification Flows 
 
-**Templates**: TBW
+The flows contain the **general setup for the Issuance and Verification**, with focus on the parameters for a specific credential, such as name, description, logo, microservices issueing/verifying those. **The business logic and data structures** for the Issuance and Verification are **contained in templates**, which can be **selected inside the Issuance and Verification Flows**. The complexity within the protocols and cryptography and hidden behind the DIDroom Control room, the specs are in the pages [Issuance flow](./issuance.md) and [Verification flow](./verification.md). 
+
+
+
+## Templates
+
+they contain the business logic of *authorization*, *issuance* and *verification* flows along with the data structures used in the flows. An issuance flow contains two templates: 
+  - The Authorization template (governs the business logic of the Authorization Server)
+  - The Issuance template (governs the business logic of the Credential Issuance)
+
+The idea behind this separation, is **to allow the user mix and re-use templates in multiple credential issuance flows**.
+
+The same template can be used in multiple flows, for example for a credential that has 3 different expiries (1 month, 6 months and 12 month). Or for example two Issuance Flows can use the same Authorization template (cause the Authorization process is the same for both) but two different issuance template (cause the Credential Issuer will need to write different data in the two credentials).
+
+---------
 
 **Decentralized Identifier (DID)**: A globally unique, self-sovereign identifier that enables individuals and entities to have control over their digital identities without relying on centralized authorities.
 

docs/guides/6_components/issuance.md

@@ -0,0 +1,53 @@
+# Issuance flow
+
+The Issuance Flow is compatible with the [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) specification
+
+
+## Basics
+
+The *DIDroom4VP* flow involves these main components: 
+- **Wallet**: [DIDroom Wallet](https://github.com/ForkbombEu/wallet)
+- **(Credential )Issuer**: a microservices contained in [DIDroom Microservices](https://github.com/ForkbombEu/DIDroom_microservices)
+- **Authorization Server**: a microservices contained in [DIDroom Microservices](https://github.com/ForkbombEu/DIDroom_microservices)
+
+We worked on separating the deployment of the **Authorization Server** and the **Credential Issuer**, which can optionally be deployed on the same server but consist of two indpependent microservices.
+
+## Diagram: Issuance Flow
+
+
+
+@startuml
+!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
+
+actor Holder
+participant Wallet
+participant Issuer
+participant AuthorizationServer
+
+
+Issuer -> Holder : Step 1: Send Credential Offer with information and endpoints
+Holder -> Wallet : Step 2: Scan Credential Offer or start issuance flow
+
+
+Wallet -> Issuer : Step 3: Retrieve .well-known configuration file of the Issuer
+Issuer -> Wallet : Step 3: Provide .well-known file with Authorization Server URL
+
+
+
+Wallet -> AuthorizationServer : Step 4: Authorization Request with requested credentials
+AuthorizationServer -> AuthorizationServer : Step 5: Authenticate Holder and request consent
+AuthorizationServer -> Wallet : Step 6: Authorization Code
+Wallet -> AuthorizationServer : Step 7: Token Request with Authorization Code
+AuthorizationServer -> Wallet : Step 8: Access Token
+
+
+Wallet -> Issuer : Step 9: Credential Request with Access Token and required data
+Issuer -> Issuer : Step 10: Process Credential Request
+Issuer -> Wallet : Step 11: Issue Verifiable Credential
+Wallet -> Holder : Step 12: Store Verifiable Credential in Wallet
+@enduml
+
+
+
+----------
+