diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index 463693f..4b1c210 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -18,7 +18,7 @@ * 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 ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd) +* 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) @@ -64,7 +64,7 @@ Voir [_Doc_references.md](_Doc_references.md). * `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`, `RequestPrdResponse` et `RequestPrdMessage`). + * `RequestPrdResponse`: Réponse aux autres types de `RequestPrd` (à l'exception de `RequestPrdConfirm`, et `RequestPrdMessage`). * **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`. @@ -90,7 +90,7 @@ Les `RequestPrd` sont des demandes d'actions ou des réponses à ces demandes, i * 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`, `RequestPrdMessage` et `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`. +* `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`. 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 : @@ -128,7 +128,7 @@ Ce qui est résumé pour l'envoi : Les traitements pour la réception des `RequestPrd` 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 confirmaiton, 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. @@ -138,10 +138,10 @@ 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 ) | |----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------| | `RequestPrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | -| `RequestPrdUpdate` | Info | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | 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` | Info | Yes | No | No | No | No | -| `RequestPrdConfirm` | Info | No | No | No | No | No | +| `RequestPrdResponse` | RequestPrd | Yes | No | No | No | No | +| `RequestPrdConfirm` | RequestPrd | No | No | No | No | No | ## 6. Encryption @@ -171,34 +171,6 @@ Principaux champs des `Request` contenus dans les `RequestPcd` et `RequestPrd` c * **`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. -### 6.1. Création et envoi - -Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de messages (`JSON`) via les `websockets` des relais. - -Ces `Message` contiennent soit des `RequestPrd`, soit des `RequestPcd`, encapsulés dans l'attribut `request_enc`, lequel est chiffré à l'aide de la clé `ProcessKey` de l'`ItemProcess` concerné. - -Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md). - -**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md). - -### 6.2. Réception - -Les `RequestPcd` et `RequestPrd` sont reçus sous forme de messages (`JSON`) via les `websockets` des relais. - -Ces messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, lequel est chiffré avec la clé `ProcessKey` de l'`ItemProcess` concerné. - -À la réception des `Message`, ceux-ci sont déchiffrés puis conservés ou non, selon le `process_hash` du `RequestPcd` ou du `RequestPrd` (dans l'attribut `request`). Si le `process_hash` n'est pas reconnu, le message est ignoré. - -Les types `RequestPrd` et `RequestPcd` sont distingués par l'attribut `request_type` dans le `Message`. - -En cas de `RequestPcd` ou `RequestPrd` liés via `RequestPcd_reference_hash`, `request_prd_reference_hash`, `RequestPcd_origin_hash`, `request_prd_origin_hash` ou `item_reference_hash` (dans des `RequestPcd`), il est nécessaire d'avoir reçu ou d'attendre ces documents pour traiter le message. - -Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md). - - **Réception du message**: voir [Message-SP-Specs.md](Message-SP-Specs.md). - -Pour les `RequestPcd` et `RequestPrd`, il est nécessaire de vérifier si le hash du document est déjà enregistré ; si tel est le cas, le message est ignoré. - ## 7. Fonction des RequestPcd 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)). @@ -208,7 +180,7 @@ Les `Item` échangés via les `RequestPcd` sont soumis à une vérification par Principaux champs des `RequestPcd` : * **`request`** : cf la descripton de la structure `Request`. -* **`item_enc_list`** : Les `Item` chiffrés 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 `RequestPcdItemGenericEnc` 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` : @@ -260,18 +232,15 @@ La création d'un `RequestPcd` suit plusieurs étapes : 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é. -5. Traitements communs aux `RequestPcd` et `RequestPrd`. ### 7.3. Réception La réception d'un `RequestPcd` suit plusieurs étapes : -1. Traitements communs aux `RequestPcd` et `RequestPrd`. 2. Recherche des `RequestPrd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` de ces `RequestPrd`, et attente si nécessaire. 3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `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`. -6. Mise à jour du cache pour le traitement des `RequestPrd`. ## 8. Fonction des`RequestPrd` @@ -281,7 +250,7 @@ Les clés permettant le chiffrement des attributs confidentiels par rôles des ` 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. -Principaux champs des `RequestPcd` : +Principaux champs des `RequestPrd` : * **`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`). @@ -315,65 +284,32 @@ Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. ![RequestPrd](diagrams/PRD.png "RequestPrd") -### 8.2. Fonctionnalités optionnelles - -L'attribut `sig_value` permet d'attribuer une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess`, avec des valeurs pouvant être `OK`, `KO` ou `none` pour les validations des `RequestPrd`. - -Lorsque la réponse fait référence à un `RequestPcd`, cela est précisé dans `RequestPcd_reference_hash`; de même pour les `RequestPrd` avec `request_prd_reference_hash`. - -Lorsque la réponse fait suite directement à un `RequestPcd`, cela est indiqué dans `RequestPcd_origin_hash`; idem pour les `RequestPrd` avec `request_prd_origin_hash`. - -Les `RequestPrdResponse` signalent de façon confidentielle : - -* soit des conditions ad hoc déjà remplies via les attributs `payment_method_enc_by_shared_secret`, `deposit_method_enc_by_shared_secret`, `commitment_method_enc_by_shared_secret`, `commitment_request_pcd_hash_list` pour les paiements et les preuves ad hoc éventuellement associées aux `RequestPcd` de la nouvelle version. -* soit des appels à recevoir les moyens de satisfaire ces conditions via les attributs `ask_payment_method_enc_by_shared_secret`, `ask_deposit_method_enc_by_shared_secret`, `ask_commitment_method_enc_by_shared_secret`. - -Les `Item` associés sont référencés dans des `RequestPcd` identifiés par `payment_request_pcd_hash_list_enc_by_shared_secret`, `cap_request_pcd_hash_list_enc_by_shared_secret` (dans le cas de paiements temporaires en attente du passage d'un cap), `deposit_request_pcd_hash_list_enc_by_shared_secret` et `commitment_request_pcd_hash_list_enc_by_shared_secret`. - -Des champs de messages peuvent accompagner les `RequestPrd` via `message_public`, `message_confidential`, `message_private`. - -Il est également possible de partager des clés de chiffrement ad hoc via `certif_key_enc_by_shared_secret`. - -En plus des horodatages automatiques, il est possible de déclarer un timestamp dans `timestamp_declared`, qui ne sera pas pris en compte dans le traitement mais sera ainsi tracé dans les éléments de preuve. - -Les adresses et les rôles sont précisés en cas d'utilisateurs ayant plusieurs rôles dans les `ItemProcess` et pour préciser les adresses de réponse en cas d'utilisation sur plusieurs dispositifs. - -Tous les échanges sont complétés par l'empreinte du dispositif de l'émetteur, envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`. - ### 8.3. Création et envoi La création d'un `RequestPrd` suit plusieurs étapes : 1. Récupération des clés de chiffrement confidentiel des attributs des items d'un `RequestPcd`. -2. Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné. -3. Création d'une `adresse SP` pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain. -4. Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, et l'adresse du faucet. -5. Sélection de 4 relais pour le message selon l'historique des pings et des réponses obtenues. -6. Sélection de 4 noeuds de signet pour l'envoi de la `transaction SP`. -7. Chiffrement des données confidentielles du `RequestPrd` avec la `KeyConfidential` de la `transaction SP`. -8. Envoi du message aux relais. -9. Envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la `transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`. -10. Mise à jour du cache avec les nouveaux `RequestPrd` envoyés (sans mise en cache du `RequestPrdMessage`). +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` Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md). ### 8.4. Réception -La réception d'un `RequestPcd` suit plusieurs étapes : +La réception d'un `RequestPrd` suit plusieurs étapes : -1. Traitements communs aux `RequestPcd` et `RequestPrd`. -2. Recherche des `RequestPcd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash`, attente si nécessaire et traitement de ceux-ci. -3. Vérification de la conformité des `RequestPcd` en relation. -4. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, attente si nécessaire et traitement de ceux-ci. -5. Vérification de la conformité des `RequestPrd` en relation. -6. Recherche de l'`Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci. -7. Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` de la `transaction SP` correspondante via le hash du `RequestPrd` dans l'output `2` de la transaction. -8. Mise à jour du cache pour le traitement des `RequestPrd`. -9. Consultation du `RequestPrdConfirm` pour création et envoi. -10. 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`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md). -11. Traitements spécifiques au type de `RequestPrd`. +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 ( RequestPcd) +## 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. diff --git a/doc/diagrams/.$PRDListFlows.drawio.bkp b/doc/diagrams/.$PRDListFlows.drawio.bkp index 70ae0dd..477696c 100644 --- a/doc/diagrams/.$PRDListFlows.drawio.bkp +++ b/doc/diagrams/.$PRDListFlows.drawio.bkp @@ -1,9 +1,48 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -239,45 +278,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/PRDListFlows.drawio b/doc/diagrams/PRDListFlows.drawio index 477696c..1fd3bd6 100644 --- a/doc/diagrams/PRDListFlows.drawio +++ b/doc/diagrams/PRDListFlows.drawio @@ -1,46 +1,46 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -76,10 +76,10 @@ - + - + @@ -131,7 +131,7 @@ - + diff --git a/doc/diagrams/PRDListFlows.png b/doc/diagrams/PRDListFlows.png index b57d9da..d68154a 100644 Binary files a/doc/diagrams/PRDListFlows.png and b/doc/diagrams/PRDListFlows.png differ