4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Definitions added (doc)

Browse Source
This commit is contained in:
NicolasCantu 2024-03-19 11:26:25 +01:00
parent 86dbd2ec4b
commit 4f82a6e733
2 changed files with 106 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

167
doc/PRD-PCD-Specs.md
View File

@ -1,41 +1,43 @@
<!-- vscode-markdown-toc --> <!-- vscode-markdown-toc -->
* 1. [Objectif](#Objectif) * 1. [Objectif](#Objectif)
* 2. [Portée](#Porte) * 2. [Portée](#Porte)
* 3. [3. Documents de référence](#Documentsderfrence) * 3. [Documents de référence](#Documentsderfrence)
* 4. [Commun aux `RequestPcd` et RequestPrd](#CommunauxRequestPcdetRequestPrd) * 4. [Encryption](#Encryption)
* 4.1. [Création et envoi](#Crationetenvoi) * 5. [Définitions](#Dfinitions)
* 4.2. [Réception](#Rception) * 6. [Principe de messagerie](#Principedemessagerie)
* 5. [Fonction des RequestPcd](#FonctiondesRequestPcd) * 6.1. [Création et envoi](#Crationetenvoi)
* 5.1. [Schéma des flux](#Schmadesflux) * 6.2. [Réception](#Rception)
* 5.2. [Création et envoi](#Crationetenvoi-1) * 7. [Fonction des RequestPcd](#FonctiondesRequestPcd)
* 5.3. [Réception](#Rception-1) * 7.1. [Schéma des flux](#Schmadesflux)
* 6. [Fonction des RequestPrd](#FonctiondesRequestPrd) * 7.2. [Création et envoi](#Crationetenvoi-1)
* 6.1. [Schéma des flux](#Schmadesflux-1) * 7.3. [Réception](#Rception-1)
* 6.2. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles) * 8. [Fonction des`RequestPrd`](#FonctiondesRequestPrd)
* 6.3. [Création et envoi](#Crationetenvoi-1) * 8.1. [Schéma des flux](#Schmadesflux-1)
* 6.4. [Réception](#Rception-1) * 8.2. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
* 7. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd) * 8.3. [Création et envoi](#Crationetenvoi-1)
* 7.1. [Schéma des flux](#Schmadesflux-1) * 8.4. [Réception](#Rception-1)
* 7.2. [Création : Datas spécifiques](#Cration:Datasspcifiques) * 9. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd)
* 7.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques) * 9.1. [Schéma des flux](#Schmadesflux-1)
* 8. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages) * 9.2. [Création : Datas spécifiques](#Cration:Datasspcifiques)
* 8.1. [Schéma des flux](#Schmadesflux-1) * 9.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques)
* 8.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) * 10. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages)
* 8.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) * 10.1. [Schéma des flux](#Schmadesflux-1)
* 9. [RequestPrdUpdate - Mises à Jour de RequestPcd](#RequestPrdUpdate-MisesJourdeRequestPcd) * 10.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
* 9.1. [Schéma des flux](#Schmadesflux-1) * 10.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
* 9.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) * 11. [RequestPrdUpdate - Mises à Jour de RequestPcd](#RequestPrdUpdate-MisesJourdeRequestPcd)
* 9.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) * 11.1. [Schéma des flux](#Schmadesflux-1)
* 10. [RequestPrdConfirm - Confirmation de Réception](#RequestPrdConfirm-ConfirmationdeRception) * 11.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
* 10.1. [Schéma des flux](#Schmadesflux-1) * 11.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
* 10.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) * 12. [RequestPrdConfirm - Confirmation de Réception](#RequestPrdConfirm-ConfirmationdeRception)
* 10.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) * 12.1. [Schéma des flux](#Schmadesflux-1)
* 11. [RequestPrdResponse - Répondre à une Demande](#RequestPrdResponse-RpondreuneDemande) * 12.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
* 11.1. [Schéma des flux](#Schmadesflux-1) * 12.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
* 11.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) * 13. [RequestPrdResponse - Répondre à une Demande](#RequestPrdResponse-RpondreuneDemande)
* 11.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) * 13.1. [Schéma des flux](#Schmadesflux-1)
* 12. [Exemples de Code](#ExemplesdeCode) * 13.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
* 13. [Todo](#Todo) * 13.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
* 14. [Exemples de Code](#ExemplesdeCode)
* 15. [Todo](#Todo)
# `RequestPrd` et `RequestPcd` - Specs # `RequestPrd` et `RequestPcd` - Specs
@ -47,13 +49,13 @@ Le but de cette section est d'introduire les Portable Contract Document (`Reques
La spécification couvre la conception, le développement, et l'application pratique des `RequestPcd` et `RequestPrd`.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 `RequestPcd` et `RequestPrd` 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. La spécification couvre la conception, le développement, et l'application pratique des `RequestPcd` et `RequestPrd`.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 `RequestPcd` et `RequestPrd` 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>Documents de référence
Voir [_Doc_references.md](_Doc_references.md). Voir [_Doc_references.md](_Doc_references.md).
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et `RequestPrd` ## 4. <a name='Encryption'></a>Encryption
Encryption : Schema :
![PCD_PRD_encryption](diagrams/PCD_PRD_encryption.png "PCD_PRD_encryption") ![PCD_PRD_encryption](diagrams/PCD_PRD_encryption.png "PCD_PRD_encryption")
@ -67,7 +69,30 @@ Les `Metadata` des `Item` des `RequestPcd` et les attributs des `RequestPcd` et
* **Données privées** : Chiffrées symétriquement en utilisant la clé de dépense de connexion (`recover`) du signet (voir Login - Specs). * **Données privées** : Chiffrées symétriquement en utilisant la clé de dépense de connexion (`recover`) du signet (voir Login - Specs).
### 4.1. <a name='Crationetenvoi'></a>Création et envoi ## 5. <a name='Dfinitions'></a>Définitions
* **Portable Contract Document (`RequestPcd`)**: Format `JSON` chiffré destiné à contenir des listes d'éléments d'un type, attachées à un process (`process_hash`) et soumis aux règles de valiation décrit dans le role correspondant à ce type d'item dans le process (`item_type`).
* **Portable Request Document (`RequestPrd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requètes et validation) des `RequestPcd`. Les `RequestPrdResponse` sont collectés afin de vérifier que les conditions de l'`ItemProcess` sont bien respectées. D'autres types de `RequestPcd` permettent :
* `RequestPrdList`: Demande de Listes d'`Item` en retour une `RequestPcd` sera reçu avec les `RequestPrdResponse` correspondant.
* `RequestPrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou des transactions Silent Payments à broacaster sur le réseau de noeuds de la side chain. Les `RequestPrdMessage` peuvent se répondre entre eux.
* `RequestPrdUpdate`: Demande de mise à Jour d'une liste d'`Item` (publiée va un `RequestPCD`) qui sera validé ou non par des `RequestPrdResponse` en retour.
* `RequestPrdConfirm`: Confirmation de Réception des `RequestPrd`.
* `RequestPrdResponse`: Réponse aux autres types de `RequestPrd` (hors `RequestPrdConfirm` et `RequestPrdResponse`).
* **Message**: Enveloppe commune au `RequestPrd` et `RequestPcd` lorsqu'ils sont transmis au relais et reçus des relais. Cette enveloppe est chiffrée par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)).
* **KeyConfidential**: Clé AES-GCM-256 du `Diffie-Hellman` de la transaction Silent Payment correspondant à un `RequestPrd`.
* **ProcessKey**: la clé publique de chiffrement public d'un `ItemProcess` (dans un `ItemProcess`, 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é prive de spend de `recover` du signet, qui sert de référence pour l'identité.
* **pre-id**: Pré identifiant des utilisateurs constitué du hash de partie 1 de la `KeyRecover`.
## 6. <a name='Principedemessagerie'></a>Principe de messagerie
### 6.1. <a name='Crationetenvoi'></a>Création et envoi
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de messages (`JSON`) via les `websockets` des relais. Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de messages (`JSON`) via les `websockets` des relais.
@ -77,7 +102,7 @@ Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](
**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md). **Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
### 4.2. <a name='Rception'></a>Réception ### 6.2. <a name='Rception'></a>Réception
Les `RequestPcd` et `RequestPrd` sont reçus sous forme de messages (`JSON`) via les `websockets` des relais. Les `RequestPcd` et `RequestPrd` sont reçus sous forme de messages (`JSON`) via les `websockets` des relais.
@ -95,17 +120,17 @@ Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.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é. 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é.
## 5. <a name='FonctiondesRequestPcd'></a>Fonction des RequestPcd ## 7. <a name='FonctiondesRequestPcd'></a>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)). 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)).
Les `Item` échangés via les `RequestPcd` sont soumis à une vérification par les `RequestPrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné. Les `Item` échangés via les `RequestPcd` sont soumis à une vérification par les `RequestPrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné.
### 5.1. <a name='Schmadesflux'></a>Schéma des flux ### 7.1. <a name='Schmadesflux'></a>Schéma des flux
![RequestPcd](diagrams/PCD.png "RequestPcd") ![RequestPcd](diagrams/PCD.png "RequestPcd")
### 5.2. <a name='Crationetenvoi-1'></a>Création et envoi ### 7.2. <a name='Crationetenvoi-1'></a>Création et envoi
La création d'un `RequestPcd` suit plusieurs étapes : La création d'un `RequestPcd` suit plusieurs étapes :
@ -115,7 +140,7 @@ La création d'un `RequestPcd` suit plusieurs étapes :
4. Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné. 4. Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné.
5. Traitements communs aux `RequestPcd` et `RequestPrd`. 5. Traitements communs aux `RequestPcd` et `RequestPrd`.
### 5.3. <a name='Rception-1'></a>Réception ### 7.3. <a name='Rception-1'></a>Réception
La réception d'un `RequestPcd` suit plusieurs étapes : La réception d'un `RequestPcd` suit plusieurs étapes :
@ -126,7 +151,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
5. Déchiffrage des attributs privés des `Item` des `RequestPcd` avec la clé privée `KeyRecover`. 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`. 6. Mise à jour du cache pour le traitement des `RequestPrd`.
## 6. <a name='FonctiondesRequestPrd'></a>Fonction des`RequestPrd` ## 8. <a name='FonctiondesRequestPrd'></a>Fonction des`RequestPrd`
Les Portable Request Documents (RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. Les Portable Request Documents (RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
@ -134,13 +159,13 @@ 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. 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.
### 6.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 8.1. <a name='Schmadesflux-1'></a>Schéma des flux
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma.
![RequestPrd](diagrams/PRD.png "RequestPrd") ![RequestPrd](diagrams/PRD.png "RequestPrd")
### 6.2. <a name='Fonctionnalitsoptionnelles'></a>Fonctionnalités optionnelles ### 8.2. <a name='Fonctionnalitsoptionnelles'></a>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`. 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`.
@ -165,7 +190,7 @@ Les adresses et les rôles sont précisés en cas d'utilisateurs ayant plusieurs
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`. 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`.
### 6.3. <a name='Crationetenvoi-1'></a>Création et envoi ### 8.3. <a name='Crationetenvoi-1'></a>Création et envoi
La création d'un `RequestPrd` suit plusieurs étapes : La création d'un `RequestPrd` suit plusieurs étapes :
@ -190,7 +215,7 @@ Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
| `RequestPrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | | `RequestPrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes |
| `RequestPrdConfirm` | (option) Waiting `code_confirm_enc_by_shared_secret` | Yes | No | See Received | No | No | No | | `RequestPrdConfirm` | (option) Waiting `code_confirm_enc_by_shared_secret` | Yes | No | See Received | No | No | No |
### 6.4. <a name='Rception-1'></a>Réception ### 8.4. <a name='Rception-1'></a>Réception
La réception d'un `RequestPcd` suit plusieurs étapes : La réception d'un `RequestPcd` suit plusieurs étapes :
@ -214,23 +239,23 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
| `RequestPrdResponse` | Info | Yes | No | No | No | No | | `RequestPrdResponse` | Info | Yes | No | No | No | No |
| `RequestPrdConfirm` | Info | No | No | No | No | No | | `RequestPrdConfirm` | Info | No | No | No | No | No |
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd) ## 9. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd)
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. 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.
### 7.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 9.1. <a name='Schmadesflux-1'></a>Schéma des flux
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma.
![RequestPrdList](diagrams/PRDList.png "RequestPrdList") ![RequestPrdList](diagrams/PRDList.png "RequestPrdList")
### 7.2. <a name='Cration:Datasspcifiques'></a>Création : Datas spécifiques ### 9.2. <a name='Cration:Datasspcifiques'></a>Création : Datas spécifiques
1. Traitement des `RequestPrd`, avec le `type_request`. 1. Traitement des `RequestPrd`, avec le `type_request`.
2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouvel `ItemMember` (création d'une identité numérique), uniquement destiné aux gestionnaires des membres. 2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouvel `ItemMember` (création d'une identité numérique), uniquement destiné aux gestionnaires des membres.
3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement destiné aux gestionnaires des membres. 3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement destiné aux gestionnaires des membres.
### 7.3. <a name='Rception:Datasspcifiques'></a>Réception : Datas spécifiques ### 9.3. <a name='Rception:Datasspcifiques'></a>Réception : Datas spécifiques
La réception d'un `RequestPrdList` suit plusieurs étapes : La réception d'un `RequestPrdList` suit plusieurs étapes :
@ -239,7 +264,7 @@ La réception d'un `RequestPrdList` suit plusieurs étapes :
3. En cas de `item_member_enc_by_sp_shared_secret`, pour la création d'un nouvel `ItemMember` (création d'une identité numérique), cette étape est réservée uniquement aux gestionnaires des membres. L'`ItemMember` est ajouté au cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé. 3. En cas de `item_member_enc_by_sp_shared_secret`, pour la création d'un nouvel `ItemMember` (création d'une identité numérique), cette étape est réservée uniquement aux gestionnaires des membres. L'`ItemMember` est ajouté au cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé.
4. En cas de `pre_id_sp_enc_by_shared_secret`, pour la connexion avec une identité numérique existante, cette étape est destinée uniquement aux gestionnaires des membres pour le renvoi du shard correspondant dans le `RequestPrdResponse`. 4. En cas de `pre_id_sp_enc_by_shared_secret`, pour la connexion avec une identité numérique existante, cette étape est destinée uniquement aux gestionnaires des membres pour le renvoi du shard correspondant dans le `RequestPrdResponse`.
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages ## 10. <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. Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
@ -250,22 +275,22 @@ Il permet la communication :
Les `RequestPrdMessage` peuvent répondre aux autres `RequestPrdMessage`, sauf en cas d'envoi de `raw_transaction_list` (dans le cas d'utilisation pour transférer la `transaction SP` depuis un autre `RequestPrd`). Les `RequestPrdMessage` peuvent répondre aux autres `RequestPrdMessage`, sauf en cas d'envoi de `raw_transaction_list` (dans le cas d'utilisation pour transférer la `transaction SP` depuis un autre `RequestPrd`).
### 8.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `RequestPrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `RequestPrdMessage` contient une `raw_transaction_list` non vide. Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `RequestPrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `RequestPrdMessage` contient une `raw_transaction_list` non vide.
![RequestPrdMessage](diagrams/PRDMessage.png "RequestPrdMessage") ![RequestPrdMessage](diagrams/PRDMessage.png "RequestPrdMessage")
### 8.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques ### 10.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué au `RequestPrdMessage`. 1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué au `RequestPrdMessage`.
2. Cas de la transmission d'une `Transaction SP` depuis un autre `RequestPrd` au format `raw` dans l'attribut `raw_transaction_list`, pour la publication de la transaction dans la side chain. 2. Cas de la transmission d'une `Transaction SP` depuis un autre `RequestPrd` au format `raw` dans l'attribut `raw_transaction_list`, pour la publication de la transaction dans la side chain.
### 8.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques ### 10.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
1. Traitements des `RequestPrd` 1. Traitements des `RequestPrd`
## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd ## 11. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `RequestPcd`. `RequestPrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `RequestPcd`.
@ -277,25 +302,25 @@ Par exemple, la mise à jour de la liste des membres permet d'ajouter de nouveau
Les `RequestPrdUpdate` signalent au réseau, via l'attribut `RequestPcd_new_version_hash`, les nouvelles versions des `RequestPcd`. Les `RequestPrdUpdate` signalent au réseau, via l'attribut `RequestPcd_new_version_hash`, les nouvelles versions des `RequestPcd`.
### 9.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux
Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma. Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma.
![RequestPrdUpdate](diagrams/PRDUpdate.png "RequestPrdUpdate") ![RequestPrdUpdate](diagrams/PRDUpdate.png "RequestPrdUpdate")
### 9.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques ### 11.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdUpdate`. 1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdUpdate`.
2. Pas de données spécifiques. 2. Pas de données spécifiques.
### 9.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques ### 11.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
La réception d'un `RequestPrdUpdate` suit plusieurs étapes : La réception d'un `RequestPrdUpdate` suit plusieurs étapes :
1. Traitement des `RequestPrd`. 1. Traitement des `RequestPrd`.
2. Comparaison de la dernière version du `RequestPcd` en cache avec la nouvelle version du `RequestPcd` associée, via `RequestPcd_new_version_hash`, et attente si nécessaire. 2. Comparaison de la dernière version du `RequestPcd` en cache avec la nouvelle version du `RequestPcd` associée, via `RequestPcd_new_version_hash`, et attente si nécessaire.
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>RequestPrdConfirm - Confirmation de Réception ## 12. <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. 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.
@ -303,21 +328,21 @@ Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdRespon
`code_confirm_enc_by_shared_secret` : 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 `RequestPrdConfirm`. `code_confirm_enc_by_shared_secret` : 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 `RequestPrdConfirm`.
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 12.1. <a name='Schmadesflux-1'></a>Schéma des flux
![RequestPrdConfirm](diagrams/PRDConfirm.png "RequestPrdConfirm") ![RequestPrdConfirm](diagrams/PRDConfirm.png "RequestPrdConfirm")
### 10.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques ### 12.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdConfirm`. 1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdConfirm`.
2. Communication éventuelle d'un `code_confirm_enc_by_shared_secret` à confirmer dans le `RequestPrdConfirm`. 2. Communication éventuelle d'un `code_confirm_enc_by_shared_secret` à confirmer dans le `RequestPrdConfirm`.
### 10.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques ### 12.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
1. Traitement des `RequestPrd`, sans traitement supplémentaire. 1. Traitement des `RequestPrd`, sans traitement supplémentaire.
2. Vérification du `code_confirm_enc_by_shared_secret` dans le `RequestPrdConfirm` reçu. 2. Vérification du `code_confirm_enc_by_shared_secret` dans le `RequestPrdConfirm` reçu.
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - Répondre à une Demande ## 13. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - Répondre à une Demande
Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties.
@ -325,28 +350,28 @@ Les `RequestPrdResponse` sont utilisés pour répondre aux `RequestPrdList`, `Re
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. 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.
### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux ### 13.1. <a name='Schmadesflux-1'></a>Schéma des flux
Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma. Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma.
![RequestPrdResponse](diagrams/PRDResponse.png "RequestPrdResponse") ![RequestPrdResponse](diagrams/PRDResponse.png "RequestPrdResponse")
### 11.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques ### 13.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué à `RequestPrdResponse`. 1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué à `RequestPrdResponse`.
2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si celle-ci n'est pas automatique). 2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si celle-ci n'est pas automatique).
3. En cas de réponse à un `RequestPrdKeyList`, fourniture de `pre_id_enc_by_sp_shared_secret` avec les shards correspondant à la `pre-id` demandée. 3. En cas de réponse à un `RequestPrdKeyList`, fourniture de `pre_id_enc_by_sp_shared_secret` avec les shards correspondant à la `pre-id` demandée.
4. (Optionnel) Partage d'une clé de chiffrement ad hoc via `shared_secret_key`. 4. (Optionnel) Partage d'une clé de chiffrement ad hoc via `shared_secret_key`.
### 11.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques ### 13.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
1. Traitement des `RequestPrd`. 1. Traitement des `RequestPrd`.
2. Vérification des conditions de validation des `RequestPcd` associés. 2. Vérification des conditions de validation des `RequestPcd` associés.
3. En cas de réponse reçue pour un `RequestPrdList` : récupération des shards correspondant à la `pre-id` demandée et génération de la clé `KeyRecover`. 3. En cas de réponse reçue pour un `RequestPrdList` : récupération des shards correspondant à la `pre-id` demandée et génération de la clé `KeyRecover`.
## 12. <a name='ExemplesdeCode'></a>Exemples de Code ## 14. <a name='ExemplesdeCode'></a>Exemples de Code
## 13. <a name='Todo'></a>Todo ## 15. <a name='Todo'></a>Todo
[ ] Définition claire de ‘request-type’ [ ] Définition claire de ‘request-type’
[ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’: [ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’:

16
doc/Specs-Definition.md
View File

@ -20,17 +20,23 @@ Voir [_Doc_references.md](_Doc_references.md).
## 2. <a name='Spcifique4NK'></a>Spécifique 4NK ## 2. <a name='Spcifique4NK'></a>Spécifique 4NK
* **4NK**: Système décentralisé innovant basé sur les principes du web 5, centré sur la sécurité des données et l'identité numérique. * **4NK**: Système décentralisé innovant basé sur les principes du web 5, centré sur la sécurité des données et l'identité numérique.
* **Portable Contract Document (`RequestPcd`)**: Format `JSON` chiffré destiné à contenir des listes d'éléments d'un type, attachées à un process (`process_hash`) et soumis aux règles de valiation décrit dans le role correspondant à ce type d'item dans le process (`item_type`).
* **Portable Contract Document ( RequestPcd)**: Format JSON chiffré destiné à contenir les données relatives aux accords entre parties. * **Portable Request Document (`RequestPrd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requètes et validation) des `RequestPcd`. Les `RequestPrdResponse` sont collectés afin de vérifier que les conditions de l'`ItemProcess` sont bien respectées. D'autres types de `RequestPcd` permettent :
* `RequestPrdList`: Demande de Listes d'`Item` en retour une `RequestPcd` sera reçu avec les `RequestPrdResponse` correspondant.
* `RequestPrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou des transactions Silent Payments à broacaster sur le réseau de noeuds de la side chain. Les `RequestPrdMessage` peuvent se répondre entre eux.
* `RequestPrdUpdate`: Demande de mise à Jour d'une liste d'`Item` (publiée va un `RequestPCD`) qui sera validé ou non par des `RequestPrdResponse` en retour.
* `RequestPrdConfirm`: Confirmation de Réception des `RequestPrd`.
* `RequestPrdResponse`: Réponse aux autres types de `RequestPrd` (hors `RequestPrdConfirm` et `RequestPrdResponse`).
* **Portable Request Document ( RequestPrd)**: Format JSON chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des RequestPcd. * **Message**: Enveloppe commune au `RequestPrd` et `RequestPcd` lorsqu'ils sont transmis au relais et reçus des relais. Cette enveloppe est chiffrée par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)).
* **KeyConfidential**: Clé AES-GCM-256 du `Diffie-Hellman` de la transaction Silent Payment correspondant à un `RequestPrd`.s à l'interprétation des RequestPcd.
* **Peer**: Terme générique pour représenter un nœud du réseau, pouvant avoir diverses fonctions. * **Peer**: Terme générique pour représenter un nœud du réseau, pouvant avoir diverses fonctions.
* **Relay**: Un serveur web socket qui relaie en peer to peer les messages entre les autres pairs du réseau de relais et avec les clients connectés. * **Relay**: Un serveur web socket qui relaie en peer to peer les messages entre les autres pairs du réseau de relais et avec les clients connectés.
* **Message**: Enveloppe commune au `RequestPrd` et `RequestPcd` lorsqu'ils sont transmis au relais.
* **Process**: Contrat off-chain définissant des conditions d'affichage, légales, de validation cryptographique et de rémunération des signatures. * **Process**: Contrat off-chain définissant des conditions d'affichage, légales, de validation cryptographique et de rémunération des signatures.
* **Utilisateur**: Client connecté pouvant être un navigateur, une application mobile, un logiciel, ou un IoT, utilisé par un humain ou une machine. * **Utilisateur**: Client connecté pouvant être un navigateur, une application mobile, un logiciel, ou un IoT, utilisé par un humain ou une machine.
@ -45,8 +51,6 @@ Voir [_Doc_references.md](_Doc_references.md).
* **Third parties**:`adresse SP` complétant un `member` pour reconnaître d'autres dispositifs du `member`. * **Third parties**:`adresse SP` complétant un `member` pour reconnaître d'autres dispositifs du `member`.
* **KeyConfidential**: Clé AES-GCM-256 du Diffie-Hellman de la transaction Silent Payment correspondant à un RequestPrd.
* **ProcessKey**: la clé publique de chiffrement public d'un `ItemProcess` (dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément). * **ProcessKey**: la clé publique de chiffrement public d'un `ItemProcess` (dans un `ItemProcess`, 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é prive de spend de `recover` du signet, qui sert de référence pour l'identité. * **KeyRecover**: la clé prive de spend de `recover` du signet, qui sert de référence pour l'identité.