From e205b7fc9f6f072ed78c78330d5908192499d057 Mon Sep 17 00:00:00 2001 From: NicolasCantu Date: Thu, 15 Feb 2024 17:07:45 +0100 Subject: [PATCH] wip (doc) --- doc/PRD-PCD-Specs.md | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index 0c8dd02..5026089 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -39,6 +39,20 @@ 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 + +Les PCD et les PRD sont reçus 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é. + +A la réception des messages, ils sont tous déchiffrés puis conservés ou non en fonction du `process hash` du PCD ou du PRD (dans l'attribut `request`). Si le `process hash` n'est pas reconnu, le message est ignoré. + +Les PRD et PCD sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md). + +Les types PRD et PCD sont distingués par l'attribut `request_type` dans le `message`. + +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. 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)). @@ -57,6 +71,14 @@ La création d'un PCD suit plusieurs étapes : 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. +### Réception + +Les PCD sont reçus sous forme de `message` 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é. + + + ## 5. 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. @@ -90,6 +112,14 @@ 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. 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. + +La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des PRD donc de la validation des données des PCD. Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et PRD (sauf `PRDKeyBackup`) et des PCD. Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication. + +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. Création et envoi La création d'un PRD suit plusieurs étapes : @@ -102,13 +132,7 @@ 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. -## 6. 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. - -La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des PRD donc de la validation des données des PCD. Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et PRD (sauf `PRDKeyBackup`) et des PCD. Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication. - -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). +### Réception ## 7. RequestPrdList - Demande de Listes (PCD)