From fcc8d0db152150d0c1f868e740ec6ef478810503 Mon Sep 17 00:00:00 2001 From: NicolasCantu Date: Fri, 16 Feb 2024 17:14:35 +0100 Subject: [PATCH] =?UTF-8?q?tables=20des=20mati=C3=A8res=20update=20(doc)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/Doc_references.md | 4 +- doc/Messages-Specs.md | 62 +++++++++---------- doc/PRD-PCD-Specs.md | 115 ++++++++++++++++++------------------ doc/Process-roles-Specs.md | 30 +++++----- doc/Silent-Payment-Specs.md | 16 +++-- doc/Specs-Code.md | 28 ++++----- 6 files changed, 129 insertions(+), 126 deletions(-) diff --git a/doc/Doc_references.md b/doc/Doc_references.md index a11d3ad..a034af5 100644 --- a/doc/Doc_references.md +++ b/doc/Doc_references.md @@ -1,7 +1,7 @@ * 1. [Worfklows](#Worfklows) * 2. [Transverse](#Transverse) -* 3. [3.3. Diagrammes d'architecture](#Diagrammesdarchitecture) +* 3. [Diagrammes d'architecture](#Diagrammesdarchitecture) * 4. [Todo](#Todo) # `RequestPrd` et `RequestPcd` - Specs -## 1. Objectif +## 1. Objectif Le but de cette section est d'introduire les Portable Contract Document (`RequestPcd`) et Portable Request Document (`RequestPrd`) comme éléments fondamentaux du système 4NK. Ces documents jouent un rôle crucial dans la sécurisation des échanges de données et la gestion des identités numériques au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau. -## 2. Portée +## 2. Portée La spécification couvre la conception, le développement, et l'application pratique des `RequestPcd` et `RequestPrd`.Elle vise à expliquer leur fonctionnement, leur structure, et la manière dont ils contribuent à l'écosystème 4NK en offrant une méthode sécurisée et efficace pour le partage d'informations et la validation des transactions. Les `RequestPcd` et `RequestPrd` encapsulent les données contractuelles et les requêtes dans un format standardisé, assurant l'intégrité, la confidentialité, l'authenticité et la validation des informations échangées. -## 3. 3. Documents de référence +## 3. 3. Documents de référence Voir [Doc_references.md](Doc_references.md). -## 4. Commun aux `RequestPcd` et RequestPrd +## 4. Commun aux `RequestPcd` et RequestPrd -### 4.1. Création et envoi +### 4.1. Création et envoi Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais. @@ -65,7 +64,7 @@ Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l **Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md). -### 4.2. Réception +### 4.2. Réception Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais. @@ -83,13 +82,13 @@ En cas de `RequestPcd` ou `RequestPrd` en relation via `RequestPcd_reference_has Pour les `RequestPcd` et les `RequestPrd` il faut vérifier que le hash du document n'est pas déjà en cas, si c'est le cas, le message est ignoré. -## 5. Fonction des RequestPcd +## 5. Fonction des RequestPcd Les Portable Contract Documents ( RequestPcd) sont des documents JSON qui encapsulent les listes versionnées d'`Item` dont les attributs sont chiffrés soit en public, soit en confidentiel par rôles soit en privé (cf. [Specs-Security.md](Specs-Security.md)). Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés. -### 5.1. Création et envoi +### 5.1. Création et envoi La création d'un `RequestPcd` suit plusieurs étapes : @@ -99,7 +98,7 @@ La création d'un `RequestPcd` suit plusieurs étapes : 4. **Chiffrement du RequestPcd**: Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné. 5. Traitements communs aux `RequestPcd` et RequestPrd -### 5.2. Réception +### 5.2. Réception La réception d'un `RequestPcd` suit plusieurs étapes : @@ -110,7 +109,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 5. Déchiffrage des attributs privés des `Item` des `RequestPcd` avec la clé privée `KeyRecover` 6. Mise à jour du cache pour les traitement des RequestPrd. -## 6. Fonction des RequestPrd +## 6. Fonction des RequestPrd Les Portable Request Documents ( RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. @@ -118,7 +117,7 @@ Les clés de chiffrement des attributs confidentiels par rôles des `Item` des ` Les `RequestPrd` sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `RequestPrd` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. -### 6.1. Fonctionnalités optionnelles +### 6.1. Fonctionnalités optionnelles L'attribut `sig_value` permet de donner une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess` avec des valeurs valant pour `OK` ou `KO` pour `none` pour les validations des `RequestPrd`. @@ -143,7 +142,7 @@ Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`. -### 6.3. Création et envoi +### 6.2. Création et envoi La création d'un `RequestPrd` suit plusieurs étapes : @@ -159,7 +158,7 @@ La création d'un `RequestPrd` suit plusieurs étapes : Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md). -### 6.4. Réception +### 6.3. Réception La réception d'un `RequestPcd` suit plusieurs étapes : @@ -174,15 +173,15 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 9. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md). 10. Traitements spécifiques au type de RequestPrd. -## 7. RequestPrdList - Demande de Listes ( RequestPcd) +## 7. RequestPrdList - Demande de Listes ( RequestPcd) Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `RequestPcd` liste des `Item` d'un même type, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc. -### 7.1. Création et envoi +### 7.1. 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. -### 7.2. Réception +### 7.2. Réception La réception d'un `RequestPrdList` suit plusieurs étapes : @@ -195,7 +194,7 @@ La réception d'un `RequestPrdList` suit plusieurs étapes : 5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash` 6. Mise à jour du cache avec les nouveaux `RequestPcd` et `RequestPrdResponse` et `RequestPrdConfirm` envoyés. -## 8. RequestPrdMessage - Envoi de Messages +## 8. RequestPrdMessage - Envoi de Messages Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats. @@ -205,11 +204,11 @@ Permet la communication des`transaction SP` au format `raw` dans l'attribut `raw Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`. -### 8.1. Création et envoi +### 8.1. 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. -### 8.2. Réception +### 8.2. Réception La réception d'un `RequestPrdMessage` suit plusieurs étapes : @@ -219,7 +218,7 @@ La réception d'un `RequestPrdMessage` suit plusieurs étapes : 4. Le cas échéant : création et envoi à l'émetteur du `RequestPrdMessage` d'un `RequestPrdMessage` avec : 5.1. le hash du `RequestPrdMessage` reçu dans l'attribut `request_prd_origin_hash` -## 9. RequestPrdUpdate - Mises à Jour de RequestPcd +## 9. RequestPrdUpdate - Mises à Jour de RequestPcd `RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `RequestPcd`. @@ -231,13 +230,13 @@ Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux ut Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd. -### 9.1. Création et envoi +### 9.1. 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. -### 9.2. Réception +### 9.2. Réception -## 10. RequestPrdConfirm - Confirmation de Réception +## 10. RequestPrdConfirm - Confirmation de Réception Le `RequestPrdConfirm` est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau. @@ -247,13 +246,13 @@ Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdRespon 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. Création et envoi +### 10.1. 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. -### 10.2. Réception +### 10.2. Réception -## 11. RequestPrdResponse - Répondre à une Demande +## 11. RequestPrdResponse - Répondre à une Demande Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. @@ -263,37 +262,37 @@ Utilisé pour fournir des feedbacks, des confirmations, ou des instructions supp Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions. -### 11.1. Création et envoi +### 11.1. 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. -### 11.2. Réception +### 11.2. Réception -## 12. RequestPrdKeyHelloBakcup +## 12. RequestPrdKeyHelloBakcup Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` . -### 12.1. Création et envoi +### 12.1. 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. -### 12.2. Réception +### 12.2. Réception -## 13. RequestPrdKeyHello - Échange de Clés et d'Identités +## 13. RequestPrdKeyHello - Échange de Clés et d'Identités RequestPrdKeyHello est conçu pour initier ou répondre à des demandes d'échange de clés ou d'informations d'identité, essentiel pour la gestion sécurisée des accès et des identités au sein du réseau. Important pour les processus d'onboarding de nouveaux membres, de réinitialisation des accès, ou de renouvellement des clés, facilitant une intégration sécurisée et la mise à jour des identités dans le réseau. -### 13.1. Création et envoi +### 13.1. 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. -### 13.2. Réception +### 13.2. Réception -## 14. Exemples de Code +## 14. Exemples de Code -## 15. Todo +## 15. Todo * [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/Process-roles-Specs.md b/doc/Process-roles-Specs.md index 38bc3ac..0670855 100644 --- a/doc/Process-roles-Specs.md +++ b/doc/Process-roles-Specs.md @@ -4,23 +4,23 @@ * 3. [3. Documents de référence](#Documentsderfrence) * 4. [Rôles et Sous-Rôles](#RlesetSous-Rles) * 5. [Précisions sur les rôles](#Prcisionssurlesrles) - * 5.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles) - * 5.1.1. [Composition et Fonction](#CompositionetFonction) - * 5.1.2. [Cas d'utilisation](#Casdutilisation) - * 5.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect) - * 5.3. [TransactionModeDistribution](#TransactionModeDistribution) - * 5.3.1. [TransactionModeDirect](#TransactionModeDirect) - * 5.4. [Cas d'utilisation](#Casdutilisation-1) - * 5.4.1. [Composition et Fonction](#CompositionetFonction-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.1. [Composition et Fonction](#CompositionetFonction-1) - * 5.5.2. [Cas d'utilisation](#Casdutilisation-1) + * 5.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles) + * 5.1.1. [Composition et Fonction](#CompositionetFonction) + * 5.1.2. [Cas d'utilisation](#Casdutilisation) + * 5.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect) + * 5.3. [TransactionModeDistribution](#TransactionModeDistribution) + * 5.3.1. [TransactionModeDirect](#TransactionModeDirect) + * 5.4. [Cas d'utilisation](#Casdutilisation-1) + * 5.4.1. [Composition et Fonction](#CompositionetFonction-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.1. [Composition et Fonction](#CompositionetFonction-1) + * 5.5.2. [Cas d'utilisation](#Casdutilisation-1) * 6. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions) - * 6.1. [RoleCommitment](#RoleCommitment) - * 6.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment) + * 6.1. [RoleCommitment](#RoleCommitment) + * 6.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment) * 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) * 9. [Exemples de Code](#ExemplesdeCode) * 10. [Todo](#Todo) diff --git a/doc/Silent-Payment-Specs.md b/doc/Silent-Payment-Specs.md index 277403b..8b6ea6f 100644 --- a/doc/Silent-Payment-Specs.md +++ b/doc/Silent-Payment-Specs.md @@ -2,7 +2,11 @@ * 1. [Objectif](#Objectif) * 2. [Portée](#Porte) * 3. [Documents de référence](#Documentsderfrence) -* 4. [Structure des outputs](#Structuredesoutputs) +* 4. [Fontion](#Fontion) +* 5. [Structure des outputs](#Structuredesoutputs) +* 6. [Envoi de la transaction SP](#EnvoidelatransactionSP) + * 6.1. [Dans un `RequestPrdMessage`](#DansunRequestPrdMessage) + * 6.2. [Dans un `Message` du `RequestPrdMessage`](#DansunMessageduRequestPrdMessage) # Specs - Code -## 1. Documents de référence +## 1. Documents de référence Voir [Doc_references.md](Doc_references.md). -## 2. Gestion des erreurs +## 2. Gestion des erreurs Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être `catch` si il y a une possiblité d'interuption. @@ -38,7 +38,7 @@ Les arrêts des membres dans les `ItemProcess` dans leur ensemble n'entraînent Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques. -## 3. Journalisation et monitoring +## 3. Journalisation et monitoring Tous les utilisateurs reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les `RequestPcd` sont les listes à jour de l'état de validation de tous les éléments échangés, et les `RequestPrd` sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un `ItemProcess` (possible de segmenter par zones et services). @@ -46,27 +46,27 @@ Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents s La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque message) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels. -## 4. Tests +## 4. Tests -### 4.1. Stratégie de test +### 4.1. Stratégie de test À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur. -### 4.2. Plan pour les tests unitaires +### 4.2. Plan pour les tests unitaires Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire. -### 4.3. Plan d'intégration +### 4.3. Plan d'intégration L'intégration se réalise par sprint hebdomadaire. L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint. -### 4.4. Plan de charge +### 4.4. Plan de charge Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des utilisateurs. -## 5. Outils et les librairies à utiliser +## 5. Outils et les librairies à utiliser Respect des normes de syntaxe Rust. @@ -84,7 +84,7 @@ Utilisation de Visual Studio (pour le partage de configurations). * **Librairies de tests** : Cargo test -## 6. Critères d'acceptation +## 6. Critères d'acceptation Critères de validation pour que le système puisse être considéré comme prêt pour la production : @@ -98,15 +98,15 @@ Critères de validation pour que le système puisse être considéré comme prê * Documentation manquante clairement précisée. * Autres tests manquants clairement précisés. -## 7. CI/CD +## 7. CI/CD GitLab CI : TBD -## 8. Maintenance +## 8. Maintenance La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint. Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance. -## 9. Exemples de Code +## 9. Exemples de Code -## 10. Todo +## 10. Todo