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. [Commun aux PCD et PRD](#CommunauxPCDetPRD)
* 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.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)
@ -39,7 +44,17 @@ La spécification couvre la conception, le développement, et l'application prat
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,7 +152,17 @@ 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
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)