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

Messages-SP-Specs.md

Browse Source
This commit is contained in:
NicolasCantu 2024-02-12 17:57:54 +01:00
parent 4a46351f95
commit 4429049129
3 changed files with 73 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/Doc_references.md
View File

@ -20,6 +20,7 @@
## 2. <a name='Transverse'></a>Transverse
* **Datamodel**: [Specs-Datamodel.md](Specs-Datamodel.md)
* **Définitions et abréviations.**: [Specs-Definition.md]
* **Exigences de sécurité**: [Specs-Security.md](Specs-Security.md)
* **Code**: [Specs-Code.md]

281
doc/Messages-SP-Specs.md
View File

@ -2,17 +2,20 @@
* 1. [Objectif](#Objectif)
* 2. [Portée](#Porte)
* 3. [3. Documents de référence](#Documentsderfrence)
* 3.1. [Worfklows](#Worfklows)
* 3.2. [Transverse](#Transverse)
* 4. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
* 5. [Connexion via des tiers](#Connexionviadestiers)
* 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
* 7. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
* 8. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
* 8.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
* 8.1.1. [HD Wallet (BIP32 + BIP44)](#HDWalletBIP32BIP44)
* 8.1.2. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
* 9. [Exemples de Code](#ExemplesdeCode)
* 4. [Taille des données](#Tailledesdonnes)
* 5. [Preuve de travail](#Preuvedetravail)
* 6. [Récupération et choix des relais](#Rcuprationetchoixdesrelais)
* 7. [Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais](#RcuprationdesUTXOpourlesadressesSilentPaymentSPdepuislefaucetdeswalletsdesrelais)
* 8. [Connexion au réseau de relais via les messages de type `MessageConnect`](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnect)
* 9. [Broadcast des messages de type `MessageConnect` vers les relais](#BroadcastdesmessagesdetypeMessageConnectverslesrelais)
* 10. [Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage)
* 11. [Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage)
* 12. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
* 13. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
* 14. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
* 15. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
* 16. [Génération des adresses SP](#GnrationdesadressesSP)
* 17. [Exemples de Code](#ExemplesdeCode)
<!-- vscode-markdown-toc-config
numbering=true
@ -26,68 +29,90 @@
## 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='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
# Variable `SharedPeerList` du SDK (Wasm)
Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `process`.
La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, c'est la première liste disponible, en dur fournie par le relais sur lequel on est connecté.
Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payment pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties`.
# Structure du stockage en cache des relais
Les utilisateurs sont reconnus par une adresse Silent Payment dans un ou plusieurs rôles dans un process. Ces process préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`.
Le cache est constitué de 2 parties :
Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par process dans lequel l'utilisateur a un rôle (`onboarding`).
1. `public` :
1.1. Liste des relais partagée avec les relais (aggrée au fil des relais découverts par le partage des listes de relais dans les messages).
2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné)
2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
2. `private` :
2.1. Liste des relais non partagés (aggrégée à partir de relais communiqués de façon confidentielle).
2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné)
2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
## 5. <a name='Connexionviadestiers'></a>Connexion via des tiers
Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience utilisateur.
Les relais sont ainsi partagés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`.
# Caractéristiques générales des messages de type `Message` et de type `MessageConnect`
## 6. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
## 4. <a name='Tailledesdonnes'></a>Taille des données
En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis.
## 5. <a name='Preuvedetravail'></a>Preuve de travail
Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux PCD et PRD correspondants.
## Partage de la liste de relais
## 7. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
## Parage de la liste de process
Le système ne maintiendra pas de session traditionnelle sur le serveur. La navigation de l'utilisateur persiste grâce à un cache local dans IndexedDB ou en mémoire, avec une politique de sécurité stricte forçant la resaisie du mot de passe après un rafraîchissement de la page ou une inactivité prolongée, déterminée par une durée maximale sans login.
# Connexion d'un client à sa liste relais via les messages de type `MessageConnect`
## 8. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
## 6. <a name='Rcuprationetchoixdesrelais'></a>Récupération et choix des relais
### 8.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
Afin de pouvoir discuter avec les relais du réseau et faire relayer des `PCD` et des `PRD` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, 4 par défaut.
#### 8.1.1. <a name='HDWalletBIP32BIP44'></a>HD Wallet (BIP32 + BIP44)
L'utilisateur enverra un message de type `MessageConnect` à chaque relais pour se connecter. Puis il pourra envoyer des`Message` à chacun des 4 relais connectés et recevoir des `Message` de chacun des 4 relais connectés.
Les transactions SP ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) :
Ainsi il y a des doubles des messages pour chaque relais à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience. A ce stade l'arbitrage repose sur une réponse devant satisfaire au moins 80% de même réponse que des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache.
* **Clé de dépense** : la clé qui prouve sa détention par la capacité de dépenser un UTXO d'une transaction SP.
* **Clé de scan** : la clé qui permet de détecter qu'une transaction SP nous est destinée.
Pour s'y connecter l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis la liste de relais non partagée `private` du cache et depuis la liste de relais non partagée `public` du cache.
Il y a 3 paires de ces clés privées :
Un ping est réalisé sur chaque relais pour vérifier leur disponibilité et l'on choisit les 4 premiers relais disponibles. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings).
* **2 paires pour les données exif de l'image de login** : l'une pour les transactions sur le signet, l'autre pour le mainnet.
* **1 paire pour les données exif de l'image de révocation** : pour les transactions de révocation sur le signet.
Les relais dits "navigators" ont un nom de domaine et un certificat SSL afin de satisfaires aux exigences de sécurité des navigateurs. Les autres relais n'ont pas de nom spécifique et n'ont pas nécessairement de nom de domaine et de certificat SSL, ils sont utilisés pour relayer les messages entre les relais.
Techniquement ces clés sont identiques et générées de la même manière.
Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` ou `wss://`) et les messages sont en JSON.
Chaque clé possède un chemin de dérivation spécifique et propre à son réseau (`/0` pour le mainnet, `/44` pour le signet).
## 7. <a name='RcuprationdesUTXOpourlesadressesSilentPaymentSPdepuislefaucetdeswalletsdesrelais'></a>Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais
Afin de constituer un portefeuille unique de clés du signet et du mainnet on génère un HD Wallet.
Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, lors de la réception d'un message de type `MessageConnect` ou de type `Message` par un relais, ce relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis ces clés privées et transmise via un message de type `MessageConnect` ou de type `Message`).
L'aléatoire pour la génération des clés est critique, et il convient de choisir un aléatoire fourni par une librairie de référence (`rand` pour le Rust).
# Traitement des messages de type `MessageConnect` par les relais
Dans l'ordre on génère donc :
## 8. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnect'></a>Connexion au réseau de relais via les messages de type `MessageConnect`
1. Clé privée de dépense du login du signet `spend_recover`.
2. Clé privée de scan du login du signet `scan_recover`.
3. Clé privée de dépense de révocation du signet `spend_revoke`.
4. Clé privée de scan de révocation du signet `scan_revoke`.
5. Clé privée de dépense mainnet `spend_mainnet`.
6. Clé privée de scan du mainnet `scan_mainnet`.
## 9. <a name='BroadcastdesmessagesdetypeMessageConnectverslesrelais'></a>Broadcast des messages de type `MessageConnect` vers les relais
##### Génération des adresses SP
# Traitement des messages de type `Message` par les relais
## 10. <a name='EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PCD sur les relais via les messages de type `Message`
## 11. <a name='EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PRD sur les relais via les messages de type `Message`
## 12. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>Broadcast des messages de type `Message` vers les relais
## 13. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>Broadcast des messages de type `Message` vers les clients connectés
# Connexion au réseau de nodes de side chain
# Connexion au réseau de nodes de layer 1
# Horodatage et ancrage des PRD via les transactions Silent Payment (SP)
# Transactions mainnet Bitcoin
## 14. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Horodatage et ancrage des blocs de la side chain sur Bitcoin
## 15. <a name='RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin
## 16. <a name='GnrationdesadressesSP'></a>Génération des adresses SP
Le relais partage leur liste de relais au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedPeer`.
@ -124,168 +149,6 @@ Puis on génère les adresses SP :
2. Adresse `id_SP` de révocation du signet depuis `spend_revoke` et `scan_revoke` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de révocation du signet.
3. Adresse `id_SP` du mainnet depuis `spend_mainnet` et `scan_mainnet` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` du mainnet.
##### Clés de dépense du signet du login
Le relais partage leur liste de process au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedProcess`.
La clé privée de dépense du signet du login est la clé principale pour forger les identités.
Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Voici les principales étapes :
1. Cette clé sera scindée en 2 parties (à la moitié de la longueur de leur représentation hexadécimale) :
1.1. `Part1`, c'est la partie qui sera chiffrée (AES-GCM 256 bits) par le mot de passe et stockée en cache dans une image dite de login.
1.2. `Part2`, c'est la partie qui sera décomposée par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres du process.
2. Une `préimage Part1EncHash` qui identifie l'utilisateur est générée par le hash (SHA 256) de la `Part1` et du mot de passe de l'utilisateur.
3. Création d'un `PRDKeyBackup` par membre (1 shard par membre), par PRD :
3.1. Génération d'une clé de chiffrement dite `sp_shared_secret` qui sera transmise dans le Diffie-Hellman de la transaction SP.
3.2. Définition de l'attribut `device_footprint_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
3.3. Définition de l'attribut `part_1_enc_hash_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
3.4. Définition de l'attribut `shard_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
4. Création des messages de type `Message` correspondant aux PRD, envoi des messages aux relais connectés.
Dans l'ordre on réalise donc les opérations suivantes donc :
1. Split de `spend_recover`.
2. Chiffrement AES de `Part1`.
3. Mise en cache de `Part1Enc`.
4. Création de la préimage
5. Chiffrement AES de `Part2`.
6. Sharding de `Part2Enc`.
Puis (exemple avec 2 membres) :
1. Création de `PRDKeyBackup` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
2. Création de `PRDKeyBackup` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
3. Création de `Message` du `PRDKeyBackup` à destination de membre 1.
4. Création de `Message` du `PRDKeyBackup` à destination de membre 2.
5. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 1.
6. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 1.
8. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 2.
9. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 3.
10. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 4.
11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 1.
12. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 2.
13. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 3.
14. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 4.
##### Étape d'`update` et envoi de l'objet `ItemMember` pour `Onboarding`
Pour être `onboard` dans un process, c'est-à-dire avoir un rôle, il faut s'ajouter dans la liste des membres du process.
Cela signifie envoyer un `PRDUpdate` avec une nouvelle version du PCD de la liste des membres, contenant notre objet `ItemMember` complet. Ce PRD devra recevoir des membres du rôle `Member` du process les `PRDResponse` correspondant aux critères de validation du `process`.
C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que donnée privée (chiffrée par la clé de dépense du signet) dans un PCD (et les `PRDUpdate` correspondant).
Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet.
Avant de choisir un process pour continuer l'update de la nouvelle identité :
1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyBackup`.
3. Attente et réception des `pcd_reference_hash` des `PRDResponse` reçus avec le PCD des membres du processus (liste de `itemMember`).
4. Recomposition de la clé selon :
4.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
4.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
4.3 Recomposition de `Part2Enc` et déchiffrement par le mot de passe
4.4 Concaténation de `Part1` et `Part2`
Demande d'update de la liste des membres (PCD) d'un process (exemple avec 2 membres):
1. Création et envoi des `PRDKeyHello`.
1.1. Création de `PRDKeyHello` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
1.2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
1.3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
1.4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
1.5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
1.6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
1.7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
1.8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
1.9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
1.10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
1.11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
1.12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
1.13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
1.14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
2. Réception des `PRDResponse` en réponse aux `PRDKeyHello` et mise à jour des listes depuis les `PCD` correspondants.
3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
4. Création d'une nouvelle version du PCD avec l'ajout de l'`ItemMember` créé.
5. Parcours des membres du rôle `Member` et envoi des `PRDUpdate`.
6. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
7. Redirection vers la page du process sur le relai.
##### Clés de révocation (`revoke`)
Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif.
L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `PRDKeyBackup` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface).
##### Clés de third parties
En plus, on peut générer d'autres paires de clés de dépense et de scan qui seront à exporter vers d'autres dispositifs pour du 2FA, avec leurs UTXO.
Pour cela, il faut se connecter aux relais avec les adresses de faucet de ces nouvelles clés (adresses publiques classiques générées depuis ces clés privées). Comme pour les clés de `recover` et de `revoke`.
Les adresses SP de ces clés sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
Ces clés sont générées lors de l'update d'un membre, avec déjà une identité créée sur un process, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les PRD concernés.
#### 8.1.2. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
Comme pour la création de compte, les relais partagent leur liste de relais et de process au setup du SDK (Wasm), ces listes sont stockées en cache sous forme d'objets `SharedPeer` et `SharedProcess`.
Afin d'obtenir de nouveaux UTXO indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
Dans l'ordre on réalise les opérations suivantes :
1. Récupération de Part1Enc en cache
2. Création de la pré-image avec le mot de passe
Puis :
1. Création de `PRDKeyHello` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyHello`.
3. Attente et réception des `pcd_reference_hash` des `PRDResponse` reçus avec le PCD des membres du processus (liste de `itemMember`).
4. Recomposition de la clé selon :
4.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
4.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
4.3 Recomposition de `Part2Enc` et déchiffrement par le mot de passe
4.4 Concaténation de `Part1` et `Part2`
Demande d'update de la liste des membres (PCD) d'un process :
1. Création et envoi des `PRDList`.
2. Réception des `PRDResponse` en réponse aux `PRDList` et mise à jour des listes depuis les `PCD` correspondants.
3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
4. Création d'une nouvelle version du PCD avec l'ajout de l'`ItemMember` créé.
5. Redirection vers la page du process sur le relai.
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
## 17. <a name='ExemplesdeCode'></a>Exemples de Code
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.

0
doc/Specs-Datas.md → doc/Specs-Datamodel.md
View File