Definitions added (doc)
This commit is contained in:
parent
86dbd2ec4b
commit
4f82a6e733
@ -1,41 +1,43 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 4. [Commun aux `RequestPcd` et RequestPrd](#CommunauxRequestPcdetRequestPrd)
|
||||
* 4.1. [Création et envoi](#Crationetenvoi)
|
||||
* 4.2. [Réception](#Rception)
|
||||
* 5. [Fonction des RequestPcd](#FonctiondesRequestPcd)
|
||||
* 5.1. [Schéma des flux](#Schmadesflux)
|
||||
* 5.2. [Création et envoi](#Crationetenvoi-1)
|
||||
* 5.3. [Réception](#Rception-1)
|
||||
* 6. [Fonction des RequestPrd](#FonctiondesRequestPrd)
|
||||
* 6.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 6.2. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
|
||||
* 6.3. [Création et envoi](#Crationetenvoi-1)
|
||||
* 6.4. [Réception](#Rception-1)
|
||||
* 7. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd)
|
||||
* 7.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 7.2. [Création : Datas spécifiques](#Cration:Datasspcifiques)
|
||||
* 7.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques)
|
||||
* 8. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Encryption](#Encryption)
|
||||
* 5. [Définitions](#Dfinitions)
|
||||
* 6. [Principe de messagerie](#Principedemessagerie)
|
||||
* 6.1. [Création et envoi](#Crationetenvoi)
|
||||
* 6.2. [Réception](#Rception)
|
||||
* 7. [Fonction des RequestPcd](#FonctiondesRequestPcd)
|
||||
* 7.1. [Schéma des flux](#Schmadesflux)
|
||||
* 7.2. [Création et envoi](#Crationetenvoi-1)
|
||||
* 7.3. [Réception](#Rception-1)
|
||||
* 8. [Fonction des`RequestPrd`](#FonctiondesRequestPrd)
|
||||
* 8.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 8.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 8.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 9. [RequestPrdUpdate - Mises à Jour de RequestPcd](#RequestPrdUpdate-MisesJourdeRequestPcd)
|
||||
* 8.2. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
|
||||
* 8.3. [Création et envoi](#Crationetenvoi-1)
|
||||
* 8.4. [Réception](#Rception-1)
|
||||
* 9. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd)
|
||||
* 9.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 9.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 9.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 10. [RequestPrdConfirm - Confirmation de Réception](#RequestPrdConfirm-ConfirmationdeRception)
|
||||
* 9.2. [Création : Datas spécifiques](#Cration:Datasspcifiques)
|
||||
* 9.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques)
|
||||
* 10. [RequestPrdMessage - Envoi de Messages](#RequestPrdMessage-EnvoideMessages)
|
||||
* 10.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 10.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 10.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 11. [RequestPrdResponse - Répondre à une Demande](#RequestPrdResponse-RpondreuneDemande)
|
||||
* 11. [RequestPrdUpdate - Mises à Jour de RequestPcd](#RequestPrdUpdate-MisesJourdeRequestPcd)
|
||||
* 11.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 11.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 11.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 12. [Exemples de Code](#ExemplesdeCode)
|
||||
* 13. [Todo](#Todo)
|
||||
* 12. [RequestPrdConfirm - Confirmation de Réception](#RequestPrdConfirm-ConfirmationdeRception)
|
||||
* 12.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 12.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 12.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 13. [RequestPrdResponse - Répondre à une Demande](#RequestPrdResponse-RpondreuneDemande)
|
||||
* 13.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 13.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1)
|
||||
* 13.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1)
|
||||
* 14. [Exemples de Code](#ExemplesdeCode)
|
||||
* 15. [Todo](#Todo)
|
||||
|
||||
# `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.
|
||||
|
||||
## 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).
|
||||
|
||||
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et `RequestPrd`
|
||||
## 4. <a name='Encryption'></a>Encryption
|
||||
|
||||
Encryption :
|
||||
Schema :
|
||||
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
### 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.
|
||||
|
||||
@ -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).
|
||||
|
||||
### 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.
|
||||
|
||||
@ -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é.
|
||||
|
||||
## 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 `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
|
||||
|
||||
|
||||
|
||||
### 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 :
|
||||
|
||||
@ -115,7 +140,7 @@ La création d'un `RequestPcd` suit plusieurs étapes :
|
||||
4. Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
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 :
|
||||
|
||||
@ -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`.
|
||||
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.
|
||||
|
||||
@ -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.
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
|
||||
@ -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`.
|
||||
|
||||
### 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 :
|
||||
|
||||
@ -190,7 +215,7 @@ Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
||||
| `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 |
|
||||
|
||||
### 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 :
|
||||
|
||||
@ -214,23 +239,23 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
| `RequestPrdResponse` | Info | Yes | 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.
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
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.
|
||||
|
||||
### 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 :
|
||||
|
||||
@ -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éé.
|
||||
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.
|
||||
|
||||
@ -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`).
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
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`
|
||||
|
||||
## 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`.
|
||||
|
||||
@ -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`.
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
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 :
|
||||
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
@ -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`.
|
||||
|
||||
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 12.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
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.
|
||||
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.
|
||||
|
||||
@ -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.
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
### 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`.
|
||||
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.
|
||||
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`.
|
||||
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`.
|
||||
|
||||
## 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’
|
||||
[ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’:
|
||||
|
||||
@ -20,17 +20,23 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
## 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.
|
||||
* **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.
|
||||
|
||||
* **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.
|
||||
|
||||
* **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`.
|
||||
|
||||
* **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é.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user