From 799d87d5600d7089d2cbc527cacecacadac1fb06 Mon Sep 17 00:00:00 2001 From: NicolasCantu Date: Fri, 22 Mar 2024 09:12:15 +0100 Subject: [PATCH] Wording (doc) --- Cargo.toml | 2 +- doc/Auth-Specs.md | 58 +-- doc/Item-Specs.md | 10 +- doc/Messages-Specs.md | 36 +- doc/PRD-PCD-Specs.md | 480 +++++++----------- doc/Process-roles-Specs.md | 38 +- ...ment-Specs.md => Silent-Payments-Specs.md} | 44 +- doc/Specs-Code.md | 2 +- doc/Specs-Datamodel.md | 350 ++++++------- doc/Specs-Definition.md | 26 +- doc/Specs-References.md | 4 +- doc/Specs-Security-confidentiality.md | 18 +- doc/_Doc_references.md | 4 +- doc/diagrams/4NK-CheatSheet.drawio | 2 +- doc/diagrams/PCD.drawio | 6 +- doc/diagrams/PCD_PRD_encryption.drawio | 6 +- doc/diagrams/PRD.drawio | 12 +- doc/diagrams/PRDConfirm.drawio | 6 +- doc/diagrams/PRDKeyBackup.drawio | 10 +- doc/diagrams/PRDKeyHello.drawio | 16 +- doc/diagrams/PRDList.drawio | 14 +- doc/diagrams/PRDMessage.drawio | 12 +- doc/diagrams/PRDResponse.drawio | 4 +- doc/diagrams/PRDUpdate.drawio | 22 +- doc/diagrams/PeerReceivedScore.drawio | 2 +- doc/diagrams/WalletCreate.drawio | 40 +- doc/diagrams/WalletOnboard.drawio | 16 +- doc/diagrams/WalletRecover.drawio | 60 +-- src/models/condition_payment.rs | 16 +- src/models/condition_publish.rs | 10 +- src/models/item_enum.rs | 4 +- src/models/item_member.rs | 64 +-- src/models/item_payment.rs | 46 +- src/models/key_encryption.rs | 32 +- src/models/mod.rs | 8 +- src/models/payment_method.rs | 4 +- src/models/request_pcd.rs | 12 +- src/models/request_prd.rs | 14 +- src/models/request_prd_confirm.rs | 28 +- src/models/request_prd_key_backup.rs | 16 +- src/models/request_prd_key_hello.rs | 16 +- src/models/request_prd_list.rs | 16 +- src/models/request_prd_message.rs | 16 +- src/models/request_prd_response.rs | 56 +- src/models/request_prd_update.rs | 34 +- src/models/role.rs | 14 +- src/models/role_payment.rs | 6 +- src/models/roles_group.rs | 14 +- src/wallet.rs | 2 +- .../workflow_pcd_create_and_send_all.rs | 14 +- 50 files changed, 827 insertions(+), 915 deletions(-) rename doc/{Silent-Payment-Specs.md => Silent-Payments-Specs.md} (50%) diff --git a/Cargo.toml b/Cargo.toml index 6aa3f31..44f1c53 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -11,7 +11,7 @@ wasm-bindgen = "0.2.90" serde = { version = "1.0.193", features = ["derive"] } serde_json = "1.0.108" # sp_backend = { git = "https://github.com/Sosthene00/sp-backend.git", branch = "master" } -# silentpayments = { git = "https://github.com/Sosthene00/rust-silentpayments", branch = "utils" } +# silentPayments = { git = "https://github.com/Sosthene00/rust-silentPayments", branch = "utils" } rand = "0.8.5" hex = "0.4.3" uuid = { version = "1.6.1", features = ["serde", "v4"] } diff --git a/doc/Auth-Specs.md b/doc/Auth-Specs.md index 70543c9..e1675ae 100644 --- a/doc/Auth-Specs.md +++ b/doc/Auth-Specs.md @@ -20,7 +20,7 @@ * 10.1.3. [Onboarding](#Onboarding-1) * 10.2. [ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process](#ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess) * 10.3. [ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess) - * 10.4. [Réception des RequestPcd et RequestPrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)](#RceptiondesRequestPcdetRequestPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn) + * 10.4. [Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)](#RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn) * 11. [Clés de révocation (`revoke`)](#Clsdervocationrevoke) * 12. [Clés de third parties](#Clsdethirdparties) * 13. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover) @@ -31,7 +31,7 @@ ## 1. Objectif -Développer un système de login sécurisé utilisant les clés cryptographiques de Bitcoin et sa timechain (via un réseau Signet personnalisé, appelé "side chain") ainsi qu'un système de relais de messages entre parties prenantes. Le concept de Silent Payment est employé pour authentifier les utilisateurs sans réutilisation d'adresses, tout en utilisant une approche de `calcul multipartite (MPC)` pour une gestion sécurisée et distribuée des clés. Déployer une interface de login conforme aux wireframes : +Développer un système de login sécurisé utilisant les clés cryptographiques de Bitcoin et sa timechain (via un réseau Signet personnalisé, appelé "side chain") ainsi qu'un système de relais de messages entre parties prenantes. Le concept de Silent Payments est employé pour authentifier les utilisateurs sans réutilisation d'adresses, tout en utilisant une approche de `calcul multipartite (MPC)` pour une gestion sécurisée et distribuée des clés. Déployer une interface de login conforme aux wireframes : ![Wireframes](diagrams/Login-Wireframes.png "Wireframes") @@ -75,7 +75,7 @@ Voir [_Doc_references.md](_Doc_references.md). 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`. +Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payments pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties`. 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`. @@ -91,7 +91,7 @@ Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API d En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis. -Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux `RequestPcd` et `RequestPrd` correspondants. +Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux `Pcd` et `Prd` correspondants. ## 8. Gestion de session basée sur un cache @@ -186,13 +186,13 @@ Hash speudo code : pre_id=sha256(part1_spend_recover_enc, MDP) ``` -3. Création d'un `RequestPrdList` par membre (1 shard par membre), par `RequestPrd` : +3. Création d'un `PrdList` par membre (1 shard par membre), par `Prd` : 3.1. Génération d'une clé de chiffrement dite `sp_shared_secret` qui sera transmise dans le Diffie-Hellman de la transaction SP. - 3.2. Création d'un `ItemMember` à envoyer avec le `RequestPrdList`. + 3.2. Création d'un `ItemMember` à envoyer avec le `PrdList`. -4. Création des messages de type `Message` correspondant aux RequestPrd, envoi des messages aux relais connectés. +4. Création des messages de type `Message` correspondant aux Prd, envoi des messages aux relais connectés. Dans l'ordre on réalise donc les opérations suivantes donc : @@ -207,18 +207,18 @@ Dans l'ordre on réalise donc les opérations suivantes donc : Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant l'`ItemProcess` choisi. -Chacun de des managers des membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `RequestPrdResponse` en réponse au `RequestPrdList` envoyé. +Chacun de des managers des membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `PrdResponse` en réponse au `PrdList` envoyé. Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : -1. Création de `RequestPrdList` à destination du membre -2. Création de `Message` du `RequestPrdList` à destination du membre. +1. Création de `PrdList` à destination du membre +2. Création de `Message` du `PrdList` à destination du membre. 3. Envoi de la transaction SP du `Message` du `RequestList` à destination du membre. -4. Envoi du `Message` du `RequestPrdList` à destination du membre. -5. Atttente de la réception des `RequestPrdResponse` en réponse aux `RequestPrdList` (confirmations). -6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. +4. Envoi du `Message` du `PrdList` à destination du membre. +5. Atttente de la réception des `PrdResponse` en réponse aux `PrdList` (confirmations). +6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PrdResponse`. 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. - 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. + 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_confidential` des `PrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. 6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe 6.4. Concaténation de `Part1` et `Part2` @@ -230,23 +230,23 @@ Le role `member` de l'`itemProcess` sélectionné contient un `Item` avec des `m Ces formulaires permettront de créé les champs attendus par `condition_attribute_encryption_list` dans le role `Member` de l'`ItemProcess` sélectionné, dans l`ItemMember` de l'utilisateur (champs dans `data` des attribut `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` correpsondants). -Une fois l'`ItemMember` complété, il est ajouté à la liste des membres pour créer un nouveau `RequestPcd` envoyé pour mises à jours aux managers du rôle `Member` du `ItemProcess` sélectionné via un `RequestPrdUpdate`. +Une fois l'`ItemMember` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Member` du `ItemProcess` sélectionné via un `PrdUpdate`. ### 10.3. ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process Pour le ou les roles sélectionnés, l'attribut `request_prd_sp_address_list` de `condition_prd_address_set_list` est complété par l'adresse SP de l'utilisateur. -Une fois l'`ItemProcess` complété, il est ajouté à la liste des membres pour créer un nouveau `RequestPcd` envoyé pour mises à jours aux managers du rôle `Process` du `ItemProcess` sélectionné via un `RequestPrdUpdate`. +Une fois l'`ItemProcess` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Process` du `ItemProcess` sélectionné via un `PrdUpdate`. -### 10.4. Réception des RequestPcd et RequestPrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné) +### 10.4. Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné) -Envoi d'un `RequestPrdList` pour chaque membre de chaque rôle du process sélectionné. +Envoi d'un `PrdList` pour chaque membre de chaque rôle du process sélectionné. ## 11. Clés de révocation (`revoke`) Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif. -L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `RequestPrdList` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface). +L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `PrdList` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface). ## 12. Clés de third parties @@ -254,25 +254,25 @@ Au moment de l'update de l'`ItemMember` il est possible de charger des addresses 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. -Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les `RequestPrd` concernés. +Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les `Prd` concernés. ## 13. Connexions avec une identité crée (`recover`) -Pour recrééer sa clé privée et envoyer un `RequestPrdList` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes : +Pour recrééer sa clé privée et envoyer un `PrdList` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes : 1. Récupération de Part1Enc en cache 2. Création de la `pre_id` avec le mot de passe Puis depuis la liste des membres du process, pour chacun des membres : -1. Création de `RequestPrdList` à destination du membre 1. -2. Création de `Message` du `RequestPrdList` à destination du membre. -3. Envoi de la transaction SP du `Message` du `RequestPrdList` à destination du membre avec la `pre_id`. -4. Envoi du `Message` du `RequestPrdList` à destination du membre. -5. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`. -6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. +1. Création de `PrdList` à destination du membre 1. +2. Création de `Message` du `PrdList` à destination du membre. +3. Envoi de la transaction SP du `Message` du `PrdList` à destination du membre avec la `pre_id`. +4. Envoi du `Message` du `PrdList` à destination du membre. +5. Attente de la validation (`PrdResponse`) du `PrdUpdate`. +6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PrdResponse`. 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. - 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. + 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_confidential` des `PrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. 6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe 6.4. Concaténation de `Part1` et `Part2` 7. Réception des flux PCD et PRDResponse des gestionnaires des membres @@ -281,4 +281,4 @@ Puis depuis la liste des membres du process, pour chacun des membres : ## 15. Todo -* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. +* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. diff --git a/doc/Item-Specs.md b/doc/Item-Specs.md index 4e776c8..ea83763 100644 --- a/doc/Item-Specs.md +++ b/doc/Item-Specs.md @@ -16,7 +16,7 @@ ## 1. Objectif -Les transactions Silent Payment SP intègrent directement dans l'architecture web de l'application, comme démontré dans le client web. La gestion et l'intégration des SP sont conçues pour être fluides avec les systèmes front-end, assurant une expérience utilisateur transparente tout en maintenant la sécurité et la confidentialité au cœur de l'interaction utilisateur. +Les transactions Silent Payments SP intègrent directement dans l'architecture web de l'application, comme démontré dans le client web. La gestion et l'intégration des SP sont conçues pour être fluides avec les systèmes front-end, assurant une expérience utilisateur transparente tout en maintenant la sécurité et la confidentialité au cœur de l'interaction utilisateur. ## 2. Portée @@ -32,16 +32,16 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé * **Member**: Représente les utilisateurs ou entités participant à un processus. * **Peer**: Identifie les nœuds ou participants du réseau qui aident à faciliter les communications et les transactions. * **Artefact** : Un type d'objet générique personnalisable dans les `ItemProcess` , il peut y avoir une quantité infinie de type d'`artefacts` différents par `ItemProcess`. -* **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. +* **Payments, Deposit, Commitment**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques. ### 3.2. Composition et Fonction * **uuid**: Identifiant unique de l'item, assurant sa traçabilité et son unicité au sein du système. * **version**: Numéro de version de l'item, facilitant le suivi des mises à jour et des modifications. * **hash**: Optionnel, fournit un hash de l'item pour vérifier son intégrité et son authenticité. -* **item_type**: Catégorie ou type de l'item, tel que Process, Member, Payment, qui détermine son rôle et son utilisation dans le réseau. +* **item_type**: Catégorie ou type de l'item, tel que Process, Member, Payments, qui détermine son rôle et son utilisation dans le réseau. * **name**: Nom ou description de l'item, offrant un moyen de le référencer ou de l'identifier de manière lisible. -* **pagination_number_per_request_pcd**: Détermine comment l'item est paginé ou divisé dans le contexte des RequestPcd, affectant la manière dont il est présenté ou accessible. +* **pagination_number_per_request_pcd**: Détermine comment l'item est paginé ou divisé dans le contexte des Pcd, affectant la manière dont il est présenté ou accessible. * **metadata**: Comprend MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate, encapsulant les attributs de l'item selon différents niveaux de confidentialité. #### 3.2.1. Cas d'utilisation @@ -72,5 +72,5 @@ La richesse et la diversité des métadonnées permettent une personnalisation e ## 6. Todo -* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. +* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/Messages-Specs.md b/doc/Messages-Specs.md index 5e0d9c5..843b8ca 100644 --- a/doc/Messages-Specs.md +++ b/doc/Messages-Specs.md @@ -22,8 +22,8 @@ * 7.1. [Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect) * 7.1.1. [Récupération et choix des relais](#Rcuprationetchoixdesrelais) * 7.1.2. [Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais) - * 7.2. [Envoi de `RequestPcd` sur les relais via les messages de type `Message`](#EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage) - * 7.3. [Envoi de `RequestPrd` sur les relais via les messages de type `Message`](#EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage) + * 7.2. [Envoi de `Pcd` sur les relais via les messages de type `Message`](#EnvoidePcdsurlesrelaisvialesmessagesdetypeMessage) + * 7.3. [Envoi de `Prd` sur les relais via les messages de type `Message`](#EnvoidePrdsurlesrelaisvialesmessagesdetypeMessage) * 7.4. [Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients) * 8. [Traitements par les relais](#Traitementsparlesrelais) * 8.1. [Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais) @@ -41,7 +41,7 @@ * 10.6.1. [Clients](#Clients) * 10.6.2. [Relais](#Relais-1) * 10.7. [Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1) - * 10.8. [Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP)](#HorodatageetancragedesRequestPrdvialestransactionsSilentPaymentSP) + * 10.8. [Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)](#HorodatageetancragedesPrdvialestransactionsSilentPaymentsP) * 11. [Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin) * 11.1. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin) * 11.2. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin) @@ -84,9 +84,9 @@ Les objets `SharedPeer` définissent les caractéristiques de la preuve de trava ### 5.5. 6.5. Adresse SP de faucet -L'utilisateur fournit aux relais une adresse SP (Silent Payment) dite de faucet `faucet_sp_address`. Un portefeuille est généré en mémoire pour chaque relais à la réception des fonds, les fonds sont ensuite transférés vers l'adresse SP de l'utilisateur et le portefeuille est supprimé. +L'utilisateur fournit aux relais une adresse SP (Silent Payments) dite de faucet `faucet_sp_address`. Un portefeuille est généré en mémoire pour chaque relais à la réception des fonds, les fonds sont ensuite transférés vers l'adresse SP de l'utilisateur et le portefeuille est supprimé. -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 inclut un output supplémentaire avec le hash du message de type `MessageConnect` ou `Message` correspondant. +L'utilisateur reçoit en retour une transaction Silent Payments (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction inclut un output supplémentaire avec le hash du message de type `MessageConnect` ou `Message` correspondant. ### Objets `MessageGeneric` contenu dans les types `Message` et `MessageConnect` @@ -94,7 +94,7 @@ L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant de * **`shared_peer_list`** : Une liste de pairs partagés, représentée par des objets `SharedPeer`. Cette liste sert à partager les pairs entre les relais et les clients et les relais entre eux. * **`shared_process_list`** : Une liste de processus partagés, représentée par des objets `SharedProcess`. Cette liste sert à partager les processus entre les relais et les clients et les relais entre eux. -* **`faucet_sp_address`** : L'adresse pour recevoir les fonds du faucet (indispensable pour pouvoir crééer des requètes Silent Payment). +* **`faucet_sp_address`** : L'adresse pour recevoir les fonds du faucet (indispensable pour pouvoir crééer des requètes Silent Payments). * **`pow`** : Représente un défi de Preuve de Travail (PoW), représentée par un objet `Pow`. * **`raw_transaction_list`** : Liste de transactions à diffuser. @@ -138,13 +138,13 @@ La structure `L1Node` détaille un nœud blockchain de niveau 1 pour la validati * **`reward_send_tx_list`** : Liste des transactions de récompense dépensées par ce noeud. * **`anchorage_tx_list`** : Liste des transactions d'ancrage dépensées par ce noeud. * **`spend_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour dépenser les fonds de ce noeud. -* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payment les fonds de ce noeud. +* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payments les fonds de ce noeud. La structure `L1NodeMining` détaille un nœud blockchain de niveau 1 (Layer 1) se concentrant sur les opérations minières. Les attributs ont les fonctions suivantes : * **`block_mined_list`** : Liste des blocs extraits. * **`spend_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour dépenser les fonds de ce noeud. -* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payment les fonds de ce noeud. +* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payments les fonds de ce noeud. La structure `L2Node` représente un nœud blockchain de niveau 2 (Layer 2) pour la validation et le relais des transaction. Les attributs ont les fonctions suivantes : @@ -156,7 +156,7 @@ La structure `L2Node` représente un nœud blockchain de niveau 2 (Layer 2) pou * **`magic_number`** : Le nombre magique propre à la blochain. * **`challenge`** : Le script de signature des blocs. * **`spend_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour dépenser les fonds de ce noeud. -* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payment les fonds de ce noeud. +* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payments les fonds de ce noeud. La structure `L2NodeMining` détaille un nœud blockchain de niveau 2 (Layer 2) se concentrant sur les opérations minières. Les attributs ont les fonctions suivantes : @@ -164,14 +164,14 @@ La structure `L2NodeMining` détaille un nœud blockchain de niveau 2 (Layer 2) * **`sp_address_refunder`** : Adresse SP rembourseur. * **`block_hash_mined_list`** : Liste des hashes de blocs extraits. * **`spend_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour dépenser les fonds de ce noeud. -* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payment les fonds de ce noeud. +* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payments les fonds de ce noeud. La structure `L2Certif` spécifie une certification de niveau 2. Les attributs ont les fonctions suivantes : * **`sp_address_certif_l1`** : Adresse de certification de niveau 1. * **`block_certified_list`** : Liste des blocs certifiés de types `BlockCertif`. * **`spend_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour dépenser les fonds de ce noeud. -* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payment les fonds de ce noeud. +* **`scan_key`** : [PRIVE] cet attribut n'est pas partager dans le message, c'est la clé privée pour détecter les transaction Silent Payments les fonds de ce noeud. La structure `BlockCertif` spécifie un bloc certifié. Les attributs ont les fonctions suivantes : @@ -184,7 +184,7 @@ La structure `BlockCertif` spécifie un bloc certifié. Les attributs ont les f #### 6.1.1. 7.1.1. Récupération et choix des relais -Pour discuter avec les relais du réseau et faire relayer des `RequestPcd` et des `RequestPrd` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, quatre par défaut. +Pour discuter avec les relais du réseau et faire relayer des `Pcd` et des `Prd` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, quatre par défaut. L'utilisateur envoie un message de type `MessageConnect` à chaque relais pour se connecter. Ensuite, il peut envoyer des `Message` à chacun des quatre relais connectés et recevoir des `Message` de leur part. @@ -210,7 +210,7 @@ Objet de type `MessageConnect`. Les attributs ont les fonctions suivantes : * ***message** : Contient le `MessageGeneric` -### 6.2. 7.2. Envoi de `Request` sur les relais via les messages de type `Message` +### 6.2. 7.2. Envoi de `Request` sur les relais via les messages de type `Message` ![MessageSend.png](diagrams/MessageSend.png "MessageSend.") @@ -219,7 +219,7 @@ Objet de type `MessageConnect`. Les attributs ont les fonctions suivantes : Objet de type `Message`, Les attributs ont les fonctions suivantes : * **`message`** : Contient le `MessageGeneric` -* **`request_enc`** : Contient le `RequestPcd` ou un `RequestPrd` chiffré par la `ProcessKey` +* **`request_enc`** : Contient le `Pcd` ou un `Prd` chiffré par la `ProcessKey` ### 6.4. 7.4. Traitement des messages de type `Message` par les clients @@ -279,7 +279,7 @@ Bitcoin gère les bifurcations temporaires de la blockchain, permettant une réo #### 9.6.1. 10.6.1. Clients -Les clients se connectent au réseau de nœuds de side chain pour recevoir les blocs et les transactions, y compris les transactions Silent Payment (SP) liées aux `RequestPrd`. +Les clients se connectent au réseau de nœuds de side chain pour recevoir les blocs et les transactions, y compris les transactions Silent Payments (SP) liées aux `Prd`. #### 9.6.2. 10.6.2. Relais @@ -289,9 +289,9 @@ Les relais fonctionnent comme des nœuds complets de la side chain, facilitant l Les relais maintiennent également une connexion au réseau principal (mainnet) pour des opérations d'ancrage et d'horodatage. -### 9.8. 10.8. Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP) +### 9.8. 10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP) -Les `RequestPrd` sont ancrés dans la side chain à travers des transactions SP, offrant une preuve immuable de leur existence et de leur intégrité. +Les `Prd` sont ancrés dans la side chain à travers des transactions SP, offrant une preuve immuable de leur existence et de leur intégrité. ## 10. 11. Transactions mainnet Bitcoin @@ -309,5 +309,5 @@ Ces spécifications techniques fournissent une vue d'ensemble de la façon dont ## 12. Todo -* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. +* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index d7f67b2..39b5915 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -4,71 +4,56 @@ * 3. [Documents de référence](#Documentsderfrence) * 4. [Définitions](#Dfinitions) * 5. [Principes de messagerie](#Principesdemessagerie) - * 5.1. [`RequestPrdConfirm`](#RequestPrdConfirm) - * 5.2. [`RequestPrdResponse`](#RequestPrdResponse) * 6. [Encryption](#Encryption) - * 6.1. [Création et envoi](#Crationetenvoi) - * 6.2. [Réception](#Rception) -* 7. [Fonction des RequestPcd](#FonctiondesRequestPcd) - * 7.1. [Schéma des flux](#Schmadesflux) - * 7.2. [Création et envoi](#Crationetenvoi-1) - * 7.3. [Réception](#Rception-1) -* 8. [Fonction des`RequestPrd`](#FonctiondesRequestPrd) - * 8.1. [Schéma des flux](#Schmadesflux-1) - * 8.2. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles) - * 8.3. [Création et envoi](#Crationetenvoi-1) - * 8.4. [Réception](#Rception-1) -* 9. [RequestPrdList - Demande de Listes ](#RequestPrdList-DemandedeListesRequestPcd) - * 9.1. [Schéma des flux](#Schmadesflux-1) - * 9.2. [Création : Datas spécifiques](#Cration:Datasspcifiques) - * 9.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques) -* 10. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages) - * 10.1. [Schéma des flux](#Schmadesflux-1) - * 10.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 10.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 11. [RequestPrdUpdate - Mises à Jour de RequestPcd](#RequestPrdUpdate-MisesJourdeRequestPcd) - * 11.1. [Schéma des flux](#Schmadesflux-1) - * 11.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 11.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 12. [RequestPrdConfirm - Confirmation de Réception](#RequestPrdConfirm-ConfirmationdeRception) - * 12.1. [Schéma des flux](#Schmadesflux-1) - * 12.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 12.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 13. [RequestPrdResponse - Répondre à une Demande](#RequestPrdResponse-RpondreuneDemande) - * 13.1. [Schéma des flux](#Schmadesflux-1) - * 13.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 13.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) +* 7. [Fonction des Pcd](#FonctiondesPcd) +* 7.1. [Schéma des flux](#Schmadesflux) +* 7.2. [Création et envoi](#Crationetenvoi) +* 7.3. [Réception](#Rception) +* 8. [Fonction des`Prd`](#FonctiondesPrd) +* 8.1. [Schéma des flux](#Schmadesflux-1) +* 8.2. [Création d'un `Prd`](#CrationdunPrd) +* 8.3. [Réception](#Rception-1) +* 9. [PrdList - Demande de Listes](#PrdList-DemandedeListes) +* 9.1. [Schéma des flux](#Schmadesflux-1) +* 10. [PrdMessage - Envoi de Messages](#PrdMessage-EnvoideMessages) +* 10.1. [Schéma des flux](#Schmadesflux-1) +* 11. [PrdUpdate - Mises à Jour de Pcd](#PrdUpdate-MisesJourdePcd) +* 11.1. [Schéma des flux](#Schmadesflux-1) +* 12. [PrdConfirm - Confirmation de Réception](#PrdConfirm-ConfirmationdeRception) +* 12.1. [Schéma des flux](#Schmadesflux-1) +* 13. [PrdResponse - Répondre à une Demande](#PrdResponse-RpondreuneDemande) +* 13.1. [Schéma des flux](#Schmadesflux-1) * 14. [Exemples de Code](#ExemplesdeCode) * 15. [Todo](#Todo) -# `RequestPrd` et `RequestPcd` - Specs +# `Prd` et `Pcd` - Specs -## 1. Objectif +## 1. Objectif -Le but de cette section est d'introduire les Portable Contract Document (`RequestPcd`) et Portable Request Document (`RequestPrd`) comme éléments fondamentaux du système 4NK. Ces documents jouent un rôle crucial dans la sécurisation des échanges de données et la gestion des identités numériques au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau. +Le but de cette section est d'introduire les Portable Contract Document (`Pcd`) et Portable Request Document (`Prd`) comme éléments fondamentaux du système 4NK. Ces documents jouent un rôle crucial dans la sécurisation des échanges de données et la gestion des identités numériques au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau. -## 2. Portée +## 2. Portée -La spécification couvre la conception, le développement, et l'application pratique des `RequestPcd` et `RequestPrd`.Elle vise à expliquer leur fonctionnement, leur structure, et la manière dont ils contribuent à l'écosystème 4NK en offrant une méthode sécurisée et efficace pour le partage d'informations et la validation des transactions. Les `RequestPcd` et `RequestPrd` encapsulent les données contractuelles et les requêtes dans un format standardisé, assurant l'intégrité, la confidentialité, l'authenticité et la validation des informations échangées. +La spécification couvre la conception, le développement, et l'application pratique des `Pcd` et `Prd`.Elle vise à expliquer leur fonctionnement, leur structure, et la manière dont ils contribuent à l'écosystème 4NK en offrant une méthode sécurisée et efficace pour le partage d'informations et la validation des transactions. Les `Pcd` et `Prd` encapsulent les données contractuelles et les requêtes dans un format standardisé, assurant l'intégrité, la confidentialité, l'authenticité et la validation des informations échangées. -## 3. Documents de référence +## 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 4. Définitions +## 4. Définitions -* **Portable Contract Document (`RequestPcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `ItemProcess` (`item_type`). +* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `ItemProcess` (`item_type`). -* **Portable Request Document (`RequestPrd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `RequestPcd`. Les `RequestPrdResponse` sont collectés pour vérifier le respect des conditions de l'`ItemProcess`. D'autres types de `RequestPrd` incluent : - * `RequestPrdList`: Demande de listes d'`Item`. En réponse, une `RequestPcd` est reçue avec les `RequestPrdResponse` correspondants. - * `RequestPrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou de transactions Silent Payments des autres `RequestPrd` à diffuser sur le réseau des nœuds de la side chain. Les `RequestPrdMessage` peuvent répondre les uns aux autres. - * `RequestPrdUpdate`: Demande de mise à jour d'une liste d'`Item` (publiée via un `RequestPCD`), qui sera déchiffrée et validée ou non par des `RequestPrdResponse` en retour. - * `RequestPrdConfirm`: Confirmation de la réception des `RequestPrd` (à l'exception de `RequestPrdConfirm` eux-même). - * `RequestPrdResponse`: Réponse aux autres types de `RequestPrd` (à l'exception de `RequestPrdConfirm`, et `RequestPrdMessage`). +* **Portable Request Document (`Prd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `Pcd`. Les `PrdResponse` sont collectés pour vérifier le respect des conditions de l'`ItemProcess`. D'autres types de `Prd` incluent : + * `PrdList`: Demande de listes d'`Item`. En réponse, une `Pcd` est reçue avec les `PrdResponse` correspondants. + * `PrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou de transactions Silent Payments des autres `Prd` à diffuser sur le réseau des nœuds de la side chain. Les `PrdMessage` peuvent répondre les uns aux autres. + * `PrdUpdate`: Demande de mise à jour d'une liste d'`Item` (publiée via un `PCD`), qui sera déchiffrée et validée ou non par des `PrdResponse` en retour. + * `PrdConfirm`: Confirmation de la réception des `Prd` (à l'exception de `PrdConfirm` eux-même). + * `PrdResponse`: Réponse aux autres types de `Prd` (à l'exception de `PrdConfirm`, et `PrdMessage`). -* **Message**: Enveloppe commune pour les `RequestPrd` et `RequestPcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `RequestPrd` et `RequestPcd` sont chiffrés par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`. +* **Message**: Enveloppe commune pour les `Prd` et `Pcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `Prd` et `Pcd` sont chiffrés par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`. -* **KeyConfidential**: Clé AES-GCM-256 issue du `Diffie-Hellman` de la transaction Silent Payment correspondant à un `RequestPrd`. +* **KeyConfidential**: Clé AES-GCM-256 issue du `Diffie-Hellman` de la transaction Silent Payments correspondant à un `Prd`. * **ProcessKey**: La clé publique de chiffrement d'un `ItemProcess` (trouvée dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément). @@ -76,111 +61,111 @@ Voir [_Doc_references.md](_Doc_references.md). * **pre-id**: Pré-identifiant des utilisateurs, constitué du hash de la partie 1 de la `KeyRecover`. -## 5. Principes de messagerie +## 5. Principes de messagerie -Les `RequestPcd` sont envoyés à tous les participants connectés sans attente de retour spécifique et ne sont pas associés à une `transaction SP`. +Les `Pcd` sont envoyés à tous les participants connectés sans attente de retour spécifique et ne sont pas associés à une `transaction SP`. -Les `RequestPrd` sont toujours accompagnés d'une `transaction SP`, transmise dans l'attribut `raw_transaction_list` d'un `RequestPrdMessage` associé (à l'exception des `RequestPrdMessage` eux-mêmes). +Les `Prd` sont toujours accompagnés d'une `transaction SP`, transmise dans l'attribut `raw_transaction_list` d'un `PrdMessage` associé (à l'exception des `PrdMessage` eux-mêmes). -Les `RequestPrd` sont des demandes d'actions ou des réponses à ces demandes, interagissant de la manière suivante : +Les `Prd` sont des demandes d'actions ou des réponses à ces demandes, interagissant de la manière suivante : -* `RequestPrdList` : Constitue généralement la première requête d'un workflow et ne répond pas à un autre `RequestPrd`. -* `RequestPrdMessage`, avec 2 cas de figure : - * Demande de relais d'une `transaction SP`, dans ce cas, le `RequestPrdMessage` ne répond pas à un autre `RequestPrd`. - * Envoi de message, pouvant initier un échange de messagerie ou répondre à un autre `RequestPrdMessage`. -* `RequestPrdUpdate` : Souvent la première requête d'un workflow, un `RequestPrdUpdate` ne répond pas à un autre `RequestPrd`. -* `RequestPrdConfirm` : Répond à tous les autres types de `RequestPrd` (à l'exception des `RequestPrdConfirm` eux-mêmes). -* `RequestPrdResponse` : Répond à tous les autres types de `RequestPrd` (à l'exception des `RequestPrdConfirm`, `RequestPrdResponse` eux-mêmes). Dans le cas d'une réponse à un `RequestPrdList` ou d'un `RequestPrdUpdate`, le `RequestPrdResponse` doit obligatoirement être accompagné d'un `RequestPcd`. +* `PrdList` : Constitue généralement la première requête d'un workflow et ne répond pas à un autre `Prd`. +* `PrdMessage`, avec 2 cas de figure : + * Demande de relais d'une `transaction SP`, dans ce cas, le `PrdMessage` ne répond pas à un autre `Prd`. + * Envoi de message, pouvant initier un échange de messagerie ou répondre à un autre `PrdMessage`. +* `PrdUpdate` : Souvent la première requête d'un workflow, un `PrdUpdate` ne répond pas à un autre `Prd`. +* `PrdConfirm` : Répond à tous les autres types de `Prd` (à l'exception des `PrdConfirm` eux-mêmes). +* `PrdResponse` : Répond à tous les autres types de `Prd` (à l'exception des `PrdConfirm`, `PrdResponse` eux-mêmes). Dans le cas d'une réponse à un `PrdList` ou d'un `PrdUpdate`, le `PrdResponse` doit obligatoirement être accompagné d'un `Pcd`. -Selon le type de `RequestPrd`, les demandes peuvent s'adresser à tous les membres de l'`ItemProcess`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : +Selon le type de `Prd`, les demandes peuvent s'adresser à tous les membres de l'`ItemProcess`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : -* `RequestPrdList` : Envoyé aux gestionnaires du type d'`Item` concerné. -* `RequestPrdMessage`, avec 2 cas de figure : - * Demande de relais d'une `transaction SP`, dans ce cas, destinée au destinataire du `RequestPrd` associé. +* `PrdList` : Envoyé aux gestionnaires du type d'`Item` concerné. +* `PrdMessage`, avec 2 cas de figure : + * Demande de relais d'une `transaction SP`, dans ce cas, destinée au destinataire du `Prd` associé. * Envoi de message au destinataire du message. -* `RequestPrdUpdate` : Envoyé aux gestionnaires du type d'`Item` concerné. -* `RequestPrdConfirm` : Envoyé à l'émetteur du `RequestPrd` associé. -* `RequestPrdResponse`, avec 2 cas de figure : - * Réponse à un `RequestPrdList` : envoyée à l'émetteur du `RequestPrdList`. - * Réponse à un `RequestPrdUpdate` : envoyée à tous les membres et à l'émetteur du `RequestPrdUpdate`. +* `PrdUpdate` : Envoyé aux gestionnaires du type d'`Item` concerné. +* `PrdConfirm` : Envoyé à l'émetteur du `Prd` associé. +* `PrdResponse`, avec 2 cas de figure : + * Réponse à un `PrdList` : envoyée à l'émetteur du `PrdList`. + * Réponse à un `PrdUpdate` : envoyée à tous les membres et à l'émetteur du `PrdUpdate`. -Les traitements pour l'envoi des `RequestPrd` varient selon leur type, principalement autour des aspects suivants : +Les traitements pour l'envoi des `Prd` varient selon leur type, principalement autour des aspects suivants : -* **`request_type`**: Est un attribut des `RequestPrd` et des `RequestPcd` permettant de connaître le type de requête. +* **`request_type`**: Est un attribut des `Prd` et des `Pcd` permettant de connaître le type de requête. * **Notification user** : Nécessité de notifier l'utilisateur courant, ou non. -* **`transaction SP` + `RequestPrdMessage`** : Envoi d'une `transaction SP` dans un `RequestPrdMessage`, ou non. -* **`RequestPcd` to send** : Envoi d'un `RequestPcd` en complément du `RequestPrd`. -* **`request_type` send to** : Membres qui recevront les `transaction SP` et les `RequestPrdMessage` correspondants, avec les clés de déchiffrement pour les champs confidentiels. -* **`RequestPcd` reply waiting** : Attente d'un `RequestPcd` en retour, ou non. -* **`RequestPrdResponse` reply waiting** : Attente d'un ou de plusieurs `RequestPrdResponse` en retour, ou non. -* **`RequestPrdConfirm` reply waiting** : Attente d'un `RequestPrdConfirm` en retour, ou non. +* **`transaction SP` + `PrdMessage`** : Envoi d'une `transaction SP` dans un `PrdMessage`, ou non. +* **`Pcd` to send** : Envoi d'un `Pcd` en complément du `Prd`. +* **`request_type` send to** : Membres qui recevront les `transaction SP` et les `PrdMessage` correspondants, avec les clés de déchiffrement pour les champs confidentiels. +* **`Pcd` reply waiting** : Attente d'un `Pcd` en retour, ou non. +* **`PrdResponse` reply waiting** : Attente d'un ou de plusieurs `PrdResponse` en retour, ou non. +* **`PrdConfirm` reply waiting** : Attente d'un `PrdConfirm` en retour, ou non. Ce qui est résumé pour l'envoi : -| `request_type` | Notification user | `transaction SP` + `RequestPrdMessage` | `RequestPcd` to send | `request_type` send to | `RequestPcd` reply waiting | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting | +| `request_type` | Notification user | `transaction SP` + `PrdMessage` | `Pcd` to send | `request_type` send to | `Pcd` reply waiting | `PrdResponse` reply waiting | `PrdConfirm` reply waiting | |----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------| -| `RequestPrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes | -| `RequestPrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `ItemProcess` | No | Yes | Yes | -| `RequestPrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `ItemProcess` | No | No | if no `raw_transaction_list` | -| `RequestPrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | -| `RequestPrdConfirm` | (option) Waiting `code_confirm_enc_by_shared_secret` | Yes | No | See Received | No | No | No | +| `PrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes | +| `PrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `ItemProcess` | No | Yes | Yes | +| `PrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `ItemProcess` | No | No | if no `raw_transaction_list` | +| `PrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | +| `PrdConfirm` | (option) Waiting `code_confirm_confidential` | Yes | No | See Received | No | No | No | -Les traitements pour la réception des `RequestPrd` varient selon leur type, principalement autour des aspects suivants : +Les traitements pour la réception des `Prd` varient selon leur type, principalement autour des aspects suivants : * **Notification user** : Nécessité de notifier l'utilisateur courant, ou non. -* **`RequestPrdConfirm` to send**: Envoi d'une confirmation, ou non -* **`RequestPrdResponse` to send**: Envoi d'un `RequestPrdResponse` ou non. -* **`RequestPrdResponse` reply waiting**: Attente d'un `RequestPrdResponse` en retour ou non. -* **`RequestPrdConfirm` reply waiting (from `RequestPrdResponse` send )**: Attente d'un `RequestPrdConfirm` en retour ou non. +* **`PrdConfirm` to send**: Envoi d'une confirmation, ou non +* **`PrdResponse` to send**: Envoi d'un `PrdResponse` ou non. +* **`PrdResponse` reply waiting**: Attente d'un `PrdResponse` en retour ou non. +* **`PrdConfirm` reply waiting (from `PrdResponse` send )**: Attente d'un `PrdConfirm` en retour ou non. Ce qui est résumé Pour la réception : -| `request_type` | Notification user | `RequestPrdConfirm` to send | `RequestPcd` to send | `RequestPrdResponse` to send | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting (from `RequestPrdResponse` send ) | +| `request_type` | Notification user | `PrdConfirm` to send | `Pcd` to send | `PrdResponse` to send | `PrdResponse` reply waiting | `PrdConfirm` reply waiting (from `PrdResponse` send ) | |----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------| -| `RequestPrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | -| `RequestPrdUpdate` | RequestPrd | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | Yes | -| `RequestPrdMessage` | Waiting `RequestPrdMessage` reply | if no `raw_transaction_list` | No | No | No | No | -| `RequestPrdResponse` | RequestPrd | Yes | No | No | No | No | -| `RequestPrdConfirm` | RequestPrd | No | No | No | No | No | +| `PrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | +| `PrdUpdate` | Prd | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | Yes | +| `PrdMessage` | Waiting `PrdMessage` reply | if no `raw_transaction_list` | No | No | No | No | +| `PrdResponse` | Prd | Yes | No | No | No | No | +| `PrdConfirm` | Prd | No | No | No | No | No | -## 6. Encryption +## 6. Encryption Schema : ![PCD_PRD_encryption](diagrams/PCD_PRD_encryption.png "PCD_PRD_encryption") -Les `Metadata` des `Item` des `RequestPcd` et les attributs des `RequestPcd` et `RequestPrd` sont chiffrés de la sorte : +Les `Metadata` des `Item` des `Pcd` et les attributs des `Pcd` et `Prd` sont chiffrés de la sorte : * **Données publiques** : Utilisent un chiffrement symétrique basé sur la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)). Ces données sont ainsi accessibles à tous pour le déchiffrement. -* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les RequestPcd** : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un `RequestPcd`. Ces clés seront ensuite ajoutées aux `RequestPrd` dans l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`; lui même alors chiffré par la `KeyConfidential`. +* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les Pcd** : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un `Pcd`. Ces clés seront ensuite ajoutées aux `Prd` dans l'attribut `Pcd_keys_role_confidential_list_confidential`; lui même alors chiffré par la `KeyConfidential`. -* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les RequestPrd** : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les `RequestPcd` et transmises par le `RequestPrd`, chiffrées par la `KeyConfidential` du Diffie-Hellman de la transaction Silent Payment associée à ce `RequestPrd` (cf. [Specs-Definition](SpecsDefinition.md)) d'une transaction `SP`. +* **Données confidentielles destinées aux membres d'un `role` spécifique d'un `ItemProcess` dans les Prd** : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les `Pcd` et transmises par le `Prd`, chiffrées par la `KeyConfidential` du Diffie-Hellman de la transaction Silent Payments associée à ce `Prd` (cf. [Specs-Definition](SpecsDefinition.md)) d'une transaction `SP`. * **Données privées** : Chiffrées symétriquement en utilisant la clé de dépense de connexion (`recover`) du signet (voir Login - Specs). -Principaux champs des `Request` contenus dans les `RequestPcd` et `RequestPrd` chiffrés : +Principaux champs des `Request` contenus dans les `Pcd` et `Prd` chiffrés : -* **`request_type`** : Type de requête : `RequestPcd`, `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, `RequestPrdConfirm`, `RequestPrdResponse`. -* **`item_name`** : Noms des items : `peer`, `member`, `process`, `payment`, `deposit`, `commitment`, et les `artefact` personnalisés. +* **`request_type`** : Type de requête : `Pcd`, `PrdList`, `PrdMessage`, `PrdUpdate`, `PrdConfirm`, `PrdResponse`. +* **`item_name`** : Noms des items : `peer`, `member`, `process`, `Payments`, `deposit`, `commitment`, et les `artefact` personnalisés. * **`version`** : Version de la requête. * **`process_hash`** : Hash de l'`ItemProcess` concerné. -* **`request_pcd_reference_hash`** : Hash du `RequestPcd` auquel le `RequestPrd` fait référence. -* **`request_pcd_origin_hash`** : Hash du `RequestPcd` à l'origine du `RequestPrd`. -* **`request_prd_reference_hash`** : Hash du `RequestPrd` auquel le `RequestPrd` fait référence. -* **`request_prd_origin_hash`** : Hash du `RequestPrd` à l'origine du `RequestPrd`. -* **`item_reference_hash`** : Hash de l'`Item` auquel le `RequestPcd` fait référence. +* **`request_pcd_reference_hash`** : Hash du `Pcd` auquel le `Prd` fait référence. +* **`request_pcd_origin_hash`** : Hash du `Pcd` à l'origine du `Prd`. +* **`request_prd_reference_hash`** : Hash du `Prd` auquel le `Prd` fait référence. +* **`request_prd_origin_hash`** : Hash du `Prd` à l'origine du `Prd`. +* **`item_reference_hash`** : Hash de l'`Item` auquel le `Pcd` fait référence. -## 7. Fonction des RequestPcd +## 7. Fonction des Pcd -Les Portable Contract Documents (`RequestPcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)). +Les Portable Contract Documents (`Pcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)). -Les `Item` échangés via les `RequestPcd` sont soumis à une vérification par les `RequestPrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné. +Les `Item` échangés via les `Pcd` sont soumis à une vérification par les `PrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné. -Principaux champs des `RequestPcd` : +Principaux champs des `Pcd` : * **`request`** : cf la descripton de la structure `Request`. -* **`item_enc_list`** : Les `Item` chiffrés sous forme `RequestPcdItemGenericEnc` par une clé symétrique générée à la volée pour chaque champ et pour chaque item d'une liste. +* **`item_enc_list`** : Les `Item` chiffrés sous forme `PcdItemGenericEnc` par une clé symétrique générée à la volée pour chaque champ et pour chaque item d'une liste. * **`pagination`** : La pagination de la liste des `Item`. Principaux champs de la structure `Pagination` : @@ -190,72 +175,70 @@ Principaux champs de la structure `Pagination` : * **`page_index`** : Index de la page. * **`page_total`** : Nombre total de pages. -Principaux champs de la structure `RequestPcdItemGenericEnc` : +Principaux champs de la structure `PcdItemGenericEnc` : * **`version`** : Version de l'`Item`. * **`item_type`** : Type de l'`Item`. * **`name`** : Nom de l'`Item`. -* **`request_pcd_item_enc_attribute_public_list`** : Liste d'objets `RequestPcdItemEncAttributePublic` des attributs publics de l'`Item` chiffré. -* **`request_pcd_item_enc_attribute_role_confidential_list`** : Liste d'objets `RequestPcdItemEncAttributeRoleConfidential` des attributs confidentiels de l'`Item` chiffré. -* **`request_pcd_item_enc_attribute_private_list`** : Liste d'objets `RequestPcdItemEncAttributePrivate` des attributs privés de l'`Item` chiffré. +* **`request_pcd_item_enc_attribute_public_list`** : Liste d'objets `PcdItemEncAttributePublic` des attributs publics de l'`Item` chiffré. +* **`request_pcd_item_enc_attribute_role_confidential_list`** : Liste d'objets `PcdItemEncAttributeRoleConfidential` des attributs confidentiels de l'`Item` chiffré. +* **`request_pcd_item_enc_attribute_private_list`** : Liste d'objets `PcdItemEncAttributePrivate` des attributs privés de l'`Item` chiffré. -Principaux champs de la structure `RequestPcdItemEncAttributePublic` : +Principaux champs de la structure `PcdItemEncAttributePublic` : * **`attribute_name`** : Nom de l'attribut. * **`data_enc`** : Données chiffrées par la clé `ProcessKey` de l'`ItemProcess` concerné. * **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair. * **`data`** : [PRIVE] Non partagé dans les messages. Données en clair. -Principaux champs de la structure `RequestPcdItemEncAttributeRoleConfidential` : +Principaux champs de la structure `PcdItemEncAttributeRoleConfidential` : * **`attribute_name`** : Nom de l'attribut. * **`data_enc`** : Données chiffrées par une clé symétrique générée à la volée pour chaque champ et pour chaque item d'une liste. * **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair. * **`data`** : [PRIVE] Non partagé dans les messages. Données en clair. -Principaux champs de la structure `RequestPcdItemEncAttributePrivate` : +Principaux champs de la structure `PcdItemEncAttributePrivate` : * **`attribute_name`** : Nom de l'attribut. * **`data_enc`** : Données chiffrées par la clé privée `KeyRecover`. * **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair. * **`data`** : [PRIVE] Non partagé dans les messages. Données en clair. -### 7.1. Schéma des flux +### 7.1. Schéma des flux -![RequestPcd](diagrams/PCD.png "RequestPcd") +![Pcd](diagrams/PCD.png "Pcd") -### 7.2. Création et envoi +### 7.2. Création et envoi -La création d'un `RequestPcd` suit plusieurs étapes : +La création d'un `Pcd` suit plusieurs étapes : 1. 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. Ajouts et modifications éventuelles des `Item`. -3. 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` avec la clé `ProcessKey` du `ItemProcess` concerné. +3. Chiffrement cf Encryption. +4. Envoi du message cf [Messages - Specs](Messages-Specs.md). -### 7.3. Réception +### 7.3. Réception -La réception d'un `RequestPcd` suit plusieurs étapes : +La réception d'un `Pcd` suit plusieurs étapes : -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 `ItemProcess` concerné. -4. Déchiffrage des attributs confidentiels des `Item` des `RequestPcd` avec les clés de déchiffrement fournies par 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`. +1. Recherche des `Prd` en relation via `Pcd_reference_hash` et `Pcd_origin_hash` de ces `Prd`, et attente si nécessaire. +2. Déchiffrement cf Encryption. -## 8. Fonction des`RequestPrd` +## 8. Fonction des`Prd` -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 solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. +Les Portable Request Documents (Prd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `Pcd` via l'attribut `Pcd_keys_role_confidential_list_confidential`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. -Les clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `RequestPcd` sont elles-mêmes chiffrées dans les `RequestPrd` au moyen du chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `ItemProcess`). +Les clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `Pcd` sont elles-mêmes chiffrées dans les `Prd` au moyen du chiffrement du `Prd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées aux `members` concernés par les `Item` des `Pcd` (rôles dans les `ItemProcess`). -Les `RequestPrd` se déclinent en plusieurs types, tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc., correspondant à différentes actions comme l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. +Les `Prd` se déclinent en plusieurs types, tels que `PrdList`, `PrdMessage`, `PrdUpdate`, etc., correspondant à différentes actions comme l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. -Principaux champs des `RequestPrd` : +Principaux champs des `Prd` : * **`request`** : cf la descripton de la structure `Request`. * **`sig_value`** : Valeur de la signature (parmi les valeurs valant pour `OK`, `KO` ou `none` telles que définies dans l'`ItemProcess`). -* **`request_pcd_reference_keys_role_confidential_list_enc_by_shared_secret`** : Clés de déchiffrement des attributs confidentiels des `Item` des `RequestPcd` chiffrées par la clé `KeyConfidential` d'une `transaction SP`. -* **`request_pcd_origin_hash_keys_role_confidential_list_enc_by_shared_secret`** : Clés de déchiffrement des attributs confidentiels des `Item` des `RequestPcd` du `RequestPCD` de référence, chiffrées par la clé `KeyConfidential` d'une `transaction SP`. +* **`request_pcd_reference_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` chiffrées par la clé `KeyConfidential` d'une `transaction SP`. +* **`request_pcd_origin_hash_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` du `PCD` de référence, chiffrées par la clé `KeyConfidential` d'une `transaction SP`. * **`message_public`** : Message public, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. * **`message_confidential`** : Message confidentiel, chiffré par la clé `ProcessKey` du `ItemProcess` concerné. * **`message_private`** : Message privé, chiffré par la clé privée `KeyRecover`. @@ -265,61 +248,59 @@ Principaux champs des `RequestPrd` : * **`timestamp_declared`** : Horodatage déclaré. * **`role_name_from`** : Nom du rôle de l'émetteur. * **`role_name_to`** : Nom du rôle du destinataire. -* **`payment_request_pcd_hash_list_enc_by_shared_secret`** : Liste des `RequestPcd` d'`Item` de nom `paiement` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`cap_request_pcd_hash_list_enc_by_shared_secret`** : Liste des `RequestPcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP` servant à la validation des paiements temporaires en attente du passage d'un cap. -* **`deposit_request_pcd_hash_list_enc_by_shared_secret`** : Liste des `RequestPcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`commitment_request_pcd_hash_list_enc_by_shared_secret`** : Liste des `RequestPcd` d'`Item` de nom `commitment` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`ask_payment_method_enc_by_shared_secret`** : Demande de méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`ask_deposit_method_enc_by_shared_secret`** : Demande de méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`ask_commitment_method_enc_by_shared_secret`** : Demande de méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -* **`payment_method_enc_by_shared_secret`** : Méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. -* **`deposit_method_enc_by_shared_secret`** : Méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. -* **`commitment_method_enc_by_shared_secret`** : Méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. -* **`certif_key_enc_by_shared_secret`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`Payments_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `paiement` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`cap_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP` servant à la validation des paiements temporaires en attente du passage d'un cap. +* **`deposit_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `deposit` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`commitment_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `commitment` chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`ask_Payments_method_confidential`** : Demande de méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`ask_deposit_method_confidential`** : Demande de méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`ask_commitment_method_confidential`** : Demande de méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`. +* **`Payments_method_confidential`** : Méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. +* **`deposit_method_confidential`** : Méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. +* **`commitment_method_confidential`** : Méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande. +* **`certif_key_confidential`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`device_footprint_enc_by_sp_shared_secret`** : Empreinte du dispositif de l'émetteur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -### 8.1. Schéma des flux +### 8.1. Schéma des flux -Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. +Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. -![RequestPrd](diagrams/PRD.png "RequestPrd") +![Prd](diagrams/PRD.png "Prd") -### 8.3. Création et envoi +### 8.2. Création d'un `Prd` -La création d'un `RequestPrd` suit plusieurs étapes : +1. Complétion des attributs +2. Création d'une `adresse SP` cf [Silent Payments - Specs](Silent-Payments-Specs.md) +3. Chiffrement cf Encryption. +4. Envoi du message cf [Messages - Specs](Messages-Specs.md). -1. Récupération des clés de chiffrement confidentiel des attributs des items d'un `RequestPcd`. -2. Création d'une `adresse SP` pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans un output de la transaction -3. Chiffrement des clés confidentielles avec la `KeyConfidential`. -4. Créer `RequestPrdMessage` pour la publication de la `transaction SP` +### 8.3. Réception -Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md). +La réception d'un `Prd` suit plusieurs étapes : -### 8.4. Réception +1. Parcours des `ItemProcess` pour trouver le `ItemProcess` correspondant au `process_hash` du `Prd` +2. Tentative de déchiffrement du `Prd` avec la clé `ProcessKey` du `ItemProcess` correspondant. +3. Recherche des `Pcd` en relation via `Pcd_reference_hash` et `Pcd_origin_hash`, attente si nécessaire et traitement de ceux-ci. +4. Vérification de la conformité des `Pcd` en relation. +5. Recherche des `Prd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, attente si nécessaire et traitement de ceux-ci. +6. Vérification de la conformité des `Prd` en relation. +7. Recherche de l'`Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci. +8. Déchiffrement voir Encryption. +9. Validation des conditions définies dans le `ItemProcess` pour cet `Item`, avec le `Role` correspondant dans le `ItemProcess`, et dans ces rôles, les conditions pour ce type de `Prd` (dans l'attribut `request_prd_type`) +10. Vérification du role de l'utilisateur courant dans le `ItemProcess` et dans le `Item` concerné. +11. Traitements spécifiques au type de `Prd`. -La réception d'un `RequestPrd` suit plusieurs étapes : +## 9. PrdList - Demande de Listes -1. Recherche des `RequestPcd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash`, attente si nécessaire et traitement de ceux-ci. -2. Vérification de la conformité des `RequestPcd` en relation. -3. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, attente si nécessaire et traitement de ceux-ci. -4. Vérification de la conformité des `RequestPrd` en relation. -5. Recherche de l'`Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci. -6. Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` -7. Déchiffrage les champs confididentiels depuis la `KeyConfidential` -8. Validation des conditions définies dans le `ItemProcess` pour cet `Item`, avec le `Role` correspondant dans le `ItemProcess`, et dans ces rôles, les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) -9. Traitements spécifiques au type de `RequestPrd`. - -## 9. RequestPrdList - Demande de Listes - -Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `RequestPcd` liste des `Item` d'un même type, tels que les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc. +Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayments`, etc. Workflow: ![PRDListFlows](diagrams/PRDListFlows.png "PRDListFlows") -Principaux champs des `RequestPrdList` : +Principaux champs des `PrdList` : -* **`request_prd`** : cf la descripton de la structure `RequestPrd`. +* **`request_prd`** : cf la descripton de la structure `Prd`. * **`pagination_start`** : Première "page" de résultats. * **`pagination_stop`** : Dernière "page" de résultats. * **`sub_pagination_start`** : Première "page" de résultats dans les items qui contiennent une liste. @@ -337,7 +318,7 @@ L'`ItemMember` temporaire contient les métadonnées de type `Metadata` suivante * **`sp_address_revoke_public`** : Adresse publique de révocation de l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. * **`third_sp_address_list_public`** : Liste des adresses publiques de devices tiers, chiffré par la `ProcessKey` de l'`ItemProcess`. * **`data_size_max`** : Taille maximale des données acceptée par l'utilisateur (par flux), chiffré par la `ProcessKey` de l'`ItemProcess`. -* **`payment_method_list_public`** : Liste des méthodes de paiement acceptées par l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. +* **`Payments_method_list_public`** : Liste des méthodes de paiement acceptées par l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. * **`succession_process_hash`** : Hash du processus de succession de l'utilisateur (transmission de l'identité numérique et donc de tous les flux associés), chiffré par la `ProcessKey` de l'`ItemProcess`. * **`device_footprint`** : Empreinte du dispositif de l'utilisateur, chiffré par la `ProcessKey` de l'`ItemProcess`. @@ -352,135 +333,89 @@ L'`ItemMember` temporaire contient les métadonnées de type `Metadata` suivante * **`priv_key_mainnet_scan`** : Clé de scan de l'utilisateur, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`. * **`priv_key_signet_scan`** : Clé de scan du signet de `recover`de l'utilisateur, chiffrée `KeyRecover`. -### 9.1. Schéma des flux +### 9.1. Schéma des flux -Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. +Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. -![RequestPrdList](diagrams/PRDList.png "RequestPrdList") +![PrdList](diagrams/PRDList.png "PrdList") -### 9.2. Création : Datas spécifiques +## 10. PrdMessage - Envoi de Messages -1. Traitement des `RequestPrd`, avec le `type_request`. -2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouvel `ItemMember` (création d'une identité numérique), uniquement destiné aux gestionnaires des membres. -3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement destiné aux gestionnaires des membres. - -### 9.3. Réception : Datas spécifiques - -La réception d'un `RequestPrdList` suit plusieurs étapes : - -1. Traitement des `RequestPrd`. -2. Recherche en cache de la dernière version de la liste du type d'`Item` concerné (voir `RequestPcd` pour la création et l'envoi vers l'émetteur du `RequestPrdList`). -3. En cas de `item_member_enc_by_sp_shared_secret`, pour la création d'un nouvel `ItemMember` (création d'une identité numérique), cette étape est réservée uniquement aux gestionnaires des membres. L'`ItemMember` est ajouté au cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé. -4. En cas de `pre_id_sp_enc_by_shared_secret`, pour la connexion avec une identité numérique existante, cette étape est destinée uniquement aux gestionnaires des membres pour le renvoi du shard correspondant dans le `RequestPrdResponse`. - -## 10. RequestPrdMessage - Envoi de Messages - -Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats. +Le `PrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats. Il permet la communication : * Directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties. * Des `transaction SP` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain. -Les `RequestPrdMessage` peuvent répondre aux autres `RequestPrdMessage`, sauf en cas d'envoi de `raw_transaction_list` (dans le cas d'utilisation pour transférer la `transaction SP` depuis un autre `RequestPrd`). +Les `PrdMessage` peuvent répondre aux autres `PrdMessage`, sauf en cas d'envoi de `raw_transaction_list` (dans le cas d'utilisation pour transférer la `transaction SP` depuis un autre `Prd`). Workflow : ![PRDMessageFlows](diagrams/PRDMessageFlows.png "PRDMessageFlows") -Principaux champs des `RequestPrdMessage` : +Principaux champs des `PrdMessage` : -* **`request_prd`** : cf la descripton de la structure `RequestPrd`. +* **`request_prd`** : cf la descripton de la structure `Prd`. * **`raw_transaction_list`** : Liste des `transaction SP` au format `raw` pour la publication de la transaction dans la side chain. -### 10.1. Schéma des flux +### 10.1. Schéma des flux -Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `RequestPrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `RequestPrdMessage` contient une `raw_transaction_list` non vide. +Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `PrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `PrdMessage` contient une `raw_transaction_list` non vide. -![RequestPrdMessage](diagrams/PRDMessage.png "RequestPrdMessage") +![PrdMessage](diagrams/PRDMessage.png "PrdMessage") -### 10.2. Création : Datas spécifiques +## 11. PrdUpdate - Mises à Jour de Pcd -1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué au `RequestPrdMessage`. -2. Cas de la transmission d'une `Transaction SP` depuis un autre `RequestPrd` au format `raw` dans l'attribut `raw_transaction_list`, pour la publication de la transaction dans la side chain. +`PrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `Pcd`. -### 10.3. Réception : Datas spécifiques - -1. Traitements des `RequestPrd` - -## 11. RequestPrdUpdate - Mises à Jour de RequestPcd - -`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `RequestPcd`. - -Basé sur le `RequestPrd`, avec des ajouts pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour : +Basé sur le `Prd`, avec des ajouts pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour : Essentiel pour les utilisateurs ou les processus nécessitant de mettre à jour des informations contractuelles ou des attributs d'items, assurant la pertinence et l'actualité des données dans le système. Par exemple, la mise à jour de la liste des membres permet d'ajouter de nouveaux utilisateurs à un `ItemProcess`, et la mise à jour de la liste des `ItemProcess` permet de leur affecter un nouveau `Role`. -Les `RequestPrdUpdate` signalent au réseau, via l'attribut `RequestPcd_new_version_hash`, les nouvelles versions des `RequestPcd`. +Les `PrdUpdate` signalent au réseau, via l'attribut `Pcd_new_version_hash`, les nouvelles versions des `Pcd`. Workflow: ![PRDUpdateFlows](diagrams/PRDUpdateFlows.png "PRDUpdateFlows") -Principaux champs des `RequestPrdUpdate` : +Principaux champs des `PrdUpdate` : -* **`request_prd`** : cf la descripton de la structure `RequestPrd`. +* **`request_prd`** : cf la descripton de la structure `Prd`. -### 11.1. Schéma des flux +### 11.1. Schéma des flux -Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma. +Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma. -![RequestPrdUpdate](diagrams/PRDUpdate.png "RequestPrdUpdate") +![PrdUpdate](diagrams/PRDUpdate.png "PrdUpdate") -### 11.2. Création : Datas spécifiques +## 12. PrdConfirm - Confirmation de Réception -1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdUpdate`. -2. Pas de données spécifiques. +Le `PrdConfirm` est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau. -### 11.3. Réception : Datas spécifiques +Les `PrdList`, `PrdUpdate`, `PrdMessage`, `PrdResponse` et `PrdKeyHello` reçoivent systématiquement un `PrdConfirm` suite à leur réception par le destinataire. -La réception d'un `RequestPrdUpdate` suit plusieurs étapes : - -1. Traitement des `RequestPrd`. -2. Comparaison de la dernière version du `RequestPcd` en cache avec la nouvelle version du `RequestPcd` associée, via `RequestPcd_new_version_hash`, et attente si nécessaire. - -## 12. RequestPrdConfirm - Confirmation de Réception - -Le `RequestPrdConfirm` est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau. - -Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdResponse` et `RequestPrdKeyHello` reçoivent systématiquement un `RequestPrdConfirm` suite à leur réception par le destinataire. - -`code_confirm_enc_by_shared_secret` : Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas, un output spécifique chiffré par la clé `KeyConfidential` précise ce code, lequel doit être confirmé dans le `RequestPrdConfirm`. +`code_confirm_confidential` : Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas, un output spécifique chiffré par la clé `KeyConfidential` précise ce code, lequel doit être confirmé dans le `PrdConfirm`. Worflow: Voir les diagrammes `PRDUpdateFlows`, `PRDUpdateFlows` et `PRDMessageFlows`. -Principaux champs des `RequestPrdConfirm` : +Principaux champs des `PrdConfirm` : -* **`request_prd`** : cf la descripton de la structure `RequestPrd`. -* **`code_confirm_enc_by_shared_secret`** : Code de confirmation chiffré par la clé `KeyConfidential` d'une `transaction SP` dans le cas d'un 2FA. +* **`request_prd`** : cf la descripton de la structure `Prd`. +* **`code_confirm_confidential`** : Code de confirmation chiffré par la clé `KeyConfidential` d'une `transaction SP` dans le cas d'un 2FA. -### 12.1. Schéma des flux +### 12.1. Schéma des flux -![RequestPrdConfirm](diagrams/PRDConfirm.png "RequestPrdConfirm") +![PrdConfirm](diagrams/PRDConfirm.png "PrdConfirm") -### 12.2. Création : Datas spécifiques +## 13. PrdResponse - Répondre à une Demande -1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdConfirm`. -2. Communication éventuelle d'un `code_confirm_enc_by_shared_secret` à confirmer dans le `RequestPrdConfirm`. +Le `PrdResponse` permet de répondre spécifiquement à des `Prd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. -### 12.3. Réception : Datas spécifiques - -1. Traitement des `RequestPrd`, sans traitement supplémentaire. -2. Vérification du `code_confirm_enc_by_shared_secret` dans le `RequestPrdConfirm` reçu. - -## 13. RequestPrdResponse - Répondre à une Demande - -Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. - -Les `RequestPrdResponse` sont utilisés pour répondre aux `RequestPrdList`, `RequestPrdUpdate`, facilitant la fourniture de feedbacks, de confirmations, ou d'instructions supplémentaires en réponse aux demandes initiales. Ils supportent une communication bidirectionnelle sécurisée et vérifiable. +Les `PrdResponse` sont utilisés pour répondre aux `PrdList`, `PrdUpdate`, facilitant la fourniture de feedbacks, de confirmations, ou d'instructions supplémentaires en réponse aux demandes initiales. Ils supportent une communication bidirectionnelle sécurisée et vérifiable. C'est également le moyen par lequel demander des moyens de paiement, de dépôt, ou de preuve, puis de partager le payload de ces actions. @@ -488,41 +423,18 @@ Workflow: Voir les diagrammes `PRDUpdateFlows` et `PRDUpdateFlows`. -Principaux champs des `RequestPrdResponse` : +Principaux champs des `PrdResponse` : -* **`request_prd`** : cf la descripton de la structure `RequestPrd`. +* **`request_prd`** : cf la descripton de la structure `Prd`. * **`shared_secret_key_enc_by_sp_shared_secret`** : Clé de chiffrement partagée chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`shard_enc_by_sp_shared_secret`** : Shard chiffré par la clé `KeyConfidential` d'une `transaction SP`. -### 13.1. Schéma des flux +### 13.1. Schéma des flux -Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma. +Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma. -![RequestPrdResponse](diagrams/PRDResponse.png "RequestPrdResponse") +![PrdResponse](diagrams/PRDResponse.png "PrdResponse") -### 13.2. Création : Datas spécifiques +## 14. Exemples de Code -1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué à `RequestPrdResponse`. -2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si celle-ci n'est pas automatique). -3. En cas de réponse à un `RequestPrdKeyList`, fourniture de `pre_id_enc_by_sp_shared_secret` avec les shards correspondant à la `pre-id` demandée. -4. (Optionnel) Partage d'une clé de chiffrement ad hoc via `shared_secret_key`. - -### 13.3. Réception : Datas spécifiques - -1. Traitement des `RequestPrd`. -2. Vérification des conditions de validation des `RequestPcd` associés. -3. En cas de réponse reçue pour un `RequestPrdList` : récupération des shards correspondant à la `pre-id` demandée et génération de la clé `KeyRecover`. - -## 14. Exemples de Code - -## 15. Todo - -[ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’: - [x] Qu’y a-t-il dans le ‘request-type’? - [x] A quoi sert l’attribut X du ‘request-type’? - [x] Description un par un des contextes où le ‘request-type’ est utilisé. - [x] Description pas à pas de l’envoi du ‘request-type’. - [ ] Que se passe-t-il dans le système lorsque le ‘request-type est envoyé? -[x] Description pas à pas de la réception du ‘request-type’. -[x] Que se passe-t-il dans le système lorsque le ‘request-type est reçu? -[x] Exemple d’utilisation. +## 15. Todo diff --git a/doc/Process-roles-Specs.md b/doc/Process-roles-Specs.md index eccd9a2..c87182a 100644 --- a/doc/Process-roles-Specs.md +++ b/doc/Process-roles-Specs.md @@ -18,17 +18,17 @@ * 5.5.2. [Cas d'utilisation](#Casdutilisation-1) * 6. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions) * 6.1. [RoleCommitment](#RoleCommitment) - * 6.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment) + * 6.2. [RoleDeposit et RolePayments](#RoleDepositetRolePayments) * 7. [Sécurisation des Communications](#ScurisationdesCommunications) * 7.1. [Composition et Utilisation](#CompositionetUtilisation) * 8. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus) -* 9. [Condition RequestPrdAddressSet](#ConditionRequestPrdAddressSet) +* 9. [Condition PrdAddressSet](#ConditionPrdAddressSet) * 9.1. [ Participants](#Participants) * 9.2. [ Valeurs des signatures (`sig_value`)](#Valeursdessignaturessig_value) * 9.3. [Minimums et maximums de valeurs "OK", "KO" et "NONE"](#MinimumsetmaximumsdevaleursOKKOetNONE) * 9.4. [Minimums et maximums de scores](#Minimumsetmaximumsdescores) * 10. [ConditionPublish : conditions de publication](#ConditionPublish:conditionsdepublication) -* 11. [ConditionPayment : conditions de paiement](#ConditionPayment:conditionsdepaiement) +* 11. [ConditionPayments : conditions de paiement](#ConditionPayments:conditionsdepaiement) * 12. [ConditionCommitment : conditions d'engagement](#ConditionCommitment:conditionsdengagement) * 13. [ConditionDeposit : conditions de dépôt de garantie](#ConditionDeposit:conditionsdedptdegarantie) * 14. [ConditionOrchestration : conditions d'orchestration des processus](#ConditionOrchestration:conditionsdorchestrationdesprocessus) @@ -40,7 +40,7 @@ ## 1. Objectif -Cette section vise à présenter en détail les Documents de Contrat Portable ( RequestPcd) et les Documents de Demande Portable ( RequestPrd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les `RequestPcd` et `RequestPrd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé. +Cette section vise à présenter en détail les Documents de Contrat Portable ( Pcd) et les Documents de Demande Portable ( Prd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les `Pcd` et `Prd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé. ## 2. Portée @@ -57,7 +57,7 @@ Les rôles déterminent les permissions et les responsabilités des participants * **RoleProcess**: Conditions des listes des processus et des versions des listes. * **RoleArtefact**: Définit les permissions et les interactions pour les artefacts au sein du réseau et des version de ces listes, par types d'artefacts. -Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayment`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent. +Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayments`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent. ## 5. Précisions sur les rôles @@ -124,14 +124,14 @@ Cette structure permet une personnalisation détaillée des rôles au sein du sy ## 6. Gestion des Engagements et Transactions -Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayment, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties. +Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayments, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties. ### 6.1. RoleCommitment * **item_name**: Identifie l'engagement spécifique ou l'obligation prise par une partie. * **role**: Définit les permissions, les conditions et les critères associés à cet engagement, assurant une exécution et une validation conformes aux attentes. -### 6.2. RoleDeposit et RolePayment +### 6.2. RoleDeposit et RolePayments Ces structures gèrent respectivement les dépôts de garantie et les paiements, en spécifiant les conditions sous lesquelles les fonds sont déposés, retenus ou transférés, contribuant ainsi à la confiance et à la fluidité des transactions au sein du réseau. @@ -148,9 +148,9 @@ La structure MetaData et ses sous-structures comme MetadataContractPublic, Metad L'ItemProcess et ItemProcessPublicAttributeGroup offrent un cadre pour l'intégration et l'orchestration des processus dans le système 4NK, permettant la définition, la gestion et l'exécution de workflows complexes de manière sécurisée et efficace. -## 9. Condition RequestPrdAddressSet +## 9. Condition PrdAddressSet -A l'issue d'un délai `validation_timeout` par `Role` et par * `request_prd_type`, les `RequestPrdRequest` sont collectés afin de vérifier les conditions de validation par roles sont définies en fonction des critères suivants : +A l'issue d'un délai `validation_timeout` par `Role` et par * `request_prd_type`, les `PrdRequest` sont collectés afin de vérifier les conditions de validation par roles sont définies en fonction des critères suivants : Les membres concernés sont identifiés par leurs `adresse SP`. @@ -192,13 +192,13 @@ Les membres concernés sont identifiés par leurs `adresse SP`. ## 10. ConditionPublish : conditions de publication -* (option)`request_pcd_data_size_max_unit`: Taille maximale des données de chaque `RequestPcd` en Mo -* (option)`request_pcd_data_size_max_total`: Taille maximale des données des `RequestPcd` en Mo -* (option)`request_pcd_number_min`: Nombre minimum de publication de `RequestPcd` -* (option)`request_pcd_number_max`: Nombre maximum de publication de `RequestPcd` -* (option)`request_pcd_amount_max_total`: Montant maximum des montants dans les items des `RequestPcd` -* (option)`request_prd_waiting_timeout`: Délai d'attente pour la réception des `RequestPrd` -* (option)`request_pcd_waiting_timeout`: Délai d'attente pour la réception des `RequestPcd` +* (option)`request_pcd_data_size_max_unit`: Taille maximale des données de chaque `Pcd` en Mo +* (option)`request_pcd_data_size_max_total`: Taille maximale des données des `Pcd` en Mo +* (option)`request_pcd_number_min`: Nombre minimum de publication de `Pcd` +* (option)`request_pcd_number_max`: Nombre maximum de publication de `Pcd` +* (option)`request_pcd_amount_max_total`: Montant maximum des montants dans les items des `Pcd` +* (option)`request_prd_waiting_timeout`: Délai d'attente pour la réception des `Prd` +* (option)`request_pcd_waiting_timeout`: Délai d'attente pour la réception des `Pcd` ## 14. ConditionOrchestration : conditions d'orchestration des processus @@ -206,9 +206,9 @@ Les membres concernés sont identifiés par leurs `adresse SP`. * (option) `role_ok`: `Role` à vérifier en cas de résulats final "OK" * (option) `role_ko`: `Role` à vérifier en cas de résulats final "KO" -## 11. ConditionPayment : conditions de paiement +## 11. ConditionPayments : conditions de paiement -* (option) `payment_method_list`: Liste des modes de paiement acceptés +* (option) `Payments_method_list`: Liste des modes de paiement acceptés * (option) `role_transaction` : voir `TransactionMode` ## 12. ConditionCommitment : conditions d'engagement @@ -240,5 +240,5 @@ Les membres concernés sont identifiés par leurs `adresse SP`. ## 17. Todo -* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. +* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/Silent-Payment-Specs.md b/doc/Silent-Payments-Specs.md similarity index 50% rename from doc/Silent-Payment-Specs.md rename to doc/Silent-Payments-Specs.md index cf3badf..dbb9091 100644 --- a/doc/Silent-Payment-Specs.md +++ b/doc/Silent-Payments-Specs.md @@ -5,8 +5,8 @@ * 4. [Fonction](#Fonction) * 5. [Structure des outputs](#Structuredesoutputs) * 6. [Envoi de la transaction SP](#EnvoidelatransactionSP) - * 6.1. [Dans un `RequestPrdMessage`](#DansunRequestPrdMessage) - * 6.2. [Dans un `Message` du `RequestPrdMessage`](#DansunMessageduRequestPrdMessage) + * 6.1. [Dans un `PrdMessage`](#DansunPrdMessage) + * 6.2. [Dans un `Message` du `PrdMessage`](#DansunMessageduPrdMessage)