477 lines
35 KiB
Markdown
477 lines
35 KiB
Markdown
# PRD PCD - Specifications
|
|
|
|
## 1. <a name='Autheursvalidationsdatesversionschangementandhistorique'></a>Autheurs, validations, dates, versions, changement and historique
|
|
|
|
Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc)
|
|
|
|
## 2. <a name='Tabledesmatires'></a>Table des matières
|
|
|
|
<!-- vscode-markdown-toc -->
|
|
* 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique)
|
|
* 2. [Table des matières](#Tabledesmatires)
|
|
* 3. [Objectif](#Objectif)
|
|
* 4. [Portée](#Porte)
|
|
* 5. [Documents de référence](#Documentsderfrence)
|
|
* 6. [Définitions](#Dfinitions)
|
|
* 7. [Principes d'une `Envelope` rie](#PrincipesduneEnveloperie)
|
|
* 8. [Encryption](#Encryption)
|
|
* 9. [Fonction des Pcd](#FonctiondesPcd)
|
|
* 9.1. [Schéma des flux](#Schmadesflux)
|
|
* 9.2. [Création et envoi](#Crationetenvoi)
|
|
* 9.3. [Réception](#Rception)
|
|
* 10. [Fonction des`Prd`](#FonctiondesPrd)
|
|
* 10.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 10.2. [Création d'un `Prd`](#CrationdunPrd)
|
|
* 10.3. [Réception](#Rception-1)
|
|
* 11. [PrdList - Demande de Listes](#PrdList-DemandedeListes)
|
|
* 11.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 12. [PrdMessage - Envoi d'une `Envelope`](#PrdMessage-EnvoiduneEnvelope)
|
|
* 12.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 13. [PrdUpdate - Mises à Jour de Pcd](#PrdUpdate-MisesJourdePcd)
|
|
* 13.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 14. [PrdConfirm - Confirmation de Réception](#PrdConfirm-ConfirmationdeRception)
|
|
* 14.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 15. [PrdResponse - Répondre à une Demande](#PrdResponse-RpondreuneDemande)
|
|
* 15.1. [Schéma des flux](#Schmadesflux-1)
|
|
* 16. [Exemples de Code](#ExemplesdeCode)
|
|
* 17. [Todo](#Todo)
|
|
|
|
<!-- vscode-markdown-toc-config
|
|
numbering=true
|
|
autoSave=true
|
|
/vscode-markdown-toc-config -->
|
|
<!-- /vscode-markdown-toc -->
|
|
|
|
## 3. <a name='Objectif'></a>Objectif
|
|
|
|
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 `User` 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.
|
|
|
|
## 4. <a name='Porte'></a>Portée
|
|
|
|
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.
|
|
|
|
## 5. <a name='Documentsderfrence'></a>Documents de référence
|
|
|
|
Voir [_Doc_references.md](_Doc_references.md).
|
|
|
|
## 6. <a name='Dfinitions'></a>Définitions
|
|
|
|
* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `Process` (`item_type`).
|
|
|
|
* **Portable Request Document (`Prd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `Pcd`. Les `PrdResponse` sont collectés pour vérifier le respect des conditions de `Process`. D'autres types de `Prd` incluent :
|
|
* `PrdList`: Demande de listes d'`Item`. En réponse, une `Pcd` est reçue avec les `PrdResponse` correspondants.
|
|
* `PrdMessage`: Envoi d'une `Envelope` 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`).
|
|
|
|
* **Envelope**: Enveloppe commune pour les `Prd` et `Pcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `Prd` et `Pcd` sont chiffrés par la `ProcessKey` de `Process` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`.
|
|
|
|
* **KeyConfidential**: Clé AES-GCM-256 issue du `Diffie-Hellman` de la transaction Silent Payments correspondant à un `Prd`.
|
|
|
|
* **ProcessKey**: La clé publique de chiffrement d'un `Process` (trouvée dans un `Process`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément).
|
|
|
|
* **KeyRecover**: La clé privée de dépense de `recover` du signet, utilisée comme référence pour le `User`.
|
|
|
|
* **pre-id**: Pré-identifiant des `User`, constitué du hash de la partie 1 de la `KeyRecover`.
|
|
|
|
## 7. <a name='PrincipesduneEnveloperie'></a>Principes d'une `Envelope` rie
|
|
|
|
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 `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 `Prd` sont des demandes d'actions ou des réponses à ces demandes, interagissant de la manière suivante :
|
|
|
|
* `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 d'une `Envelope` , pouvant initier un échange d'une `Envelope` rie 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 `Prd`, les demandes peuvent s'adresser à tous les Members de `Process`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon :
|
|
|
|
* `PrdList` : Envoyé aux gestionnaires du type d'`Item` concerné.
|
|
* `PrdMessage`, avec 2 cas de figure :
|
|
* Demande de relais d'une `transaction SP`, dans ce cas, destinée au destinataire du `Prd` associé.
|
|
* Envoi d'une `Envelope` au destinataire de l'`Envelope` .
|
|
* `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 Members et à l'émetteur du `PrdUpdate`.
|
|
|
|
Les traitements pour l'envoi des `Prd` varient selon leur type, principalement autour des aspects suivants :
|
|
|
|
* **`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'`User` courant, 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** : Members 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` + `PrdMessage` | `Pcd` to send | `request_type` send to | `Pcd` reply waiting | `PrdResponse` reply waiting | `PrdConfirm` reply waiting |
|
|
|----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------|
|
|
| `PrdList` | No | Yes | No | all the Members of the `item_name` `Role` into to `Process` | Yes | Yes | Yes |
|
|
| `PrdUpdate` | waiting `sig_value` | Yes | Yes | all the Members of all `Role` into to `Process` | No | Yes | Yes |
|
|
| `PrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a Member of the `Process` | No | No | if no `raw_transaction_list` |
|
|
| `PrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes |
|
|
| `PrdConfirm` | (option) Waiting `code_confirm_confidential` | Yes | No | See Received | No | No | No |
|
|
|
|
Les traitements pour la réception des `Prd` varient selon leur type, principalement autour des aspects suivants :
|
|
|
|
* **Notification user** : Nécessité de notifier l'`User` courant, 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 | `PrdConfirm` to send | `Pcd` to send | `PrdResponse` to send | `PrdResponse` reply waiting | `PrdConfirm` reply waiting (from `PrdResponse` send ) |
|
|
|----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------|
|
|
| `PrdList` | No | Yes | Yes | all the Members of the `item_name` `Role` into to `Process` | No | Yes |
|
|
| `PrdUpdate` | Prd | Yes | No | all the Members of all `Role` into to `Process` | Yes (other Members) | Yes |
|
|
| `PrdMessage` | Waiting `PrdMessage` reply | if no `raw_transaction_list` | No | No | No | No |
|
|
| `PrdResponse` | Prd | Yes | No | No | No | No |
|
|
| `PrdConfirm` | Prd | No | No | No | No | No |
|
|
|
|
## 8. <a name='Encryption'></a>Encryption
|
|
|
|
Schema :
|
|
|
|
|
|
|
|
Les `Metadata` des `Item` des `Pcd` et les attributs des `Pcd` et `Prd` sont chiffrés de la sorte :
|
|
|
|
* **Données publiques** : Utilisent un chiffrement symétrique basé sur la `ProcessKey` de `Process` (cf. [Specs-Definition](SpecsDefinition.md)). Ces données sont ainsi accessibles à tous pour le déchiffrement.
|
|
|
|
* **Données confidentielles destinées aux Members d'un `role` spécifique d'un `Process` dans les Pcd** : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un `Pcd`. Ces clés seront ensuite ajoutées aux `Prd` dans l'attribut `Pcd_keys_role_confidential_list_confidential`; lui même alors chiffré par la `KeyConfidential`.
|
|
|
|
* **Données confidentielles destinées aux Members d'un `role` spécifique d'un `Process` dans les Prd** : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les `Pcd` et transmises par le `Prd`, chiffrées par la `KeyConfidential` du Diffie-Hellman de la transaction Silent Payments associée à ce `Prd` (cf. [Specs-Definition](SpecsDefinition.md)) d'une transaction `SP`.
|
|
|
|
* **Données privées** : Chiffrées symétriquement en utilisant la clé de dépense de connexion (`recover`) du signet (voir Login - Specs).
|
|
|
|
Principaux champs des `Request` contenus dans les `Pcd` et `Prd` chiffrés :
|
|
|
|
* **`request_type`** : Type de requête : `Pcd`, `PrdList`, `PrdMessage`, `PrdUpdate`, `PrdConfirm`, `PrdResponse`.
|
|
* **`item_name`** : Noms des items : `peer`, `Member`, `process`, `Payments`, `deposit`, `commit`, et les `artefact` personnalisés.
|
|
* **`version`** : Version de la requête.
|
|
* **`process_hash`** : Hash de `Process` concerné.
|
|
* **`request_pcd_reference_hash`** : Hash du `Pcd` auquel le `Prd` fait référence.
|
|
* **`request_pcd_origin_hash`** : Hash du `Pcd` à l'origine du `Prd`.
|
|
* **`request_prd_reference_hash`** : Hash du `Prd` auquel le `Prd` fait référence.
|
|
* **`request_prd_origin_hash`** : Hash du `Prd` à l'origine du `Prd`.
|
|
* **`item_reference_hash`** : Hash de `Item` auquel le `Pcd` fait référence.
|
|
|
|
## 9. <a name='FonctiondesPcd'></a>Fonction des Pcd
|
|
|
|
Les Portable Contract Documents (`Pcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)).
|
|
|
|
Les `Item` échangés via les `Pcd` sont soumis à une vérification par les `PrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `Process` et les `Member` du `Role` concerné.
|
|
|
|
Principaux champs des `Pcd` :
|
|
|
|
* **`request`** : cf la descripton de la structure `Request`.
|
|
* **`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` :
|
|
|
|
* **`start`** : Index du premier `Item` de la liste.
|
|
* **`number`** : Nombre d'`Item` à afficher.
|
|
* **`page_index`** : Index de la page.
|
|
* **`page_total`** : Nombre total de pages.
|
|
|
|
Principaux champs de la structure `PcdItemGenericEnc` :
|
|
|
|
* **`version`** : Version de `Item`.
|
|
* **`item_type`** : Type de `Item`.
|
|
* **`name`** : Nom de `Item`.
|
|
* **`request_pcd_item_enc_attribute_public_list`** : Liste d'objets `PcdItemEncAttributePublic` des attributs publics de `Item` chiffré.
|
|
* **`request_pcd_item_enc_attribute_role_confidential_list`** : Liste d'objets `PcdItemEncAttributeRoleConfidential` des attributs confidentiels de `Item` chiffré.
|
|
* **`request_pcd_item_enc_attribute_private_list`** : Liste d'objets `PcdItemEncAttributePrivate` des attributs privés de `Item` chiffré.
|
|
|
|
Principaux champs de la structure `PcdItemEncAttributePublic` :
|
|
|
|
* **`attribute_name`** : Nom de l'attribut.
|
|
* **`data_enc`** : Données chiffrées par la clé `ProcessKey` de `Process` concerné.
|
|
* **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les `Envelope`. Données en clair.
|
|
* **`data`** : [PRIVE] Non partagé dans les `Envelope`. Données en clair.
|
|
|
|
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 `Envelope`. Données en clair.
|
|
* **`data`** : [PRIVE] Non partagé dans les `Envelope`. Données en clair.
|
|
|
|
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 `Envelope`. Données en clair.
|
|
* **`data`** : [PRIVE] Non partagé dans les `Envelope`. Données en clair.
|
|
|
|
### 9.1. <a name='Schmadesflux'></a>Schéma des flux
|
|
|
|
|
|
|
|
### 9.2. <a name='Crationetenvoi'></a>Création et envoi
|
|
|
|
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 cf Encryption.
|
|
4. Envoi de l'`Envelope` cf [Envelope - Specs](Envelope-Specs.md).
|
|
|
|
Schéma de finalisation de la création d'un `Pcd` :
|
|
|
|
[PCD finalize](diagrams/PCDFinalize.png "PCD finalize")
|
|
|
|
### 9.3. <a name='Rception'></a>Réception
|
|
|
|
La réception d'un `Pcd` suit plusieurs étapes :
|
|
|
|
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.
|
|
|
|
Schéma de finalisation de la réception d'un `Pcd` :
|
|
|
|
[PCD Received](diagrams/PCDReceived.png "PCD Received")
|
|
|
|
## 10. <a name='FonctiondesPrd'></a>Fonction des`Prd`
|
|
|
|
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 d'une `Envelope`, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
|
|
|
Les clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `Pcd` sont elles-mêmes chiffrées dans les `Prd` au moyen du chiffrement du `Prd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées aux `Members` concernés par les `Item` des `Pcd` (rôles dans les `Process`).
|
|
|
|
Les `Prd` se déclinent en plusieurs types, tels que `PrdList`, `PrdMessage`, `PrdUpdate`, etc., correspondant à différentes actions comme l'envoi d'une `Envelope`, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
|
|
|
Principaux champs des `Prd` :
|
|
|
|
* **`request`** : cf la descripton de la structure `Request`.
|
|
* **`sig_value`** : Valeur de la signature (parmi les valeurs valant pour `OK`, `KO` ou `none` telles que définies dans `Process`).
|
|
* **`request_pcd_reference_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` chiffrées par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`request_pcd_origin_hash_keys_role_confidential_list_confidential`** : Clés de déchiffrement des attributs confidentiels des `Item` des `Pcd` du `PCD` de référence, chiffrées par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`message_public`** : `Envelope` public, chiffré par la clé `ProcessKey` du `Process` concerné.
|
|
* **`message_confidential`** : `Envelope` confidentiel, chiffré par la clé `ProcessKey` du `Process` concerné.
|
|
* **`message_private`** : `Envelope` privé, chiffré par la clé privée `KeyRecover`.
|
|
* **`sp_address_to`** : Adresse du destinataire.
|
|
* **`sp_address_from`** : Adresse de l'émetteur.
|
|
* **`sp_address_reply`** : Adresse de réponse à l'émetteur.
|
|
* **`timestamp_declared`** : Horodatage déclaré.
|
|
* **`role_name_from`** : Nom du rôle de l'émetteur.
|
|
* **`role_name_to`** : Nom du rôle du destinataire.
|
|
* **`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`.
|
|
* **`commit_request_pcd_hash_list_confidential`** : Liste des `Pcd` d'`Item` de nom `commit` chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`ask_Payments_method_confidential`** : Demande de méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`ask_deposit_method_confidential`** : Demande de méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`ask_commit_method_confidential`** : Demande de méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`Payments_method_confidential`** : Méthode de paiement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande.
|
|
* **`deposit_method_confidential`** : Méthode de dépôt chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande.
|
|
* **`commit_method_confidential`** : Méthode d'engagement chiffrée par la clé `KeyConfidential` d'une `transaction SP`, en réponse à une demande.
|
|
* **`certif_key_confidential`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`device_footprint_enc_by_sp_shared_secret`** : Empreinte du dispositif de l'émetteur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
|
|
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma.
|
|
|
|
|
|
|
|
### 10.2. <a name='CrationdunPrd'></a>Création d'un `Prd`
|
|
|
|
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 de l'`Envelope` cf [Envelope - Specs](Envelope-Specs.md).
|
|
|
|
Schéma de finalisation de la création d'un `Prd` :
|
|
|
|
[PRD finalize](diagrams/PRDFinalize.png "PRD finalize")
|
|
|
|
### 10.3. <a name='Rception-1'></a>Réception
|
|
|
|
La réception d'un `Prd` suit plusieurs étapes :
|
|
|
|
1. Parcours des `Process` pour trouver le `Process` correspondant au `process_hash` du `Prd`
|
|
2. Tentative de déchiffrement du `Prd` avec la clé `ProcessKey` du `Process` correspondant.
|
|
3. Recherche des `Pcd` en relation via `Pcd_reference_hash` et `Pcd_origin_hash`, attente si nécessaire et traitement de ceux-ci.
|
|
4. Vérification de la conformité des `Pcd` en relation.
|
|
5. Recherche des `Prd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, attente si nécessaire et traitement de ceux-ci.
|
|
6. Vérification de la conformité des `Prd` en relation.
|
|
7. Recherche de `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 `Process` pour cet `Item`, avec le `Role` correspondant dans le `Process`, et dans ces rôles, les conditions pour ce type de `Prd` (dans l'attribut `request_prd_type`)
|
|
10. Vérification du role de l'`User` courant dans le `Process` et dans le `Item` concerné.
|
|
11. Traitements spécifiques au type de `Prd`.
|
|
|
|
Schéma de finalisation de la réception d'un `Prd` :
|
|
|
|
[PRD Received](diagrams/PRDReceived.png "PRD Received")
|
|
|
|
## 11. <a name='PrdList-DemandedeListes'></a>PrdList - Demande de Listes
|
|
|
|
Utile pour les `User` souhaitant consulter ou explorer des listes de contrats, de membres ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `Process`, les `Member`, les `Peer`, les `Payments`, etc.
|
|
|
|
Un `PRDList` concerne un seul type d'`Item` parmi `Member`, `Peer`, `Process`, `Artefact`, `Payment`… et demande le dernier `PCD` de ce type (la dernière liste validée). Ainsi, en retour d'un `PRDList`, on ne reçoit qu'une liste de membres (`PCD`) et les signatures qui la vérifient (`PRDResponse`). Il faudra, par exemple, un `PRDList` pour mettre à jour la liste d'un autre type d'`Item`.
|
|
|
|
Par exemple, à la connexion, on envoie des `PRDList` à chaque `adresse SP` de chaque `Role`, et l'on reçoit chaque liste (`PCD`) à jour pour tous les objets dont les `Member` et les `Process`. Lorsqu'il y a une mise à jour de la liste des `Member` et des `Process` et que l'on est connecté, alors on reçoit à jour ces listes en temps réel; donc, il y a peu de risques d'écarts entre, par exemple, la liste des `Member` et les `adresse sp` dans les `Process`. Une mise à jour est une nouvelle version d'un `PCD` et les `PRDResponse` qui ont répondu au `PRDUpdate` ayant demandé la mise à jour. Les `PRDResponse` permettront de vérifier la conformité de la nouvelle version du `PCD` avec les conditions du `Process`.
|
|
|
|
Note : dans les `Process` on ne connait que les `adresse SP` des gestionnaires; pour interagir avec les autres users, il faut utiliser la liste (`PCD`) des `Member` fournie par les `PRDList` envoyés par les gestionnaires de la liste des `Member`. Dans les process, nous n'avons besoin que des `adresse SP` des membres pour vérifier les `PCD` et les `PRDResponse` des `PRDList` et des `PRDUpdate` ou pour envoyer des `PRD` vers spécifiquement des `Member` d'un `Role`. Si dans les interfaces et services on a besoin du détail d'un membre comme son image d'avatar ou son nom, il faudra récupérer ces informations dans la dernière version du `PCD` des `Member`.
|
|
|
|
Workflow:
|
|
|
|
|
|
|
|
Principaux champs des `PrdList` :
|
|
|
|
* **`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.
|
|
* **`sub_pagination_stop`** : Dernière "page" de résultats dans les items qui contiennent une liste.
|
|
|
|
Dans le cas d'une création de compte :
|
|
|
|
* **`item_Member_enc_by_sp_shared_secret`** : Nouvel `Member` temporaire,chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
|
|
`Member` temporaire contient les métadonnées de type `Metadata` suivantes :
|
|
|
|
* **`MetadataProcessPublic` de type `MemberPublicAttributeGroup`** :
|
|
|
|
* **`sp_address_public`** : Adresse publique de l'`User`, chiffré par la `ProcessKey` de `Process`.
|
|
* **`sp_address_revoke_public`** : Adresse publique de révocation de l'`User`, chiffré par la `ProcessKey` de `Process`.
|
|
* **`third_sp_address_list_public`** : Liste des adresses publiques de devices tiers, chiffré par la `ProcessKey` de `Process`.
|
|
* **`data_size_max`** : Taille maximale des données acceptée par l'`User` (par flux), chiffré par la `ProcessKey` de `Process`.
|
|
* **`Payments_method_list_public`** : Liste des méthodes de paiement acceptées par l'`User`, chiffré par la `ProcessKey` de `Process`.
|
|
* **`succession_process_hash`** : Hash du processus de succession de l'`User` (transmission du `User` et donc de tous les flux associés), chiffré par la `ProcessKey` de `Process`.
|
|
* **`device_footprint`** : Empreinte du dispositif de l'`User`, chiffré par la `ProcessKey` de `Process`.
|
|
|
|
* **`MetadataRoleConfidential` de type `MemberRoleConfidentialAttributeGroup`** :
|
|
|
|
* **`shard_confidential`** : Shard de l'`User`, chiffré par la clé `KeyConfidential` d'une `transaction SP`.
|
|
* **`pre_id_confidential`** : Pré empreinte du `User`, chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
|
|
|
* **`MetadataPrivate` de type `MemberRolePrivateAttributeGroup`** :
|
|
|
|
* **`priv_key_mainnet_spend`** : Clé de dépense de l'`User`, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`.
|
|
* **`priv_key_mainnet_scan`** : Clé de scan de l'`User`, 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'`User`, chiffrée `KeyRecover`.
|
|
|
|
### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma.
|
|
|
|
|
|
|
|
## 12. <a name='PrdMessage-EnvoiduneEnvelope'></a>PrdMessage - Envoi d'une `Envelope`
|
|
|
|
Le `PrdMessage` facilite l'envoi d'une `Envelope` sécurisés entre `User` ou entre `User` 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 `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 :
|
|
|
|
|
|
Principaux champs des `PrdMessage` :
|
|
|
|
* **`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.
|
|
|
|
### 12.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
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.
|
|
|
|
|
|
|
|
## 13. <a name='PrdUpdate-MisesJourdePcd'></a>PrdUpdate - Mises à Jour de Pcd
|
|
|
|
`PrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `Pcd`.
|
|
|
|
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 `User` 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 Members permet d'ajouter de nouveaux `User` à un `Process`, et la mise à jour de la liste des `Process` permet de leur affecter un nouveau `Role`.
|
|
|
|
Les `PrdUpdate` signalent au réseau, via l'attribut `Pcd_new_version_hash`, les nouvelles versions des `Pcd`.
|
|
|
|
Workflow:
|
|
|
|
|
|
|
|
Principaux champs des `PrdUpdate` :
|
|
|
|
* **`request_prd`** : cf la descripton de la structure `Prd`.
|
|
|
|
### 13.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma.
|
|
|
|
|
|
|
|
## 14. <a name='PrdConfirm-ConfirmationdeRception'></a>PrdConfirm - Confirmation de Réception
|
|
|
|
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.
|
|
|
|
Les `PrdList`, `PrdUpdate`, `PrdMessage`, `PrdResponse` et `PrdKeyHello` reçoivent systématiquement un `PrdConfirm` suite à leur réception par le destinataire.
|
|
|
|
`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 `PrdConfirm` :
|
|
|
|
* **`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.
|
|
|
|
### 14.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
|
|
|
|
## 15. <a name='PrdResponse-RpondreuneDemande'></a>PrdResponse - Répondre à une Demande
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Workflow:
|
|
|
|
Voir les diagrammes `PRDUpdateFlows` et `PRDUpdateFlows`.
|
|
|
|
Principaux champs des `PrdResponse` :
|
|
|
|
* **`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`.
|
|
|
|
### 15.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
|
|
|
Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma.
|
|
|
|
|
|
|
|
## 16. <a name='ExemplesdeCode'></a>Exemples de Code
|
|
|
|
## 17. <a name='Todo'></a>Todo
|