simplification (doc)
This commit is contained in:
parent
fcc8d0db15
commit
664e50775f
@ -179,7 +179,7 @@ Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de
|
|||||||
|
|
||||||
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList`.
|
||||||
|
|
||||||
### 7.2. <a name='Rception-1'></a>Réception
|
### 7.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -206,7 +206,7 @@ Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi d
|
|||||||
|
|
||||||
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la`transaction SP` via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage`.
|
||||||
|
|
||||||
### 8.2. <a name='Rception-1'></a>Réception
|
### 8.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -232,7 +232,7 @@ Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_versi
|
|||||||
|
|
||||||
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate`.
|
||||||
|
|
||||||
### 9.2. <a name='Rception-1'></a>Réception
|
### 9.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -244,11 +244,9 @@ Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdRespon
|
|||||||
|
|
||||||
`code_confirm_enc_by_shared_secret`: Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas un output spécifique chiffré par la clé `KeyConfidential` précise ce code, à confirmer dans le RequestPrdConfirm.
|
`code_confirm_enc_by_shared_secret`: Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas un output spécifique chiffré par la clé `KeyConfidential` précise ce code, à confirmer dans le RequestPrdConfirm.
|
||||||
|
|
||||||
Crucial pour les processus qui nécessitent une confirmation explicite de réception ou d'acceptation, comme la finalisation d'une transaction ou la validation d'un changement d'état dans un contrat.
|
|
||||||
|
|
||||||
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm`.
|
||||||
|
|
||||||
### 10.2. <a name='Rception-1'></a>Réception
|
### 10.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -264,7 +262,7 @@ Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, pui
|
|||||||
|
|
||||||
### 11.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 11.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse`.
|
||||||
|
|
||||||
### 11.2. <a name='Rception-1'></a>Réception
|
### 11.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -274,7 +272,7 @@ Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards as
|
|||||||
|
|
||||||
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse`.
|
||||||
|
|
||||||
### 12.2. <a name='Rception-1'></a>Réception
|
### 12.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
@ -286,7 +284,7 @@ Important pour les processus d'onboarding de nouveaux membres, de réinitialisat
|
|||||||
|
|
||||||
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||||
|
|
||||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello`.
|
||||||
|
|
||||||
### 13.2. <a name='Rception-1'></a>Réception
|
### 13.2. <a name='Rception-1'></a>Réception
|
||||||
|
|
||||||
|
@ -4,23 +4,23 @@
|
|||||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||||
* 4. [Rôles et Sous-Rôles](#RlesetSous-Rles)
|
* 4. [Rôles et Sous-Rôles](#RlesetSous-Rles)
|
||||||
* 5. [Précisions sur les rôles](#Prcisionssurlesrles)
|
* 5. [Précisions sur les rôles](#Prcisionssurlesrles)
|
||||||
* 5.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
|
* 5.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
|
||||||
* 5.1.1. [Composition et Fonction](#CompositionetFonction)
|
* 5.1.1. [Composition et Fonction](#CompositionetFonction)
|
||||||
* 5.1.2. [Cas d'utilisation](#Casdutilisation)
|
* 5.1.2. [Cas d'utilisation](#Casdutilisation)
|
||||||
* 5.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect)
|
* 5.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect)
|
||||||
* 5.3. [TransactionModeDistribution](#TransactionModeDistribution)
|
* 5.3. [TransactionModeDistribution](#TransactionModeDistribution)
|
||||||
* 5.3.1. [TransactionModeDirect](#TransactionModeDirect)
|
* 5.3.1. [TransactionModeDirect](#TransactionModeDirect)
|
||||||
* 5.4. [Cas d'utilisation](#Casdutilisation-1)
|
* 5.4. [Cas d'utilisation](#Casdutilisation-1)
|
||||||
* 5.4.1. [Composition et Fonction](#CompositionetFonction-1)
|
* 5.4.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||||
* 5.4.2. [Cas d'utilisation](#Casdutilisation-1)
|
* 5.4.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||||
* 5.5. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
|
* 5.5. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
|
||||||
* 5.5.1. [Composition et Fonction](#CompositionetFonction-1)
|
* 5.5.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||||
* 5.5.2. [Cas d'utilisation](#Casdutilisation-1)
|
* 5.5.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||||
* 6. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
|
* 6. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
|
||||||
* 6.1. [RoleCommitment](#RoleCommitment)
|
* 6.1. [RoleCommitment](#RoleCommitment)
|
||||||
* 6.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment)
|
* 6.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment)
|
||||||
* 7. [Sécurisation des Communications](#ScurisationdesCommunications)
|
* 7. [Sécurisation des Communications](#ScurisationdesCommunications)
|
||||||
* 7.1. [Composition et Utilisation](#CompositionetUtilisation)
|
* 7.1. [Composition et Utilisation](#CompositionetUtilisation)
|
||||||
* 8. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
|
* 8. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
|
||||||
* 9. [Exemples de Code](#ExemplesdeCode)
|
* 9. [Exemples de Code](#ExemplesdeCode)
|
||||||
* 10. [Todo](#Todo)
|
* 10. [Todo](#Todo)
|
||||||
@ -31,17 +31,17 @@
|
|||||||
/vscode-markdown-toc-config -->
|
/vscode-markdown-toc-config -->
|
||||||
<!-- /vscode-markdown-toc --># `ItemProcess` et roles
|
<!-- /vscode-markdown-toc --># `ItemProcess` et roles
|
||||||
|
|
||||||
## 1. <a name='Objectif'></a>Objectif
|
## 1. <a name='Objectif'></a>Objectif
|
||||||
|
|
||||||
Cette section vise à présenter en détail les Documents de Contrat Portable ( RequestPcd) et les Documents de Demande Portable ( RequestPrd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les `RequestPcd` et `RequestPrd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
|
Cette section vise à présenter en détail les Documents de Contrat Portable ( RequestPcd) et les Documents de Demande Portable ( RequestPrd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les `RequestPcd` et `RequestPrd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
|
||||||
|
|
||||||
## 2. <a name='Porte'></a>Portée
|
## 2. <a name='Porte'></a>Portée
|
||||||
|
|
||||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||||
|
|
||||||
Voir [Doc_references.md](Doc_references.md).
|
Voir [Doc_references.md](Doc_references.md).
|
||||||
|
|
||||||
## 4. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
|
## 4. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
|
||||||
|
|
||||||
Les rôles déterminent les permissions et les responsabilités des participants dans le système 4NK. Ils sont essentiels pour contrôler l'accès aux données et les autorisations au sein des `ItemProcess` . Les `rôles` principaux incluent :
|
Les rôles déterminent les permissions et les responsabilités des participants dans le système 4NK. Ils sont essentiels pour contrôler l'accès aux données et les autorisations au sein des `ItemProcess` . Les `rôles` principaux incluent :
|
||||||
|
|
||||||
@ -52,36 +52,36 @@ Les rôles déterminent les permissions et les responsabilités des participants
|
|||||||
|
|
||||||
Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayment`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent.
|
Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayment`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent.
|
||||||
|
|
||||||
## 5. <a name='Prcisionssurlesrles'></a>Précisions sur les rôles
|
## 5. <a name='Prcisionssurlesrles'></a>Précisions sur les rôles
|
||||||
|
|
||||||
### 5.1. <a name='RolesGroup-GestiondesRles'></a>RolesGroup - Gestion des Rôles
|
### 5.1. <a name='RolesGroup-GestiondesRles'></a>RolesGroup - Gestion des Rôles
|
||||||
|
|
||||||
La structure RolesGroup est essentielle pour définir et gérer les groupes de rôles au sein du système 4NK, permettant une organisation claire des permissions et des responsabilités.
|
La structure RolesGroup est essentielle pour définir et gérer les groupes de rôles au sein du système 4NK, permettant une organisation claire des permissions et des responsabilités.
|
||||||
|
|
||||||
#### 5.1.1. <a name='CompositionetFonction'></a>Composition et Fonction
|
#### 5.1.1. <a name='CompositionetFonction'></a>Composition et Fonction
|
||||||
|
|
||||||
* **role_peer**: Définit le rôle des pairs dans le réseau, responsables de la facilitation des communications et des transactions.
|
* **role_peer**: Définit le rôle des pairs dans le réseau, responsables de la facilitation des communications et des transactions.
|
||||||
* **role_member**: Spécifie le rôle des membres, ou utilisateurs, qui participent activement dans les processus et les interactions.
|
* **role_member**: Spécifie le rôle des membres, ou utilisateurs, qui participent activement dans les processus et les interactions.
|
||||||
* **role_process**: Représente les entités chargées de définir et de gérer les processus au sein du système.
|
* **role_process**: Représente les entités chargées de définir et de gérer les processus au sein du système.
|
||||||
* **role_artefact_list**: Une liste de rôles d'artefacts, permettant la personnalisation et l'extension des fonctionnalités et des interactions au-delà des rôles standards.
|
* **role_artefact_list**: Une liste de rôles d'artefacts, permettant la personnalisation et l'extension des fonctionnalités et des interactions au-delà des rôles standards.
|
||||||
|
|
||||||
#### 5.1.2. <a name='Casdutilisation'></a>Cas d'utilisation
|
#### 5.1.2. <a name='Casdutilisation'></a>Cas d'utilisation
|
||||||
|
|
||||||
Cette structure permet une gestion flexible des rôles au sein du système, facilitant l'assignation de permissions spécifiques et la délimitation des responsabilités pour une sécurité et une efficacité accrues.
|
Cette structure permet une gestion flexible des rôles au sein du système, facilitant l'assignation de permissions spécifiques et la délimitation des responsabilités pour une sécurité et une efficacité accrues.
|
||||||
|
|
||||||
### 5.2. <a name='TransactionModeDistributionetTransactionModeDirect'></a>TransactionModeDistribution et TransactionModeDirect
|
### 5.2. <a name='TransactionModeDistributionetTransactionModeDirect'></a>TransactionModeDistribution et TransactionModeDirect
|
||||||
|
|
||||||
Les modes de transaction, tels que TransactionModeDistribution et TransactionModeDirect, déterminent comment les demandes et les réponses sont distribuées et traitées au sein du réseau 4NK, influençant l'efficacité et la sécurité des interactions.
|
Les modes de transaction, tels que TransactionModeDistribution et TransactionModeDirect, déterminent comment les demandes et les réponses sont distribuées et traitées au sein du réseau 4NK, influençant l'efficacité et la sécurité des interactions.
|
||||||
|
|
||||||
### 5.3. <a name='TransactionModeDistribution'></a>TransactionModeDistribution
|
### 5.3. <a name='TransactionModeDistribution'></a>TransactionModeDistribution
|
||||||
|
|
||||||
Permet la distribution des demandes ou des informations à plusieurs rôles ou entités, facilitant une communication large et la collaboration au sein du système.
|
Permet la distribution des demandes ou des informations à plusieurs rôles ou entités, facilitant une communication large et la collaboration au sein du système.
|
||||||
|
|
||||||
#### 5.3.1. <a name='TransactionModeDirect'></a>TransactionModeDirect
|
#### 5.3.1. <a name='TransactionModeDirect'></a>TransactionModeDirect
|
||||||
|
|
||||||
Concentre l'échange d'informations ou de demandes directement entre un émetteur et un destinataire spécifique, garantissant une interaction ciblée et sécurisée.
|
Concentre l'échange d'informations ou de demandes directement entre un émetteur et un destinataire spécifique, garantissant une interaction ciblée et sécurisée.
|
||||||
|
|
||||||
### 5.4. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
### 5.4. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||||
|
|
||||||
Ces modes supportent divers scénarios de communication, de la diffusion large d'informations ou de mises à jour, à des échanges directs pour des opérations spécifiques, offrant ainsi une flexibilité dans la gestion des flux d'informations.
|
Ces modes supportent divers scénarios de communication, de la diffusion large d'informations ou de mises à jour, à des échanges directs pour des opérations spécifiques, offrant ainsi une flexibilité dans la gestion des flux d'informations.
|
||||||
|
|
||||||
@ -89,61 +89,61 @@ Ces modes supportent divers scénarios de communication, de la diffusion large d
|
|||||||
|
|
||||||
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
||||||
|
|
||||||
#### 5.4.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
#### 5.4.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||||
|
|
||||||
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
||||||
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
||||||
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
||||||
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
||||||
|
|
||||||
#### 5.4.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
#### 5.4.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||||
|
|
||||||
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
||||||
|
|
||||||
### 5.5. <a name='Role-DfinitionetGestiondesRlesSpcifiques'></a>Role - Définition et Gestion des Rôles Spécifiques
|
### 5.5. <a name='Role-DfinitionetGestiondesRlesSpcifiques'></a>Role - Définition et Gestion des Rôles Spécifiques
|
||||||
|
|
||||||
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
||||||
|
|
||||||
#### 5.5.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
#### 5.5.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||||
|
|
||||||
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
||||||
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
||||||
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
||||||
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
||||||
|
|
||||||
#### 5.5.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
#### 5.5.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||||
|
|
||||||
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
||||||
|
|
||||||
## 6. <a name='GestiondesEngagementsetTransactions'></a>Gestion des Engagements et Transactions
|
## 6. <a name='GestiondesEngagementsetTransactions'></a>Gestion des Engagements et Transactions
|
||||||
|
|
||||||
Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayment, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties.
|
Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayment, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties.
|
||||||
|
|
||||||
### 6.1. <a name='RoleCommitment'></a>RoleCommitment
|
### 6.1. <a name='RoleCommitment'></a>RoleCommitment
|
||||||
|
|
||||||
* **item_name**: Identifie l'engagement spécifique ou l'obligation prise par une partie.
|
* **item_name**: Identifie l'engagement spécifique ou l'obligation prise par une partie.
|
||||||
* **role**: Définit les permissions, les conditions et les critères associés à cet engagement, assurant une exécution et une validation conformes aux attentes.
|
* **role**: Définit les permissions, les conditions et les critères associés à cet engagement, assurant une exécution et une validation conformes aux attentes.
|
||||||
|
|
||||||
### 6.2. <a name='RoleDepositetRolePayment'></a>RoleDeposit et RolePayment
|
### 6.2. <a name='RoleDepositetRolePayment'></a>RoleDeposit et RolePayment
|
||||||
|
|
||||||
Ces structures gèrent respectivement les dépôts de garantie et les paiements, en spécifiant les conditions sous lesquelles les fonds sont déposés, retenus ou transférés, contribuant ainsi à la confiance et à la fluidité des transactions au sein du réseau.
|
Ces structures gèrent respectivement les dépôts de garantie et les paiements, en spécifiant les conditions sous lesquelles les fonds sont déposés, retenus ou transférés, contribuant ainsi à la confiance et à la fluidité des transactions au sein du réseau.
|
||||||
|
|
||||||
## 7. <a name='ScurisationdesCommunications'></a>Sécurisation des Communications
|
## 7. <a name='ScurisationdesCommunications'></a>Sécurisation des Communications
|
||||||
|
|
||||||
La structure MetaData et ses sous-structures comme MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate fournissent un cadre pour sécuriser les communications et les données au sein du système 4NK, permettant une distinction claire entre les informations accessibles publiquement, celles réservées à certains rôles, et celles strictement privées.
|
La structure MetaData et ses sous-structures comme MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate fournissent un cadre pour sécuriser les communications et les données au sein du système 4NK, permettant une distinction claire entre les informations accessibles publiquement, celles réservées à certains rôles, et celles strictement privées.
|
||||||
|
|
||||||
### 7.1. <a name='CompositionetUtilisation'></a>Composition et Utilisation
|
### 7.1. <a name='CompositionetUtilisation'></a>Composition et Utilisation
|
||||||
|
|
||||||
* **meta_data**: Chaque instance de MetaData encapsule des informations détaillées, des attributs et des clés de chiffrement liés à un item, facilitant la gestion sécurisée et la distribution ciblée des données.
|
* **meta_data**: Chaque instance de MetaData encapsule des informations détaillées, des attributs et des clés de chiffrement liés à un item, facilitant la gestion sécurisée et la distribution ciblée des données.
|
||||||
* **key_list**: Un élément crucial pour le chiffrement et la sécurisation des données, assurant que seules les parties autorisées peuvent accéder aux informations confidentielles.
|
* **key_list**: Un élément crucial pour le chiffrement et la sécurisation des données, assurant que seules les parties autorisées peuvent accéder aux informations confidentielles.
|
||||||
|
|
||||||
## 8. <a name='IntgrationetOrchestrationdesProcessus'></a>Intégration et Orchestration des Processus
|
## 8. <a name='IntgrationetOrchestrationdesProcessus'></a>Intégration et Orchestration des Processus
|
||||||
|
|
||||||
L'ItemProcess et ItemProcessPublicAttributeGroup offrent un cadre pour l'intégration et l'orchestration des processus dans le système 4NK, permettant la définition, la gestion et l'exécution de workflows complexes de manière sécurisée et efficace.
|
L'ItemProcess et ItemProcessPublicAttributeGroup offrent un cadre pour l'intégration et l'orchestration des processus dans le système 4NK, permettant la définition, la gestion et l'exécution de workflows complexes de manière sécurisée et efficace.
|
||||||
|
|
||||||
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
|
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||||
|
|
||||||
## 10. <a name='Todo'></a>Todo
|
## 10. <a name='Todo'></a>Todo
|
||||||
|
|
||||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||||
* [ ] Diagrammes de séquences
|
* [ ] Diagrammes de séquences
|
||||||
|
@ -43,7 +43,7 @@ Il y a une `transactions SP` pour tous les types de `RequestPrd` sauf pour les `
|
|||||||
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:
|
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:
|
||||||
|
|
||||||
0. L'output 0 est toujours un paiment au destinataire
|
0. L'output 0 est toujours un paiment au destinataire
|
||||||
1. L'output 1 c'est toujours l'op_return avec un tableau de hashs en clair selon un tableau de hashs en JSON :
|
1. L'output 1 c'est toujours l'op_return avec un tableau de hashs en clair selon un tableau de hashs en JSON avec les index suivants :
|
||||||
1.1. Le hash du message de type `Message` correspondant
|
1.1. Le hash du message de type `Message` correspondant
|
||||||
1.2. Le hash du `RequestPrd`
|
1.2. Le hash du `RequestPrd`
|
||||||
1.3. Le hash du process
|
1.3. Le hash du process
|
||||||
|
Loading…
x
Reference in New Issue
Block a user