Réception / envoi PCD/PRD

This commit is contained in:
NicolasCantu 2024-02-15 18:21:39 +01:00
parent e205b7fc9f
commit b6fe884458

View File

@ -2,12 +2,17 @@
* 1. [Objectif](#Objectif)
* 2. [Portée](#Porte)
* 3. [3. Documents de référence](#Documentsderfrence)
* 4. [Fonction des PCD](#FonctiondesPCD)
* 4.1. [Création et envoi](#Crationetenvoi)
* 5. [Fonction des PRD](#FonctiondesPRD)
* 5.1. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
* 5.2. [Création et envoi](#Crationetenvoi-1)
* 6. [Fonction des transactions silent payment SP associées aux PRD](#FonctiondestransactionssilentpaymentSPassociesauxPRD)
* 4. [Commun aux PCD et PRD](#CommunauxPCDetPRD)
* 4.1. [Création et envoi](#Crationetenvoi)
* 4.2. [Réception](#Rception)
* 5. [Fonction des PCD](#FonctiondesPCD)
* 5.1. [Création et envoi](#Crationetenvoi-1)
* 5.2. [Réception](#Rception-1)
* 6. [Fonction des PRD](#FonctiondesPRD)
* 6.1. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
* 6.2. [Fonction des transactions silent payment SP associées aux PRD](#FonctiondestransactionssilentpaymentSPassociesauxPRD)
* 6.3. [Création et envoi](#Crationetenvoi-1)
* 6.4. [Réception](#Rception-1)
* 7. [RequestPrdList - Demande de Listes (PCD)](#RequestPrdList-DemandedeListesPCD)
* 8. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages)
* 9. [RequestPrdUpdate - Mises à Jour de PCD](#RequestPrdUpdate-MisesJourdePCD)
@ -16,8 +21,8 @@
* 12. [RequestPrdKeyHelloBakcup](#RequestPrdKeyHelloBakcup)
* 13. [RequestPrdKeyHello - Échange de Clés et d'Identités](#RequestPrdKeyHello-changedeClsetdIdentits)
* 14. [Gestion et Échange des Documents](#GestionetchangedesDocuments)
* 14.1. [Création et Distribution](#CrationetDistribution)
* 14.2. [Validation et Mise à Jour](#ValidationetMiseJour)
* 14.1. [Création et Distribution](#CrationetDistribution)
* 14.2. [Validation et Mise à Jour](#ValidationetMiseJour)
* 15. [Exemples de Code](#ExemplesdeCode)
* 16. [Todo](#Todo)
@ -27,19 +32,29 @@
/vscode-markdown-toc-config -->
<!-- /vscode-markdown-toc --># PRD et PCD - Specs
## 1. <a name='Objectif'></a>Objectif
## 1. <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 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. <a name='Porte'></a>Portée
## 2. <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.
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
Voir [Doc_references.md](Doc_references.md).
## Commun aux PCD et PRD
## 4. <a name='CommunauxPCDetPRD'></a>Commun aux PCD et PRD
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
Les PCD et les PRD sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
Les messages contiennent des PRD ou des PCD encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
### 4.2. <a name='Rception'></a>Réception
Les PCD et les PRD sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
@ -53,13 +68,17 @@ Les types PRD et PCD sont distingués par l'attribut `request_type` dans le `mes
En cas de PCD ou PRD en relation via `pcd_reference_hash` ou `prd_reference_hash` ou `pcd_origin_hash` ou `prd_origin_hash` ou `item_reference_hash` (dans des PCD), il avoir reçu ou attendre ces documents pour traiter le message.
## 4. <a name='FonctiondesPCD'></a>Fonction des PCD
**Réception du message**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
Pour les PCD et les PRD il faut vérifier que le hash du document n'est pas déjà en cas, si c'est le cas, le message est ignoré.
## 5. <a name='FonctiondesPCD'></a>Fonction des PCD
Les Portable Contract Documents (PCD) sont des documents JSON qui encapsulent les listes versionnées d'`Item` dont les attributs sont chiffrés soit en public, soit en confidentiel par rôles soit en privé (cf. [Specs-Security.md](Specs-Security.md)).
Les `Item` ainsi échangés via les PCD sont vérifiés par les `PRDResponse` afin de vérifier les validations de ces données et leurs conformités avec les `process` et les `members` concernés.
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
### 5.1. <a name='Crationetenvoi-1'></a>Création et envoi
La création d'un PCD suit plusieurs étapes :
@ -67,19 +86,20 @@ La création d'un PCD suit plusieurs étapes :
2. **Mise à jour**: Ajouts et modifications eventuelles des `Item`
3. **Chiffrement des attributs**: Chiffrement des attributs de chaque Item selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)).
4. **Chiffrement du PCD**: Chiffrement du PCD avec la clé `ProcessKey` du `process` concerné.
5. **Création du message**: Création du `message` contenant le PCD chiffré, la preuve de travail, l'adresse de faucet
6. **Sélection des relais pour le message**: Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées.
7. **Envoi du message**: Envoi du message aux relais.
5. Traitements communs aux PCD et PRD
### Réception
### 5.2. <a name='Rception-1'></a>Réception
Les PCD sont reçus sous forme de `message` depuis les websockets des relais.
La réception d'un PCD suit plusieurs étapes :
Les messages contiennent des PRD ou des PCD encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
1. Traitements communs aux PCD et PRD
2. Recherche des PRD en relation via `pcd_reference_hash` ou `pcd_origin_hash` de ces PRD et attente si nécessaire.
3. Déchiffrage des attributs publics des `Item` des PCD avec la `ProcessKey` du `process` concerné.
4. Déchiffrage des attributs confidentiels des `Item` des PCD avec les clés de déchiffrement depuis l'attribut `pcd_keys_role_confidential_list_enc_by_shared_secret` des PRD.
5. Déchiffrage des attributs privés des `Item` des PCD avec la clé privée `KeyRecover`
6. Mise à jour du cache pour les traitement des PRD.
## 5. <a name='FonctiondesPRD'></a>Fonction des PRD
## 6. <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_enc_by_shared_secret`. Ils sont utilisés pour demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
@ -87,7 +107,7 @@ Les clés de chiffrement des attributs confidentiels par rôles des `Item` des P
Les PRD sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `PRD` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
### 5.1. <a name='Fonctionnalitsoptionnelles'></a>Fonctionnalités optionnelles
### 6.1. <a name='Fonctionnalitsoptionnelles'></a>Fonctionnalités optionnelles
L'attribut `sig_value` permet de donner une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess` avec des valeurs valant pour `OK` ou `KO` pour `none` pour les validations des `PRD`.
@ -112,7 +132,7 @@ Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs
Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`.
### 6. <a name='FonctiondestransactionssilentpaymentSPassociesauxPRD'></a>Fonction des transactions silent payment SP associées aux PRD
### 6.2. <a name='FonctiondestransactionssilentpaymentSPassociesauxPRD'></a>Fonction des transactions silent payment SP associées aux PRD
La clé `KeyConfidential` d'une transaction Silent Payment SP est utilisée pour chiffrer les PRD. Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. Cette information est parrallèle aux PRD et permet une meilleur sécurité et confidentialité des échanges.
@ -120,7 +140,7 @@ La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de
Les `PRDConfirm` qui sont des accusés automatiques de réception des PRD sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).
### 5.2. <a name='Crationetenvoi-1'></a>Création et envoi
### 6.3. <a name='Crationetenvoi-1'></a>Création et envoi
La création d'un PRD suit plusieurs étapes :
@ -132,13 +152,23 @@ La création d'un PRD suit plusieurs étapes :
6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP.
7. **Envoi du message**: Envoi du message aux relais et des transactions aux noeuds de signet.
### Réception
### 6.4. <a name='Rception-1'></a>Réception
## 7. <a name='RequestPrdList-DemandedeListesPCD'></a>RequestPrdList - Demande de Listes (PCD)
La réception d'un PCD suit plusieurs étapes :
1. Traitements communs aux PCD et PRD
2. Recherche des PCD en relation via `pcd_reference_hash` ou `pcd_origin_hash` et attente si nécessaire.
3. Recherche des PRD en relation via `prd_reference_hash` ou `prd_origin_hash` et attente si nécessaire.
4. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire.
5. Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du PRD dans l'output `2` de la transaction.
6. Mise à jour du cache pour les traitement des PRD.
7. Traitements spécifiques au type de PRD.
## 7. <a name='RequestPrdList-DemandedeListesPCD'></a>RequestPrdList - Demande de Listes (PCD)
Utile pour les utilisateurs cherchant à 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, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages
Le RequestPrdMessage facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
@ -146,7 +176,7 @@ Permet la communication directe et sécurisée au sein du réseau, supportant de
Les `PRDMessage` répondent aux `PRDMessage`.
## 9. <a name='RequestPrdUpdate-MisesJourdePCD'></a>RequestPrdUpdate - Mises à Jour de PCD
## 9. <a name='RequestPrdUpdate-MisesJourdePCD'></a>RequestPrdUpdate - Mises à Jour de PCD
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `PCD`.
@ -163,7 +193,7 @@ Les `PRDUpdate` signalent de façon confidentielle :
* soient des conditions ad'hoc déjà remplies via l'attribut `payment_pcd_hash_list`, `cap_pcd_hash_list`, `deposit_pcd_hash_list`, `commitment_pcd_hash_list` pour les paiements et preuves ad'hoc éventuellements associés aux PCD de la nouvelle version.
* soient des appels pour recevoir les moyens de satisfaire ces conditions via les attributs `ask_payment_method`, `ask_deposit_method`, `ask_commitment_method`.
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>RequestPrdConfirm - Confirmation de Réception
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>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.
@ -173,7 +203,7 @@ Les `PRDList`, `PRDUpdate`, `PRDMessage`, `PRDResponse` et `PRDKeyHello` reçoiv
Crucial pour les processus qui nécessitent une confirmation explicite de réception ou d'acceptation, comme la finalisation d'une transaction ou la validation d'un changement d'état dans un contrat.
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - Répondre à une Demande
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - 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.
@ -183,29 +213,29 @@ Utilisé pour fournir des feedbacks, des confirmations, ou des instructions supp
Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions.
## 12. <a name='RequestPrdKeyHelloBakcup'></a>RequestPrdKeyHelloBakcup
## 12. <a name='RequestPrdKeyHelloBakcup'></a>RequestPrdKeyHelloBakcup
Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` .
## 13. <a name='RequestPrdKeyHello-changedeClsetdIdentits'></a>RequestPrdKeyHello - Échange de Clés et d'Identités
## 13. <a name='RequestPrdKeyHello-changedeClsetdIdentits'></a>RequestPrdKeyHello - Échange de Clés et d'Identités
RequestPrdKeyHello est conçu pour initier ou répondre à des demandes d'échange de clés ou d'informations d'identité, essentiel pour la gestion sécurisée des accès et des identités au sein du réseau.
Important pour les processus d'onboarding de nouveaux membres, de réinitialisation des accès, ou de renouvellement des clés, facilitant une intégration sécurisée et la mise à jour des identités dans le réseau.
## 14. <a name='GestionetchangedesDocuments'></a>Gestion et Échange des Documents
## 14. <a name='GestionetchangedesDocuments'></a>Gestion et Échange des Documents
### 14.1. <a name='CrationetDistribution'></a>Création et Distribution
### 14.1. <a name='CrationetDistribution'></a>Création et Distribution
Procédure de création des PCD et PRD, leur chiffrement, et les mécanismes de distribution sécurisée à travers le réseau 4NK.
### 14.2. <a name='ValidationetMiseJour'></a>Validation et Mise à Jour
### 14.2. <a name='ValidationetMiseJour'></a>Validation et Mise à Jour
Processus de validation des informations contenues dans les PCD et PRD, ainsi que les procédures de mise à jour et de versioning des documents.
## 15. <a name='ExemplesdeCode'></a>Exemples de Code
## 15. <a name='ExemplesdeCode'></a>Exemples de Code
## 16. <a name='Todo'></a>Todo
## 16. <a name='Todo'></a>Todo
* [ ] Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
* [ ] Diagrammes de séquences