diff --git a/doc/Auth-Specs.md b/doc/Auth-Specs.md index b3d77d7..6e6dd30 100644 --- a/doc/Auth-Specs.md +++ b/doc/Auth-Specs.md @@ -37,19 +37,19 @@ Voir [Doc_references.md](Doc_references.md). ## 4. 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 `process`. +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` . 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 Payment 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`. -Les utilisateurs sont reconnus par une adresse Silent Payment 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`. +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`. -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`). +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`). ## 5. 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 process 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 `ItemProcess` 4NK. ## 6. Fonctionnalité de récupération de mot de passe @@ -134,7 +134,7 @@ Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Vo 1.1. `Part1`, c'est la partie qui sera chiffrée (AES-GCM 256 bits) par le mot de passe et stockée en cache dans une image dite de login. - 1.2. `Part2`, c'est la partie qui sera décomposée 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 du process. + 1.2. `Part2`, c'est la partie qui sera décomposée 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 du `ItemProcess`. 2. Une `pre-id Part1EncHash` qui identifie l'utilisateur est générée par le hash (SHA 256) de la `Part1` et du mot de passe de l'utilisateur. @@ -161,7 +161,7 @@ Dans l'ordre on réalise donc les opérations suivantes donc : #### 9.1.2. Backup de `Part2Enc` -Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant les membres du rôle `member` du `process` choisi. +Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant les membres du rôle `member` du `ItemProcess` choisi. Chacun de ses membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `RequestPrdResponse` en réponse à un `RequestPrdKeyBackup`. @@ -174,7 +174,7 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : 5. Atttente de la réception des `RequestPrdResponse` en réponse aux `RequestPrdKeyBackup` (confirmations). 6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. 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_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du process. +6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` 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` @@ -183,17 +183,17 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : Pour être `onboard` dans un process, c'est-à-dire avoir un rôle, il faut : 1. s'ajouter (objet `Member`) dans la liste des membres et -2. s'ajouter son adresse SP dans les adresses d'un des rôles du process. +2. s'ajouter son adresse SP dans les adresses d'un des rôles du `ItemProcess`. ###### Mise à jour de la liste des membres -Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce `RequestPrd` devra recevoir des membres du rôle `Member` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`. +Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce `RequestPrd` devra recevoir des membres du rôle `Member` du `ItemProcess` les `RequestPrdResponse` correspondant aux critères de validation du `ItemProcess` . C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que `metadadata` privée (chiffrée par la clé de dépense du signet) dans un `RequestPcd` (et les `RequestPrdUpdate` correspondant). Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet. -Les metadatas des membres propres au process sont décrits dans le process et doivent compléter les metadatas de l'`ItemMember`. +Les metadatas des membres propres au `ItemProcess` sont décrits dans le `ItemProcess` et doivent compléter les metadatas de l'`ItemMember`. L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md). @@ -208,11 +208,11 @@ L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Dat ###### Mise à jour de la liste des process -Pour mettre à jour la liste des process il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `process`. Ce `RequestPrd` devra recevoir des membres du rôle `Process` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`. +Pour mettre à jour la liste des `ItemProcess` il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `ItemProcess` . Ce `RequestPrd` devra recevoir des membres du rôle `ItemProcess` du `ItemProcess` les `RequestPrdResponse` correspondant aux critères de validation du `ItemProcess` . L'`ItemProcess` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md). -Demande d'update de la liste des membres ( RequestPcd) d'un process vers chaque membre du rôle `Member` du process.: +Demande d'update de la liste des membres ( RequestPcd) d'un `ItemProcess` vers chaque membre du rôle `Member` du `ItemProcess`.: 1. Création d'un `ItemProcess` correspondant à l'utilisateur. 2. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemProcess` créé. @@ -222,7 +222,7 @@ Demande d'update de la liste des membres ( RequestPcd) d'un process vers chaque 6. Envoi du `Message` du `RequestPrdKeyHello` à destination du membre. 7. Réception des `RequestPrdResponse` en réponse aux `RequestPrdKeyHello` et mise à jour des listes depuis les `RequestPcd` correspondants. 8. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`. -9. Redirection vers la page du process sur le relai. +9. Redirection vers la page du `ItemProcess` sur le relai. ##### Clés de révocation (`revoke`) @@ -232,7 +232,7 @@ L'envoi d'une révocation est identique à la création d'une nouvelle adresse v ##### 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 process. 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 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`. 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. @@ -254,17 +254,17 @@ Puis depuis la liste des membres du process, pour chacun des membres : 5. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`. 6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. 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_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du process. +6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` 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` -Demande d'update de la liste des membres ( RequestPcd) d'un process : +Demande d'update de la liste des membres ( RequestPcd) d'un `ItemProcess` : 1. Création et envoi des `RequestPrdList`. 2. Réception des `RequestPrdResponse` en réponse aux `RequestPrdList` et mise à jour des listes depuis les `RequestPcd` correspondants. 3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques. 4. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemMember` créé. -5. Redirection vers la page du process sur le relai. +5. Redirection vers la page du `ItemProcess` sur le relai. ## 10. Exemples de Code diff --git a/doc/Doc_references.md b/doc/Doc_references.md index f28e33f..a11d3ad 100644 --- a/doc/Doc_references.md +++ b/doc/Doc_references.md @@ -16,7 +16,7 @@ * **Authentification**: [Auth.md](Auth-Specs.md) * **Items**: [Item-Specs.md](Item-Specs.md) * **RequestPrd et RequestPcd**: [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md) -* **Messages et transactions SP**: [Message-SP-Specs.md] +* **Messages des relais**: [Message-Specs.md] * **Process et roles**: [Process-Role-Specs.md](Process-Role-Specs.md) * **Transactions Silent Payment**: [Silent-Payment-Specs.md](Silent-Payment-Specs.md) diff --git a/doc/Item-Specs.md b/doc/Item-Specs.md index 36fdf19..109c3a2 100644 --- a/doc/Item-Specs.md +++ b/doc/Item-Specs.md @@ -33,7 +33,7 @@ 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 `process`, il peut y avoir une quantité infinie de type d'`artefacts` différents par process. +* **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`. * **Payment, 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. ### 3.2. Composition et Fonction diff --git a/doc/Messages-SP-Specs.md b/doc/Messages-Specs.md similarity index 90% rename from doc/Messages-SP-Specs.md rename to doc/Messages-Specs.md index a46196a..0f1a330 100644 --- a/doc/Messages-SP-Specs.md +++ b/doc/Messages-Specs.md @@ -90,13 +90,13 @@ Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (d Le cache est constitué de 2 parties : 1. `public` : - * Liste partagée des process avec les relais (agrégée au fil des relais découverts par le partage des listes de process dans les messages). - * Liste partagée des process complets reçus depuis les mises à jour des parties prenantes. + * Liste partagée des `ItemProcess` avec les relais (agrégée au fil des relais découverts par le partage des listes de `ItemProcess` dans les messages). + * Liste partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes. 2. `private` : - * Liste non partagée des process (agrégée à partir de process communiqués de façon confidentielle). - * Liste non partagée des process complets reçus depuis les mises à jour des parties prenantes. + * Liste non partagée des `ItemProcess` (agrégée à partir de `ItemProcess` communiqués de façon confidentielle). + * Liste non partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes. -Dans chaque partie, les process sont stockés sous forme d'objets `SharedProcess` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)). +Dans chaque partie, les `ItemProcess` sont stockés sous forme d'objets `SharedProcess` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)). ### 5.3. 5.3. Liste des hashs des messages reçus @@ -125,7 +125,7 @@ Le cache contient une liste des sockets ouverts, répartie en 2 parties : ### 6.2. 6.2. SharedProcessList -`SharedProcessList` est une liste de process. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de process. +`SharedProcessList` est une liste de `ItemProcess`. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de `ItemProcess`. ### 6.3. 6.3. Taille des données @@ -137,7 +137,7 @@ Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail ### 6.5. 6.5. Adresse SP de faucet -L'utilisateur fournit aux relais une adresse Silent Payment (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client). +L'utilisateur fournit aux relais une`adresse SP` (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client). L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction contient un output supplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant. @@ -163,31 +163,19 @@ Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` o #### 7.1.2. 7.1.2. Envoi du message de type `MessageConnect` à chaque relais -L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process. +L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. Il n'y a pas de retour attendu pour ce message. ### 7.2. 7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message` -Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. +Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. -L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process. +L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. ### 7.3. 7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message` -Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur des outputs aux indexs suivants: - -1. Le hash du message de type `Message` correspondant -2. Le hash du `RequestPrd` -3. Le hash du process -4. Le hash de l'`item_name` de l'`Item` concerné -5. Le hash de la valeur de la signature (attribut `sig_value` du RequestPrd) -6. Le hash du `RequestPrd` d'origine associé au `RequestPrd` (le cas échéant) -7. Le hash du `RequestPcd` d'origine associé au `RequestPrd` (le cas échéant) -8. Le hash du `RequestPcd` de référence associé au `RequestPrd` (le cas échéant) -9. Le hash d'un `Amount` de paiement (le cas échéant) -10. Le hash d'un `Amount`de dépôt (le cas échéant) -11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant) +Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés (voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md)). : La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les champs suivants : @@ -217,9 +205,9 @@ Pour les `RequestPrd` de type `RequestPrdKeyHello` : * `part_1_enc_hash_enc_by_sp_shared_secret` -Puis le `RequestPrd` est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. +Puis le `RequestPrd` est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. -L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process. +L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. ### 7.4. 7.4. Traitement des messages de type `Message` par les clients @@ -232,9 +220,9 @@ Le client réalise les contrôles suivants : Le client met à jour ses propres listes suivantes : * Liste des relais depuis la liste partagée par le relais `SharedPeerList`. -* Liste des process depuis la liste partagée par le relais `SharedProcessList`. +* Liste des `ItemProcess` depuis la liste partagée par le relais `SharedProcessList`. -Déchiffrement du message avec la `ProcessKey` du process et contrôles suivants : +Déchiffrement du message avec la `ProcessKey` du `ItemProcess` et contrôles suivants : * Calcul du hash du `RequestPcd` ou `RequestPrd` et vérification de la non-existence du hash dans le cache. * Voir [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md) pour les détails des contrôles. @@ -256,7 +244,7 @@ Le relais réalise les contrôles suivants : Le relais met à jour ses propres listes suivantes : * Liste des relais depuis la liste partagée par le client `SharedPeerList`. -* Liste des process depuis la liste partagée par le client `SharedProcessList`. +* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`. Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client. @@ -266,7 +254,7 @@ Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse d ### 8.2. 8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais -Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process. +Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. @@ -285,7 +273,7 @@ Le relais réalise les contrôles suivants : Le relais met à jour ses propres listes suivantes : * Liste des relais depuis la liste partagée par le client `SharedPeerList`. -* Liste des process depuis la liste partagée par le client `SharedProcessList`. +* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`. Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client. @@ -295,19 +283,19 @@ Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse d ### 9.1. 9.1. Broadcast des messages de type `Message` vers les relais -Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process. +Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. Envoi vers chaque relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant. -Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de process (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai). +Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess` (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai). Il n'y a pas de retour attendu pour ce message. ### 9.2. 9.2. Broadcast des messages de type `Message` vers les clients connectés -Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de process. +Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. Envoi vers chaque client d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant. diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index d4606a7..b0c6b75 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -10,7 +10,7 @@ * 5.2. [Réception](#Rception-1) * 6. [Fonction des RequestPrd](#FonctiondesRequestPrd) * 6.1. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles) - * 6.2. [Fonction des transactions silent payment SP associées aux RequestPrd](#FonctiondestransactionssilentpaymentSPassociesauxRequestPrd) + * 6.2. [Fonction des`transaction SP` associées aux RequestPrd](#FonctiondestransactionssilentpaymentSPassociesauxRequestPrd) * 6.3. [Création et envoi](#Crationetenvoi-1) * 6.4. [Réception](#Rception-1) * 7. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd) @@ -61,7 +61,7 @@ Voir [Doc_references.md](Doc_references.md). Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais. -Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné. +Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. **Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md). @@ -69,7 +69,7 @@ Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais. -Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné. +Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. A la réception des messages, ils sont tous déchiffrés puis conservés ou non en fonction du `process hash` du `RequestPcd` ou du `RequestPrd` (dans l'attribut `request`). Si le `process hash` n'est pas reconnu, le message est ignoré. @@ -87,7 +87,7 @@ Pour les `RequestPcd` et les `RequestPrd` il faut vérifier que le hash du docum 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 `process` et les `members` concernés. +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 @@ -96,7 +96,7 @@ La création d'un `RequestPcd` suit plusieurs étapes : 1. **Chargement de la dernière version de la liste ( RequestPcd)**: Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage. 2. **Mise à jour**: Ajouts et modifications eventuelles des `Item` 3. **Chiffrement des attributs**: Chiffrement des attributs de chaque Item selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)). -4. **Chiffrement du RequestPcd**: Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `process` concerné. +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 @@ -105,7 +105,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 1. Traitements communs aux `RequestPcd` et RequestPrd 2. Recherche des `RequestPrd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` de ces `RequestPrd` et attente si nécessaire. -3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `process` concerné. +3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `ItemProcess` concerné. 4. Déchiffrage des attributs confidentiels des `Item` des `RequestPcd` avec les clés de déchiffrement depuis l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret` des RequestPrd. 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. @@ -114,7 +114,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 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. -Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `RequestPcd` sont chiffrées dans les `RequestPrd` avec le chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une transaction Silent Payment SP (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `process`). +Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `RequestPcd` sont chiffrées dans les `RequestPrd` avec le chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une`transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `ItemProcess` ). 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. @@ -139,30 +139,25 @@ Il est aussi possible de partager des clés de chiffrement ad'hoc via `certif_ke En plus des horodatages automatique, il est possible de déclarer un timestamp dans `timestamp_declared` qui ne sera pas pris en compte dans le traitement mais qui est ainsi tracé dans les éléments de preuves. -Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs roles dans les process et pour préciser les adresses de réponses en cas d'utilisations en multi-devices. +Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs roles dans les `ItemProcess` et pour préciser les adresses de réponses en cas d'utilisations en multi-devices. 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.2. Fonction des transactions silent payment SP associées aux RequestPrd - -La clé `KeyConfidential` d'une transaction Silent Payment SP est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges. - -La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des `RequestPrd` donc de la validation des données des `RequestPcd`.Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et `RequestPrd` (sauf `RequestPrdKeyBackup`) et des `RequestPcd`.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication. - -Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des `RequestPrd` sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non). - ### 6.3. Création et envoi La création d'un `RequestPrd` suit plusieurs étapes : 1. **Chargement des clés de chiffrement confidentiel'**: Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd. -2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `process` concerné. -3. **Création de l'adresse SP**: (Sauf `RequestPRDKeyBackup`) Création d'une adresse Silent Payment SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain. +2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné. +3. **Création de l'adresse SP**: Création d'une`adresse SP` SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain. 4. **Création du message**: Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet 5. **Sélection des relais pour le message**: Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées. -6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP. -7. **Envoi du message**: Envoi du message aux relais -8. **Envoi de la transaction**: (Sauf `RequestPRDKeyBackup`) envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la transaction Silent Payment SP avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`. +6. **Sélection des noeuds de signet pour la transaction silent Payment (SP) \***: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la`transaction SP`. +7. **Chiffrement des données confidentielles du `request_prd`**: Chiffrement des données confidentielles du `request_prd` avec la `KeyConfidential` de la`transaction SP`. +8. **Envoi du message**: Envoi du message aux relais +9. **Envoi de la transaction**: envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la`transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`. + +Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md). ### 6.4. Réception @@ -174,9 +169,10 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 4. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash` et attente si nécessaire et traitement de ceux ci. 5. Vérification de la conformité des `RequestPrd` en relation. 6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci. -7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du `RequestPrd` dans l'output `2` de la transaction. +7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` de la`transaction SP` correspondante via hash du `RequestPrd` dans l'output `2` de la transaction. 8. Mise à jour du cache pour les traitement des RequestPrd. -9. Traitements spécifiques au type de RequestPrd. +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) @@ -184,16 +180,14 @@ Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de ### 7.1. Création et envoi -L'envoi d'un `RequestPrdList` suit plusieurs étapes : - -Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 La réception d'un `RequestPrdList` suit plusieurs étapes : 1. Traitements des `RequestPrd` -2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la transaction Silent Payment SP associée avec +2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la`transaction SP` associée avec 3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné. 4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné. 5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdRResponse` avec : @@ -207,13 +201,13 @@ Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateu Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties. -Permet la communication des transactions Silent Payment SP au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain. +Permet la communication des`transaction SP` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain. Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`. ### 8.1. Création et envoi -Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la transaction Silent Payment 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` 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 @@ -221,11 +215,9 @@ La réception d'un `RequestPrdMessage` suit plusieurs étapes : 1. Traitements des `RequestPrd` 2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`. -3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné. -4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné. -5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdResponse` avec : - 5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash` - 5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash` +3. Notificaiton et attente du retour de l'utilisateur (valeur de la signature et message de réponse) +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 @@ -235,13 +227,13 @@ Basé sur le `RequestPrd`. avec des additions pour spécifier les modifications 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, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `process`, la mise à jour de la liste des `process` permettra de leur affecter un nouveau role. +Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `ItemProcess` , la mise à jour de la liste des `ItemProcess` permettra de leur affecter un nouveau role. Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd. ### 9.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 @@ -257,7 +249,7 @@ Crucial pour les processus qui nécessitent une confirmation explicite de récep ### 10.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 @@ -273,7 +265,7 @@ Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, pui ### 11.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 @@ -283,7 +275,7 @@ Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards as ### 12.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 @@ -295,7 +287,7 @@ Important pour les processus d'onboarding de nouveaux membres, de réinitialisat ### 13.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. +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 diff --git a/doc/Process-roles-Specs.md b/doc/Process-roles-Specs.md index 4c966e5..38bc3ac 100644 --- a/doc/Process-roles-Specs.md +++ b/doc/Process-roles-Specs.md @@ -29,7 +29,7 @@ numbering=true autoSave=true /vscode-markdown-toc-config --> -# Process et roles +# `ItemProcess` et roles ## 1. Objectif @@ -43,7 +43,7 @@ Voir [Doc_references.md](Doc_references.md). ## 4. 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 `process`. 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 : * **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. diff --git a/doc/Silent-Payment-Specs.md b/doc/Silent-Payment-Specs.md index b182307..277403b 100644 --- a/doc/Silent-Payment-Specs.md +++ b/doc/Silent-Payment-Specs.md @@ -1,7 +1,8 @@ * 1. [Objectif](#Objectif) * 2. [Portée](#Porte) -* 3. [3. Documents de référence](#Documentsderfrence) +* 3. [Documents de référence](#Documentsderfrence) +* 4. [Structure des outputs](#Structuredesoutputs) ## 1. Objectif - ## 2. Portée -## 3. 3. Documents de référence +## 3. Documents de référence Voir [Doc_references.md](Doc_references.md). + +## 4.  Fontion + +La transaction SP à plusieurs objectifs : + +1. Permettre l'horodatage de l'empreinte des `RequestPrd` sur la side chain (hors `RequestPrdKeyBackup` et les `RequestPrdKeyMessage` sans message confidentiel). +2. Permettre le partage de la `keyConfidential` pour les `RequestPrd` afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le `RequestPrd`. + +La clé `KeyConfidential` d'une`transaction SP` est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. + +Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges. + +La`transaction SP` a aussi une fonction d'horodate et de preuve de publication des `RequestPrd` donc de la validation des données des `RequestPcd`.Les outputs de la`transaction SP` contiennent les empreintes cryptographiques des `messages` et `RequestPrd` et des `RequestPcd`.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication. + +Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des `RequestPrd` sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non). + +Il y a une `transactions SP` pour tous les types de `RequestPrd` sauf pour les `RequestPrdKeyBackup` et les `RequestPrdKeyMessage` ayant l'attribut `raw_transaction_list` non vide. + +## 4.  Structure des outputs + +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 +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.1. Le hash du message de type `Message` correspondant + 1.2. Le hash du `RequestPrd` + 1.3. Le hash du process + 1.4. Le hash de la valeur de la signature (attribut `sig_value` du RequestPrd) + 1.5. Le hash de l'`item_name` de l'`Item` concerné (le cas échéant) + 1.6. Le hash du `RequestPrd` d'origine associé au `RequestPrd` (le cas échéant) + 1.7. Le hash du `RequestPcd` d'origine associé au `RequestPrd` (le cas échéant) + 1.8. Le hash du `RequestPcd` de référence associé au `RequestPrd` (le cas échéant) + 1.9. Le hash d'un `Amount` de paiement (le cas échéant) + 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 `RequestPrd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`. + +## 5. 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 `RequestPrdMessage` à un membre du rôle `member` du `ItemProcess` concerné et +2. Dans le `Message` du `RequestPrdMessage` sur les relais + +### Dans un `RequestPrdMessage` + +Dans l'attribut `raw_transaction_list` du `RequestPrdMessage` 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. + +### Dans un `Message` du `RequestPrdMessage` + +Dans l'attribut `raw_transaction_list` du `Message` associé à la transaction SP. +La transaction sera broadcastée par les noeuds de signet des relais. diff --git a/doc/Specs-Code.md b/doc/Specs-Code.md index 60d2bcc..df1ddc1 100644 --- a/doc/Specs-Code.md +++ b/doc/Specs-Code.md @@ -34,13 +34,13 @@ Tous les flux sont reçus par autant de relais et de membres de même rôles. Un Les arrêts de la blockchain dans son ensemble n'entraînent pas d'interruption de service, car les horodatages sont non bloquants, l'impact est une diminution de la preuve le temps de "ré-ancrer" ce qui n'aurait pas pu l'être. L'arrêt de nœuds de la blockchain pourrait ralentir la propagation des informations dans les scénarios les plus critiques, sans impact majeur sur le fonctionnement. -Les arrêts des membres dans les process dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des process pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des process est en charge de l'arbitrage pour la bonne restitution des actions. +Les arrêts des membres dans les `ItemProcess` dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des `ItemProcess` pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des `ItemProcess` est en charge de l'arbitrage pour la bonne restitution des actions. 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 -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 process (possible de segmenter par zones et services). +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). Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair. diff --git a/doc/Specs-Datamodel.md b/doc/Specs-Datamodel.md index d7c63a4..99404da 100644 --- a/doc/Specs-Datamodel.md +++ b/doc/Specs-Datamodel.md @@ -1,96 +1,96 @@  * 1. [Documents de référence](#Documentsderfrence) -* 2. [Conditions](#Conditions) - * 2.1. [ConditionCap](#ConditionCap) - * 2.2. [ConditionCommitment](#ConditionCommitment) - * 2.3. [ConditionDeposit](#ConditionDeposit) - * 2.4. [ConditionOrchestration](#ConditionOrchestration) - * 2.5. [ConditionPayment](#ConditionPayment) - * 2.6. [Condition RequestPrdAddressSet](#ConditionRequestPrdAddressSet) - * 2.7. [ConditionPublish](#ConditionPublish) -* 3. [Methods](#Methods) - * 3.1. [DepositMethod](#DepositMethod) - * 3.2. [CommitmentMethod](#CommitmentMethod) - * 3.3. [PaymentMethod](#PaymentMethod) -* 4. [Items](#Items) - * 4.1. [ItemArtefact](#ItemArtefact) - * 4.2. [ItemCommitmentPublicAttributeGroup](#ItemCommitmentPublicAttributeGroup) - * 4.3. [ItemMemberPublicAttributeGroup](#ItemMemberPublicAttributeGroup) - * 4.4. [ItemDepositPublicAttributeGroup](#ItemDepositPublicAttributeGroup) - * 4.5. [ItemCommitmentRoleConfidentialAttributeGroup](#ItemCommitmentRoleConfidentialAttributeGroup) - * 4.6. [ItemCommitmentPrivateAttributeGroup](#ItemCommitmentPrivateAttributeGroup) - * 4.7. [ItemCommitment](#ItemCommitment) - * 4.8. [ItemDepositRoleConfidentialAttributeGroup](#ItemDepositRoleConfidentialAttributeGroup) - * 4.9. [ItemDepositPrivateAttributeGroup](#ItemDepositPrivateAttributeGroup) - * 4.10. [ItemDeposit](#ItemDeposit) - * 4.11. [ItemEnum](#ItemEnum) - * 4.12. [ItemPaymentPublicAttributeGroup](#ItemPaymentPublicAttributeGroup) - * 4.13. [ItemPaymentRoleConfidentialAttributeGroup](#ItemPaymentRoleConfidentialAttributeGroup) - * 4.14. [ItemPaymentPrivateAttributeGroup](#ItemPaymentPrivateAttributeGroup) - * 4.15. [ItemPayment](#ItemPayment) - * 4.16. [ItemPeerPublicAttributeGroup](#ItemPeerPublicAttributeGroup) - * 4.17. [ItemPeerPrivateAttributeGroup](#ItemPeerPrivateAttributeGroup) - * 4.18. [ItemPeer](#ItemPeer) - * 4.19. [ItemProcess](#ItemProcess) - * 4.20. [ItemProcessPublicAttributeGroup](#ItemProcessPublicAttributeGroup) - * 4.21. [Item](#Item) -* 5. [Encryption](#Encryption) - * 5.1. [KeyEncryption](#KeyEncryption) - * 5.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) -* 6. [Messages](#Messages) - * 6.1. [Message](#Message) - * 6.2. [MessageConnect](#MessageConnect) - * 6.3. [MessageGeneric](#MessageGeneric) - * 6.4. [Pow](#Pow) - * 6.5. [SharedProcess](#SharedProcess) - * 6.6. [SharedPeer](#SharedPeer) -* 7. [Relay](#Relay) - * 7.1. [L1Node](#L1Node) - * 7.2. [L1Miner](#L1Miner) - * 7.3. [L2Node](#L2Node) - * 7.4. [L2Certif](#L2Certif) -* 8. [Metadata](#Metadata) - * 8.1. [MetadataContractPublic](#MetadataContractPublic) - * 8.2. [MetadataPrivate](#MetadataPrivate) - * 8.3. [MetadataRoleConfidential](#MetadataRoleConfidential) - * 8.4. [Amount](#Amount) - * 8.5. [Number](#Number) -* 9. [Request](#Request) -* 10. [RequestPcd](#RequestPcd) - * 10.1. [Pagination](#Pagination) - * 10.2. [RequestPcdItemEncAttributePublic](#RequestPcdItemEncAttributePublic) - * 10.3. [RequestPcdItemEncAttributeRoleConfidential](#RequestPcdItemEncAttributeRoleConfidential) - * 10.4. [RequestPcdItemEncAttributePrivate](#RequestPcdItemEncAttributePrivate) - * 10.5. [RequestPcdItemGenericEnc](#RequestPcdItemGenericEnc) - * 10.6. [RequestPcdItemEnc](#RequestPcdItemEnc) -* 11. [RequestPrd](#RequestPrd) - * 11.1. [RequestPrdResponse](#RequestPrdResponse) - * 11.2. [RequestPrdConfirm](#RequestPrdConfirm) - * 11.3. [RequestPrdKeyBackup](#RequestPrdKeyBackup) - * 11.4. [RequestPrdKeyHello](#RequestPrdKeyHello) - * 11.5. [RequestPrdList](#RequestPrdList) - * 11.6. [RequestPrdMessage](#RequestPrdMessage) - * 11.7. [RequestPrdResponse](#RequestPrdResponse-1) - * 11.8. [RequestPrdUpdate](#RequestPrdUpdate) -* 12. [Roles](#Roles) - * 12.1. [RolesGroup](#RolesGroup) - * 12.2. [RoleArtefact](#RoleArtefact) - * 12.3. [RoleDeposit](#RoleDeposit) - * 12.4. [RoleCommitment](#RoleCommitment) - * 12.5. [RoleMember](#RoleMember) - * 12.6. [RolePayment](#RolePayment) - * 12.7. [RoleProcess](#RoleProcess) - * 12.8. [Role](#Role) - * 12.9. [TransactionMode](#TransactionMode) - * 12.10. [RolePeer](#RolePeer) -* 13. [12. Rust considerations](#Rustconsiderations) - * 13.1. [General Implications for Project Objects](#GeneralImplicationsforProjectObjects) - * 13.2. [Debug](#Debug) - * 13.3. [Default](#Default) - * 13.4. [PartialEq, Eq](#PartialEqEq) - * 13.5. [Hash](#Hash) - * 13.6. [PartialOrd, Ord](#PartialOrdOrd) -* 14. [Todo](#Todo) +* 2. [Methods](#Methods) + * 2.1. [DepositMethod](#DepositMethod) + * 2.2. [CommitmentMethod](#CommitmentMethod) + * 2.3. [PaymentMethod](#PaymentMethod) +* 3. [Items](#Items) + * 3.1. [ItemArtefact](#ItemArtefact) + * 3.2. [ItemCommitmentPublicAttributeGroup](#ItemCommitmentPublicAttributeGroup) + * 3.3. [ItemMemberPublicAttributeGroup](#ItemMemberPublicAttributeGroup) + * 3.4. [ItemDepositPublicAttributeGroup](#ItemDepositPublicAttributeGroup) + * 3.5. [ItemCommitmentRoleConfidentialAttributeGroup](#ItemCommitmentRoleConfidentialAttributeGroup) + * 3.6. [ItemCommitmentPrivateAttributeGroup](#ItemCommitmentPrivateAttributeGroup) + * 3.7. [ItemCommitment](#ItemCommitment) + * 3.8. [ItemDepositRoleConfidentialAttributeGroup](#ItemDepositRoleConfidentialAttributeGroup) + * 3.9. [ItemDepositPrivateAttributeGroup](#ItemDepositPrivateAttributeGroup) + * 3.10. [ItemDeposit](#ItemDeposit) + * 3.11. [ItemEnum](#ItemEnum) + * 3.12. [ItemPaymentPublicAttributeGroup](#ItemPaymentPublicAttributeGroup) + * 3.13. [ItemPaymentRoleConfidentialAttributeGroup](#ItemPaymentRoleConfidentialAttributeGroup) + * 3.14. [ItemPaymentPrivateAttributeGroup](#ItemPaymentPrivateAttributeGroup) + * 3.15. [ItemPayment](#ItemPayment) + * 3.16. [ItemPeerPublicAttributeGroup](#ItemPeerPublicAttributeGroup) + * 3.17. [ItemPeerPrivateAttributeGroup](#ItemPeerPrivateAttributeGroup) + * 3.18. [ItemPeer](#ItemPeer) + * 3.19. [ItemProcess](#ItemProcess) + * 3.20. [ItemProcessPublicAttributeGroup](#ItemProcessPublicAttributeGroup) + * 3.21. [Item](#Item) +* 4. [Encryption](#Encryption) + * 4.1. [KeyEncryption](#KeyEncryption) + * 4.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) +* 5. [Messages](#Messages) + * 5.1. [Message](#Message) + * 5.2. [MessageConnect](#MessageConnect) + * 5.3. [MessageGeneric](#MessageGeneric) + * 5.4. [Pow](#Pow) + * 5.5. [SharedProcess](#SharedProcess) + * 5.6. [SharedPeer](#SharedPeer) +* 6. [Relay](#Relay) + * 6.1. [L1Node](#L1Node) + * 6.2. [L1Miner](#L1Miner) + * 6.3. [L2Node](#L2Node) + * 6.4. [L2Certif](#L2Certif) +* 7. [Metadata](#Metadata) + * 7.1. [MetadataContractPublic](#MetadataContractPublic) + * 7.2. [MetadataPrivate](#MetadataPrivate) + * 7.3. [MetadataRoleConfidential](#MetadataRoleConfidential) + * 7.4. [Amount](#Amount) + * 7.5. [Number](#Number) +* 8. [Request](#Request) +* 9. [ RequestPcd](#RequestPcd) + * 9.1. [Pagination](#Pagination) + * 9.2. [ RequestPcdItemEncAttributePublic](#RequestPcdItemEncAttributePublic) + * 9.3. [ RequestPcdItemEncAttributeRoleConfidential](#RequestPcdItemEncAttributeRoleConfidential) + * 9.4. [ RequestPcdItemEncAttributePrivate](#RequestPcdItemEncAttributePrivate) + * 9.5. [ RequestPcdItemGenericEnc](#RequestPcdItemGenericEnc) + * 9.6. [ RequestPcdItemEnc](#RequestPcdItemEnc) +* 10. [RequestPrd](#RequestPrd) + * 10.1. [RequestPrdResponse](#RequestPrdResponse) + * 10.2. [RequestPrdConfirm](#RequestPrdConfirm) + * 10.3. [RequestPrdKeyBackup](#RequestPrdKeyBackup) + * 10.4. [RequestPrdKeyHello](#RequestPrdKeyHello) + * 10.5. [RequestPrdList](#RequestPrdList) + * 10.6. [RequestPrdMessage](#RequestPrdMessage) + * 10.7. [RequestPrdResponse](#RequestPrdResponse-1) + * 10.8. [RequestPrdUpdate](#RequestPrdUpdate) +* 11. [Roles](#Roles) + * 11.1. [Role](#Role) + * 11.2. [Conditions](#Conditions) + * 11.2.1. [ConditionCap](#ConditionCap) + * 11.2.2. [ConditionCommitment](#ConditionCommitment) + * 11.2.3. [ConditionDeposit](#ConditionDeposit) + * 11.2.4. [ConditionOrchestration](#ConditionOrchestration) + * 11.2.5. [ConditionPayment](#ConditionPayment) + * 11.2.6. [Condition RequestPrdAddressSet](#ConditionRequestPrdAddressSet) + * 11.2.7. [ConditionPublish](#ConditionPublish) + * 11.2.8. [RolesGroup](#RolesGroup) + * 11.2.9. [RoleArtefact](#RoleArtefact) + * 11.2.10. [RoleDeposit](#RoleDeposit) + * 11.2.11. [RoleCommitment](#RoleCommitment) + * 11.2.12. [RoleMember](#RoleMember) + * 11.2.13. [RolePayment](#RolePayment) + * 11.2.14. [RoleProcess](#RoleProcess) + * 11.3. [TransactionMode](#TransactionMode) + * 11.4. [RolePeer](#RolePeer) +* 12. [12. Rust considerations](#Rustconsiderations) + * 12.1. [ General Implications for Project Objects](#GeneralImplicationsforProjectObjects) + * 12.2. [ Debug](#Debug) + * 12.3. [ Default](#Default) + * 12.4. [ PartialEq, Eq](#PartialEqEq) + * 12.5. [ Hash](#Hash) + * 12.6. [ PartialOrd, Ord](#PartialOrdOrd) +* 13. [Todo](#Todo) # Specs - Datas -## 1. Documents de référence +## 1. Documents de référence Voir [Doc_references.md](Doc_references.md). +## 2. Methods -## 2. Conditions - -### 2.1. ConditionCap - -The `ConditionCap` struct represents a condition related to a deposit role and its associated transaction mode, indicating the requirements for transactions within this context. - -| Attribute Name | Type | Option | Description | -|--------------------|-----------------------|--------|-----------------------------------------------------------| -| `role_deposit` | ```String``` | | Represents the deposit role in the condition. | -| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | - -### 2.2. ConditionCommitment - -The `ConditionCommitment` struct specifies a condition involving an artefact role and transaction mode, defining how commitments are handled and verified. - -| Attribute Name | Type | Option | Description | -|--------------------|-----------------------|--------|-----------------------------------------------------------| -| `role_artefact` | ```String``` | | Represents the artefact role in the condition. | -| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | - -### 2.3. ConditionDeposit - -`ConditionDeposit` is similar to ConditionCap but specifically focuses on deposit-related transactions, establishing the criteria for deposit actions. - -| Attribute Name | Type | Option | Description | -|--------------------|-----------------------|--------|-----------------------------------------------------------| -| `role_deposit` | ```String``` | | Represents the deposit role in the condition. | -| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | - -### 2.4. ConditionOrchestration - -`ConditionOrchestration` defines success and failure roles for orchestration conditions, guiding the flow of processes based on outcomes. - -| Attribute Name | Type | Option | Description | -|----------------|--------------|--------|----------------------------------------------------------| -| `role_ok` | ```String``` | | Represents the successful outcome role in the condition. | -| `role_ko` | ```String``` | | Represents the failed outcome role in the condition. | - -### 2.5. ConditionPayment - -This struct outlines the conditions for payments, including the amount, payment method, and transaction mode, setting the parameters for financial transactions. - -| Attribute Name | Type | Option | Description | -|--------------------|-----------------------|--------|-----------------------------------------------------------| -| `payment_amount` | ```String``` | | Represents the amount to be paid in the condition. | -| `payment_method` | ```PaymentMode``` | | Specifies the payment method to be used. | -| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | - -### 2.6. Condition RequestPrdAddressSet - -Condition `request_prdAddressSet` involves complex conditions based on RequestPrd addresses, including quotas, values, and scores, to determine condition fulfillment. - -| Attribute Name | Type | Option | Description | -|-------------------------------------------------|-------------------|--------|------------------------------------------------------------| -| `from_role` | ```String``` | | Identifies the originating role in the condition. | -| `request_prd_sp_address_list` | ```Vec``` | | Lists addresses involved in the condition. | -| `request_prd_sp_address_required_list` | ```Vec``` | | Lists required addresses for the condition to be met. | -| `request_prd_sp_address_quota` | ```i32``` | | Specifies the quota of addresses for the condition. | -| `request_prd_request_prd_value_ok_list` | ```Vec``` | | Lists the values that are considered acceptable. | -| `request_prd_value_ko_list` | ```Vec``` | | Lists the values that are considered failures. | -| `request_prd_value_none_list` | ```Vec``` | | Lists the values that are considered neutral or no-op. | -| `request_prd_sp_address_value_min` | ```i64``` | | The minimum value for an address to be considered. | -| `request_prd_sp_address_value_min_per` | ```i64``` | | The minimum percentage for the minimum address value. | -| `request_prd_sp_address_value_min_ok` | ```boolean``` | | Indicates if the minimum address value is considered OK. | -| `request_prd_sp_adddress_value_ok_min_per` | ```i64``` | | The minimum percentage for an address value to be OK. | -| `request_prd_sp_address_value_ok_max` | ```i64``` | | The maximum value for an address to be considered OK. | -| `request_prd_sp_adderss_value_ko_max_per` | ```i64``` | | The maximum percentage for an address value to be KO. | -| `request_prd_sp_address_value_none_max` | ```i64``` | | The maximum value for an address to be considered neutral. | -| `request_prd_sp_adderss_value_none_max_per` | ```i64``` | | The maximum percentage for a neutral address value. | -| `request_prd_sp_address_score_min` | ```i32``` | | The minimum score for an address to be considered. | -| `request_prd_sp_address_score_min_min_required` | ```i32``` | | The minimum required score for an address. | -| `request_prd_sp_address_score_min_min_ok` | ```boolean``` | | Indicates if the minimum score is considered OK. | -| `request_prd_sp_address_score_min_min_per` | ```i64``` | | The minimum percentage for the minimum score. | -| `request_prd_value_auto_ok` | ```boolean``` | | Automatically consider values as OK. | -| `request_prd_value_auto_ko` | ```boolean``` | | Automatically consider values as KO. | -| `request_prd_value_auto_none` | ```boolean``` | | Automatically consider values as neutral or no-op. | - -### 2.7. ConditionPublish - -`ConditionPublish` sets the criteria for publishing actions, including data size limits, publication counts, and timeouts, to regulate content distribution. - -| Attribute Name | Type | Option | Description | -|-----------------------------------|--------------|--------|---------------------------------------------------------------| -| `request_pcd_data_size_max_unit` | ```String``` | | Specifies the maximum unit size for published data. | -| `request_pcd_data_size_max_total` | ```i64``` | | Specifies the total maximum data size allowed. | -| `request_pcd_number_min` | ```i32``` | | The minimum number of publications required. | -| `request_pcd_number_max` | ```i32``` | | The maximum number of publications allowed. | -| `request_pcd_amount_max_total` | ```Amount``` | | The maximum total amount for publications. | -| `request_prd_waiting_timeout` | ```u64``` | | The waiting timeout for a publication to be considered valid. | -| `request_pcd_waiting_timeout` | ```u64``` | | The waiting timeout for the condition to be considered met. | - -## 3. Methods - -### 3.1. DepositMethod +### 2.1. DepositMethod The `DepositMethod` struct identifies a specific deposit method, encapsulating the approach or mechanism for deposits within the system. @@ -203,7 +111,7 @@ The `DepositMethod` struct identifies a specific deposit method, encapsulating t |----------------|--------------|--------|------------------------------| | `method` | ```String``` | | Represents a deposit method. | -### 3.2. CommitmentMethod +### 2.2. CommitmentMethod `CommitmentMethod` represents a particular method of commitment, defining how commitments are made or managed in the system. @@ -211,7 +119,7 @@ The `DepositMethod` struct identifies a specific deposit method, encapsulating t |----------------|--------------|--------|---------------------------------| | `method` | ```String``` | | Represents a commitment method. | -### 3.3. PaymentMethod +### 2.3. PaymentMethod `PaymentMethod` specifies a payment mechanism, detailing the method used for financial transactions. @@ -219,9 +127,9 @@ The `DepositMethod` struct identifies a specific deposit method, encapsulating t |----------------|--------------|--------|------------------------------------------------------| | `method` | ```String``` | | La méthode de paiement représentée par cette struct. | -## 4. Items +## 3. Items -### 4.1. ItemArtefact +### 3.1. ItemArtefact `ItemArtefact` associates an item with artefact-specific attributes, including public, confidential, and private attribute groups, to represent artefacts within the system. @@ -232,7 +140,7 @@ The `DepositMethod` struct identifies a specific deposit method, encapsulating t | `role_confidential_attribute_group` | ```Vec``` | | A list of role-specific confidential attributes for the artefact. | | `private_attribute_group` | ```Vec``` | | A list of private attributes associated with the artefact. | -### 4.2. ItemCommitmentPublicAttributeGroup +### 3.2. ItemCommitmentPublicAttributeGroup This struct groups public attributes related to commitments, such as goals and provider types, to publicly share commitment details. @@ -246,7 +154,7 @@ This struct groups public attributes related to commitments, such as goals and p | `ref_request_pcd_hash_list` | ```Vec``` | | A list of reference hashes for RequestPcd documents related to this commitment. | | `payload_public_list` | ```Vec``` | | A list of public payloads associated with this commitment. | -### 4.3. ItemMemberPublicAttributeGroup +### 3.3. ItemMemberPublicAttributeGroup `ItemMemberPublicAttributeGroup` outlines public attributes for members, including service provider addresses and payment methods, for transparency in member-related information. @@ -261,7 +169,7 @@ This struct groups public attributes related to commitments, such as goals and p | `payment_method_list_public` | ```Vec``` | | A list of public payment methods available. | | `succession_process_hash` | ```String``` | | The hash of the succession process associated with this item. | -### 4.4. ItemDepositPublicAttributeGroup +### 3.4. ItemDepositPublicAttributeGroup It details public attributes for deposits, including target addresses and goals, facilitating the understanding of deposit objectives. @@ -276,7 +184,7 @@ It details public attributes for deposits, including target addresses and goals, | `payload_list_public` | ```Vec``` | | A list of public payloads associated with this deposit. | | `audit_code_list_public` | ```Vec``` | | A list of public audit codes associated with this deposit. | -### 4.5. ItemCommitmentRoleConfidentialAttributeGroup +### 3.5. ItemCommitmentRoleConfidentialAttributeGroup This struct encompasses role-specific confidential attributes for commitments, securing sensitive commitment information. @@ -284,7 +192,7 @@ This struct encompasses role-specific confidential attributes for commitments, s |-----------------------------|-------------------|--------|------------------------------------------------------------------| | `payload_list_confidential` | ```Vec``` | | A list of confidential payloads associated with this commitment. | -### 4.6. ItemCommitmentPrivateAttributeGroup +### 3.6. ItemCommitmentPrivateAttributeGroup `ItemCommitmentPrivateAttributeGroup` contains private attributes for commitments, ensuring privacy for the most sensitive commitment details. @@ -292,7 +200,7 @@ This struct encompasses role-specific confidential attributes for commitments, s |------------------------|-------------------|--------|-------------------------------------------------------------| | `payload_list_private` | ```Vec``` | | A list of private payloads associated with this commitment. | -### 4.7. ItemCommitment +### 3.7. ItemCommitment `ItemCommitment` links an item with commitment-specific attributes across public, confidential, and private spheres, fully representing a commitment. @@ -303,7 +211,7 @@ This struct encompasses role-specific confidential attributes for commitments, s | `role_confidential_attribute_group` | ```ItemCommitmentRoleConfidentialAttributeGroup``` | | The role-specific confidential attribute group for this commitment. | | `private_attribute_group` | ```ItemCommitmentPrivateAttributeGroup``` | | The private attribute group associated with this commitment. | -### 4.8. ItemDepositRoleConfidentialAttributeGroup +### 3.8. ItemDepositRoleConfidentialAttributeGroup Similar to its commitment counterpart, this struct holds confidential attributes specific to deposits, protecting sensitive deposit information. @@ -312,7 +220,7 @@ Similar to its commitment counterpart, this struct holds confidential attributes | `payload_list_confidential` | ```Vec``` | | A list of confidential payloads associated with this deposit. | | `audit_code_list_confidential` | ```Vec``` | | A list of confidential audit codes associated with this deposit. | -### 4.9. ItemDepositPrivateAttributeGroup +### 3.9. ItemDepositPrivateAttributeGroup `ItemDepositPrivateAttributeGroup` secures private deposit attributes, safeguarding the most sensitive aspects of deposits. @@ -321,7 +229,7 @@ Similar to its commitment counterpart, this struct holds confidential attributes | `payload_list_private` | ```Vec``` | | A list of private payloads associated with this deposit. | | `audit_code_private` | ```String``` | | A private audit code associated with this deposit. | -### 4.10. ItemDeposit +### 3.10. ItemDeposit It combines an item with deposit-specific attributes, including public, confidential, and private groups, to comprehensively represent a deposit. @@ -332,7 +240,7 @@ It combines an item with deposit-specific attributes, including public, confiden | `role_confidential_attribute_group` | ```ItemDepositRoleConfidentialAttributeGroup``` | | The role-specific confidential attribute group for this deposit. | | `private_attribute_group` | ```ItemDepositPrivateAttributeGroup``` | | The private attribute group associated with this deposit. | -### 4.11. ItemEnum +### 3.11. ItemEnum This enumeration represents different types of items within a system, where each variant encapsulates a specific struct for a type of item: @@ -344,7 +252,7 @@ This enumeration represents different types of items within a system, where each * **```Artefact(ItemArtefact)```**: Contains an item of type ItemArtefact, representing an artefact. * **```Commitment(ItemCommitment)```**: Contains an item of type ItemCommitment, representing a commitment. -### 4.12. ItemPaymentPublicAttributeGroup +### 3.12. ItemPaymentPublicAttributeGroup This struct organizes public payment attributes, detailing aspects like service provider addresses and payment goals, for public knowledge. @@ -362,7 +270,7 @@ This struct organizes public payment attributes, detailing aspects like service | `payload_list_public` | ```Vec``` | | A list of public payloads associated with this payment. | | `audit_code_list_public` | ```Vec``` | | A list of public audit codes associated with this payment. | -### 4.13. ItemPaymentRoleConfidentialAttributeGroup +### 3.13. ItemPaymentRoleConfidentialAttributeGroup It holds confidential payment attributes, maintaining the confidentiality of critical payment information. @@ -371,7 +279,7 @@ It holds confidential payment attributes, maintaining the confidentiality of cri | `payload_list_confidential` | ```Vec``` | | A list of confidential payloads associated with this payment. | | `audit_code_list_confidential` | ```Vec``` | | A list of confidential audit codes associated with this payment. | -### 4.14. ItemPaymentPrivateAttributeGroup +### 3.14. ItemPaymentPrivateAttributeGroup ItemPaymentPrivateAttributeGroup protects private payment attributes, ensuring the highest level of privacy for payment details. @@ -380,7 +288,7 @@ ItemPaymentPrivateAttributeGroup protects private payment attributes, ensuring t | `payload_list_private` | ```Vec``` | | A list of private payloads associated with this payment. | | `audit_code_private` | ```String``` | | A private audit code associated with this payment. | -### 4.15. ItemPayment +### 3.15. ItemPayment `ItemPayment` links an item with payment-specific attributes across public, confidential, and private groups, offering a full view of a payment. @@ -391,7 +299,7 @@ ItemPaymentPrivateAttributeGroup protects private payment attributes, ensuring t | `role_confidential_attribute_group` | ```ItemPaymentRoleConfidentialAttributeGroup``` | | The role-specific confidential attribute group for this payment. | | `private_attribute_group` | ```ItemPaymentPrivateAttributeGroup``` | | The private attribute group associated with this payment. | -### 4.16. ItemPeerPublicAttributeGroup +### 3.16. ItemPeerPublicAttributeGroup It outlines public peer attributes, such as service provider addresses and PoW details, for transparency in peer-related information. @@ -409,7 +317,7 @@ It outlines public peer attributes, such as service provider addresses and PoW d | `daily_sp_tx_mine_list` | ```Vec``` | | A daily list of service provider transactions mined by this peer. | | `daily_sp_tx_mine_reward_list` | ```Vec``` | | A daily list of rewards for service provider transactions mined by this peer. | -### 4.17. ItemPeerPrivateAttributeGroup +### 3.17. ItemPeerPrivateAttributeGroup `ItemPeerPrivateAttributeGroup` contains a private configuration ```String``` for a peer, keeping certain peer configurations confidential. @@ -417,7 +325,7 @@ It outlines public peer attributes, such as service provider addresses and PoW d |----------------|--------------|--------|-----------------------------------------------------------------| | `config` | ```String``` | | A private configuration ```String``` associated with this peer. | -### 4.18. ItemPeer +### 3.18. ItemPeer `ItemPeer` combines basic item information with layers, public, and private attributes, fully detailing a peer within the system. @@ -428,7 +336,7 @@ It outlines public peer attributes, such as service provider addresses and PoW d | `public_attribute_group` | ```ItemPeerPublicAttributeGroup``` | | Groupe d'attributs publics associés à ce pair. | | `private_attribute_group` | ```ItemPeerPrivateAttributeGroup``` | | Groupe d'attributs privés associés à ce pair. | -### 4.19. ItemProcess +### 3.19. ItemProcess `ItemProcess` associates an item with a process, including public attribute groups, to represent processes within the system comprehensively. @@ -437,7 +345,7 @@ It outlines public peer attributes, such as service provider addresses and PoW d | `item` | ```Item``` | | Represents the item associated with this process. | | `item_process_public_attribute_group` | ```ItemProcessPublicAttributeGroup``` | | The public attribute group associated with this process. | -### 4.20. ItemProcessPublicAttributeGroup +### 3.20. ItemProcessPublicAttributeGroup This struct details public attributes related to processes, like roles groups, to facilitate understanding of process organization. @@ -445,7 +353,7 @@ This struct details public attributes related to processes, like roles groups, t |----------------|------------|--------|-----------------------------------------------------------| | `roles_group` | RolesGroup | | Represents a group of roles associated with this process. | -### 4.21. Item +### 3.21. Item The `Item` struct serves as a foundational element, detailing the basic structure of an item with attributes like UUID, version, and type, central to item management in the system. @@ -460,9 +368,9 @@ The `Item` struct serves as a foundational element, detailing the basic structur | `metadata_role_confidential` | ```MetadataRoleConfidential``` | | Role-specific confidential metadata associated with the item. | | `metadata_private` | ```MetadataPrivate``` | | Private metadata associated with the item. | -## 5. Encryption +## 4. Encryption -### 5.1. KeyEncryption +### 4.1. KeyEncryption The `KeyEncryption` struct provides details about encryption keys, including the attribute it's for, the key itself, and the algorithm used, crucial for securing data within the system. @@ -472,7 +380,7 @@ The `KeyEncryption` struct provides details about encryption keys, including the | `key` | ```String``` | Yes | An optional encryption key. | | `algorithm` | ```String``` | Yes | An optional encryption algorithm used with this key. | -### 5.2. Aes256GcmIv96Bit +### 4.2. Aes256GcmIv96Bit This struct represents an encryption scheme using `AES-256-GCM` with a 96-bit initialization vector (IV), specifying the key details for robust data encryption. @@ -480,9 +388,9 @@ This struct represents an encryption scheme using `AES-256-GCM` with a 96-bit in |----------------|-----------------------------|--------|------------------------------------------------------------------------------| | `key` | ```GenericArray``` | | Represents an encryption key for the AES-256-GCM algorithm with a 96-bit IV. | -## 6. Messages +## 5. Messages -### 6.1. Message +### 5.1. Message `Message` encapsulates a client message, including an encrypted request and its hash, essential for secure and verifiable client-server communication. @@ -491,7 +399,7 @@ This struct represents an encryption scheme using `AES-256-GCM` with a 96-bit in | `message` | ```Message``` | | Represents a message, assuming `Message` is a predefined struct. | | `request_enc` | ```String``` | | The encrypted request content. | -### 6.2. MessageConnect +### 5.2. MessageConnect The `MessageConnect` struct is designed to handle connection-related messages, facilitating the establishment of connections within the system. @@ -499,7 +407,7 @@ The `MessageConnect` struct is designed to handle connection-related messages, f |----------------|---------------|--------|------------------------------------------------------------------| | message | ```Message``` | | Represents a message, assuming `Message` is a predefined struct. | -### 6.3. MessageGeneric +### 5.3. MessageGeneric `Message` provides a general structure for messages, including shared peers and processes, and details like PoW challenges, supporting diverse communication needs @@ -511,7 +419,7 @@ The `MessageConnect` struct is designed to handle connection-related messages, f | `pow` | ```Pow``` | | Represents a Proof of Work (PoW) challenge, assuming `Pow` is a predefined struct. | | `raw_transaction_list` | ```Vec``` | Yes | Transaction to broadcast | -### 6.4. Pow +### 5.4. Pow The `Pow` struct outlines a Proof of Work challenge, including data hash, timestamp, and nonce, to ensure computational effort for security purposes. @@ -523,7 +431,7 @@ The `Pow` struct outlines a Proof of Work challenge, including data hash, timest | `pattern` | ```String``` | | The pattern that the PoW solution must match. | | `difficulty` | ```usize``` | | The difficulty level of the PoW challenge. | -### 6.5. SharedProcess +### 5.5. SharedProcess `SharedProcess` identifies a shared process within the system, aiding in the management and coordination of collaborative processes. @@ -533,7 +441,7 @@ The `Pow` struct outlines a Proof of Work challenge, including data hash, timest | `key` | `KeyEncryption` | | The encryption key used for the process. | | `role_process_sp_address_list` | `Vec` | | A list of SP addresses related to the role. | -### 6.6. SharedPeer +### 5.6. SharedPeer `SharedPeer` specifies a peer within the network, playing a key role in distributed information sharing and communication. @@ -547,7 +455,7 @@ The `Pow` struct outlines a Proof of Work challenge, including data hash, timest | `l2_node` | ```L2Node``` | | Represents a level 2 (L2) node in the network. | | `l2_certif` | ```L2Certif``` | | Represents a level 2 (L2) certification authority or function in the network. | -## 7. Relay +## 6. Relay Represents a `Relay` in the network, specifying its address and port, data handling capacity, and Proof of Work (PoW) requirements. @@ -561,7 +469,7 @@ Represents a `Relay` in the network, specifying its address and port, data handl | `pow_timeout` | ```u32``` | | Timeout for pow | | `faucet_sp_address` | ```u32``` | | Faucet address | -### 7.1. L1Node +### 6.1. L1Node The `L1Node` struct details a Level 1 blockchain node, including its network, IP address, and status, integral to blockchain operations and interactions. @@ -574,7 +482,7 @@ The `L1Node` struct details a Level 1 blockchain node, including its network, IP | `status` | ```String``` | | Current status of the L1 node (e.g., active, inactive). | | `last_checked` | ```DateTime``` | | Timestamp of the last health check performed on the L1 node. | -### 7.2. L1Miner +### 6.2. L1Miner `L1Miner` describes a miner on a Level 1 blockchain, detailing its network, mining power, and status, crucial for understanding blockchain mining dynamics. @@ -587,7 +495,7 @@ The `L1Node` struct details a Level 1 blockchain node, including its network, IP | `status` | ```String``` | | Current status of the L1 miner (e.g., active, inactive). | | `mining_power` | ```u16``` | | The mining power of the L1 miner in hashes per second. | -### 7.3. L2Node +### 6.3. L2Node This struct represents a Level 2 (Layer 2) blockchain node, focusing on scalability solutions and includes details such as its network and operation layer. @@ -600,7 +508,7 @@ This struct represents a Level 2 (Layer 2) blockchain node, focusing on scalabil | `status` | ```String``` | | Current status of the L2 node (e.g., active, inactive). | | `layer` | ```String``` | | Indicates the layer (L2) the node operates at. | -### 7.4. L2Certif +### 6.4. L2Certif `L2Certif` specifies a Layer 2 certification authority, including its network and certification type, vital for managing certifications on Layer 2 solutions. @@ -613,7 +521,7 @@ This struct represents a Level 2 (Layer 2) blockchain node, focusing on scalabil | `status` | ```String``` | | Current status of the L2 certification authority (e.g., active, inactive). | | `certif_type` | ```String``` | | Type of certification or service provided by the L2 certif. | -## 8. Metadata +## 7. Metadata `MetaData` aggregates various metadata types, including tags, zones, and key lists, offering a comprehensive view of metadata for diverse applications. @@ -630,7 +538,7 @@ This struct represents a Level 2 (Layer 2) blockchain node, focusing on scalabil | `legal_text_list` | ```Vec``` | | A list of legal texts associated with the metadata. | | `key_list` | ```Vec``` | | A list of key encryption methods associated with the metadata. | -### 8.1. MetadataContractPublic +### 7.1. MetadataContractPublic The `MetadataContractPublic` struct encapsulates public metadata for contracts, providing transparency and accessibility of contract-related information. @@ -638,7 +546,7 @@ The `MetadataContractPublic` struct encapsulates public metadata for contracts, |----------------|----------------|--------|------------------------------------------------------------| | `meta_data` | ```MetaData``` | | Represents the public metadata associated with a contract. | -### 8.2. MetadataPrivate +### 7.2. MetadataPrivate `MetadataPrivate` holds private metadata, ensuring the confidentiality of sensitive information associated with entities or contracts. @@ -646,7 +554,7 @@ The `MetadataContractPublic` struct encapsulates public metadata for contracts, |----------------|----------------|--------|------------------------------------------------------------| | `meta_data` | ```MetaData``` | | Represents the private metadata associated with an entity. | -### 8.3. MetadataRoleConfidential +### 7.3. MetadataRoleConfidential This struct contains role-specific confidential metadata, balancing the need for privacy with role-based access and transparency. @@ -654,7 +562,7 @@ This struct contains role-specific confidential metadata, balancing the need for |----------------|----------------|--------|-------------------------------------------------------------------------------| | `meta_data` | ```MetaData``` | | Represents the role-specific confidential metadata associated with an entity. | -### 8.4. Amount +### 7.4. Amount The `Amount` struct details financial amounts, including its timestamp, unit, and changes, facilitating precise financial transactions and records. @@ -666,7 +574,7 @@ The `Amount` struct details financial amounts, including its timestamp, unit, an | `amount_unit` | ```String``` | | The unit of the amount, such as "USD", "EUR", etc. | | `amount_unit_ref` | ```String``` | | A reference to an external unit system, providing context for the `amount_unit`. | -### 8.5. Number +### 7.5. Number `Number` provides a numeric value and its unit, supporting a wide range of quantitative representations in system operations. @@ -676,7 +584,7 @@ The `Amount` struct details financial amounts, including its timestamp, unit, an | `number` | ```i32``` | | The numeric value. | | `number_unit` | ```String``` | | The unit of measurement for the number, if applicable. | -## 9. Request +## 8. Request Defines a general request structure within the system, encapsulating details about the requested item, its type, version, and associated process and document references. @@ -692,7 +600,7 @@ Defines a general request structure within the system, encapsulating details abo | `request_prd_origin_hash` | ```String``` | Yes | Optional hash of the originating RequestPrd. | | `item_reference_hash` | ```String``` | Yes | Optionally specifies the hash of the item related to the request. | -## 10. RequestPcd +## 9. RequestPcd The `request_pcd` struct integrates a request with a list of generic encrypted items and pagination details, facilitating the handling of encrypted RequestPcd requests within the system. @@ -702,7 +610,7 @@ The `request_pcd` struct integrates a request with a list of generic encrypted i | `item_list` | ```Vec< RequestPcdItemGenericEnc>``` | | List of generic encrypted items. | | `pagination` | ```Pagination``` | Yes | Pagination details, assuming `Pagination` is a predefined struct. | -### 10.1. Pagination +### 9.1. Pagination The `Pagination` struct is essential for managing large datasets, detailing the pagination strategy with start index, number of items, and page index. @@ -712,7 +620,7 @@ The `Pagination` struct is essential for managing large datasets, detailing the | `number` | ```usize``` | | Le nombre d'éléments par page. | | `page_index` | ```usize``` | | L'indice de la page actuelle pour la pagination. | -### 10.2. RequestPcdItemEncAttributePublic +### 9.2. RequestPcdItemEncAttributePublic This struct outlines public encrypted attributes for RequestPcd items, ensuring the secure transmission of public attribute data. @@ -721,7 +629,7 @@ This struct outlines public encrypted attributes for RequestPcd items, ensuring | `attribute_name` | ```String``` | | The name of the attribute. | | `data_enc` | ```String``` | | The encrypted data associated with the attribute. | -### 10.3. RequestPcdItemEncAttributeRoleConfidential +### 9.3. RequestPcdItemEncAttributeRoleConfidential `request_pcdItemEncAttributeRoleConfidential` deals with role-specific confidential encrypted attributes, securing sensitive data while allowing role-based access. @@ -731,7 +639,7 @@ This struct outlines public encrypted attributes for RequestPcd items, ensuring | `data_enc` | ```String``` | Yes | The encrypted data associated with the attribute. | | `key` | ```KeyEncryption``` | Yes | The key used for encrypting the data. | -### 10.4. RequestPcdItemEncAttributePrivate +### 9.4. RequestPcdItemEncAttributePrivate It specifies private encrypted attributes for `request_pcd` items, protecting the most sensitive information with encryption. @@ -740,7 +648,7 @@ It specifies private encrypted attributes for `request_pcd` items, protecting th | `attribute_name` | ```String``` | | The name of the attribute. | | `data_enc` | ```String``` | Yes | The encrypted data associated with this attribute name. | -### 10.5. RequestPcdItemGenericEnc +### 9.5. RequestPcdItemGenericEnc `request_pcdItemGenericEnc` encompasses encrypted items with optional lists of public, role-confidential, and private encrypted attributes, offering a flexible encryption model for diverse data types. @@ -751,7 +659,7 @@ It specifies private encrypted attributes for `request_pcd` items, protecting th | `request_pcd_item_enc_attribute_role_confidential_list` | ```Vec< RequestPcdItemEncAttributeRoleConfidential>``` | Yes | Optional list of role-confidential encrypted attributes. | | `request_pcd_item_enc_attribute_private_list` | ```Vec< RequestPcdItemEncAttributePrivate>``` | Yes | Optional list of private encrypted attributes. | -### 10.6. RequestPcdItemEnc +### 9.6. RequestPcdItemEnc The `request_pcdItemEnc` struct encapsulates encrypted RequestPcd items, detailing the version, type, and name of the item, alongside encrypted attributes segregated into public, role-confidential, and private categories, ensuring comprehensive encryption coverage. @@ -765,7 +673,7 @@ The `request_pcdItemEnc` struct encapsulates encrypted RequestPcd items, detaili | `request_pcd_item_enc_attribute_role_confidential_list` | ```Vec< RequestPcdItemEncAttributeRoleConfidential>``` | | List of role-confidential encrypted attributes. | | `request_pcd_item_enc_attribute_private_list` | ```Vec< RequestPcdItemEncAttributePrivate>``` | | List of private encrypted attributes. | -## 11. RequestPrd +## 10. RequestPrd Encapsulates a detailed request within the system, focusing on the interaction with Portable Request Documents ( RequestPrd) and specifying various levels of message confidentiality and intended service provider (SP) communication details. @@ -796,7 +704,7 @@ Encapsulates a detailed request within the system, focusing on the interaction w | `certif_key_enc_by_shared_secret` | ```String``` | Yes | Encrypted certification key, encrypted with a shared secret. | | `device_footprint_enc_by_sp_shared_secret` | ```String``` | | The device footprint encrypted by a service provider's shared secret. | -### 11.1. RequestPrdResponse +### 10.1. RequestPrdResponse `request_prd` and its variations (Confirm, KeyBackup, KeyHello, List, Message, Response, Update) represent different aspects and actions related to Portable Request Documents ( RequestPrd), covering everything from confirmation to updates, key management, and messaging, essential for managing and processing RequestPrds securely and efficiently. @@ -810,7 +718,7 @@ Encapsulates a detailed request within the system, focusing on the interaction w | `part_1_enc_hash_enc_by_sp_shared_secret` | ```String``` | Yes | The first part of the hash encrypted by a service provider's shared secret. | | `shard_enc_by_sp_shared_secret` | ```String``` | Yes | The shard encrypted by a service provider's shared secret. | -### 11.2. RequestPrdConfirm +### 10.2. RequestPrdConfirm The `request_prdConfirm` struct is designed for confirming actions or requests within the system, utilizing a Portable Request Document ( RequestPrd) alongside an encrypted confirmation code, ensuring secure acknowledgment of operations. @@ -819,7 +727,7 @@ The `request_prdConfirm` struct is designed for confirming actions or requests w | `request_prd` | ```request_prd``` | | The RequestPrd (Portable Request Document) request. | | `code_confirm_enc_by_shared_secret` | ```String``` | Yes | The confirmation code encrypted by a shared secret. | -### 11.3. RequestPrdKeyBackup +### 10.3. RequestPrdKeyBackup `request_prdKeyBackup` focuses on backup functionalities for RequestPrd keys, incorporating device footprint and shard information, encrypted for security, facilitating the safe backup and recovery of crucial cryptographic keys. @@ -829,7 +737,7 @@ The `request_prdConfirm` struct is designed for confirming actions or requests w | `part_1_enc_hash_enc_by_sp_shared_secret` | ```String``` | | The first part of the hash encrypted by a service provider's shared secret. | | `shard_enc_by_sp_shared_secret` | ```String``` | | The shard encrypted by a service provider's shared secret. | -### 11.4. RequestPrdKeyHello +### 10.4. RequestPrdKeyHello The `request_prdKeyHello` struct is employed for initiating cryptographic communications, specifically for sharing initial key information or for cryptographic introductions between entities, enhancing secure connections. @@ -838,7 +746,7 @@ The `request_prdKeyHello` struct is employed for initiating cryptographic commun | `request_prd` | ```request_prd``` | | Represents a Portable Request Document ( RequestPrd). | | `part_1_enc_hash_enc_by_sp_shared_secret` | ```String``` | | The encrypted hash of part 1, encrypted by the service provider's shared secret. | -### 11.5. RequestPrdList +### 10.5. RequestPrdList `request_prdList` struct is utilized for listing or querying RequestPrds, aiding in the retrieval or enumeration of Portable Request Documents within the system, streamlining the management and access of RequestPrds. @@ -846,15 +754,16 @@ The `request_prdKeyHello` struct is employed for initiating cryptographic commun |----------------|-------------------|--------|-----------------------------------------| | `request_prd` | ```request_prd``` | | Represents a Portable Request Document. | -### 11.6. RequestPrdMessage +### 10.6. RequestPrdMessage The `request_prdMessage` struct serves the purpose of encapsulating messages within RequestPrds, allowing for secure and structured communication of information wrapped in a Portable Request Document. -| Attribute Name | Type | Option | Description | -|----------------|-------------------|--------|-----------------------------------------| -| `request_prd` | ```request_prd``` | | Represents a Portable Request Document. | +| Attribute Name | Type | Option | Description | +|------------------------|-------------------|--------|-----------------------------------------| +| `request_prd` | ```request_prd``` | | Represents a Portable Request Document. | +| `raw_transaction_list` | ```Vec``` | Yes | Represents a Portable Request Document. | -### 11.7. RequestPrdResponse +### 10.7. RequestPrdResponse `request_prdResponse` is designed for responding to RequestPrd requests, including the original RequestPrd, signature for verification, and optional encrypted methods, ensuring a secure and verifiable response mechanism. @@ -863,7 +772,7 @@ The `request_prdMessage` struct serves the purpose of encapsulating messages wit | `request_prd` | ```request_prd``` | | Represents a Portable Request Document. | | `sig_value` | ```String``` | | The signature value for the response. | -### 11.8. RequestPrdUpdate +### 10.8. RequestPrdUpdate `request_prdUpdate` struct facilitates the updating of RequestPrds, incorporating new version hashes and lists of related RequestPcd hashes, alongside requested methods for payments, deposits, and commitments, ensuring RequestPrds remain current and relevant. @@ -871,11 +780,128 @@ The `request_prdMessage` struct serves the purpose of encapsulating messages wit |----------------|-------------------|--------|-----------------------------------------| | `request_prd` | ```request_prd``` | | Represents a Portable Request Document. | -## 12. Roles +## 11. Roles The `Roles` enum defines the various roles within the system, specifying responsibilities, required security measures such as two-factor authentication, validation timeouts, and conditions for action validation, crucial for role-based access control and process flow. -### 12.1. RolesGroup +### 11.1. Role + +The `Role` struct broadly defines a role within the system, encapsulating the general responsibilities, required security measures like two-factor authentication, validation timeouts, and conditions for action validation. This serves as a foundation for more specific role definitions, ensuring a flexible yet secure role-based access and action framework. +|--------------------------------------|-------------------------------|--------|------------------------------------------------------------------| +| `item` | ```Item``` | | The item associated with the role. | +| `sp_output_salt_enc` | ```string``` | | he salt encrypted for the hash in the sp outputs. | +| `required_2fa` | ```bool``` | | Indicates if two-factor authentication is required. | +| `validation_timeout` | ```u64``` | Yes | The timeout for validation in seconds. | +| `condition_prd_address_set_list` | ```Vec``` | | A list of product address set conditions. | +| `condition_publish` | ```Vec``` | Yes | The condition for publishing. | +| `condition_cap_list` | ```Vec``` | Yes | A list of capability conditions. | +| `condition_payment_list` | ```Vec``` | Yes | A list of payment conditions. | +| `condition_commitment_list` | ```Vec``` | Yes | A list of commitment conditions. | +| `condition_attribute_encryption_list`| ```Vec``` | | A list of attribute encryption conditions. | +| `condition_orchestration` | ```Vec``` | Yes | The condition for orchestration. | +| `role_succession` | ```String``` | Yes | Optional role for succession. | +| `role_resolve` | ```String``` | Yes | Optional role for resolving conflicts. | +| `role_renew` | ```String``` | Yes | Optional role for renewing conditions or capabilities. | + +### 11.2. Conditions + +#### 11.2.1. ConditionCap + +The `ConditionCap` struct represents a condition related to a deposit role and its associated transaction mode, indicating the requirements for transactions within this context. + +| Attribute Name | Type | Option | Description | +|--------------------|-----------------------|--------|-----------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `role_deposit` | ```String``` | | Represents the deposit role in the condition. | +| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | + +#### 11.2.2. ConditionCommitment + +The `ConditionCommitment` struct specifies a condition involving an artefact role and transaction mode, defining how commitments are handled and verified. + +| Attribute Name | Type | Option | Description | +|--------------------|-----------------------|--------|-----------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `role_artefact` | ```String``` | | Represents the artefact role in the condition. | +| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | + +#### 11.2.3. ConditionDeposit + +`ConditionDeposit` is similar to ConditionCap but specifically focuses on deposit-related transactions, establishing the criteria for deposit actions. + +| Attribute Name | Type | Option | Description | +|--------------------|-----------------------|--------|-----------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `role_deposit` | ```String``` | | Represents the deposit role in the condition. | +| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | + +#### 11.2.4. ConditionOrchestration + +`ConditionOrchestration` defines success and failure roles for orchestration conditions, guiding the flow of processes based on outcomes. + +| Attribute Name | Type | Option | Description | +|--------------------|--------------|--------|----------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `role_ok` | ```String``` | | Represents the successful outcome role in the condition. | +| `role_ko` | ```String``` | | Represents the failed outcome role in the condition. | + +#### 11.2.5. ConditionPayment + +This struct outlines the conditions for payments, including the amount, payment method, and transaction mode, setting the parameters for financial transactions. + +| Attribute Name | Type | Option | Description | +|--------------------|-----------------------|--------|-----------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `payment_amount` | ```String``` | | Represents the amount to be paid in the condition. | +| `payment_method` | ```PaymentMode``` | | Specifies the payment method to be used. | +| `role_transaction` | ```TransactionMode``` | | Specifies the transaction mode associated with this role. | + +#### 11.2.6. Condition RequestPrdAddressSet + +Condition `request_prdAddressSet` involves complex conditions based on RequestPrd addresses, including quotas, values, and scores, to determine condition fulfillment. + +| Attribute Name | Type | Option | Description | +|-------------------------------------------------|-------------------|--------|------------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `from_role` | ```String``` | | Identifies the originating role in the condition. | +| `request_prd_sp_address_list` | ```Vec``` | | Lists addresses involved in the condition. | +| `request_prd_sp_address_required_list` | ```Vec``` | | Lists required addresses for the condition to be met. | +| `request_prd_sp_address_quota` | ```i32``` | | Specifies the quota of addresses for the condition. | +| `request_prd_request_prd_value_ok_list` | ```Vec``` | | Lists the values that are considered acceptable. | +| `request_prd_value_ko_list` | ```Vec``` | | Lists the values that are considered failures. | +| `request_prd_value_none_list` | ```Vec``` | | Lists the values that are considered neutral or no-op. | +| `request_prd_sp_address_value_min` | ```i64``` | | The minimum value for an address to be considered. | +| `request_prd_sp_address_value_min_per` | ```i64``` | | The minimum percentage for the minimum address value. | +| `request_prd_sp_address_value_min_ok` | ```boolean``` | | Indicates if the minimum address value is considered OK. | +| `request_prd_sp_adddress_value_ok_min_per` | ```i64``` | | The minimum percentage for an address value to be OK. | +| `request_prd_sp_address_value_ok_max` | ```i64``` | | The maximum value for an address to be considered OK. | +| `request_prd_sp_adderss_value_ko_max_per` | ```i64``` | | The maximum percentage for an address value to be KO. | +| `request_prd_sp_address_value_none_max` | ```i64``` | | The maximum value for an address to be considered neutral. | +| `request_prd_sp_adderss_value_none_max_per` | ```i64``` | | The maximum percentage for a neutral address value. | +| `request_prd_sp_address_score_min` | ```i32``` | | The minimum score for an address to be considered. | +| `request_prd_sp_address_score_min_min_required` | ```i32``` | | The minimum required score for an address. | +| `request_prd_sp_address_score_min_min_ok` | ```boolean``` | | Indicates if the minimum score is considered OK. | +| `request_prd_sp_address_score_min_min_per` | ```i64``` | | The minimum percentage for the minimum score. | +| `request_prd_value_auto_ok` | ```boolean``` | | Automatically consider values as OK. | +| `request_prd_value_auto_ko` | ```boolean``` | | Automatically consider values as KO. | +| `request_prd_value_auto_none` | ```boolean``` | | Automatically consider values as neutral or no-op. | + +#### 11.2.7. ConditionPublish + +`ConditionPublish` sets the criteria for publishing actions, including data size limits, publication counts, and timeouts, to regulate content distribution. + +| Attribute Name | Type | Option | Description | +|-----------------------------------|--------------|--------|---------------------------------------------------------------| +| `request_prd_type` | ```String``` | | Type of prd request concerned by this conditions | +| `request_pcd_data_size_max_unit` | ```String``` | | Specifies the maximum unit size for published data. | +| `request_pcd_data_size_max_total` | ```i64``` | | Specifies the total maximum data size allowed. | +| `request_pcd_number_min` | ```i32``` | | The minimum number of publications required. | +| `request_pcd_number_max` | ```i32``` | | The maximum number of publications allowed. | +| `request_pcd_amount_max_total` | ```Amount``` | | The maximum total amount for publications. | +| `request_prd_waiting_timeout` | ```u64``` | | The waiting timeout for a publication to be considered valid. | +| `request_pcd_waiting_timeout` | ```u64``` | | The waiting timeout for the condition to be considered met. | + +#### 11.2.8. RolesGroup RolesGroup outlines a collection of roles. @@ -886,7 +912,7 @@ RolesGroup outlines a collection of roles. | `role_process` | ```String``` | | Represents the entities charged with defining and managing processes within the system. | | `role_artefact_list` | ```Vec``` | | A list of artefact roles, allowing customization and extension of functionalities and interactions beyond standard roles. | -### 12.2. RoleArtefact +#### 11.2.9. RoleArtefact The `RoleArtefact` struct is utilized to define the role associated with artefacts within the system. It specifies the responsibilities and permissions tied to the handling, management, or interaction with artefacts, ensuring clarity in role-based actions and access controls related to artefact-related operations. @@ -895,7 +921,7 @@ The `RoleArtefact` struct is utilized to define the role associated with artefac | `item_name` | ```String``` | | The name of the item associated with the deposit. | | `role` | ```Role``` | | The role associated with this deposit. | -### 12.3. RoleDeposit +#### 11.2.10. RoleDeposit `RoleDeposit` outlines the role and responsibilities concerning deposits in the system. It identifies the specific obligations and permissions granted to entities managing or engaging with deposit transactions, providing a structured approach to deposit management and execution. @@ -904,7 +930,7 @@ The `RoleArtefact` struct is utilized to define the role associated with artefac | `item_name` | ```String``` | | The name of the item associated with the artefact. | | `role` | ```Role``` | | The role associated with this artefact. | -### 12.4. RoleCommitment +#### 11.2.11. RoleCommitment The `RoleCommitment` struct details the role associated with commitments, delineating the duties and authorities of entities tasked with creating, managing, or fulfilling commitments. This struct ensures that commitment-related activities are clearly defined and regulated within the system. @@ -913,7 +939,7 @@ The `RoleCommitment` struct details the role associated with commitments, deline | `item_name` | ```String``` | | The name of the item associated with the commitment. | | `role` | ```Role``` | | The role associated with this commitment. | -### 12.5. RoleMember +#### 11.2.12. RoleMember `RoleMember` defines the role of members within the system, specifying the rights and responsibilities of membership. This includes access to resources, participation in processes, and contributions to decision-making, highlighting the importance of members in the system's ecosystem. @@ -922,7 +948,7 @@ The `RoleCommitment` struct details the role associated with commitments, deline | `item_name` | ```String``` | | The name of the item associated with the member. | | `role` | ```Role``` | | The role associated with this member. | -### 12.6. RolePayment +#### 11.2.13. RolePayment The `RolePayment` struct is dedicated to defining the role related to payments, outlining the specific tasks, permissions, and responsibilities assigned to entities handling or involved in payment transactions, ensuring secure and orderly payment processes. @@ -931,7 +957,7 @@ The `RolePayment` struct is dedicated to defining the role related to payments, | `item_name` | ```String``` | | The name of the item associated with the payment. | | `role` | ```Role``` | | The role associated with this payment. | -### 12.7. RoleProcess +#### 11.2.14. RoleProcess `RoleProcess` describes the role associated with processes within the system. It specifies the expectations, duties, and permissions of entities that initiate, manage, or participate in various system processes, facilitating smooth and regulated process flow. @@ -939,26 +965,7 @@ The `RolePayment` struct is dedicated to defining the role related to payments, |----------------|--------------|--------|---------------------------------------------------| | `item_name` | ```String``` | | The name of the item associated with the process. | | `role` | ```Role``` | | The role associated with this process. | - -### 12.8. Role - -The `Role` struct broadly defines a role within the system, encapsulating the general responsibilities, required security measures like two-factor authentication, validation timeouts, and conditions for action validation. This serves as a foundation for more specific role definitions, ensuring a flexible yet secure role-based access and action framework. -|--------------------------------------|-------------------------------|--------|------------------------------------------------------------------| -| `item` | ```Item``` | | The item associated with the role. | -| `required_2fa` | ```bool``` | | Indicates if two-factor authentication is required. | -| `validation_timeout` | ```u64``` | Yes | The timeout for validation in seconds. | -| `condition_prd_address_set_list` | ```Vec``` | | A list of product address set conditions. | -| `condition_publish` | ```ConditionPublish``` | Yes | The condition for publishing. | -| `condition_cap_list` | ```Vec``` | Yes | A list of capability conditions. | -| `condition_payment_list` | ```Vec``` | Yes | A list of payment conditions. | -| `condition_commitment_list` | ```Vec``` | Yes | A list of commitment conditions. | -| `condition_attribute_encryption_list`| ```Vec``` | | A list of attribute encryption conditions. | -| `condition_orchestration` | ```ConditionOrchestration``` | Yes | The condition for orchestration. | -| `role_succession` | ```String``` | Yes | Optional role for succession. | -| `role_resolve` | ```String``` | Yes | Optional role for resolving conflicts. | -| `role_renew` | ```String``` | Yes | Optional role for renewing conditions or capabilities. | - -### 12.9. TransactionMode +### 11.3. TransactionMode `TransactionMode` and its specific types (Distribution, Direct) describe how transactions are handled within the system, whether through direct communication or distributed across multiple entities, influencing the flow and security of transactions. @@ -971,7 +978,7 @@ The `Role` struct broadly defines a role within the system, encapsulating the ge | `to_type` | ```String``` | | Soit "addresses" soit "roles" | | `to_method` | ```String``` | | Méthode de distribution de la somme des versements : "Amount divided" ou "Same Amount" | -### 12.10. RolePeer +### 11.4. RolePeer The `RolePeer` struct identifies peers associated with specific roles, detailing their identifiers, associated peers, and metadata, essential for defining peer responsibilities and permissions within the networked environment. @@ -980,9 +987,9 @@ The `RolePeer` struct identifies peers associated with specific roles, detailing | `item_name` | ```String``` | | The name of the item associated with the peer. | | `role` | ```Role``` | | The role associated with this peer. | -## 13. 12. Rust considerations +## 12. 12. Rust considerations -### 13.1.  General Implications for Project Objects +### 12.1.  General Implications for Project Objects Incorporating these traits into a struct's definition enhances its utility across various aspects of a project. For instance: @@ -991,31 +998,31 @@ Incorporating these traits into a struct's definition enhances its utility acros * **Comparison and ordering traits (PartialEq, Eq, PartialOrd, Ord)**: are crucial for logic checks, sorting, and storing objects in data structures that require ordering or uniqueness. * **The Hash trait**: expands the struct's utility in hash-based collections, enabling efficient data retrieval and storage. -### 13.2.  Debug +### 12.2.  Debug The Debug trait allows instances of the struct to be formatted using the {:?} formatter. This is essential for debugging purposes, as it provides a way to output the contents of the struct to the console or logs, aiding in the development and troubleshooting process. Serialize, Deserialize (serde crate) Serialize and Deserialize traits from the serde crate enable the struct to be easily converted to and from data formats such as JSON, YAML, or TOML. This is particularly useful for web applications or services that need to send or receive data in a structured format over the network. -### 13.3.  Default +### 12.3.  Default Implementing the Default trait allows for the creation of a struct with default values. This is useful for initializing structs with a set of predetermined values or when a struct needs to be created without specifying every field explicitly. Clone The Clone trait allows for the creation of an exact copy of a struct instance. This is crucial for cases where a mutable copy of a struct is needed, while keeping the original instance unchanged. -### 13.4.  PartialEq, Eq +### 12.4.  PartialEq, Eq PartialEq and Eq traits enable comparison operations for instances of the struct. While PartialEq allows for partial equality checks (where some of the comparisons might be indeterminate), Eq denotes that every comparison will either be true or false, ensuring a stricter equality condition that is necessary for certain collections or logic checks. -### 13.5.  Hash +### 12.5.  Hash The Hash trait is used to compute a hash value for instances of the struct. This is essential for structs that need to be stored in collections such as HashMap or HashSet, where a unique identifier is required to efficiently retrieve or store items. -### 13.6.  PartialOrd, Ord +### 12.6.  PartialOrd, Ord PartialOrd and Ord traits allow for ordering comparisons between instances of the struct. PartialOrd provides functionality for partial ordering, where some comparisons might not produce a clear order, whereas Ord requires a total ordering, ensuring that any two instances can be reliably ordered. This is critical for sorting operations or when structs are stored in ordered collections. FromForm (rocket crate) -## 14. Todo +## 13. Todo diff --git a/doc/Specs-Definition.md b/doc/Specs-Definition.md index 27bbb07..96949ec 100644 --- a/doc/Specs-Definition.md +++ b/doc/Specs-Definition.md @@ -37,17 +37,17 @@ Voir [Doc_references.md](Doc_references.md). * **Recover**: Action de recomposer une identité numérique (clés privées). -* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une adresse Silent Payment indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre. +* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une`adresse SP` indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre. -* **Onboard**: Action de demander un `rôle` dans un `process`. +* **Onboard**: Action de demander un `rôle` dans un `ItemProcess` . -* **Member**: Une adresse Silent Payment, complétée de métadonnées, par `process` et d'une adresse supplémentaire pour la révocation. +* **Member**: Une adresse Silent Payment, complétée de métadonnées, par `ItemProcess` et d'une adresse supplémentaire pour la révocation. -* **Third parties**: Adresses Silent Payment complétant un `member` pour reconnaître d'autres dispositifs du `member`. +* **Third parties**:`adresse SP` complétant un `member` pour reconnaître d'autres dispositifs du `member`. * **KeyConfidential**: Clé AES-GCM-256 du Diffie-Hellman de la transaction Silent Payment correspondant à un RequestPrd. -* **ProcessKey**: la clé publique de chiffrement public d'un process (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 public d'un `ItemProcess` (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). * **KeyRecover**: la clé prive de spend de `recover` du signet, qui sert de référence pour l'identité. @@ -81,7 +81,7 @@ Voir [Doc_references.md](Doc_references.md). ## 5. Data -* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les process découverts et les pairs du réseau. Une fois identifié auprès des membres d'un process et avec son identité `member` récupérée, l'objet member et les `RequestPcd` et `RequestPrd` du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée. +* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les `ItemProcess` découverts et les pairs du réseau. Une fois identifié auprès des membres d'un `ItemProcess` et avec son identité `member` récupérée, l'objet member et les `RequestPcd` et `RequestPrd` du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée. * **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les `RequestPcd` et RequestPrd, dans les navigateurs web. diff --git a/doc/Specs-References.md b/doc/Specs-References.md index 19297af..71745d7 100644 --- a/doc/Specs-References.md +++ b/doc/Specs-References.md @@ -48,6 +48,7 @@ Voir [Doc_references.md](Doc_references.md). ## 6. Data anchoring +* * * diff --git a/doc/Specs-Security-confidentiality.md b/doc/Specs-Security-confidentiality.md index 5126dca..368ee52 100644 --- a/doc/Specs-Security-confidentiality.md +++ b/doc/Specs-Security-confidentiality.md @@ -76,9 +76,9 @@ Le chiffrement des `RequestPcd` est un chiffrement symétrique conformément aux * **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer. -* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un RequestPcd. +* **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les RequestPcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un RequestPcd. -* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `RequestPcd` et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`. +* **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `RequestPcd` et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`. * **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs). @@ -180,7 +180,7 @@ La manière dont les clés sont générées, stockées, distribuées, révoquée Les clés seront générées strictement par l'utilisateur et feront l'objet d'un traitement `MPC` avec un chiffrement des parties par le mot de passe connu de l'utilisateur seul et jamais stocké. -Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `process` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande. +Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `ItemProcess` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande. L'utilisateur seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé. @@ -196,7 +196,7 @@ En cas de perte, vol, corruption, ou expiration des clés, l'utilisateur peut de ## 14. Évolutivité -La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `process`. +La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `ItemProcess` . ## 15. Autres Mesures de sécurité