diff --git a/doc/Auth-Specs.md b/doc/Auth-Specs.md index 39cf270..2a2bd78 100644 --- a/doc/Auth-Specs.md +++ b/doc/Auth-Specs.md @@ -30,8 +30,8 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 12.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover) * 12.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc) * 12.1.3. [Onboarding](#Onboarding-1) - * 12.2. [ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process](#ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess) - * 12.3. [ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess) + * 12.2. [Member complété des champs du process sélectionné et mise à jour de la liste des membres du process](#Membercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess) + * 12.3. [Process complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess) * 12.4. [Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)](#RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn) * 13. [Clés de révocation (`revoke`)](#Clsdervocationrevoke) * 14. [Clés de third parties](#Clsdethirdparties) @@ -89,25 +89,25 @@ Voir [_Doc_references.md](_Doc_references.md). ## 7. Authentification des utilisateurs -Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `ItemProcess` . +Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite `recover` mise en cache dans IndexedDB (données chiffrées par le mot de passe cf. [Chiffrement AES quantique résistant (AES-GCM-256)](#ChiffrementAESquantiquersistantAES-GCM-256)) pour les navigateurs et les applications mobiles, sinon chiffré de la même manière mais en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `Process` . -Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payments pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties`. +Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payments pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties` (autres device de confirmation des actions en `2FA`). -Les utilisateurs sont reconnus par une`adresse SP` dans un ou plusieurs rôles dans un `ItemProcess`. Ces `ItemProcess` préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`. +Les utilisateurs sont reconnus par une`adresse SP` dans un ou plusieurs rôles dans un `Process`. Ces `Process` préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`. -Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par `ItemProcess` dans lequel l'utilisateur a un rôle (`onboarding`). +Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par `Process` dans lequel l'utilisateur a un rôle (`onboarding`). ## 8. Connexion via des tiers Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience utilisateur. -Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux `ItemProcess` 4NK. +Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux `Process` 4NK. ## 9. Fonctionnalité de récupération de mot de passe -En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis. +En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis depuis une adresse de révocation `revoke`. -Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux `Pcd` et `Prd` correspondants. +Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation pour signaler aux autres membres de `Process` de ne plus prendre en compte les transactions venant de l'adresse silent payment actuelle du membre. ## 10. Gestion de session basée sur un cache @@ -117,8 +117,8 @@ Le système ne maintiendra pas de session traditionnelle sur le serveur. La navi Les transactions SP ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) : -* **Clé de dépense** : la clé qui prouve sa détention par la capacité de dépenser un UTXO d'une transaction SP. -* **Clé de scan** : la clé qui permet de détecter qu'une transaction SP nous est destinée. +* **Clé de dépense 'spend'** : la clé qui prouve sa détention par la capacité de dépenser un UTXO d'une transaction SP. +* **Clé de scan 'scan'** : la clé qui permet de détecter qu'une transaction SP nous est destinée. Il y a 3 paires de ces clés privées : @@ -150,7 +150,7 @@ Pour revoir ces jetons l'utilisateur doit générer les adresses sur lesquelles A chaque nouveau message il génère de nouvelles addresses pour la clé qui va dépenser des jetons de signet. Soit une nouvelle adresse (publique) de la clé privée `spend_recover`. -Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envoyés aux relais. +Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envoyés aux relais cf [Messages-Specs.md](Messages-Specs.md Messages Specs) pour la générantion d'une wallet temporaire qui versera les fonds reçus du faucet sur l'adresse silent payment de l'utilisateur. ## 12. Gestion des clés de l'identité (aussi les clés des transactions SP) @@ -158,101 +158,57 @@ Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envo #### 12.1.1. Gestion de la clé servant à l'ID `spend_recover` -Les clés font 256 bits. - La clé privée `spend_recover` est la clé principale pour forger les identités. Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Voici les principales étapes : 1. Cette clé sera scindée en 2 parties (à la moitié de la longueur de leur représentation hexadécimale) : - 1.1. `Part1`, de 128 bits c'est la partie qui sera chiffrée (AES-GCM 256 bits) par - le mot de passe "hashé" (SHA-256 d'un scrytp) - etc une seed de générée aléatoirement de 256 bits avec (concaténé) - pour obtenir la seed de chiffrement AES de 256 bits - et stockée en cache dans une image dite de login avec la seed générée aléatoirement de 256 bits. - En fonction des cas d'usage le mot de passe peut être remplacé par une seed de 256 bits directement et de meilleure entropie que le mot de passe. - Le cache stocke aussi la une autre seed générée aléatoirement de 256 bits pour la `Part2` - `Part1`, et les seeds générées aléatoirement sont stockées dans les données exif de l'image de login. +`Part1` est la partie locale : + +* le mot de passe "hashé" +* et une seed de générée aléatoirement +* ajouté à l'une image de login + +`Part2` est la partie distribuée : + +* le mot de passe "hashé" +* une seed de générée aléatoirement répartie par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres. Encryption speudo code : -``` +Une `pre-id` qui identifie l'utilisateur est générée par le hash (SHA 256) d'un scrypt de la `Part1` et du mot de passe de l'utilisateur. + +```pseudo-code part1_spend_recover_enc=aes(sha(scrypt((MDP+random_seed1), part1) -image1.addExif(part1_spend_recover_enc, random_seed1, random_seed2) +part2_spend_recover_enc_shards=sss(aes(SHA256'srcypt(MDP+random_seed2), part2), nMembers, 0.8) +imageLogin.addExif(part1_spend_recover_enc, random_seed1, random_seed2) +pre_id=sha256(part1_spend_recover_enc, MDP, random_seed) ``` - 1.2. `Part2`, de 128 bits, - le mot de passe "hashé" (SHA-256 d'un scrypt) avec (concaténé) - une seed de générée aléatoirement de 256 bits - pour obtenir la seed de chiffrement AES de 256 bits - et sera répartie par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres. - -Encryption speudo code : - -``` -part2_spend_recover_enc_shars=sss(aes(SHA256'srcypt(MDP+random_seed2), part2), nMembers, 0.8) -``` - -2. Une `pre-id` qui identifie l'utilisateur est générée par le hash (SHA 256) d'un scrypt de la `Part1` et du mot de passe de l'utilisateur. - -Hash speudo code : - -``` -pre_id=sha256(part1_spend_recover_enc, MDP) -``` - -3. Création d'un `PrdList` par membre (1 shard par membre), par `Prd` : - - 3.1. Génération d'une clé de chiffrement dite `sp_shared_secret` qui sera transmise dans le Diffie-Hellman de la transaction SP. - - 3.2. Création d'un `ItemMember` à envoyer avec le `PrdList`. - -4. Création des messages de type `Message` correspondant aux Prd, envoi des messages aux relais connectés. - -Dans l'ordre on réalise donc les opérations suivantes donc : - -1. Split de `spend_recover`. -2. Chiffrement AES de `Part1`. -3. Mise en cache de `Part1Enc`. -4. Création de la pre-id -5. Chiffrement AES de `Part2`. -6. Sharding de `Part2Enc`. +2. Création d'un `PrdList` par membre (1 shard par membre) par `Prd` cf [PRD-PCD](PRD-PCD-Specs.md PRD-PCD) : #### 12.1.2. Backup de `Part2Enc` -Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant l'`ItemProcess` choisi. +Les relais initialisent le SDK (Wasm) par défaut avec une liste `ProcessList` contenant `Process` choisi. Chacun de des managers des membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `PrdResponse` en réponse au `PrdList` envoyé. -Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : - -1. Création de `PrdList` à destination du membre -2. Création de `Message` du `PrdList` à destination du membre. -3. Envoi de la transaction SP du `Message` du `RequestList` à destination du membre. -4. Envoi du `Message` du `PrdList` à destination du membre. -5. Atttente de la réception des `PrdResponse` en réponse aux `PrdList` (confirmations). -6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PrdResponse`. - 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. - 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_confidential` des `PrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. - 6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe - 6.4. Concaténation de `Part1` et `Part2` - #### 12.1.3. Onboarding -### 12.2. ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process +### 12.2. Member complété des champs du process sélectionné et mise à jour de la liste des membres du process -Le role `member` de l'`itemProcess` sélectionné contient un `Item` avec des `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` contenant chacun une `render_template_list` dont le premier élément du tableau est le formulaire de création de l'identité pour champs concernés (publiques ou confidentiels ou privés). +Le role `member` de `Process` sélectionné contient un `Item` avec des `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` contenant chacun une `render_template_list` dont le premier élément du tableau est le formulaire de création de l'identité pour champs concernés (publiques ou confidentiels ou privés). -Ces formulaires permettront de créé les champs attendus par `condition_attribute_encryption_list` dans le role `Member` de l'`ItemProcess` sélectionné, dans l`ItemMember` de l'utilisateur (champs dans `data` des attribut `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` correpsondants). +Ces formulaires permettront de créé les champs attendus par `condition_attribute_encryption_list` dans le role `Member` de `Process` sélectionné, dans `Member` de l'utilisateur (champs dans `data` des attribut `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` correpsondants). -Une fois l'`ItemMember` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Member` du `ItemProcess` sélectionné via un `PrdUpdate`. +Une fois `Member` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Member` du `Process` sélectionné via un `PrdUpdate`. -### 12.3. ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process +### 12.3. Process complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process Pour le ou les roles sélectionnés, l'attribut `request_prd_sp_address_list` de `condition_prd_address_set_list` est complété par l'adresse SP de l'utilisateur. -Une fois l'`ItemProcess` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Process` du `ItemProcess` sélectionné via un `PrdUpdate`. +Une fois `Process` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Process` du `Process` sélectionné via un `PrdUpdate`. ### 12.4. Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné) @@ -260,13 +216,13 @@ Envoi d'un `PrdList` pour chaque membre de chaque rôle du process sélectionné ## 13. Clés de révocation (`revoke`) -Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif. +Les clés de l'image de révocation sont chiffrées par le mot de passe et stockées directement dans les données exifs de l'image de révocation. L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `PrdList` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface). ## 14. Clés de third parties -Au moment de l'update de l'`ItemMember` il est possible de charger des addresses SP de third parties pour lesquelles l'utilisateur a un rôle dans un `ItemProcess`. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`. +Au moment de l'update de `Member` il est possible de charger des addresses SP de third parties pour lesquelles l'utilisateur a un rôle dans un `Process`. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `Member`. Les clés privées associées sont générées lors de l'update d'un membre, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA. @@ -288,7 +244,7 @@ Puis depuis la liste des membres du process, pour chacun des membres : 5. Attente de la validation (`PrdResponse`) du `PrdUpdate`. 6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PrdResponse`. 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. - 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_confidential` des `PrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. + 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_confidential` des `PrdResponse` de chaque member du `Role` `Member`du `Process`. 6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe 6.4. Concaténation de `Part1` et `Part2` 7. Réception des flux PCD et PRDResponse des gestionnaires des membres diff --git a/doc/Item-Specs.md b/doc/Item-Specs.md index a3c4497..af2cfec 100644 --- a/doc/Item-Specs.md +++ b/doc/Item-Specs.md @@ -19,7 +19,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 5.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems) * 5.3.1. [Composition et Fonction](#CompositionetFonction-1) * 5.3.2. [Cas d'utilisation](#Casdutilisation-1) -* 6. [ItemProcess](#ItemProcess) +* 6. [Process](#Process) * 7. [Exemples de Code](#ExemplesdeCode) * 8. [Todo](#Todo) @@ -46,8 +46,8 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé * **Process**: Définit un ensemble de règles et de procédures pour gérer des interactions spécifiques au sein du réseau. * **Member**: Représente les utilisateurs ou entités participant à un processus. * **Peer**: Identifie les nœuds ou participants du réseau qui aident à faciliter les communications et les transactions. -* **Artefact** : Un type d'objet générique personnalisable dans les `ItemProcess` , il peut y avoir une quantité infinie de type d'`artefacts` différents par `ItemProcess`. -* **Payments, Deposit, Commitment**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques. +* **Artefact** : Un type d'objet générique personnalisable dans les `Process` , il peut y avoir une quantité infinie de type d'`artefacts` différents par `Process`. +* **Payments, Deposit, commit**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques. ### 5.2. Composition et Fonction @@ -78,9 +78,9 @@ La structure MetaData joue un rôle crucial dans la définition des attributs et La richesse et la diversité des métadonnées permettent une personnalisation et une spécification précises des items, soutenant des processus complexes, des contrats détaillés, et des interactions sécurisées au sein du réseau. -## 6. ItemProcess +## 6. Process -* **item**: Base de l'ItemProcess, liant les processus aux items spécifiques au sein du système. +* **item**: Base de l'Process, liant les processus aux items spécifiques au sein du système. * **item_process_public_attribute_group**: Groupe d'attributs publics associés à un processus, définissant les règles, les rôles et les conditions d'exécution du processus. ## 7. Exemples de Code diff --git a/doc/Messages-Specs.md b/doc/Messages-Specs.md index c33e855..ad86a01 100644 --- a/doc/Messages-Specs.md +++ b/doc/Messages-Specs.md @@ -12,10 +12,10 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 3. [1. Objectif](#Objectif) * 4. [2. Portée](#Porte) * 5. [Documents de référence](#Documentsderfrence) -* 6. [4. Variable `SharedPeerList` du SDK (Wasm)](#VariableSharedPeerListduSDKWasm) +* 6. [4. Variable `PeerList` du SDK (Wasm)](#VariablePeerListduSDKWasm) * 7. [6. Caractéristiques générales des messages de type `Message` et `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetMessageConnect) - * 7.1. [6.1. SharedPeerList](#SharedPeerList) - * 7.2. [6.2. SharedProcessList](#SharedProcessList) + * 7.1. [6.1. PeerList](#PeerList) + * 7.2. [6.2. ProcessList](#ProcessList) * 7.3. [6.3. Taille des données](#Tailledesdonnes) * 7.4. [6.4. Preuve de travail](#Preuvedetravail) * 7.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet) @@ -64,27 +64,27 @@ Ce document concerne les messages de type `Message` et `MessageConnect` pour le Voir [_Doc_references.md](_Doc_references.md). -## 6. 4. Variable `SharedPeerList` du SDK (Wasm) +## 6. 4. Variable `PeerList` du SDK (Wasm) -La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, constituant la première liste disponible, fournie en dur par le relais auquel on est connecté. +La variable `PeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, constituant la première liste disponible, fournie en dur par le relais auquel on est connecté. ## 7. 6. Caractéristiques générales des messages de type `Message` et `MessageConnect` -### 7.1. 6.1. SharedPeerList +### 7.1. 6.1. PeerList -`SharedPeerList` est une liste de relais partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux relais. +`PeerList` est une liste de relais partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux relais. -### 7.2. 6.2. SharedProcessList +### 7.2. 6.2. ProcessList -`SharedProcessList` est une liste de `ItemProcess` partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux `ItemProcess`. +`ProcessList` est une liste de `Process` partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux `Process`. ### 7.3. 6.3. Taille des données -Les objets `SharedPeer` spécifient la taille maximale des données pour les messages de type `Message` et `MessageConnect` dans l'attribut `data_max_size` du sous-attribut `relay`. Les messages excédant cette taille sont rejetés. +Les objets `Peer` spécifient la taille maximale des données pour les messages de type `Message` et `MessageConnect` dans l'attribut `data_max_size` du sous-attribut `relay`. Les messages excédant cette taille sont rejetés. ### 7.4. 6.4. Preuve de travail -Les objets `SharedPeer` définissent les caractéristiques de la preuve de travail pour les messages de type `Message` et `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous-attribut `relay`. Les messages ne respectant pas la preuve de travail sont rejetés. +Les objets `Peer` définissent les caractéristiques de la preuve de travail pour les messages de type `Message` et `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous-attribut `relay`. Les messages ne respectant pas la preuve de travail sont rejetés. ### 7.5. 6.5. Adresse SP de faucet @@ -96,8 +96,8 @@ L'utilisateur reçoit en retour une transaction Silent Payments (SP) contenant d `MessageGeneric` fournit une structure générale pour les messages, incluant les pairs partagés et les processus, et des détails comme les défis de PoW, soutenant des besoins de communication diversifiés. Les attributs ont les fonctions suivantes : -* **`shared_peer_list`** : Une liste de pairs partagés, représentée par des objets `SharedPeer`. Cette liste sert à partager les pairs entre les relais et les clients et les relais entre eux. -* **`shared_process_list`** : Une liste de processus partagés, représentée par des objets `SharedProcess`. Cette liste sert à partager les processus entre les relais et les clients et les relais entre eux. +* **`shared_peer_list`** : Une liste de pairs partagés, représentée par des objets `Peer`. Cette liste sert à partager les pairs entre les relais et les clients et les relais entre eux. +* **`shared_process_list`** : Une liste de processus partagés, représentée par des objets `Process`. Cette liste sert à partager les processus entre les relais et les clients et les relais entre eux. * **`faucet_sp_address`** : L'adresse pour recevoir les fonds du faucet (indispensable pour pouvoir crééer des requètes Silent Payments). * **`pow`** : Représente un défi de Preuve de Travail (PoW), représentée par un objet `Pow`. * **`raw_transaction_list`** : Liste de transactions à diffuser. @@ -110,11 +110,11 @@ La structure `Pow` détaille un défi de Preuve de Travail, incluant le hash des * **`pattern`** : Le motif des premiers caractères qui doivent être répétés autant de fois que la difficulté l'indique. * **`difficulty`** : Le niveau de difficulté du défi PoW. -La structure `SharedProcess` identifie un processus partagé au sein du système, aidant à la gestion et la coordination des processus collaboratifs. +La structure `Process` identifie un processus partagé au sein du système, aidant à la gestion et la coordination des processus collaboratifs. -* **`process_list`** : Une liste d'`ItemProcess` partagée. Cette liste sert à partager les processus entre les relais et les clients et les relais entre eux. +* **`process_list`** : Une liste d'`Process` partagée. Cette liste sert à partager les processus entre les relais et les clients et les relais entre eux. -La structure `SharedPeer` spécifie un pair au sein du réseau. Les attributs ont les fonctions suivantes : +La structure `Peer` spécifie un pair au sein du réseau. Les attributs ont les fonctions suivantes : * **`domain`** : Le domaine associé au pair partagé. * **`address_ip`** : L'adresse IP du pair partagé. @@ -194,7 +194,7 @@ L'utilisateur envoie un message de type `MessageConnect` à chaque relais pour s Il y a des doublons de messages pour chaque relais, à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable de manière autonome en rapport à sa propre expérience. L'arbitrage repose sur une réponse devant satisfaire au moins 80% de la même réponse que celle des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache. -Pour se connecter, l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis les listes de relais non partagées `private` et `public` du cache. +Pour se connecter, l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `PeerList` du SDK (Wasm) et depuis les listes de relais non partagées `private` et `public` du cache. Un ping (incluant la Preuve de Travail dans le délai) est réalisé sur chaque relais pour vérifier leur disponibilité, et les quatre premiers relais disponibles sont choisis. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings). @@ -208,7 +208,7 @@ Les connexions utilisent le protocole WebSocket avec ou sans SSL (URL commençan ![PeerSendScore.png](diagrams/PeerSendScore.png "PeerSendScore.") -L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` au format JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter. Il partage ainsi sa liste de relais et sa liste de `ItemProcess`. Il n'y a pas de retour attendu pour ce message. +L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` au format JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter. Il partage ainsi sa liste de relais et sa liste de `Process`. Il n'y a pas de retour attendu pour ce message. Objet de type `MessageConnect`. Les attributs ont les fonctions suivantes : @@ -229,7 +229,7 @@ Objet de type `Message`, Les attributs ont les fonctions suivantes : ![PeerReceivedScore.png](diagrams/PeerReceivedScore.png "PeerReceivedScore.") -Le client reçoit un nouveau message via le socket ouvert avec le relais et effectue divers contrôles, notamment le calcul du hash du message et sa vérification dans le cache. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour en conséquence. Le message est ensuite déchiffré avec la `ProcessKey` du `ItemProcess`, et d'autres contrôles sont réalisés. Les données pertinentes sont mises à jour dans le cache. +Le client reçoit un nouveau message via le socket ouvert avec le relais et effectue divers contrôles, notamment le calcul du hash du message et sa vérification dans le cache. Les listes de relais (`PeerList`) et de `Process` (`ProcessList`) sont mises à jour en conséquence. Le message est ensuite déchiffré avec la `ProcessKey` du `Process`, et d'autres contrôles sont réalisés. Les données pertinentes sont mises à jour dans le cache. ## 9. 8. Traitements par les relais @@ -239,11 +239,11 @@ Le client reçoit un nouveau message via le socket ouvert avec le relais et effe ![RelayMessageConnectReceived](diagrams/RelayMessageConnectReceived.png "RelayMessageConnectReceived") -À la réception d'un message de type `MessageConnect`, le relais enregistre le socket du client et réalise divers contrôles, y compris la vérification de la preuve de travail et la taille des données. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour. En retour, le relais envoie quelques jetons à l'adresse SP de faucet communiquée par le client et met à jour les données dans le cache. +À la réception d'un message de type `MessageConnect`, le relais enregistre le socket du client et réalise divers contrôles, y compris la vérification de la preuve de travail et la taille des données. Les listes de relais (`PeerList`) et de `Process` (`ProcessList`) sont mises à jour. En retour, le relais envoie quelques jetons à l'adresse SP de faucet communiquée par le client et met à jour les données dans le cache. ### 9.2. 8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais -Les relais se connectent à de nouveaux relais en utilisant `MessageConnect`, partageant à leur tour leur liste de relais et de `ItemProcess`. Aucun retour n'est attendu pour ce message. +Les relais se connectent à de nouveaux relais en utilisant `MessageConnect`, partageant à leur tour leur liste de relais et de `Process`. Aucun retour n'est attendu pour ce message. ## 10. 9. Traitement des messages de type `Message` par les relais @@ -259,7 +259,7 @@ Bitcoin et les side chains utilisent divers protocoles pour la découverte de pa ### 11.1. 10.1. Protocole de Découverte des Pairs -Bitcoin facilite la découverte de nouveaux nœuds via des DNS seeds et une liste de nœuds codée en dur. 4NK utilise la `SharedPeerList` comme équivalent pour faciliter la découverte de relais dans le réseau. +Bitcoin facilite la découverte de nouveaux nœuds via des DNS seeds et une liste de nœuds codée en dur. 4NK utilise la `PeerList` comme équivalent pour faciliter la découverte de relais dans le réseau. ### 11.2. 10.2. Protocole de Transmission des Transactions diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index a554232..23eb521 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -56,20 +56,20 @@ Voir [_Doc_references.md](_Doc_references.md). ## 6. Définitions -* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `ItemProcess` (`item_type`). +* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `Process` (`item_type`). -* **Portable Request Document (`Prd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `Pcd`. Les `PrdResponse` sont collectés pour vérifier le respect des conditions de l'`ItemProcess`. D'autres types de `Prd` incluent : +* **Portable Request Document (`Prd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `Pcd`. Les `PrdResponse` sont collectés pour vérifier le respect des conditions de `Process`. D'autres types de `Prd` incluent : * `PrdList`: Demande de listes d'`Item`. En réponse, une `Pcd` est reçue avec les `PrdResponse` correspondants. * `PrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou de transactions Silent Payments des autres `Prd` à diffuser sur le réseau des nœuds de la side chain. Les `PrdMessage` peuvent répondre les uns aux autres. * `PrdUpdate`: Demande de mise à jour d'une liste d'`Item` (publiée via un `PCD`), qui sera déchiffrée et validée ou non par des `PrdResponse` en retour. * `PrdConfirm`: Confirmation de la réception des `Prd` (à l'exception de `PrdConfirm` eux-même). * `PrdResponse`: Réponse aux autres types de `Prd` (à l'exception de `PrdConfirm`, et `PrdMessage`). -* **Message**: Enveloppe commune pour les `Prd` et `Pcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `Prd` et `Pcd` sont chiffrés par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`. +* **Message**: Enveloppe commune pour les `Prd` et `Pcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `Prd` et `Pcd` sont chiffrés par la `ProcessKey` de `Process` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`. * **KeyConfidential**: Clé AES-GCM-256 issue du `Diffie-Hellman` de la transaction Silent Payments correspondant à un `Prd`. -* **ProcessKey**: La clé publique de chiffrement d'un `ItemProcess` (trouvée dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément). +* **ProcessKey**: La clé publique de chiffrement d'un `Process` (trouvée dans un `Process`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément). * **KeyRecover**: La clé privée de dépense de `recover` du signet, utilisée comme référence pour l'identité. @@ -91,7 +91,7 @@ Les `Prd` sont des demandes d'actions ou des réponses à ces demandes, interagi * `PrdConfirm` : Répond à tous les autres types de `Prd` (à l'exception des `PrdConfirm` eux-mêmes). * `PrdResponse` : Répond à tous les autres types de `Prd` (à l'exception des `PrdConfirm`, `PrdResponse` eux-mêmes). Dans le cas d'une réponse à un `PrdList` ou d'un `PrdUpdate`, le `PrdResponse` doit obligatoirement être accompagné d'un `Pcd`. -Selon le type de `Prd`, les demandes peuvent s'adresser à tous les membres de l'`ItemProcess`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : +Selon le type de `Prd`, les demandes peuvent s'adresser à tous les membres de `Process`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : * `PrdList` : Envoyé aux gestionnaires du type d'`Item` concerné. * `PrdMessage`, avec 2 cas de figure : @@ -118,9 +118,9 @@ Ce qui est résumé pour l'envoi : | `request_type` | Notification user | `transaction SP` + `PrdMessage` | `Pcd` to send | `request_type` send to | `Pcd` reply waiting | `PrdResponse` reply waiting | `PrdConfirm` reply waiting | |----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------| -| `PrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes | -| `PrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `ItemProcess` | No | Yes | Yes | -| `PrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `ItemProcess` | No | No | if no `raw_transaction_list` | +| `PrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `Process` | Yes | Yes | Yes | +| `PrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `Process` | No | Yes | Yes | +| `PrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `Process` | No | No | if no `raw_transaction_list` | | `PrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | | `PrdConfirm` | (option) Waiting `code_confirm_confidential` | Yes | No | See Received | No | No | No | @@ -136,8 +136,8 @@ Ce qui est résumé Pour la réception : | `request_type` | Notification user | `PrdConfirm` to send | `Pcd` to send | `PrdResponse` to send | `PrdResponse` reply waiting | `PrdConfirm` reply waiting (from `PrdResponse` send ) | |----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------| -| `PrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | -| `PrdUpdate` | Prd | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | Yes | +| `PrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `Process` | No | Yes | +| `PrdUpdate` | Prd | Yes | No | all the members of all `Role` into to `Process` | Yes (other members) | Yes | | `PrdMessage` | Waiting `PrdMessage` reply | if no `raw_transaction_list` | No | No | No | No | | `PrdResponse` | Prd | Yes | No | No | No | No | | `PrdConfirm` | Prd | No | No | No | No | No | @@ -150,31 +150,31 @@ Schema : Les `Metadata` des `Item` des `Pcd` et les attributs des `Pcd` et `Prd` sont chiffrés de la sorte : -* **Données publiques** : Utilisent un chiffrement symétrique basé sur la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)). Ces données sont ainsi accessibles à tous pour le déchiffrement. +* **Données publiques** : Utilisent un chiffrement symétrique basé sur la `ProcessKey` de `Process` (cf. [Specs-Definition](SpecsDefinition.md)). Ces données sont ainsi accessibles à tous pour le déchiffrement. -* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les Pcd** : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un `Pcd`. Ces clés seront ensuite ajoutées aux `Prd` dans l'attribut `Pcd_keys_role_confidential_list_confidential`; lui même alors chiffré par la `KeyConfidential`. +* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `Process` dans les Pcd** : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un `Pcd`. Ces clés seront ensuite ajoutées aux `Prd` dans l'attribut `Pcd_keys_role_confidential_list_confidential`; lui même alors chiffré par la `KeyConfidential`. -* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les Prd** : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les `Pcd` et transmises par le `Prd`, chiffrées par la `KeyConfidential` du Diffie-Hellman de la transaction Silent Payments associée à ce `Prd` (cf. [Specs-Definition](SpecsDefinition.md)) d'une transaction `SP`. +* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `Process` dans les Prd** : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les `Pcd` et transmises par le `Prd`, chiffrées par la `KeyConfidential` du Diffie-Hellman de la transaction Silent Payments associée à ce `Prd` (cf. [Specs-Definition](SpecsDefinition.md)) d'une transaction `SP`. * **Données privées** : Chiffrées symétriquement en utilisant la clé de dépense de connexion (`recover`) du signet (voir Login - Specs). Principaux champs des `Request` contenus dans les `Pcd` et `Prd` chiffrés : * **`request_type`** : Type de requête : `Pcd`, `PrdList`, `PrdMessage`, `PrdUpdate`, `PrdConfirm`, `PrdResponse`. -* **`item_name`** : Noms des items : `peer`, `member`, `process`, `Payments`, `deposit`, `commitment`, et les `artefact` personnalisés. +* **`item_name`** : Noms des items : `peer`, `member`, `process`, `Payments`, `deposit`, `commit`, et les `artefact` personnalisés. * **`version`** : Version de la requête. -* **`process_hash`** : Hash de l'`ItemProcess` concerné. +* **`process_hash`** : Hash de `Process` concerné. * **`request_pcd_reference_hash`** : Hash du `Pcd` auquel le `Prd` fait référence. * **`request_pcd_origin_hash`** : Hash du `Pcd` à l'origine du `Prd`. * **`request_prd_reference_hash`** : Hash du `Prd` auquel le `Prd` fait référence. * **`request_prd_origin_hash`** : Hash du `Prd` à l'origine du `Prd`. -* **`item_reference_hash`** : Hash de l'`Item` auquel le `Pcd` fait référence. +* **`item_reference_hash`** : Hash de `Item` auquel le `Pcd` fait référence. ## 9. Fonction des Pcd Les Portable Contract Documents (`Pcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)). -Les `Item` échangés via les `Pcd` sont soumis à une vérification par les `PrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné. +Les `Item` échangés via les `Pcd` sont soumis à une vérification par les `PrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `Process` et les `member` du `Role` concerné. Principaux champs des `Pcd` : @@ -191,17 +191,17 @@ Principaux champs de la structure `Pagination` : Principaux champs de la structure `PcdItemGenericEnc` : -* **`version`** : Version de l'`Item`. -* **`item_type`** : Type de l'`Item`. -* **`name`** : Nom de l'`Item`. -* **`request_pcd_item_enc_attribute_public_list`** : Liste d'objets `PcdItemEncAttributePublic` des attributs publics de l'`Item` chiffré. -* **`request_pcd_item_enc_attribute_role_confidential_list`** : Liste d'objets `PcdItemEncAttributeRoleConfidential` des attributs confidentiels de l'`Item` chiffré. -* **`request_pcd_item_enc_attribute_private_list`** : Liste d'objets `PcdItemEncAttributePrivate` des attributs privés de l'`Item` chiffré. +* **`version`** : Version de `Item`. +* **`item_type`** : Type de `Item`. +* **`name`** : Nom de `Item`. +* **`request_pcd_item_enc_attribute_public_list`** : Liste d'objets `PcdItemEncAttributePublic` des attributs publics de `Item` chiffré. +* **`request_pcd_item_enc_attribute_role_confidential_list`** : Liste d'objets `PcdItemEncAttributeRoleConfidential` des attributs confidentiels de `Item` chiffré. +* **`request_pcd_item_enc_attribute_private_list`** : Liste d'objets `PcdItemEncAttributePrivate` des attributs privés de `Item` chiffré. Principaux champs de la structure `PcdItemEncAttributePublic` : * **`attribute_name`** : Nom de l'attribut. -* **`data_enc`** : Données chiffrées par la clé `ProcessKey` de l'`ItemProcess` concerné. +* **`data_enc`** : Données chiffrées par la clé `ProcessKey` de `Process` concerné. * **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair. * **`data`** : [PRIVE] Non partagé dans les messages. Données en clair. @@ -251,18 +251,18 @@ Schéma de finalisation de la réception d'un `Pcd` : Les Portable Request Documents (Prd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `Pcd` via l'attribut `Pcd_keys_role_confidential_list_confidential`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. -Les clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `Pcd` sont elles-mêmes chiffrées dans les `Prd` au moyen du chiffrement du `Prd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées aux `members` concernés par les `Item` des `Pcd` (rôles dans les `ItemProcess`). +Les clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `Pcd` sont elles-mêmes chiffrées dans les `Prd` au moyen du chiffrement du `Prd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées aux `members` concernés par les `Item` des `Pcd` (rôles dans les `Process`). Les `Prd` se déclinent en plusieurs types, tels que `PrdList`, `PrdMessage`, `PrdUpdate`, etc., correspondant à différentes actions comme l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. Principaux champs des `Prd` : * **`request`** : cf la descripton de la structure `Request`. -* **`sig_value`** : Valeur de la signature (parmi les valeurs valant pour `OK`, `KO` ou `none` telles que définies dans l'`ItemProcess`). +* **`sig_value`** : Valeur de la signature (parmi les valeurs valant pour `OK`, `KO` ou `none` telles que définies dans `Process`). * **`request_pcd_reference_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` chiffrées par la clé `KeyConfidential` d'une `transaction SP`. * **`request_pcd_origin_hash_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` du `PCD` de référence, chiffrées par la clé `KeyConfidential` d'une `transaction SP`. -* **`message_public`** : Message public, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. -* **`message_confidential`** : Message confidentiel, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. +* **`message_public`** : Message public, chiffré par la clé `ProcessKey` du `Process` concerné. +* **`message_confidential`** : Message confidentiel, chiffré par la clé `ProcessKey` du `Process` concerné. * **`message_private`** : Message privé, chiffré par la clé privée `KeyRecover`. * **`sp_address_to`** : Adresse du destinataire. * **`sp_address_from`** : Adresse de l'émetteur. @@ -273,13 +273,13 @@ Principaux champs des `Prd` : * **`Payments_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `paiement` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`cap_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP` servant à la validation des paiements temporaires en attente du passage d'un cap. * **`deposit_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`commitment_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `commitment` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`commit_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `commit` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`ask_Payments_method_confidential`** : Demande de méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`ask_deposit_method_confidential`** : Demande de méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`ask_commitment_method_confidential`** : Demande de méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`ask_commit_method_confidential`** : Demande de méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`Payments_method_confidential`** : Méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. * **`deposit_method_confidential`** : Méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. -* **`commitment_method_confidential`** : Méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. +* **`commit_method_confidential`** : Méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. * **`certif_key_confidential`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`device_footprint_enc_by_sp_shared_secret`** : Empreinte du dispositif de l'émetteur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`. @@ -304,16 +304,16 @@ Schéma de finalisation de la création d'un `Prd` : La réception d'un `Prd` suit plusieurs étapes : -1. Parcours des `ItemProcess` pour trouver le `ItemProcess` correspondant au `process_hash` du `Prd` -2. Tentative de déchiffrement du `Prd` avec la clé `ProcessKey` du `ItemProcess` correspondant. +1. Parcours des `Process` pour trouver le `Process` correspondant au `process_hash` du `Prd` +2. Tentative de déchiffrement du `Prd` avec la clé `ProcessKey` du `Process` correspondant. 3. Recherche des `Pcd` en relation via `Pcd_reference_hash` et `Pcd_origin_hash`, attente si nécessaire et traitement de ceux-ci. 4. Vérification de la conformité des `Pcd` en relation. 5. Recherche des `Prd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, attente si nécessaire et traitement de ceux-ci. 6. Vérification de la conformité des `Prd` en relation. -7. Recherche de l'`Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci. +7. Recherche de `Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci. 8. Déchiffrement voir Encryption. -9. Validation des conditions définies dans le `ItemProcess` pour cet `Item`, avec le `Role` correspondant dans le `ItemProcess`, et dans ces rôles, les conditions pour ce type de `Prd` (dans l'attribut `request_prd_type`) -10. Vérification du role de l'utilisateur courant dans le `ItemProcess` et dans le `Item` concerné. +9. Validation des conditions définies dans le `Process` pour cet `Item`, avec le `Role` correspondant dans le `Process`, et dans ces rôles, les conditions pour ce type de `Prd` (dans l'attribut `request_prd_type`) +10. Vérification du role de l'utilisateur courant dans le `Process` et dans le `Item` concerné. 11. Traitements spécifiques au type de `Prd`. Schéma de finalisation de la réception d'un `Prd` : @@ -322,7 +322,7 @@ Schéma de finalisation de la réception d'un `Prd` : ## 11. PrdList - Demande de Listes -Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayments`, etc. +Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `Process`, les `Member`, les `Peer`, les `Payments`, etc. Workflow: @@ -338,26 +338,26 @@ Principaux champs des `PrdList` : Dans le cas d'une création de compte : -* **`item_member_enc_by_sp_shared_secret`** : Nouvel `ItemMember` temporaire,chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`item_member_enc_by_sp_shared_secret`** : Nouvel `Member` temporaire,chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -L'`ItemMember` temporaire contient les métadonnées de type `Metadata` suivantes : +`Member` temporaire contient les métadonnées de type `Metadata` suivantes : -* **`MetadataProcessPublic` de type `ItemMemberPublicAttributeGroup`** : +* **`MetadataProcessPublic` de type `MemberPublicAttributeGroup`** : -* **`sp_address_public`** : Adresse publique de l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`sp_address_revoke_public`** : Adresse publique de révocation de l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`third_sp_address_list_public`** : Liste des adresses publiques de devices tiers, chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`data_size_max`** : Taille maximale des données acceptée par l'utilisateur (par flux), chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`Payments_method_list_public`** : Liste des méthodes de paiement acceptées par l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`succession_process_hash`** : Hash du processus de succession de l'utilisateur (transmission de l'identité numérique et donc de tous les flux associés), chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`device_footprint`** : Empreinte du dispositif de l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. +* **`sp_address_public`** : Adresse publique de l'utilisateur, chiffré par la `ProcessKey` de `Process`. +* **`sp_address_revoke_public`** : Adresse publique de révocation de l'utilisateur, chiffré par la `ProcessKey` de `Process`. +* **`third_sp_address_list_public`** : Liste des adresses publiques de devices tiers, chiffré par la `ProcessKey` de `Process`. +* **`data_size_max`** : Taille maximale des données acceptée par l'utilisateur (par flux), chiffré par la `ProcessKey` de `Process`. +* **`Payments_method_list_public`** : Liste des méthodes de paiement acceptées par l'utilisateur, chiffré par la `ProcessKey` de `Process`. +* **`succession_process_hash`** : Hash du processus de succession de l'utilisateur (transmission de l'identité numérique et donc de tous les flux associés), chiffré par la `ProcessKey` de `Process`. +* **`device_footprint`** : Empreinte du dispositif de l'utilisateur, chiffré par la `ProcessKey` de `Process`. -* **`MetadataRoleConfidential` de type `ItemMemberRoleConfidentialAttributeGroup`** : +* **`MetadataRoleConfidential` de type `MemberRoleConfidentialAttributeGroup`** : * **`shard_confidential`** : Shard de l'utilisateur, chiffré par la clé `KeyConfidential` d'une `transaction SP`. * **`pre_id_confidential`** : Pré empreinte de l'identité numérique de l'utilisateur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`MetadataPrivate` de type `ItemMemberRolePrivateAttributeGroup`** : +* **`MetadataPrivate` de type `MemberRolePrivateAttributeGroup`** : * **`priv_key_mainnet_spend`** : Clé de dépense de l'utilisateur, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`. * **`priv_key_mainnet_scan`** : Clé de scan de l'utilisateur, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`. @@ -402,7 +402,7 @@ Basé sur le `Prd`, avec des ajouts pour spécifier les modifications demandées Essentiel pour les utilisateurs ou les processus nécessitant de mettre à jour des informations contractuelles ou des attributs d'items, assurant la pertinence et l'actualité des données dans le système. -Par exemple, la mise à jour de la liste des membres permet d'ajouter de nouveaux utilisateurs à un `ItemProcess`, et la mise à jour de la liste des `ItemProcess` permet de leur affecter un nouveau `Role`. +Par exemple, la mise à jour de la liste des membres permet d'ajouter de nouveaux utilisateurs à un `Process`, et la mise à jour de la liste des `Process` permet de leur affecter un nouveau `Role`. Les `PrdUpdate` signalent au réseau, via l'attribut `Pcd_new_version_hash`, les nouvelles versions des `Pcd`. diff --git a/doc/Process-roles-Specs.md b/doc/Process-roles-Specs.md index 1b85ed2..7d80020 100644 --- a/doc/Process-roles-Specs.md +++ b/doc/Process-roles-Specs.md @@ -1,4 +1,4 @@ -# `ItemProcess` et `Role` - Specifications +# `Process` et `Role` - Specifications ## 1. Autheurs, validations, dates, versions, changement and historique @@ -27,7 +27,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 7.5.1. [Composition et Fonction](#CompositionetFonction-1) * 7.5.2. [Cas d'utilisation](#Casdutilisation-1) * 8. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions) - * 8.1. [RoleCommitment](#RoleCommitment) + * 8.1. [Rolecommit](#Rolecommit) * 8.2. [RoleDeposit et RolePayments](#RoleDepositetRolePayments) * 9. [Sécurisation des Communications](#ScurisationdesCommunications) * 9.1. [Composition et Utilisation](#CompositionetUtilisation) @@ -40,7 +40,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 12. [ConditionPublish : conditions de publication](#ConditionPublish:conditionsdepublication) * 13. [ConditionOrchestration : conditions d'orchestration des processus](#ConditionOrchestration:conditionsdorchestrationdesprocessus) * 14. [ConditionPayments : conditions de paiement](#ConditionPayments:conditionsdepaiement) -* 15. [ConditionCommitment : conditions d'engagement](#ConditionCommitment:conditionsdengagement) +* 15. [Conditioncommit : conditions d'engagement](#Conditioncommit:conditionsdengagement) * 16. [ConditionDeposit : conditions de dépôt de garantie](#ConditionDeposit:conditionsdedptdegarantie) * 17. [ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement](#ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement) * 18. [TransactionMode](#TransactionMode) @@ -65,14 +65,14 @@ Voir [_Doc_references.md](_Doc_references.md). ## 6. 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 `Process` . Les `rôles` principaux incluent : * **RolePeer**: Conditions des listes de relais participants qui facilitent les communications et les transactions et des versions de ces listes. * **RoleMember**: Conditions des listes des utilisateurs ou entités ayant une participation directe dans un processus spécifique et des versions de ces listes. * **RoleProcess**: Conditions des listes des processus et des versions des listes. * **RoleArtefact**: Définit les permissions et les interactions pour les artefacts au sein du réseau et des version de ces listes, par types d'artefacts. -Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayments`, `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 `RolePayments`, `RoleDeposit`, et `Rolecommit`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent. ## 7. Précisions sur les rôles @@ -139,9 +139,9 @@ Cette structure permet une personnalisation détaillée des rôles au sein du sy ## 8. Gestion des Engagements et Transactions -Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayments, 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 Rolecommit, RoleDeposit, et RolePayments, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties. -### 8.1. RoleCommitment +### 8.1. Rolecommit * **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. @@ -161,7 +161,7 @@ La structure MetaData et ses sous-structures comme MetadataContractPublic, Metad ## 10. 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'Process et ProcessPublicAttributeGroup 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. ## 11. Condition PrdAddressSet @@ -225,7 +225,7 @@ Les membres concernés sont identifiés par leurs `adresse SP`. * (option) `Payments_method_list`: Liste des modes de paiement acceptés * (option) `role_transaction` : voir `TransactionMode` -## 15. ConditionCommitment : conditions d'engagement +## 15. Conditioncommit : conditions d'engagement * (option) `role_artefact` * (option) `role_transaction` : voir `TransactionMode` diff --git a/doc/RelayPages.md b/doc/RelayPages.md index 0b7aafc..9267f7a 100644 --- a/doc/RelayPages.md +++ b/doc/RelayPages.md @@ -15,14 +15,14 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 6. [Interface Client Web](#InterfaceClientWeb) * 6.1. [Structure HTML de Base](#StructureHTMLdeBase) * 6.2. [Page de création d'une identité numérique (create)](#Pagedecrationduneidentitnumriquecreate) - * 6.2.1. [Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover`](#PagedeslectiondelItemProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover) - * 6.2.2. [Page d'enrolement dans un `ItemProcess` (`onboarding`)](#PagedenrolementdansunItemProcessonboarding) + * 6.2.1. [Page de sélection de `Process` et des membres en charge de renvoyer les shards de la clé `recover`](#PagedeslectiondelProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover) + * 6.2.2. [Page d'enrolement dans un `Process` (`onboarding`)](#PagedenrolementdansunProcessonboarding) * 6.2.3. [Page de téléchargement des images de login des third parties](#Pagedetlchargementdesimagesdelogindesthirdparties) * 6.3. [Page de récupération d'une identité numérique (`recover`)](#Pagedercuprationduneidentitnumriquerecover) * 6.4. [Page de révocation d'une identité numérique (`revoke`)](#Pagedervocationduneidentitnumriquerevoke) - * 6.5. [Page de la liste des `ItemProcess`](#PagedelalistedesItemProcess) - * 6.6. [Page de Détail d'un `ItemProcess`](#PagedeDtaildunItemProcess) - * 6.7. [Page socle des `ItemProcess`](#PagesocledesItemProcess) + * 6.5. [Page de la liste des `Process`](#PagedelalistedesProcess) + * 6.6. [Page de Détail d'un `Process`](#PagedeDtaildunProcess) + * 6.7. [Page socle des `Process`](#PagesocledesProcess) * 6.7.1. [4.7. Page de la liste d'un type d'`Item`](#PagedelalisteduntypedItem) * 6.7.2. [4.7. Page de détail d'un `Item`](#PagededtaildunItem) * 6.7.3. [4.7. Page de la liste des notifications](#Pagedelalistedesnotifications) @@ -43,7 +43,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) L'objectif de cette spécification est de définir les exigences et les fonctionnalités de l'interface client web pour l'authentification et l'identification des utilisateurs sur la plateforme 4NK Web5 Solution. -Tous les relais ont les mêmes pages, et partagent le SDK en Wasm de 4NK, leur liste d'`ItemPeer` et leur liste `ItemProcess`. +Tous les relais ont les mêmes pages, et partagent le SDK en Wasm de 4NK, leur liste d'`Peer` et leur liste `Process`. ## 4. Portée @@ -105,9 +105,9 @@ Cadre HML commun aux pages des relais : ### 6.2. Page de création d'une identité numérique (create) -#### 6.2.1. Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover` +#### 6.2.1. Page de sélection de `Process` et des membres en charge de renvoyer les shards de la clé `recover` -#### 6.2.2. Page d'enrolement dans un `ItemProcess` (`onboarding`) +#### 6.2.2. Page d'enrolement dans un `Process` (`onboarding`) #### 6.2.3. Page de téléchargement des images de login des third parties @@ -115,11 +115,11 @@ Cadre HML commun aux pages des relais : ### 6.4. Page de révocation d'une identité numérique (`revoke`) -### 6.5. Page de la liste des `ItemProcess` +### 6.5. Page de la liste des `Process` -### 6.6. Page de Détail d'un `ItemProcess` +### 6.6. Page de Détail d'un `Process` -### 6.7. Page socle des `ItemProcess` +### 6.7. Page socle des `Process` #### 6.7.1. 4.7. Page de la liste d'un type d'`Item` diff --git a/doc/Silent-Payments-Specs.md b/doc/Silent-Payments-Specs.md index 64afde0..5356b21 100644 --- a/doc/Silent-Payments-Specs.md +++ b/doc/Silent-Payments-Specs.md @@ -59,7 +59,7 @@ Une fois le `Prd` finalisé, une transaction SP est réalisée, dans cette trans 1.2. Le hash du `Prd` 1.3. Le hash du process 1.4. Le hash de la valeur de la signature (attribut `sig_value` du Prd) - 1.5. Le hash de l'`item_name` de l'`Item` concerné (le cas échéant) + 1.5. Le hash de `item_name` de `Item` concerné (le cas échéant) 1.6. Le hash du `Prd` d'origine associé au `Prd` (le cas échéant) 1.7. Le hash du `Pcd` d'origine associé au `Prd` (le cas échéant) 1.8. Le hash du `Pcd` de référence associé au `Prd` (le cas échéant) @@ -67,19 +67,19 @@ Une fois le `Prd` finalisé, une transaction SP est réalisée, dans cette trans 1.10. Le hash d'un `Amount`de dépôt (le cas échéant) 1.11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant) -Pour des raison de confidentialité, le `Role` associé à l'`item_name` du `Prd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`. +Pour des raison de confidentialité, le `Role` associé à `item_name` du `Prd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`. ## 8. Envoi de la transaction SP Afin d'améliorer la rélisience du broadcast des transactions, la transaction est envoyée à la fois : -1. Dans un `PrdMessage` à un membre du rôle `member` du `ItemProcess` concerné et +1. Dans un `PrdMessage` à un membre du rôle `member` du `Process` concerné et 2. Dans le `Message` du `PrdMessage` sur les relais ### 8.1. Dans un `PrdMessage` Dans l'attribut `raw_transaction_list` du `PrdMessage` associé à la transaction SP. -La transaction sera broadcastée par les noeuds de signet du membre du `Role` `member` du `ItemProcess` concerné qui a reçu ce message, il devra alors avoir un noeud de signet pour le broadcast. +La transaction sera broadcastée par les noeuds de signet du membre du `Role` `member` du `Process` concerné qui a reçu ce message, il devra alors avoir un noeud de signet pour le broadcast. ### 8.2. Dans un `Message` du `PrdMessage` diff --git a/doc/Specs-Code.md b/doc/Specs-Code.md index 95d4515..c26ce59 100644 --- a/doc/Specs-Code.md +++ b/doc/Specs-Code.md @@ -11,36 +11,39 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 2. [Table des matières](#Tabledesmatires) * 3. [Documents de référence](#Documentsderfrence) * 4. [Choix des formats de données](#Choixdesformatsdedonnes) - * 4.1. [Strings](#Strings) - * 4.2. [Hexadécimales](#Hexadcimales) - * 4.3. [Tableaux de bytes](#Tableauxdebytes) - * 4.3.1. [8 Bytes (64 bits)](#Bytes64bits) - * 4.3.2. [16 Bytes (128 bits)](#Bytes128bits) - * 4.3.3. [32 Bytes (256 bits)](#32Bytes256bits) - * 4.3.4. [64 Bytes (512 bits)](#64Bytes512bits) - * 4.3.5. [Précautions générales pour la manipulation des tableaux de bytes](#Prcautionsgnralespourlamanipulationdestableauxdebytes) - * 4.4. [Format Base64](#FormatBase64) - * 4.5. [Différence entre Bytes et Bits](#DiffrenceentreBytesetBits) - * 4.6. [Little Endian et Big Endian](#LittleEndianetBigEndian) - * 4.7. [Conversions de données](#Conversionsdedonnes) - * 4.7.1. [Conversion entre Strings et Hexadécimales](#ConversionentreStringsetHexadcimales) - * 4.7.2. [Conversion entre Tableaux de Bytes et Format Base64](#ConversionentreTableauxdeBytesetFormatBase64) - * 4.7.3. [Conversion entre Bytes et Bits](#ConversionentreBytesetBits) - * 4.7.4. [Gestion de Little Endian et Big Endian](#GestiondeLittleEndianetBigEndian) - * 4.7.5. [Bonnes Pratiques Générales](#BonnesPratiquesGnrales) -* 5. [Gestion des erreurs](#Gestiondeserreurs) -* 6. [Journalisation et monitoring](#Journalisationetmonitoring) -* 7. [Tests](#Tests) - * 7.1. [Stratégie de test](#Stratgiedetest) - * 7.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires) - * 7.3. [Plan d'intégration](#Plandintgration) - * 7.4. [Plan de charge](#Plandecharge) -* 8. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser) -* 9. [Critères d'acceptation](#Critresdacceptation) -* 10. [CI/CD](#CICD) -* 11. [Maintenance](#Maintenance) -* 12. [Exemples de Code](#ExemplesdeCode) -* 13. [Todo](#Todo) +* 4.1. [Strings](#Strings) +* 4.2. [Hexadécimales](#Hexadcimales) +* 4.3. [Tableaux de bytes](#Tableauxdebytes) +* 4.3.1. [8 Bytes (64 bits)](#Bytes64bits) +* 4.3.2. [16 Bytes (128 bits)](#Bytes128bits) +* 4.3.3. [32 Bytes (256 bits)](#32Bytes256bits) +* 4.3.4. [64 Bytes (512 bits)](#64Bytes512bits) +* 4.3.5. [Précautions générales pour la manipulation des tableaux de bytes](#Prcautionsgnralespourlamanipulationdestableauxdebytes) +* 4.4. [Format Base64](#FormatBase64) +* 4.5. [Différence entre Bytes et Bits](#DiffrenceentreBytesetBits) +* 4.6. [Little Endian et Big Endian](#LittleEndianetBigEndian) +* 4.7. [Conversions de données](#Conversionsdedonnes) +* 4.7.1. [Conversion entre Strings et Hexadécimales](#ConversionentreStringsetHexadcimales) +* 4.7.2. [Conversion entre Tableaux de Bytes et Format Base64](#ConversionentreTableauxdeBytesetFormatBase64) +* 4.7.3. [Conversion entre Bytes et Bits](#ConversionentreBytesetBits) +* 4.7.4. [Gestion de Little Endian et Big Endian](#GestiondeLittleEndianetBigEndian) +* 4.7.5. [Bonnes Pratiques Générales](#BonnesPratiquesGnrales) +* 5. [Recommandations entre l'usage de HashMap ou d'un Vec (en Rust)](#RecommandationsentrelusagedeHashMapoudunVecenRust) +* 5.1. [Utilisez un Vec si](#UtilisezunVecsi) +* 5.2. [Utilisez un HashMap si](#UtilisezunHashMapsi) +* 6. [Gestion des erreurs](#Gestiondeserreurs) +* 7. [Journalisation et monitoring](#Journalisationetmonitoring) +* 8. [Tests](#Tests) +* 8.1. [Stratégie de test](#Stratgiedetest) +* 8.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires) +* 8.3. [Plan d'intégration](#Plandintgration) +* 8.4. [Plan de charge](#Plandecharge) +* 9. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser) +* 10. [Critères d'acceptation](#Critresdacceptation) +* 11. [CI/CD](#CICD) +* 12. [Maintenance](#Maintenance) +* 13. [Exemples de Code](#ExemplesdeCode) +* 14. [Todo](#Todo)