|
|
@ -42,21 +42,21 @@
|
|
|
|
/vscode-markdown-toc-config -->
|
|
|
|
/vscode-markdown-toc-config -->
|
|
|
|
<!-- /vscode-markdown-toc --># `RequestPrd` et `RequestPcd` - Specs
|
|
|
|
<!-- /vscode-markdown-toc --># `RequestPrd` et `RequestPcd` - 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 (`RequestPcd`) et Portable Request Document (`RequestPrd`) 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.
|
|
|
|
Le but de cette section est d'introduire les Portable Contract Document (`RequestPcd`) et Portable Request Document (`RequestPrd`) 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 `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>3. 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='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et RequestPrd
|
|
|
|
|
|
|
|
|
|
|
|
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
|
|
|
|
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
|
|
|
|
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
|
|
|
|
|
|
|
|
|
|
|
@ -64,7 +64,7 @@ Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l
|
|
|
|
|
|
|
|
|
|
|
|
**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
|
|
|
|
### 4.2. <a name='Rception'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
|
|
|
Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
|
|
|
|
|
|
|
|
|
|
@ -82,23 +82,23 @@ En cas de `RequestPcd` ou `RequestPrd` en relation via `RequestPcd_reference_has
|
|
|
|
|
|
|
|
|
|
|
|
Pour les `RequestPcd` et les `RequestPrd` 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é.
|
|
|
|
Pour les `RequestPcd` et les `RequestPrd` 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='FonctiondesRequestPcd'></a>Fonction des RequestPcd
|
|
|
|
## 5. <a name='FonctiondesRequestPcd'></a>Fonction des RequestPcd
|
|
|
|
|
|
|
|
|
|
|
|
Les Portable Contract Documents ( RequestPcd) 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 Portable Contract Documents ( RequestPcd) 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 `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés.
|
|
|
|
Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés.
|
|
|
|
|
|
|
|
|
|
|
|
### 5.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 5.1. <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 :
|
|
|
|
|
|
|
|
|
|
|
|
1. **Chargement de la dernière version de la liste ( RequestPcd)**: Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage.
|
|
|
|
1. Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage.
|
|
|
|
2. **Mise à jour**: Ajouts et modifications eventuelles des `Item`
|
|
|
|
2. 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)).
|
|
|
|
3. 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 RequestPcd**: 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.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 5.2. <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 :
|
|
|
|
|
|
|
|
|
|
|
@ -109,7 +109,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 les traitement des RequestPrd.
|
|
|
|
6. Mise à jour du cache pour les traitement des RequestPrd.
|
|
|
|
|
|
|
|
|
|
|
|
## 6. <a name='FonctiondesRequestPrd'></a>Fonction des RequestPrd
|
|
|
|
## 6. <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 demander 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 demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
|
|
|
|
|
|
|
|
|
|
@ -117,7 +117,7 @@ Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `
|
|
|
|
|
|
|
|
|
|
|
|
Les `RequestPrd` sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `RequestPrd` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
|
|
|
Les `RequestPrd` sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `RequestPrd` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
|
|
|
|
|
|
|
|
|
|
|
### 6.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 `RequestPrd`.
|
|
|
|
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 `RequestPrd`.
|
|
|
|
|
|
|
|
|
|
|
@ -142,23 +142,24 @@ 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`.
|
|
|
|
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.2. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 6.2. <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 :
|
|
|
|
|
|
|
|
|
|
|
|
1. **Chargement des clés de chiffrement confidentiel'**: Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd.
|
|
|
|
1. Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd.
|
|
|
|
2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
|
|
|
2. Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
|
|
|
3. **Création de l'adresse SP**: Création d'une`adresse SP` SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
|
|
|
3. Création d'une`adresse SP` SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
|
|
|
4. **Création du message**: Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet
|
|
|
|
4. Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet
|
|
|
|
5. **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.
|
|
|
|
5. Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées.
|
|
|
|
6. **Sélection des noeuds de signet pour la transaction silent Payment (SP) \***: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la`transaction SP`.
|
|
|
|
6. Sélection de 4 noeuds de signet pour l'envoi de la`transaction SP`.
|
|
|
|
7. **Chiffrement des données confidentielles du `request_prd`**: Chiffrement des données confidentielles du `request_prd` avec la `KeyConfidential` de la`transaction SP`.
|
|
|
|
7. Chiffrement des données confidentielles du `request_prd` avec la `KeyConfidential` de la`transaction SP`.
|
|
|
|
8. **Envoi du message**: Envoi du message aux relais
|
|
|
|
8. Envoi du message aux relais
|
|
|
|
9. **Envoi de la transaction**: envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la`transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
|
|
|
9. Envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la`transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
|
|
|
|
|
|
|
10. Mis à jour du cache avec les nouveaux `RequestPrd` envoyé (pas de mis en cache du `RequestPrdMessage`)
|
|
|
|
|
|
|
|
|
|
|
|
Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
|
|
|
Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
|
|
|
|
|
|
|
|
|
|
|
### 6.3. <a name='Rception-1'></a>Réception
|
|
|
|
### 6.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 :
|
|
|
|
|
|
|
|
|
|
|
@ -170,31 +171,30 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
|
|
|
6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci.
|
|
|
|
6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci.
|
|
|
|
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la`transaction SP` correspondante via hash du `RequestPrd` dans l'output `2` de la transaction.
|
|
|
|
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la`transaction SP` correspondante via hash du `RequestPrd` dans l'output `2` de la transaction.
|
|
|
|
8. Mise à jour du cache pour les traitement des RequestPrd.
|
|
|
|
8. Mise à jour du cache pour les traitement des RequestPrd.
|
|
|
|
9. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md).
|
|
|
|
9. Voir `RequestPrdConfirm` création et envoi (sauf pour les `RequestPrdConfirm` et les `RequestPrdKeyBackup` et les `RequestPrdMessage` ayant un `raw_transaction_list` non vide).
|
|
|
|
10. Traitements spécifiques au type de RequestPrd.
|
|
|
|
10. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md).
|
|
|
|
|
|
|
|
11. Traitements spécifiques au type de RequestPrd.
|
|
|
|
|
|
|
|
|
|
|
|
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd)
|
|
|
|
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd)
|
|
|
|
|
|
|
|
|
|
|
|
Utile pour les utilisateurs cherchant à 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, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
|
|
|
Utile pour les utilisateurs cherchant à 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, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
|
|
|
|
|
|
|
|
|
|
|
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList`.
|
|
|
|
1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` et envoi vers tous les `members` concernés par le `ItemProcess` pour le `Role` correspondant dans le `item_name`
|
|
|
|
|
|
|
|
2. Attente du `RequestPrdResponse` avec le `RequestPcd` demandés.
|
|
|
|
|
|
|
|
3. voir `RequestPrdResponse` réception.
|
|
|
|
|
|
|
|
4. Voir `RequestPcd` réception.
|
|
|
|
|
|
|
|
|
|
|
|
### 7.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 7.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
La réception d'un `RequestPrdList` suit plusieurs étapes :
|
|
|
|
La réception d'un `RequestPrdList` suit plusieurs étapes :
|
|
|
|
|
|
|
|
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la`transaction SP` associée avec
|
|
|
|
2. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
|
|
|
3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
|
|
|
3. Voir `RequestPcd` Création et envoi vers l'émetteur du `RequestPrdList`.
|
|
|
|
4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné.
|
|
|
|
|
|
|
|
5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdRResponse` avec :
|
|
|
|
|
|
|
|
5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash`
|
|
|
|
|
|
|
|
5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash`
|
|
|
|
|
|
|
|
6. Mise à jour du cache avec les nouveaux `RequestPcd` et `RequestPrdResponse` et `RequestPrdConfirm` envoyés.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
|
|
|
|
|
|
|
|
|
|
@ -204,21 +204,21 @@ Permet la communication des`transaction SP` au format `raw` dans l'attribut `raw
|
|
|
|
|
|
|
|
|
|
|
|
Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`.
|
|
|
|
Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`.
|
|
|
|
|
|
|
|
|
|
|
|
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage`.
|
|
|
|
1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` vers l'emméteur du `RequestPrdMessage`.
|
|
|
|
|
|
|
|
2. Attente du `RequestPrdMessage` éventuel (sauf en cas d'envoi d'une `transaction SP`).
|
|
|
|
|
|
|
|
3. Le cas échéant : voir `RequestPrdMessage` Réception
|
|
|
|
|
|
|
|
|
|
|
|
### 8.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 8.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
La réception d'un `RequestPrdMessage` suit plusieurs étapes :
|
|
|
|
La réception d'un `RequestPrdMessage` suit plusieurs étapes :
|
|
|
|
|
|
|
|
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`.
|
|
|
|
2. Notification et attente du retour de l'utilisateur (valeur de la signature et message de réponse)
|
|
|
|
3. Notificaiton et attente du retour de l'utilisateur (valeur de la signature et message de réponse)
|
|
|
|
3. Le cas échéant : voir `RequestPrdMessage` création et envoi vers l'emméteur du `RequestPrdMessage`.
|
|
|
|
4. Le cas échéant : création et envoi à l'émetteur du `RequestPrdMessage` d'un `RequestPrdMessage` avec :
|
|
|
|
|
|
|
|
5.1. le hash du `RequestPrdMessage` reçu dans l'attribut `request_prd_origin_hash`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
|
|
|
|
## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
|
|
|
|
|
|
|
|
|
|
|
|
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `RequestPcd`.
|
|
|
|
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `RequestPcd`.
|
|
|
|
|
|
|
|
|
|
|
@ -230,13 +230,23 @@ Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux ut
|
|
|
|
|
|
|
|
|
|
|
|
Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd.
|
|
|
|
Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd.
|
|
|
|
|
|
|
|
|
|
|
|
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate`.
|
|
|
|
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate`, création d'une nouvelle version de `RequestPcd` et envoi (vers tous les `members` concernés par le `ItemProcess` pour le `Role` correspondant dans le `item_name`)
|
|
|
|
|
|
|
|
2. Attente des `RequestPrdResponse` de l'ensemble des `members` concernés (`Role` correspondant dans le `ItemProcess` ).
|
|
|
|
|
|
|
|
3. Voir `RequestPrdResponse` Réception
|
|
|
|
|
|
|
|
4. Voir `RequestPcd` Réception.
|
|
|
|
|
|
|
|
|
|
|
|
### 9.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 9.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>RequestPrdConfirm - Confirmation de Réception
|
|
|
|
|
|
|
|
|
|
|
|
La réception d'un `RequestPrdUpdate` suit plusieurs étapes :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
|
|
|
|
2. Notification et attente du retour de l'utilisateur (valeur de la signature et message de réponse)
|
|
|
|
|
|
|
|
3. Voir `RequestPrdResponse` création et envoi vers tous les membres de tous les roles du `ItemProcess`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
@ -244,13 +254,15 @@ 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, à confirmer 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, à confirmer dans le RequestPrdConfirm.
|
|
|
|
|
|
|
|
|
|
|
|
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm`.
|
|
|
|
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` envoi vers l'emméteur du `RequestPrd`.
|
|
|
|
|
|
|
|
|
|
|
|
### 10.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 10.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - Répondre à une Demande
|
|
|
|
Traitements des `RequestPrd`, pas de traitement suppplémentaire.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 11. <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.
|
|
|
|
|
|
|
|
|
|
|
@ -260,37 +272,42 @@ 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.
|
|
|
|
Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions.
|
|
|
|
|
|
|
|
|
|
|
|
### 11.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 11.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse`.
|
|
|
|
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` et envoi en fonction du type de `RequestPrd` d'origine.
|
|
|
|
|
|
|
|
2. Pas de traitement supplémentaire.
|
|
|
|
|
|
|
|
|
|
|
|
### 11.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 11.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
## 12. <a name='RequestPrdKeyHelloBakcup'></a>RequestPrdKeyHelloBakcup
|
|
|
|
1. Traitements des `RequestPrd`
|
|
|
|
|
|
|
|
2. Notification de l'utilisateur.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 12. <a name='RequestPrdKeyHelloBakcup'></a>RequestPrdKeyBakcup
|
|
|
|
|
|
|
|
|
|
|
|
Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` .
|
|
|
|
Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` .
|
|
|
|
|
|
|
|
|
|
|
|
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse`.
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse`.
|
|
|
|
|
|
|
|
|
|
|
|
### 12.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 12.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
|
|
|
|
|
|
|
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello`.
|
|
|
|
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello`.
|
|
|
|
|
|
|
|
|
|
|
|
### 13.2. <a name='Rception-1'></a>Réception
|
|
|
|
### 13.2. <a name='Rception-1'></a>Réception
|
|
|
|
|
|
|
|
|
|
|
|
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
|
|
|
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
|
|
|
|
|
|
|
|
|
|
|
## 15. <a name='Todo'></a>Todo
|
|
|
|
## 15. <a name='Todo'></a>Todo
|
|
|
|
|
|
|
|
|
|
|
|
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
|
|
|
* [ ] Ajouter un tableau : transaction SP, confirmation attendue, réponse attendue, création vers, réponse vers.
|
|
|
|
|
|
|
|
* [ ] Compléter RequestPrdKeyHelloBakcup et RequestPrdKeyHello
|
|
|
|
* [ ] Diagrammes de séquences
|
|
|
|
* [ ] Diagrammes de séquences
|
|
|
|