doc added
This commit is contained in:
parent
984fdb99db
commit
12a6e54f26
347
doc/Auth-Specs.md
Normal file
347
doc/Auth-Specs.md
Normal file
@ -0,0 +1,347 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Définitions et Abréviations](#DfinitionsetAbrviations)
|
||||
* 4. [Exigences de sécurité et de confidentialité](#Exigencesdescuritetdeconfidentialit)
|
||||
* 5. [Architecture générale](#Architecturegnrale)
|
||||
* 6. [Spécification des items](#Spcificationdesitems)
|
||||
* 7. [Spécification des roles](#Spcificationdesroles)
|
||||
* 8. [Spécifiation des PCD et PRD](#SpcifiationdesPCDetPRD)
|
||||
* 9. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
|
||||
* 10. [Connexion via des tiers](#Connexionviadestiers)
|
||||
* 11. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
|
||||
* 12. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
|
||||
* 13. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
|
||||
* 13.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
|
||||
* 13.1.1. [HD Wallet (BIP32 + BIP44)](#HDWalletBIP32BIP44)
|
||||
* 13.1.2. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
|
||||
* 13.1.3. [Workflow des PRD et PCD](#WorkflowdesPRDetPCD)
|
||||
* 13.1.4. [Workflow des Messages, transactions SP et connexion aux web sockets](#WorkflowdesMessagestransactionsSPetconnexionauxwebsockets)
|
||||
* 14. [Spécifications du code](#Spcificationsducode)
|
||||
* 14.1. [Maintenance, environnement de déploiement](#Maintenanceenvironnementdedploiement)
|
||||
* 15. [Annexe](#Annexe)
|
||||
* 15.1. [Exemples de code](#Exemplesdecode)
|
||||
* 15.2. [Références](#Rfrences)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Auth - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
Développer un système de login sécurisé utilisant les clés cryptographiques de Bitcoin et sa timechain (via un réseau Signet personnalisé, appelé "side chain") ainsi qu'un système de relais de messages entre parties prenantes. Le concept de Silent Payment est employé pour authentifier les utilisateurs sans réutilisation d'adresses, tout en utilisant une approche de calcul multipartite (MPC) pour une gestion sécurisée et distribuée des clés. Déployer une interface de login conforme aux [wireframes](https://cryptpad.fr/diagram/#/2/diagram/view/GbkNsP8MEh2oSM5442jC9ONiNZhYZvfeWUVEmiIjXHk).
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
Ce système couvrira la conception et le développement de l'architecture d'authentification, incluant la génération, la gestion, et la validation des identités numériques à travers des formats de conformité spécifiques (Portable Contract Document et Portable Request Document). Il intégrera également l'authentification des utilisateurs, la connexion via des tiers, la récupération d'identités, et une gestion de session basée sur un cache avec des contraintes de sécurité renforcées. La solution sera conçue pour des environnements hautement sécurisés, nécessitant une haute disponibilité, performance, et évolutivité.
|
||||
|
||||
## 3. <a name='DfinitionsetAbrviations'></a>Définitions et Abréviations
|
||||
|
||||
Voir Specs - Définitions et abréviations.
|
||||
|
||||
## 4. <a name='Exigencesdescuritetdeconfidentialit'></a>Exigences de sécurité et de confidentialité
|
||||
|
||||
Voir Specs - Exigences de sécurité
|
||||
|
||||
## 5. <a name='Architecturegnrale'></a>Architecture générale
|
||||
|
||||
Diagramme d'architecture montrant les composants principaux du système de login.
|
||||
[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
|
||||
|
||||
## 6. <a name='Spcificationdesitems'></a>Spécification des items
|
||||
|
||||
Voir Item - Specs
|
||||
|
||||
## 7. <a name='Spcificationdesroles'></a>Spécification des roles
|
||||
|
||||
Voir Voir Item - Specs
|
||||
|
||||
## 8. <a name='SpcifiationdesPCDetPRD'></a>Spécifiation des PCD et PRD
|
||||
|
||||
Voir Voir PRD et PCD - Specs
|
||||
|
||||
## 9. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
|
||||
|
||||
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`.
|
||||
|
||||
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`.
|
||||
|
||||
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`.
|
||||
|
||||
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`).
|
||||
|
||||
## 10. <a name='Connexionviadestiers'></a>Connexion via des tiers
|
||||
|
||||
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.
|
||||
|
||||
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`.
|
||||
|
||||
## 11. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
## 12. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
|
||||
|
||||
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.
|
||||
|
||||
## 13. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
|
||||
|
||||
### 13.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
|
||||
|
||||
#### 13.1.1. <a name='HDWalletBIP32BIP44'></a>HD Wallet (BIP32 + BIP44)
|
||||
|
||||
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) :
|
||||
|
||||
* **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.
|
||||
|
||||
Il y a 3 paires de ces clés privées :
|
||||
|
||||
* **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.
|
||||
|
||||
Techniquement ces clés sont identiques et générées de la même manière.
|
||||
|
||||
Chaque clé possède un chemin de dérivation spécifique et propre à son réseau (`/0` pour le mainnet, `/44` pour le signet).
|
||||
|
||||
Afin de constituer un portefeuille unique de clés du signet et du mainnet on génère un HD Wallet.
|
||||
|
||||
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).
|
||||
|
||||
Dans l'ordre on génère donc :
|
||||
|
||||
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`.
|
||||
|
||||
##### 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`.
|
||||
|
||||
Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
|
||||
|
||||
Ces relais envoient 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).
|
||||
|
||||
Avec ces `UTXO` et les clés de dépense et de scan, on génère 1 `adresse SP` pour le réseau signet et 1 pour le réseau mainnet et chacun pour leurs clés de login et de révocation.
|
||||
|
||||
Dans l'ordre on génère donc :
|
||||
|
||||
1. Adresse `faucet_sp_address` de login du signet.
|
||||
2. Adresse `faucet_sp_address` de révocation du signet.
|
||||
3. Adresse `faucet_sp_address` du mainnet.
|
||||
|
||||
Puis on se connecte aux relais selon (on se connecte à plusieurs relais afin de pallier aux indisponibilités éventuelles ou au manque de jetons éventuel sur le relai) :
|
||||
|
||||
1. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de login du signet.
|
||||
2. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de révocation du signet.
|
||||
3. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` du mainnet.
|
||||
4. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de login du signet.
|
||||
5. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de révocation du signet.
|
||||
6. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` du mainnet.
|
||||
7. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de login du signet.
|
||||
8. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de révocation du signet.
|
||||
9. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` du mainnet.
|
||||
10. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de login du signet.
|
||||
11. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de révocation du signet.
|
||||
12. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` du mainnet.
|
||||
|
||||
Puis on génère les adresses SP :
|
||||
|
||||
1. Adresse `id_SP` de login du signet depuis `spend_recover` et `scan_recover` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de login du signet.
|
||||
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.
|
||||
|
||||
#### 13.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.
|
||||
|
||||
#### 13.1.3. <a name='WorkflowdesPRDetPCD'></a>Workflow des PRD et PCD
|
||||
|
||||
Voir PRD et PCD - Specs.
|
||||
|
||||
#### 13.1.4. <a name='WorkflowdesMessagestransactionsSPetconnexionauxwebsockets'></a>Workflow des Messages, transactions SP et connexion aux web sockets
|
||||
|
||||
Voir Specs - Messages et transactions SP.
|
||||
|
||||
## 14. <a name='Spcificationsducode'></a>Spécifications du code
|
||||
|
||||
Voir Specs - Code
|
||||
|
||||
### 14.1. <a name='Maintenanceenvironnementdedploiement'></a>Maintenance, environnement de déploiement
|
||||
|
||||
Voir Specs - Maintenance, environnement de déploiement
|
||||
|
||||
## 15. <a name='Annexe'></a>Annexe
|
||||
|
||||
### 15.1. <a name='Exemplesdecode'></a>Exemples de code
|
||||
|
||||
Extraits de code illustrant des aspects clés du système de login, tels que le hashing de mot de passe, ou la configuration du middleware de sécurité.
|
||||
|
||||
### 15.2. <a name='Rfrences'></a>Références
|
||||
|
||||
Voir Specs - References
|
||||
103
doc/Item-Specs.md
Normal file
103
doc/Item-Specs.md
Normal file
@ -0,0 +1,103 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Définitions et Abréviations](#DfinitionsetAbrviations)
|
||||
* 4. [Exigences de sécurité et de confidentialité](#Exigencesdescuritetdeconfidentialit)
|
||||
* 5. [Architecture générale](#Architecturegnrale)
|
||||
* 5.1. [Types d'Items](#TypesdItems)
|
||||
* 5.2. [Composition et Fonction](#CompositionetFonction)
|
||||
* 5.2.1. [Cas d'utilisation](#Casdutilisation)
|
||||
* 5.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems)
|
||||
* 5.3.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 5.3.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 6. [ItemProcess](#ItemProcess)
|
||||
* 7. [Spécifications du code](#Spcificationsducode)
|
||||
* 7.1. [Maintenance, environnement de déploiement](#Maintenanceenvironnementdedploiement)
|
||||
* 8. [Annexe](#Annexe)
|
||||
* 8.1. [Exemples de Code](#ExemplesdeCode)
|
||||
* 8.2. [Références](#Rfrences)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Item - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
## 3. <a name='DfinitionsetAbrviations'></a>Définitions et Abréviations
|
||||
|
||||
Voir Specs - Définitions et abréviations.
|
||||
|
||||
## 4. <a name='Exigencesdescuritetdeconfidentialit'></a>Exigences de sécurité et de confidentialité
|
||||
|
||||
Voir Specs - Exigences de sécurité
|
||||
|
||||
## 5. <a name='Architecturegnrale'></a>Architecture générale
|
||||
|
||||
Diagramme d'architecture montrant les composants principaux du système de login.
|
||||
[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
|
||||
|
||||
### 5.1. <a name='TypesdItems'></a>Types d'Items
|
||||
|
||||
Dans le système 4NK, les items représentent les entités ou les objets appelés `Item` sur lesquels les transactions, les processus, et les interactions sont basés. Les types d'`items` incluent :
|
||||
|
||||
* **Process**: Définit un ensemble de règles et de procédures pour gérer des interactions spécifiques au sein du réseau.
|
||||
* **Member**: Représente les utilisateurs ou entités participant à un processus.
|
||||
* **Peer**: Identifie les nœuds ou participants du réseau qui aident à faciliter les communications et les transactions.
|
||||
* **Artefact** : Un type d'objet générique personnalisable dans les `process`, il peut y avoir une quantité infinie de type d'`artefacts` différents par process.
|
||||
* **Payment, Deposit, Commitment**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques.
|
||||
|
||||
### 5.2. <a name='CompositionetFonction'></a> Composition et Fonction
|
||||
|
||||
* **uuid**: Identifiant unique de l'item, assurant sa traçabilité et son unicité au sein du système.
|
||||
* **version**: Numéro de version de l'item, facilitant le suivi des mises à jour et des modifications.
|
||||
* **hash**: Optionnel, fournit un hash de l'item pour vérifier son intégrité et son authenticité.
|
||||
* **item_type**: Catégorie ou type de l'item, tel que Process, Member, Payment, qui détermine son rôle et son utilisation dans le réseau.
|
||||
* **name**: Nom ou description de l'item, offrant un moyen de le référencer ou de l'identifier de manière lisible.
|
||||
* **pagination_number_per_pcd**: Détermine comment l'item est paginé ou divisé dans le contexte des PCD, affectant la manière dont il est présenté ou accessible.
|
||||
* **metadata**: Comprend MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate, encapsulant les attributs de l'item selon différents niveaux de confidentialité.
|
||||
|
||||
#### 5.2.1. <a name='Casdutilisation'></a>Cas d'utilisation
|
||||
|
||||
Les items sont utilisés pour tout, depuis la représentation des participants et des ressources dans le système jusqu'à la structuration des contrats et des processus. Ils sont essentiels pour organiser et gérer efficacement les données et les interactions au sein du réseau 4NK.
|
||||
|
||||
### 5.3. <a name='MetaData-GestiondesAttributsdItems'></a>MetaData - Gestion des Attributs d'Items
|
||||
|
||||
La structure MetaData joue un rôle crucial dans la définition des attributs et des caractéristiques des items, enrichissant leur définition et leur utilité au sein du système.
|
||||
|
||||
#### 5.3.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
|
||||
* **tag_list**, **zone_list**, **label_list**, **ref_list**, **data_list**: Collections d'étiquettes, zones, labels, références, et données associées à l'item, permettant une classification et une organisation détaillées.
|
||||
* **amount**, **number**: Champs numériques pour représenter des quantités ou des valeurs associées à l'item, utilisés dans divers contextes comme le suivi des ressources ou la définition des conditions.
|
||||
* **render_template_list**, **legal_text_list**: Fournissent des templates pour la présentation de l'item et des textes légaux associés, cruciaux pour la documentation et la conformité.
|
||||
* **key_list**: Liste des clés de chiffrement ou d'autres clés cryptographiques associées à l'item, essentielles pour la sécurité et l'authentification.
|
||||
|
||||
#### 5.3.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
|
||||
La richesse et la diversité des métadonnées permettent une personnalisation et une spécification précises des items, soutenant des processus complexes, des contrats détaillés, et des interactions sécurisées au sein du réseau.
|
||||
|
||||
## 6. <a name='ItemProcess'></a>ItemProcess
|
||||
|
||||
* **item**: Base de l'ItemProcess, liant les processus aux items spécifiques au sein du système.
|
||||
* **item_process_public_attribute_group**: Groupe d'attributs publics associés à un processus, définissant les règles, les rôles et les conditions d'exécution du processus.
|
||||
|
||||
## 7. <a name='Spcificationsducode'></a>Spécifications du code
|
||||
|
||||
Voir Specs - Code
|
||||
|
||||
### 7.1. <a name='Maintenanceenvironnementdedploiement'></a>Maintenance, environnement de déploiement
|
||||
|
||||
Voir Specs - Maintenance, environnement de déploiement
|
||||
|
||||
## 8. <a name='Annexe'></a>Annexe
|
||||
|
||||
### 8.1. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
|
||||
|
||||
### 8.2. <a name='Rfrences'></a>Références
|
||||
|
||||
Voir Specs - References
|
||||
253
doc/PRD-PCD-Specs.md
Normal file
253
doc/PRD-PCD-Specs.md
Normal file
@ -0,0 +1,253 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Définitions et Abréviations](#DfinitionsetAbrviations)
|
||||
* 4. [Exigences de sécurité et de confidentialité](#Exigencesdescuritetdeconfidentialit)
|
||||
* 5. [Architecture générale](#Architecturegnrale)
|
||||
* 6. [Spécification des items](#Spcificationdesitems)
|
||||
* 7. [Spécification des process et roles](#Spcificationdesprocessetroles)
|
||||
* 7.1. [Structure des PCD et PRD et de leur attribut générique Request](#StructuredesPCDetPRDetdeleurattributgnriqueRequest)
|
||||
* 7.2. [Structure et Fonction des PCD](#StructureetFonctiondesPCD)
|
||||
* 7.2.1. [Structure de Base d'un PCD](#StructuredeBasedunPCD)
|
||||
* 7.2.2. [L'attribut des listes PcdItemGenericEnc `item_list`](#LattributdeslistesPcdItemGenericEncitem_list)
|
||||
* 7.3. [Types de PRD et Leur Fonction](#TypesdePRDetLeurFonction)
|
||||
* 7.3.1. [Structure de RequestPrd](#StructuredeRequestPrd)
|
||||
* 8. [Gestion et Échange des Documents](#GestionetchangedesDocuments)
|
||||
* 8.1. [Création et Distribution](#CrationetDistribution)
|
||||
* 8.2. [Validation et Mise à Jour](#ValidationetMiseJour)
|
||||
* 9. [Spécifications du code](#Spcificationsducode)
|
||||
* 9.1. [Maintenance, environnement de déploiement](#Maintenanceenvironnementdedploiement)
|
||||
* 10. [Annexe](#Annexe)
|
||||
* 10.1. [Exemples de Code](#ExemplesdeCode)
|
||||
* 10.2. [Références](#Rfrences)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># PRD et PCD - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
Le but de cette section est d'introduire les Portable Contract Document (PCD) et Portable Request Document (PRD) 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
|
||||
|
||||
La spécification couvre la conception, le développement, et l'application pratique des PCD et PRD. 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 PCD et PRD 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='DfinitionsetAbrviations'></a>Définitions et Abréviations
|
||||
|
||||
Voir Specs - Définitions et abréviations.
|
||||
|
||||
## 4. <a name='Exigencesdescuritetdeconfidentialit'></a>Exigences de sécurité et de confidentialité
|
||||
|
||||
Voir Specs - Exigences de sécurité
|
||||
|
||||
## 5. <a name='Architecturegnrale'></a>Architecture générale
|
||||
|
||||
Diagramme d'architecture montrant les composants principaux du système de login.
|
||||
[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
|
||||
|
||||
## 6. <a name='Spcificationdesitems'></a>Spécification des items
|
||||
|
||||
Voir Item - Specs
|
||||
|
||||
## 7. <a name='Spcificationdesprocessetroles'></a>Spécification des process et roles
|
||||
|
||||
Voir Voir Item - Specs
|
||||
|
||||
### 7.1. <a name='StructuredesPCDetPRDetdeleurattributgnriqueRequest'></a>Structure des PCD et PRD et de leur attribut générique Request
|
||||
|
||||
La structure Request joue un rôle central dans la création des `PRD` et des `PCD`, servant de fondement pour formuler des demandes au sein du système 4NK.
|
||||
|
||||
* **request**: Un champ encapsulant les détails de la demande, incluant le type, la version, et les références nécessaires pour l'identifier et la traiter présent dans les `PCD` et les `PRD`.
|
||||
|
||||
Il contient les attributs suivants :
|
||||
|
||||
* **item_name**: Optionnel, spécifie le nom de l'item concerné par la demande.
|
||||
* **request_type**: Identifie le type de la demande, tel que mise à jour, confirmation, ou autre action spécifique.
|
||||
* **version**: Indique la version de la demande, permettant de gérer la compatibilité et les mises à jour.
|
||||
* **process_hash**: Référence au hash du processus ItemProcess concerné, établissant le contexte de la demande.
|
||||
* **pcd_reference_hash et item_reference_hash**: Optionnels, fournissent des références aux PCD ou items spécifiques concernés par la demande.
|
||||
|
||||
### 7.2. <a name='StructureetFonctiondesPCD'></a>Structure et Fonction des PCD
|
||||
|
||||
#### 7.2.1. <a name='StructuredeBasedunPCD'></a>Structure de Base d'un PCD
|
||||
|
||||
`Item`: Chaque `PCD` est associé à un type d'`item` spécifique, définissant le contexte et la portée des informations qu'il contient.
|
||||
|
||||
`MetadataContractPublic`, `MetadataRoleConfidential`, `MetadataPrivate`: Ces métadonnées encapsulent les attributs des `items` au sein du `PCD`, classés selon leur niveau de confidentialité. Les métadonnées au sein des PCD jouent un rôle crucial en définissant le niveau de confidentialité et d'accès aux informations contractuelles. Elles permettent une segmentation claire des données selon qui peut y accéder et comment elles peuvent être utilisées.
|
||||
|
||||
#### 7.2.2. <a name='LattributdeslistesPcdItemGenericEncitem_list'></a>L'attribut des listes PcdItemGenericEnc `item_list`
|
||||
|
||||
Chaque Item dit "Enc" pour chiffré est une représentation d'un objet de type `Item` mais avec les attributs chiffrés.
|
||||
|
||||
Ainsi voici la composition d'un item chiffré :
|
||||
|
||||
* **item_enc**: Représente l'encapsulation d'un item au sein d'un PCD, y compris les informations de version, le type d'item, et son nom. Cette structure est la base pour les attributs chiffrés de l'item.
|
||||
* **pcd_item_enc_attribute_public_list**: Une liste d'attributs publics.
|
||||
* **pcd_item_enc_attribute_role_confidential_list**: Contient les attributs chiffrés destinés à être accessibles uniquement par les membres ayant un rôle spécifique dans le processus.
|
||||
* **pcd_item_enc_attribute_private_list**: Attributs chiffrés destinés uniquement au créateur de l'item ou à des parties spécifiquement autorisées.
|
||||
|
||||
Voir Specs - Exigences de sécurité pour le détail des niveaux de sécurité.
|
||||
|
||||
### 7.3. <a name='TypesdePRDetLeurFonction'></a>Types de PRD et Leur Fonction
|
||||
|
||||
`RequestPrd`: Structure de base pour toutes les demandes, contenant des informations chiffrées essentielles pour l'interaction sécurisée entre les parties.
|
||||
|
||||
`RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `PRD` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
|
||||
#### 7.3.1. <a name='StructuredeRequestPrd'></a>Structure de RequestPrd
|
||||
|
||||
La structure RequestPrd sert de fondement pour tous les types de PRD, contenant les éléments suivants :
|
||||
|
||||
* **pcd_keys_role_confidential_list_enc_by_shared_secret**: Liste des clés de chiffrement pour les attributs roleConfidential, permettant un accès sécurisé aux informations nécessaires.
|
||||
* **message_public, message_confidential, message_private**: Segments pour les messages, classés selon leur niveau de confidentialité, facilitant une communication sécurisée et ciblée.
|
||||
* **sp_address_to, sp_address_from, sp_address_reply**: Adresses Silent Payment spécifiant l'origine, la destination, et la réponse pour la transaction, assurant l'anonymat et la sécurité des participants.
|
||||
* **timestamp_declared**: Horodatage déclaré ne servant pas aux contrôles automatiques, fournissant un contexte temporel pour la demande qui peut être différent des horodatages automatiques.
|
||||
* **role_name_from et role_name_to**: Spécifient les rôles des participants à la demande, renforçant le contrôle d'accès et la segmentation des autorisations pour des identités (adresses SP) ayant plusieurs roles différents.
|
||||
|
||||
##### RequestPrdList - Demande de Listes (PCD)
|
||||
|
||||
RequestPrdList spécifie une demande pour obtenir une liste d`Item` sous forme de `PCD`.
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`.
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le réseau.
|
||||
|
||||
##### RequestPrdMessage - Envoi de Messages
|
||||
|
||||
Le RequestPrdMessage facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`.
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties.
|
||||
|
||||
Les `PRDMessage` répondent aux `PRDMessage`.
|
||||
|
||||
##### RequestPrdUpdate - Mises à Jour de PCD
|
||||
|
||||
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `PCD`.
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`. avec des additions pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour :
|
||||
|
||||
* **pcd_new_version_hash**: ,
|
||||
* **payment_pcd_hash_list**: ,
|
||||
* **cap_pcd_hash_list**: ,
|
||||
* **deposit_pcd_hash_list**: ,
|
||||
* **commitment_pcd_hash_list**: ,
|
||||
* **ask_payment_method**: ,
|
||||
* **ask_deposit_method**: ,
|
||||
* **ask_commitment_method**: ,
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
Essentiel pour les utilisateurs ou les processus nécessitant de mettre à jour des informations contractuelles ou des attributs d'items, assurant la pertinence et l'actualité des données dans le système.
|
||||
|
||||
Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `process`, la mise à jour de la liste des `process` permettra de leur affecter un nouveau role.
|
||||
|
||||
##### 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.
|
||||
|
||||
Les `PRDList`, `PRDUpdate`, `PRDMessage`, `PRDResponse` et `PRDKeyHello` reçoivent systématiquement un `PRDConfirm` depuis leur réception par le destinataire.
|
||||
|
||||
###### Composition et Fonction et code de confirmation
|
||||
|
||||
Basé sur le `RequestPrd`, incluant les informations de la demande originale nécessitant confirmation.
|
||||
|
||||
`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 PRDConfirm.
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
Crucial pour les processus qui nécessitent une confirmation explicite de réception ou d'acceptation, comme la finalisation d'une transaction ou la validation d'un changement d'état dans un contrat.
|
||||
|
||||
##### RequestPrdResponse - Répondre à une Demande
|
||||
|
||||
Le RequestPrdResponse permet de répondre spécifiquement à des PRD reçus, facilitant un échange interactif d'informations ou de décisions entre les parties.
|
||||
|
||||
Les PRDResponse répondent aux `PRDList`, `PRDUpdate`, `PRDKeyBackup` et `PRDKeyHello`.
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`, complété par :
|
||||
|
||||
* **sig_value**: Valeur de signature qui certifie l'authenticité de la réponse et de son émetteur.
|
||||
* **pcd_origin_hash**: Optionnel, fournit une référence au PCD d'origine concerné par la réponse, si applicable.
|
||||
* **payment_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential`
|
||||
* **deposit_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential`
|
||||
* **commitment_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential`
|
||||
* **certif_key_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential`
|
||||
* **shared_secret_key**: une clé secrète partagée via le `PRD`.
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
Utilisé pour fournir des feedbacks, des confirmations, ou des instructions supplémentaires en réponse à des demandes initiales, supportant une communication bidirectionnelle sécurisée et vérifiable.
|
||||
|
||||
Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions.
|
||||
|
||||
##### RequestPrdKeyHelloBakcup
|
||||
|
||||
Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` .
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`, complété par :
|
||||
|
||||
* **device_footprint_enc_by_sp_shared_secret**: String,
|
||||
* **part_1_enc_hash_enc_by_sp_shared_secret**: String,
|
||||
* **shard_enc_by_sp_shared_secret**: String,
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
##### 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.
|
||||
|
||||
###### Composition et Fonction
|
||||
|
||||
Basé sur le `RequestPrd`, complété par :
|
||||
|
||||
* **part_1_enc_hash_enc_by_sp_shared_secret**: La première partie de la clé ou de l'identité, chiffrée avec le mot de passe en `pré-id`.
|
||||
|
||||
###### Cas d'utilisation
|
||||
|
||||
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.
|
||||
|
||||
## 8. <a name='GestionetchangedesDocuments'></a>Gestion et Échange des Documents
|
||||
|
||||
### 8.1. <a name='CrationetDistribution'></a>Création et Distribution
|
||||
|
||||
Procédure de création des PCD et PRD, leur chiffrement, et les mécanismes de distribution sécurisée à travers le réseau 4NK.
|
||||
|
||||
### 8.2. <a name='ValidationetMiseJour'></a>Validation et Mise à Jour
|
||||
|
||||
Processus de validation des informations contenues dans les PCD et PRD, ainsi que les procédures de mise à jour et de versioning des documents.
|
||||
|
||||
## 9. <a name='Spcificationsducode'></a>Spécifications du code
|
||||
|
||||
Voir Specs - Code
|
||||
|
||||
### 9.1. <a name='Maintenanceenvironnementdedploiement'></a>Maintenance, environnement de déploiement
|
||||
|
||||
Voir Specs - Maintenance, environnement de déploiement
|
||||
|
||||
## 10. <a name='Annexe'></a>Annexe
|
||||
|
||||
### 10.1. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
|
||||
|
||||
### 10.2. <a name='Rfrences'></a>Références
|
||||
|
||||
Voir Specs - References
|
||||
177
doc/Process-roles-Specs.md
Normal file
177
doc/Process-roles-Specs.md
Normal file
@ -0,0 +1,177 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Définitions et Abréviations](#DfinitionsetAbrviations)
|
||||
* 4. [Exigences de sécurité et de confidentialité](#Exigencesdescuritetdeconfidentialit)
|
||||
* 5. [Architecture générale](#Architecturegnrale)
|
||||
* 6. [Rôles et Sous-Rôles](#RlesetSous-Rles)
|
||||
* 7. [Précisions sur les rôles](#Prcisionssurlesrles)
|
||||
* 7.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
|
||||
* 7.1.1. [Composition et Fonction](#CompositionetFonction)
|
||||
* 7.1.2. [Cas d'utilisation](#Casdutilisation)
|
||||
* 7.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect)
|
||||
* 7.3. [TransactionModeDistribution](#TransactionModeDistribution)
|
||||
* 7.3.1. [TransactionModeDirect](#TransactionModeDirect)
|
||||
* 7.4. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 7.4.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 7.4.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 7.5. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
|
||||
* 7.5.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 7.5.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 8. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
|
||||
* 8.1. [RoleCommitment](#RoleCommitment)
|
||||
* 8.2. [RoleDeposit et RolePayment](#RoleDepositetRolePayment)
|
||||
* 9. [Sécurisation des Communications](#ScurisationdesCommunications)
|
||||
* 9.1. [Composition et Utilisation](#CompositionetUtilisation)
|
||||
* 10. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
|
||||
* 11. [Spécifications du code](#Spcificationsducode)
|
||||
* 11.1. [Maintenance, environnement de déploiement](#Maintenanceenvironnementdedploiement)
|
||||
* 12. [Annexe](#Annexe)
|
||||
* 12.1. [Exemples de Code](#ExemplesdeCode)
|
||||
* 12.2. [Références](#Rfrences)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Process et roles
|
||||
|
||||
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
Cette section vise à présenter en détail les Documents de Contrat Portable (PCD) et les Documents de Demande Portable (PRD), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les PCD et PRD assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
## 3. <a name='DfinitionsetAbrviations'></a>Définitions et Abréviations
|
||||
|
||||
Voir Specs - Définitions et abréviations.
|
||||
|
||||
## 4. <a name='Exigencesdescuritetdeconfidentialit'></a>Exigences de sécurité et de confidentialité
|
||||
|
||||
Voir Specs - Exigences de sécurité
|
||||
|
||||
## 5. <a name='Architecturegnrale'></a>Architecture générale
|
||||
|
||||
Diagramme d'architecture montrant les composants principaux du système de login.
|
||||
[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
|
||||
|
||||
## 6. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
|
||||
|
||||
Les rôles déterminent les permissions et les responsabilités des participants dans le système 4NK. Ils sont essentiels pour contrôler l'accès aux données et les autorisations au sein des `process`. Les `rôles` principaux incluent :
|
||||
|
||||
- **RolePeer**: Conditions des listes de relais participants qui facilitent les communications et les transactions et des versions de ces listes.
|
||||
- **RoleMember**: Conditions des listes des utilisateurs ou entités ayant une participation directe dans un processus spécifique et des versions de ces listes.
|
||||
- **RoleProcess**: Conditions des listes des processus et des versions des listes.
|
||||
- **RoleArtefact**: Définit les permissions et les interactions pour les artefacts au sein du réseau et des version de ces listes, par types d'artefacts.
|
||||
|
||||
Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayment`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent.
|
||||
|
||||
## 7. <a name='Prcisionssurlesrles'></a>Précisions sur les rôles
|
||||
|
||||
### 7.1. <a name='RolesGroup-GestiondesRles'></a>RolesGroup - Gestion des Rôles
|
||||
|
||||
La structure RolesGroup est essentielle pour définir et gérer les groupes de rôles au sein du système 4NK, permettant une organisation claire des permissions et des responsabilités.
|
||||
|
||||
#### 7.1.1. <a name='CompositionetFonction'></a>Composition et Fonction
|
||||
|
||||
- **role_peer**: Définit le rôle des pairs dans le réseau, responsables de la facilitation des communications et des transactions.
|
||||
- **role_member**: Spécifie le rôle des membres, ou utilisateurs, qui participent activement dans les processus et les interactions.
|
||||
- **role_process**: Représente les entités chargées de définir et de gérer les processus au sein du système.
|
||||
- **role_artefact_list**: Une liste de rôles d'artefacts, permettant la personnalisation et l'extension des fonctionnalités et des interactions au-delà des rôles standards.
|
||||
|
||||
#### 7.1.2. <a name='Casdutilisation'></a>Cas d'utilisation
|
||||
|
||||
Cette structure permet une gestion flexible des rôles au sein du système, facilitant l'assignation de permissions spécifiques et la délimitation des responsabilités pour une sécurité et une efficacité accrues.
|
||||
|
||||
### 7.2. <a name='TransactionModeDistributionetTransactionModeDirect'></a>TransactionModeDistribution et TransactionModeDirect
|
||||
|
||||
Les modes de transaction, tels que TransactionModeDistribution et TransactionModeDirect, déterminent comment les demandes et les réponses sont distribuées et traitées au sein du réseau 4NK, influençant l'efficacité et la sécurité des interactions.
|
||||
|
||||
### 7.3. <a name='TransactionModeDistribution'></a>TransactionModeDistribution
|
||||
|
||||
Permet la distribution des demandes ou des informations à plusieurs rôles ou entités, facilitant une communication large et la collaboration au sein du système.
|
||||
|
||||
#### 7.3.1. <a name='TransactionModeDirect'></a>TransactionModeDirect
|
||||
|
||||
Concentre l'échange d'informations ou de demandes directement entre un émetteur et un destinataire spécifique, garantissant une interaction ciblée et sécurisée.
|
||||
|
||||
### 7.4. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
|
||||
Ces modes supportent divers scénarios de communication, de la diffusion large d'informations ou de mises à jour, à des échanges directs pour des opérations spécifiques, offrant ainsi une flexibilité dans la gestion des flux d'informations.
|
||||
|
||||
# Role - Définition et Gestion des Rôles Spécifiques
|
||||
|
||||
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
||||
|
||||
#### 7.4.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
|
||||
- **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
||||
- **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
||||
- **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
||||
- **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
||||
|
||||
#### 7.4.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
|
||||
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
||||
|
||||
### 7.5. <a name='Role-DfinitionetGestiondesRlesSpcifiques'></a>Role - Définition et Gestion des Rôles Spécifiques
|
||||
|
||||
La structure Role est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
|
||||
|
||||
#### 7.5.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
|
||||
- **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
|
||||
- **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
|
||||
- **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
|
||||
- **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
|
||||
|
||||
#### 7.5.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
|
||||
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
|
||||
|
||||
## 8. <a name='GestiondesEngagementsetTransactions'></a>Gestion des Engagements et Transactions
|
||||
|
||||
Les engagements dans le système 4NK, tels que représentés par les structures RoleCommitment, RoleDeposit, et RolePayment, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties.
|
||||
|
||||
### 8.1. <a name='RoleCommitment'></a>RoleCommitment
|
||||
|
||||
- **item_name**: Identifie l'engagement spécifique ou l'obligation prise par une partie.
|
||||
- **role**: Définit les permissions, les conditions et les critères associés à cet engagement, assurant une exécution et une validation conformes aux attentes.
|
||||
|
||||
### 8.2. <a name='RoleDepositetRolePayment'></a>RoleDeposit et RolePayment
|
||||
|
||||
Ces structures gèrent respectivement les dépôts de garantie et les paiements, en spécifiant les conditions sous lesquelles les fonds sont déposés, retenus ou transférés, contribuant ainsi à la confiance et à la fluidité des transactions au sein du réseau.
|
||||
|
||||
## 9. <a name='ScurisationdesCommunications'></a>Sécurisation des Communications
|
||||
|
||||
La structure MetaData et ses sous-structures comme MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate fournissent un cadre pour sécuriser les communications et les données au sein du système 4NK, permettant une distinction claire entre les informations accessibles publiquement, celles réservées à certains rôles, et celles strictement privées.
|
||||
|
||||
### 9.1. <a name='CompositionetUtilisation'></a>Composition et Utilisation
|
||||
|
||||
- **meta_data**: Chaque instance de MetaData encapsule des informations détaillées, des attributs et des clés de chiffrement liés à un item, facilitant la gestion sécurisée et la distribution ciblée des données.
|
||||
- **key_list**: Un élément crucial pour le chiffrement et la sécurisation des données, assurant que seules les parties autorisées peuvent accéder aux informations confidentielles.
|
||||
|
||||
## 10. <a name='IntgrationetOrchestrationdesProcessus'></a>Intégration et Orchestration des Processus
|
||||
|
||||
L'ItemProcess et ItemProcessPublicAttributeGroup offrent un cadre pour l'intégration et l'orchestration des processus dans le système 4NK, permettant la définition, la gestion et l'exécution de workflows complexes de manière sécurisée et efficace.
|
||||
|
||||
|
||||
## 11. <a name='Spcificationsducode'></a>Spécifications du code
|
||||
|
||||
Voir Specs - Code
|
||||
|
||||
### 11.1. <a name='Maintenanceenvironnementdedploiement'></a>Maintenance, environnement de déploiement
|
||||
|
||||
Voir Specs - Maintenance, environnement de déploiement
|
||||
|
||||
## 12. <a name='Annexe'></a>Annexe
|
||||
|
||||
### 12.1. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
|
||||
|
||||
### 12.2. <a name='Rfrences'></a>Références
|
||||
|
||||
Voir Specs - References
|
||||
101
doc/Specs-Code.md
Normal file
101
doc/Specs-Code.md
Normal file
@ -0,0 +1,101 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Gestion des erreurs](#Gestiondeserreurs)
|
||||
* 2. [Journalisation et monitoring](#Journalisationetmonitoring)
|
||||
* 3. [Tests](#Tests)
|
||||
* 3.1. [Stratégie de test](#Stratgiedetest)
|
||||
* 3.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires)
|
||||
* 3.3. [Plan d'intégration](#Plandintgration)
|
||||
* 3.4. [Plan de charge](#Plandecharge)
|
||||
* 4. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser)
|
||||
* 5. [Critères d'acceptation](#Critresdacceptation)
|
||||
* 6. [CI/CD](#CICD)
|
||||
* 7. [Maintenance](#Maintenance)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Specs - Code
|
||||
|
||||
## 1. <a name='Gestiondeserreurs'></a>Gestion des erreurs
|
||||
|
||||
Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être `catch` si il y a une possiblité d'interuption.
|
||||
|
||||
Stratégie de gestion des erreurs et de reporting pour faciliter le débogage et améliorer la résilience du système.
|
||||
|
||||
Tous les flux sont reçus par autant de relais et de membres de même rôles. 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.
|
||||
|
||||
Les arrêts de la blockchain dans son ensemble n'entraînent pas d'interruption de service, car les horodatages sont non bloquants, l'impact est une diminution de la preuve le temps de "ré-ancrer" ce qui n'aurait pas pu l'être. L'arrêt de nœuds de la blockchain pourrait ralentir la propagation des informations dans les scénarios les plus critiques, sans impact majeur sur le fonctionnement.
|
||||
|
||||
Les arrêts des membres dans les process dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des process pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des process est en charge de l'arbitrage pour la bonne restitution des actions.
|
||||
|
||||
Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques.
|
||||
|
||||
## 2. <a name='Journalisationetmonitoring'></a>Journalisation et monitoring
|
||||
|
||||
Tous les utilisateurs reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les PCD sont les listes à jour de l'état de validation de tous les éléments échangés, et les PRD sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un process (possible de segmenter par zones et services).
|
||||
|
||||
Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair.
|
||||
|
||||
La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque message) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels.
|
||||
|
||||
## 3. <a name='Tests'></a>Tests
|
||||
|
||||
### 3.1. <a name='Stratgiedetest'></a>Stratégie de test
|
||||
|
||||
À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur.
|
||||
|
||||
### 3.2. <a name='Planpourlestestsunitaires'></a>Plan pour les tests unitaires
|
||||
|
||||
Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire.
|
||||
|
||||
### 3.3. <a name='Plandintgration'></a>Plan d'intégration
|
||||
|
||||
L'intégration se réalise par sprint hebdomadaire.
|
||||
|
||||
L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint.
|
||||
|
||||
### 3.4. <a name='Plandecharge'></a>Plan de charge
|
||||
|
||||
Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des utilisateurs.
|
||||
|
||||
## 4. <a name='Outilsetleslibrairiesutiliser'></a>Outils et les librairies à utiliser
|
||||
|
||||
Respect des normes de syntaxe Rust.
|
||||
|
||||
Utilisation de Visual Studio (pour le partage de configurations).
|
||||
|
||||
À l'étude : revues et pilotage par la documentation depuis une IA et partage d'un chat IA pour la base de connaissance.
|
||||
|
||||
* **Environnement** : navigateur (tous dispositifs), et relais sous Debian.
|
||||
|
||||
* **Développement** : en Rust pour compilation Wasm.
|
||||
|
||||
* **Pas de base de données** sauf IndexedDB présent nativement pour les navigateurs et les applications mobiles.
|
||||
|
||||
* **Librairies** : `rust-bitcoin`, `rand`, `hex`, `bech32`, `shamir_secret_sharing`, `uuid`, `sha2`, `chrono`, `aes-gcm`, `base64`, `wasm-bindgen`, `serde`, `serde_json` dans leurs dernières versions.
|
||||
|
||||
* **Librairies de tests** : Cargo test
|
||||
|
||||
## 5. <a name='Critresdacceptation'></a>Critères d'acceptation
|
||||
|
||||
Critères de validation pour que le système puisse être considéré comme prêt pour la production :
|
||||
|
||||
* Tous les parcours utilisateurs fonctionnels.
|
||||
* Tous les tests unitaires présents et parcourus.
|
||||
* Tous les tests d'intégration présents et parcourus.
|
||||
* Aucun bug bloquant.
|
||||
* 10 bugs majeurs.
|
||||
* 20 bugs mineurs.
|
||||
* Contrôles manquants clairement précisés.
|
||||
* Documentation manquante clairement précisée.
|
||||
* Autres tests manquants clairement précisés.
|
||||
|
||||
## 6. <a name='CICD'></a>CI/CD
|
||||
|
||||
GitLab CI : TBD
|
||||
|
||||
## 7. <a name='Maintenance'></a>Maintenance
|
||||
|
||||
La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint.
|
||||
Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance.
|
||||
683
doc/Specs-Datas.md
Normal file
683
doc/Specs-Datas.md
Normal file
@ -0,0 +1,683 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Conditions](#Conditions)
|
||||
* 1.1. [ConditionCap](#ConditionCap)
|
||||
* 1.2. [ConditionCommitment](#ConditionCommitment)
|
||||
* 1.3. [ConditionDeposit](#ConditionDeposit)
|
||||
* 1.4. [ConditionOrchestration](#ConditionOrchestration)
|
||||
* 1.5. [ConditionPayment](#ConditionPayment)
|
||||
* 1.6. [ConditionPrdAddressSet](#ConditionPrdAddressSet)
|
||||
* 1.7. [ConditionPublish](#ConditionPublish)
|
||||
* 2. [Methods](#Methods)
|
||||
* 2.1. [DepositMethod](#DepositMethod)
|
||||
* 2.2. [CommitmentMethod](#CommitmentMethod)
|
||||
* 2.3. [PaymentMethod](#PaymentMethod)
|
||||
* 3. [Items](#Items)
|
||||
* 3.1. [ItemArtefact](#ItemArtefact)
|
||||
* 3.2. [ItemCommitmentPublicAttributeGroup](#ItemCommitmentPublicAttributeGroup)
|
||||
* 3.3. [ItemMemberPublicAttributeGroup](#ItemMemberPublicAttributeGroup)
|
||||
* 3.4. [ItemDepositPublicAttributeGroup](#ItemDepositPublicAttributeGroup)
|
||||
* 3.5. [ItemCommitmentRoleConfidentialAttributeGroup](#ItemCommitmentRoleConfidentialAttributeGroup)
|
||||
* 3.6. [ItemCommitmentPrivateAttributeGroup](#ItemCommitmentPrivateAttributeGroup)
|
||||
* 3.7. [ItemCommitment](#ItemCommitment)
|
||||
* 3.8. [ItemDepositRoleConfidentialAttributeGroup](#ItemDepositRoleConfidentialAttributeGroup)
|
||||
* 3.9. [ItemDepositPrivateAttributeGroup](#ItemDepositPrivateAttributeGroup)
|
||||
* 3.10. [ItemDeposit](#ItemDeposit)
|
||||
* 3.11. [ItemEnum](#ItemEnum)
|
||||
* 3.12. [ItemPaymentPublicAttributeGroup](#ItemPaymentPublicAttributeGroup)
|
||||
* 3.13. [ItemPaymentRoleConfidentialAttributeGroup](#ItemPaymentRoleConfidentialAttributeGroup)
|
||||
* 3.14. [ItemPaymentPrivateAttributeGroup](#ItemPaymentPrivateAttributeGroup)
|
||||
* 3.15. [ItemPayment](#ItemPayment)
|
||||
* 3.16. [ItemPeerPublicAttributeGroup](#ItemPeerPublicAttributeGroup)
|
||||
* 3.17. [ItemPeerPrivateAttributeGroup](#ItemPeerPrivateAttributeGroup)
|
||||
* 3.18. [ItemPeer](#ItemPeer)
|
||||
* 3.19. [ItemProcess](#ItemProcess)
|
||||
* 3.20. [ItemProcessPublicAttributeGroup](#ItemProcessPublicAttributeGroup)
|
||||
* 3.21. [Item](#Item)
|
||||
* 4. [Encryption](#Encryption)
|
||||
* 4.1. [KeyEncryption](#KeyEncryption)
|
||||
* 4.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit)
|
||||
* 5. [Messages](#Messages)
|
||||
* 5.1. [MessageClient](#MessageClient)
|
||||
* 5.2. [MessageConnect](#MessageConnect)
|
||||
* 5.3. [Message](#Message)
|
||||
* 5.4. [Pow](#Pow)
|
||||
* 6. [Metadata](#Metadata)
|
||||
* 6.1. [MetadataContractPublic](#MetadataContractPublic)
|
||||
* 6.2. [MetadataPrivate](#MetadataPrivate)
|
||||
* 6.3. [MetadataPrivate](#MetadataPrivate-1)
|
||||
* 6.4. [MetadataRoleConfidential](#MetadataRoleConfidential)
|
||||
* 6.5. [MetaData](#MetaData)
|
||||
* 6.6. [Amount](#Amount)
|
||||
* 6.7. [Number](#Number)
|
||||
* 7. [PCD](#PCD)
|
||||
* 7.1. [Pagination](#Pagination)
|
||||
* 7.2. [PcdItemEncAttributePublic](#PcdItemEncAttributePublic)
|
||||
* 7.3. [PcdItemEncAttributeRoleConfidential](#PcdItemEncAttributeRoleConfidential)
|
||||
* 7.4. [PcdItemEncAttributePrivate](#PcdItemEncAttributePrivate)
|
||||
* 7.5. [PcdItemGenericEnc](#PcdItemGenericEnc)
|
||||
* 7.6. [PcdItemEnc](#PcdItemEnc)
|
||||
* 7.7. [RequestPcd](#RequestPcd)
|
||||
* 8. [PRD](#PRD)
|
||||
* 8.1. [RequestPrdConfirm](#RequestPrdConfirm)
|
||||
* 8.2. [RequestPrdKeyBackup](#RequestPrdKeyBackup)
|
||||
* 8.3. [RequestPrdKeyHello](#RequestPrdKeyHello)
|
||||
* 8.4. [RequestPrdList](#RequestPrdList)
|
||||
* 8.5. [RequestPrdMessage](#RequestPrdMessage)
|
||||
* 8.6. [RequestPrdList](#RequestPrdList-1)
|
||||
* 8.7. [RequestPrdResponse](#RequestPrdResponse)
|
||||
* 8.8. [RequestPrdUpdate](#RequestPrdUpdate)
|
||||
* 8.9. [KeyRoleConfidential](#KeyRoleConfidential)
|
||||
* 8.10. [RequestPrd](#RequestPrd)
|
||||
* 8.11. [RoleArtefact](#RoleArtefact)
|
||||
* 8.12. [Request](#Request)
|
||||
* 8.13. [RoleDeposit](#RoleDeposit)
|
||||
* 8.14. [RoleCommitment](#RoleCommitment)
|
||||
* 8.15. [RoleMember](#RoleMember)
|
||||
* 8.16. [RolePayment](#RolePayment)
|
||||
* 8.17. [RoleProcess](#RoleProcess)
|
||||
* 8.18. [Role](#Role)
|
||||
* 8.19. [TransactionModeDistribution](#TransactionModeDistribution)
|
||||
* 8.20. [TransactionModeDirect](#TransactionModeDirect)
|
||||
* 8.21. [TransactionMode](#TransactionMode)
|
||||
* 8.22. [RolesGroup](#RolesGroup)
|
||||
* 8.23. [SharedProcess](#SharedProcess)
|
||||
* 8.24. [SharedPeer](#SharedPeer)
|
||||
* 8.25. [Relay](#Relay)
|
||||
* 8.26. [L1Node](#L1Node)
|
||||
* 8.27. [L1Miner](#L1Miner)
|
||||
* 8.28. [L2Node](#L2Node)
|
||||
* 8.29. [L2Certif](#L2Certif)
|
||||
* 8.30. [SharedPeer](#SharedPeer-1)
|
||||
* 8.31. [RolePeer](#RolePeer)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Specs - Datas
|
||||
|
||||
## 1. <a name='Conditions'></a>Conditions
|
||||
|
||||
### 1.1. <a name='ConditionCap'></a>ConditionCap
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------|-----------------|--------|-----------------------------------------------------------|
|
||||
| role_deposit | String | | Represents the deposit role in the condition. |
|
||||
| role_transaction | TransactionMode | | Specifies the transaction mode associated with this role. |
|
||||
|
||||
### 1.2. <a name='ConditionCommitment'></a>ConditionCommitment
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------|-----------------|--------|-----------------------------------------------------------|
|
||||
| role_artefact | String | | Represents the artefact role in the condition. |
|
||||
| role_transaction | TransactionMode | | Specifies the transaction mode associated with this role. |
|
||||
|
||||
### 1.3. <a name='ConditionDeposit'></a>ConditionDeposit
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------|-----------------|--------|-----------------------------------------------------------|
|
||||
| role_deposit | String | | Represents the deposit role in the condition. |
|
||||
| role_transaction | TransactionMode | | Specifies the transaction mode associated with this role. |
|
||||
|
||||
### 1.4. <a name='ConditionOrchestration'></a>ConditionOrchestration
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|----------------------------------------------------------|
|
||||
| role_ok | String | | Represents the successful outcome role in the condition. |
|
||||
| role_ko | String | | Represents the failed outcome role in the condition. |
|
||||
|
||||
### 1.5. <a name='ConditionPayment'></a>ConditionPayment
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------|-----------------|--------|-----------------------------------------------------------|
|
||||
| payment_amount | String | | Represents the amount to be paid in the condition. |
|
||||
| payment_method | PaymentMode | | Specifies the payment method to be used. |
|
||||
| role_transaction | TransactionMode | | Specifies the transaction mode associated with this role. |
|
||||
|
||||
### 1.6. <a name='ConditionPrdAddressSet'></a>ConditionPrdAddressSet
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|---------------------------------------|-------------|--------|------------------------------------------------------------|
|
||||
| from_role | String | | Identifies the originating role in the condition. |
|
||||
| prd_sp_address_list | Vec<String> | | Lists addresses involved in the condition. |
|
||||
| prd_sp_address_required_list | Vec<String> | | Lists required addresses for the condition to be met. |
|
||||
| prd_sp_address_quota | i32 | | Specifies the quota of addresses for the condition. |
|
||||
| prd_prd_value_ok_list | Vec<String> | | Lists the values that are considered acceptable. |
|
||||
| prd_value_ko_list | Vec<String> | | Lists the values that are considered failures. |
|
||||
| prd_value_none_list | Vec<String> | | Lists the values that are considered neutral or no-op. |
|
||||
| prd_sp_address_value_min | i64 | | The minimum value for an address to be considered. |
|
||||
| prd_sp_address_value_min_per | i64 | | The minimum percentage for the minimum address value. |
|
||||
| prd_sp_address_value_min_ok | bool | | Indicates if the minimum address value is considered OK. |
|
||||
| prd_sp_adddress_value_ok_min_per | i64 | | The minimum percentage for an address value to be OK. |
|
||||
| prd_sp_address_value_ok_max | i64 | | The maximum value for an address to be considered OK. |
|
||||
| prd_sp_adderss_value_ko_max_per | i64 | | The maximum percentage for an address value to be KO. |
|
||||
| prd_sp_address_value_none_max | i64 | | The maximum value for an address to be considered neutral. |
|
||||
| prd_sp_adderss_value_none_max_per | i64 | | The maximum percentage for a neutral address value. |
|
||||
| prd_sp_address_score_min | i32 | | The minimum score for an address to be considered. |
|
||||
| prd_sp_address_score_min_min_required | i32 | | The minimum required score for an address. |
|
||||
| prd_sp_address_score_min_min_ok | bool | | Indicates if the minimum score is considered OK. |
|
||||
| prd_sp_address_score_min_min_per | i64 | | The minimum percentage for the minimum score. |
|
||||
| prd_value_auto_ok | bool | | Automatically consider values as OK. |
|
||||
| prd_value_auto_ko | bool | | Automatically consider values as KO. |
|
||||
| prd_value_auto_none | bool | | Automatically consider values as neutral or no-op. |
|
||||
|
||||
### 1.7. <a name='ConditionPublish'></a>ConditionPublish
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-------------------------|--------|--------|---------------------------------------------------------------|
|
||||
| pcd_data_size_max_unit | String | | Specifies the maximum unit size for published data. |
|
||||
| pcd_data_size_max_total | i64 | | Specifies the total maximum data size allowed. |
|
||||
| pcd_number_min | i32 | | The minimum number of publications required. |
|
||||
| pcd_number_max | i32 | | The maximum number of publications allowed. |
|
||||
| pcd_amount_max_total | Amount | | The maximum total amount for publications. |
|
||||
| prd_waiting_timeout | u64 | | The waiting timeout for a publication to be considered valid. |
|
||||
| pcd_waiting_timeout | u64 | | The waiting timeout for the condition to be considered met. |
|
||||
|
||||
## 2. <a name='Methods'></a>Methods
|
||||
|
||||
### 2.1. <a name='DepositMethod'></a>DepositMethod
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|------------------------------|
|
||||
| method | String | | Represents a deposit method. |
|
||||
|
||||
### 2.2. <a name='CommitmentMethod'></a>CommitmentMethod
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|---------------------------------|
|
||||
| method | String | | Represents a commitment method. |
|
||||
|
||||
### 2.3. <a name='PaymentMethod'></a>PaymentMethod
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|------------------------------------------------------|
|
||||
| method | String | | La méthode de paiement représentée par cette struct. |
|
||||
|
||||
## 3. <a name='Items'></a>Items
|
||||
|
||||
### 3.1. <a name='ItemArtefact'></a>ItemArtefact
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------|-------------|--------|-------------------------------------------------------------------|
|
||||
| item | Item | | Represents the item associated with this artefact. |
|
||||
| public_attribute_group | Vec<String> | | A list of public attributes associated with the artefact. |
|
||||
| role_confidential_attribute_group | Vec<String> | | A list of role-specific confidential attributes for the artefact. |
|
||||
| private_attribute_group | Vec<String> | | A list of private attributes associated with the artefact. |
|
||||
|
||||
### 3.2. <a name='ItemCommitmentPublicAttributeGroup'></a>ItemCommitmentPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|--------------------------|-------------|--------|--------------------------------------------------------------------------|
|
||||
| for_sp_address_list | Vec<String> | | A list of service provider addresses related to this commitment. |
|
||||
| goal_list | Vec<String> | | A list of goals associated with this commitment. |
|
||||
| provider_type | String | | The type of provider making the commitment. |
|
||||
| commitment_pcd_hash_list | Vec<String> | | A list of hashes for the commitment's PCD documents. |
|
||||
| ref_item_hash_list | Vec<String> | | A list of reference hashes for items related to this commitment. |
|
||||
| ref_pcd_hash_list | Vec<String> | | A list of reference hashes for PCD documents related to this commitment. |
|
||||
| payload_public_list | Vec<String> | | A list of public payloads associated with this commitment. |
|
||||
|
||||
### 3.3. <a name='ItemMemberPublicAttributeGroup'></a>ItemMemberPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------------|-------------|--------|---------------------------------------------------------------|
|
||||
| sp_address_public | String | | The public service provider address. |
|
||||
| sp_address_public_sig | String | | The signature for the public service provider address. |
|
||||
| sp_address_revoke_public | String | | The public address for revoking service provider access. |
|
||||
| sp_address_revoke_public_sig | String | | The signature for the public address for revoking access. |
|
||||
| third_sp_address_list_public | Vec<String> | | A list of public addresses for third-party service providers. |
|
||||
| data_size_max | i64 | | The maximum size of data allowed. |
|
||||
| payment_method_list_public | Vec<String> | | A list of public payment methods available. |
|
||||
| succession_process_hash | String | | The hash of the succession process associated with this item. |
|
||||
|
||||
### 3.4. <a name='ItemDepositPublicAttributeGroup'></a>ItemDepositPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------|-------------|--------|----------------------------------------------------------------|
|
||||
| for_sp_address_list | Vec<String> | | A list of service provider addresses targeted by this deposit. |
|
||||
| for_address_list | Vec<String> | | A list of addresses targeted by this deposit. |
|
||||
| goal_list | Vec<String> | | A list of goals associated with this deposit. |
|
||||
| provider_type | String | | The type of provider making the deposit. |
|
||||
| ref_item_hash_list | Vec<String> | | A list of item hashes referenced by this deposit. |
|
||||
| ref_pcd_hash_list | Vec<String> | | A list of PCD document hashes referenced by this deposit. |
|
||||
| payload_list_public | Vec<String> | | A list of public payloads associated with this deposit. |
|
||||
| audit_code_list_public | Vec<String> | | A list of public audit codes associated with this deposit. |
|
||||
|
||||
### 3.5. <a name='ItemCommitmentRoleConfidentialAttributeGroup'></a>ItemCommitmentRoleConfidentialAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|---------------------------|-------------|--------|------------------------------------------------------------------|
|
||||
| payload_list_confidential | Vec<String> | | A list of confidential payloads associated with this commitment. |
|
||||
|
||||
### 3.6. <a name='ItemCommitmentPrivateAttributeGroup'></a>ItemCommitmentPrivateAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------|-------------|--------|-------------------------------------------------------------|
|
||||
| payload_list_private | Vec<String> | | A list of private payloads associated with this commitment. |
|
||||
|
||||
### 3.7. <a name='ItemCommitment'></a>ItemCommitment
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------|----------------------------------------------|--------|---------------------------------------------------------------------|
|
||||
| item | Item | | Represents the item associated with this commitment. |
|
||||
| public_attribute_group | ItemCommitmentPublicAttributeGroup | | The public attribute group associated with this commitment. |
|
||||
| role_confidential_attribute_group | ItemCommitmentRoleConfidentialAttributeGroup | | The role-specific confidential attribute group for this commitment. |
|
||||
| private_attribute_group | ItemCommitmentPrivateAttributeGroup | | The private attribute group associated with this commitment. |
|
||||
|
||||
### 3.8. <a name='ItemDepositRoleConfidentialAttributeGroup'></a>ItemDepositRoleConfidentialAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------------|-------------|--------|------------------------------------------------------------------|
|
||||
| payload_list_confidential | Vec<String> | | A list of confidential payloads associated with this deposit. |
|
||||
| audit_code_list_confidential | Vec<String> | | A list of confidential audit codes associated with this deposit. |
|
||||
|
||||
### 3.9. <a name='ItemDepositPrivateAttributeGroup'></a>ItemDepositPrivateAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------|-------------|--------|----------------------------------------------------------|
|
||||
| payload_list_private | Vec<String> | | A list of private payloads associated with this deposit. |
|
||||
| audit_code_private | String | | A private audit code associated with this deposit. |
|
||||
|
||||
### 3.10. <a name='ItemDeposit'></a>ItemDeposit
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------|-------------------------------------------|--------|------------------------------------------------------------------|
|
||||
| item | Item | | Represents the item associated with this deposit. |
|
||||
| public_attribute_group | ItemDepositPublicAttributeGroup | | The public attribute group associated with this deposit. |
|
||||
| role_confidential_attribute_group | ItemDepositRoleConfidentialAttributeGroup | | The role-specific confidential attribute group for this deposit. |
|
||||
| private_attribute_group | ItemDepositPrivateAttributeGroup | | The private attribute group associated with this deposit. |
|
||||
|
||||
### 3.11. <a name='ItemEnum'></a>ItemEnum
|
||||
|
||||
Cette énumération représente différents types d'items au sein d'un système, où chaque variante encapsule une struct spécifique à un type d'item :
|
||||
|
||||
* `Process(ItemProcess)`: Contient un item de type `ItemProcess`, représentant un processus.
|
||||
* `Peer(ItemPeer)`: Contient un item de type `ItemPeer`, représentant un pair.
|
||||
* `Member(ItemMember)`: Contient un item de type `ItemMember`, représentant un membre.
|
||||
* `Payment(ItemPayment)`: Contient un item de type `ItemPayment`, représentant un paiement.
|
||||
* `Deposit(ItemDeposit)`: Contient un item de type `ItemDeposit`, représentant un dépôt.
|
||||
* `Artefact(ItemArtefact)`: Contient un item de type `ItemArtefact`, représentant un artefact.
|
||||
* `Commitment(ItemCommitment)`: Contient un item de type `ItemCommitment`, représentant un engagement.
|
||||
|
||||
### 3.12. <a name='ItemPaymentPublicAttributeGroup'></a>ItemPaymentPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|--------------------------|-------------|--------|-----------------------------------------------------------------------|
|
||||
| for_sp_address_list | Vec<String> | | A list of service provider addresses related to this payment. |
|
||||
| goal_list | Vec<String> | | A list of goals associated with this payment. |
|
||||
| provider_type | String | | The type of provider making the payment. |
|
||||
| commitment_pcd_hash_list | Vec<String> | | A list of hashes for the payment's commitment precondition documents. |
|
||||
| order_pcd_hash_list | Vec<String> | | A list of hashes for the payment's order precondition documents. |
|
||||
| invoice_pcd_hash_list | Vec<String> | | A list of hashes for the payment's invoice precondition documents. |
|
||||
| pay_pcd_hash_list | Vec<String> | | A list of hashes for the payment precondition documents. |
|
||||
| ref_item_hash_list | Vec<String> | | A list of item hashes referenced by this payment. |
|
||||
| ref_pcd_hash_list | Vec<String> | | A list of precondition document hashes referenced by this payment. |
|
||||
| payload_list_public | Vec<String> | | A list of public payloads associated with this payment. |
|
||||
| audit_code_list_public | Vec<String> | | A list of public audit codes associated with this payment. |
|
||||
|
||||
### 3.13. <a name='ItemPaymentRoleConfidentialAttributeGroup'></a>ItemPaymentRoleConfidentialAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------------|-------------|--------|------------------------------------------------------------------|
|
||||
| payload_list_confidential | Vec<String> | | A list of confidential payloads associated with this payment. |
|
||||
| audit_code_list_confidential | Vec<String> | | A list of confidential audit codes associated with this payment. |
|
||||
|
||||
### 3.14. <a name='ItemPaymentPrivateAttributeGroup'></a>ItemPaymentPrivateAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------|-------------|--------|----------------------------------------------------------|
|
||||
| payload_list_private | Vec<String> | | A list of private payloads associated with this payment. |
|
||||
| audit_code_private | String | | A private audit code associated with this payment. |
|
||||
|
||||
### 3.15. <a name='ItemPayment'></a>ItemPayment
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------|-------------------------------------------|--------|------------------------------------------------------------------|
|
||||
| item | Item | | Represents the item associated with this payment. |
|
||||
| public_attribute_group | ItemPaymentPublicAttributeGroup | | The public attribute group associated with this payment. |
|
||||
| role_confidential_attribute_group | ItemPaymentRoleConfidentialAttributeGroup | | The role-specific confidential attribute group for this payment. |
|
||||
| private_attribute_group | ItemPaymentPrivateAttributeGroup | | The private attribute group associated with this payment. |
|
||||
|
||||
### 3.16. <a name='ItemPeerPublicAttributeGroup'></a>ItemPeerPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------------|-------------|--------|-------------------------------------------------------------------------------|
|
||||
| sp_address | String | | The service provider's address associated with this peer. |
|
||||
| domain | String | | The domain associated with this peer. |
|
||||
| ip_address | String | | The IP address associated with this peer. |
|
||||
| pow_difficulty | u32 | | The Proof of Work (PoW) difficulty level required by this peer. |
|
||||
| pow_pattern | String | | The PoW pattern used by this peer. |
|
||||
| pow_prefix | String | | The PoW prefix used by this peer. |
|
||||
| data_size_max | i64 | | The maximum data size allowed by this peer. |
|
||||
| timestamp_delay_max | u64 | | The maximum delay (in timestamps) allowed by this peer. |
|
||||
| daily_hash_list | Vec<String> | | A daily list of hashes associated with this peer. |
|
||||
| daily_sp_tx_mine_list | Vec<String> | | A daily list of service provider transactions mined by this peer. |
|
||||
| daily_sp_tx_mine_reward_list | Vec<String> | | A daily list of rewards for service provider transactions mined by this peer. |
|
||||
|
||||
### 3.17. <a name='ItemPeerPrivateAttributeGroup'></a>ItemPeerPrivateAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|-----------------------------------------------------------|
|
||||
| config | String | | A private configuration string associated with this peer. |
|
||||
|
||||
### 3.18. <a name='ItemPeer'></a>ItemPeer
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-------------------------|-------------------------------|--------|---------------------------------------------------------------|
|
||||
| item | Item | | Représente les informations de base de l'item. |
|
||||
| layer_list | Vec<String> | | Une liste des couches (layers) auxquelles ce pair appartient. |
|
||||
| public_attribute_group | ItemPeerPublicAttributeGroup | | Groupe d'attributs publics associés à ce pair. |
|
||||
| private_attribute_group | ItemPeerPrivateAttributeGroup | | Groupe d'attributs privés associés à ce pair. |
|
||||
|
||||
### 3.19. <a name='ItemProcess'></a>ItemProcess
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-------------------------------------|---------------------------------|--------|----------------------------------------------------------|
|
||||
| item | Item | | Represents the item associated with this process. |
|
||||
| item_process_public_attribute_group | ItemProcessPublicAttributeGroup | | The public attribute group associated with this process. |
|
||||
|
||||
### 3.20. <a name='ItemProcessPublicAttributeGroup'></a>ItemProcessPublicAttributeGroup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|------------|--------|-----------------------------------------------------------|
|
||||
| roles_group | RolesGroup | | Represents a group of roles associated with this process. |
|
||||
|
||||
### 3.21. <a name='Item'></a>Item
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------------|--------------------------|--------|---------------------------------------------------------------------------|
|
||||
| uuid | String | | A unique identifier for the item. |
|
||||
| version | i64 | | The version of the item. |
|
||||
| hash | Option<String> | | An optional hash for the item. |
|
||||
| item_type | String | | The type of the item. `type` is a reserved keyword in Rust, renamed here. |
|
||||
| name | String | | The name of the item. |
|
||||
| pagination_number_per_pcd | u32 | | The pagination number per Portable Contract Document (PCD). |
|
||||
| metadata_contract_public | MetadataContractPublic | | Public metadata contract associated with the item. |
|
||||
| metadata_role_confidential | MetadataRoleConfidential | | Role-specific confidential metadata associated with the item. |
|
||||
| metadata_private | MetadataPrivate | | Private metadata associated with the item. |
|
||||
|
||||
## 4. <a name='Encryption'></a>Encryption
|
||||
|
||||
### 4.1. <a name='KeyEncryption'></a>KeyEncryption
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|----------------|--------|---------------------------------------------------------------|
|
||||
| attribute_name | Option<String> | Yes | An optional name of the attribute this encryption key is for. |
|
||||
| key | Option<String> | Yes | An optional encryption key. |
|
||||
| algorithm | Option<String> | Yes | An optional encryption algorithm used with this key. |
|
||||
|
||||
### 4.2. <a name='Aes256GcmIv96Bit'></a>Aes256GcmIv96Bit
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|-----------------------|--------|------------------------------------------------------------------------------|
|
||||
| key | GenericArray<u8, U32> | | Represents an encryption key for the AES-256-GCM algorithm with a 96-bit IV. |
|
||||
|
||||
## 5. <a name='Messages'></a>Messages
|
||||
|
||||
### 5.1. <a name='MessageClient'></a>MessageClient
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|---------|--------|------------------------------------------------------------------|
|
||||
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
||||
| request_enc | String | | The encrypted request content. |
|
||||
| request_hash | String | | The hash of the request content. |
|
||||
|
||||
### 5.2. <a name='MessageConnect'></a>MessageConnect
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|---------|--------|------------------------------------------------------------------|
|
||||
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
||||
|
||||
### 5.3. <a name='Message'></a>Message
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|---------------------|--------------------|--------|------------------------------------------------------------------------------------|
|
||||
| shared_peer_list | Vec<SharedPeer> | | A list of shared peers, assuming `SharedPeer` is a predefined struct. |
|
||||
| shared_process_list | Vec<SharedProcess> | | A list of shared processes, assuming `SharedProcess` is a predefined struct. |
|
||||
| faucet_sp_address | String | | The service provider address for a faucet. |
|
||||
| pow | Pow | | Represents a Proof of Work (PoW) challenge, assuming `Pow` is a predefined struct. |
|
||||
|
||||
### 5.4. <a name='Pow'></a>Pow
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|-------------|--------|---------------------------------------------------------|
|
||||
| data_hash | String | | The hash of the data for which the PoW is being solved. |
|
||||
| timestamp | Option<u64> | Yes | An optional timestamp associated with the PoW solution. |
|
||||
| nonce | Option<u64> | Yes | An optional nonce value used in the PoW calculation. |
|
||||
| pattern | String | | The pattern that the PoW solution must match. |
|
||||
| difficulty | usize | | The difficulty level of the PoW challenge. |
|
||||
|
||||
## 6. <a name='Metadata'></a>Metadata
|
||||
|
||||
### 6.1. <a name='MetadataContractPublic'></a>MetadataContractPublic
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|----------|--------|------------------------------------------------------------|
|
||||
| meta_data | MetaData | | Represents the public metadata associated with a contract. |
|
||||
|
||||
### 6.2. <a name='MetadataPrivate'></a>MetadataPrivate
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|----------|--------|------------------------------------------------------------|
|
||||
| meta_data | MetaData | | Represents the private metadata associated with an entity. |
|
||||
|
||||
### 6.3. <a name='MetadataPrivate-1'></a>MetadataPrivate
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|----------|--------|------------------------------------------------------------|
|
||||
| meta_data | MetaData | | Represents the private metadata associated with an entity. |
|
||||
|
||||
### 6.4. <a name='MetadataRoleConfidential'></a>MetadataRoleConfidential
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|----------|--------|-------------------------------------------------------------------------------|
|
||||
| meta_data | MetaData | | Represents the role-specific confidential metadata associated with an entity. |
|
||||
|
||||
### 6.5. <a name='MetaData'></a>MetaDataa
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------|--------------------|--------|----------------------------------------------------------------|
|
||||
| tag_list | Vec<String> | | A list of tags associated with the metadata. |
|
||||
| zone_list | Vec<String> | | A list of zones associated with the metadata. |
|
||||
| label_list | Vec<String> | | A list of labels associated with the metadata. |
|
||||
| ref_list | Vec<String> | | A list of references associated with the metadata. |
|
||||
| data_list | Vec<String> | | A list of data entries associated with the metadata. |
|
||||
| amount | Amount | | An amount associated with the metadata. |
|
||||
| number | Number | | A number associated with the metadata. |
|
||||
| render_template_list | Vec<String> | | A list of render templates associated with the metadata. |
|
||||
| legal_text_list | Vec<String> | | A list of legal texts associated with the metadata. |
|
||||
| key_list | Vec<KeyEncryption> | | A list of key encryption methods associated with the metadata. |
|
||||
|
||||
### 6.6. <a name='Amount'></a>Amount
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|--------------------|-------------|--------|----------------------------------------------------------------------------------|
|
||||
| timestamp | u64 | | A timestamp associated with the amount. |
|
||||
| change_source_list | Vec<String> | | A list of sources for changes to the amount. |
|
||||
| amount_cent | i64 | | The amount in cents, allowing for precise financial transactions. |
|
||||
| amount_unit | String | | The unit of the amount, such as "USD", "EUR", etc. |
|
||||
| amount_unit_ref | String | | A reference to an external unit system, providing context for the `amount_unit`. |
|
||||
|
||||
### 6.7. <a name='Number'></a>Number
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|-----------------------------------------------------------------|
|
||||
| fixed_state | bool | | Indicates whether the number is in a fixed state or can change. |
|
||||
| number | i32 | | The numeric value. |
|
||||
| number_unit | String | | The unit of measurement for the number, if applicable. |
|
||||
|
||||
## 7. <a name='PCD'></a>PCD
|
||||
|
||||
### 7.1. <a name='Pagination'></a>Pagination
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|-------|--------|--------------------------------------------------|
|
||||
| start | usize | | L'indice de départ pour la pagination. |
|
||||
| number | usize | | Le nombre d'éléments par page. |
|
||||
| page_index | usize | | L'indice de la page actuelle pour la pagination. |
|
||||
|
||||
### 7.2. <a name='PcdItemEncAttributePublic'></a>PcdItemEncAttributePublic
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|---------------------------------------------------|
|
||||
| attribute_name | String | | The name of the attribute. |
|
||||
| data_enc | String | | The encrypted data associated with the attribute. |
|
||||
|
||||
### 7.3. <a name='PcdItemEncAttributeRoleConfidential'></a>PcdItemEncAttributeRoleConfidential
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|---------------|--------|---------------------------------------------------|
|
||||
| attribute_name | String | | The name of the attribute. |
|
||||
| data_enc | String | | The encrypted data associated with the attribute. |
|
||||
| key | KeyEncryption | | The key used for encrypting the data. |
|
||||
|
||||
### 7.4. <a name='PcdItemEncAttributePrivate'></a>PcdItemEncAttributePrivate
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|--------|--------|---------------------------------------------------------|
|
||||
| attribute_name | String | | The name of the attribute. |
|
||||
| data_enc | String | | The encrypted data associated with this attribute name. |
|
||||
|
||||
### 7.5. <a name='PcdItemGenericEnc'></a>PcdItemGenericEnc
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------------------|--------------------------------------------------|--------|----------------------------------------------------------|
|
||||
| item_enc | PcdItemEnc | | The encrypted item. |
|
||||
| pcd_item_enc_attribute_public_list | Option<Vec<PcdItemEncAttributePublic>> | Yes | Optional list of public encrypted attributes. |
|
||||
| pcd_item_enc_attribute_role_confidential_list | Option<Vec<PcdItemEncAttributeRoleConfidential>> | Yes | Optional list of role-confidential encrypted attributes. |
|
||||
| pcd_item_enc_attribute_private_list | Option<Vec<PcdItemEncAttributePrivate>> | Yes | Optional list of private encrypted attributes. |
|
||||
|
||||
### 7.6. <a name='PcdItemEnc'></a>PcdItemEnc
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------------------|------------------------------------------|--------|-------------------------------------------------|
|
||||
| version | i64 | | The version of the item. |
|
||||
| item_type | String | | The type of the item. |
|
||||
| name | String | | The name of the item. |
|
||||
| pagination_number_per_pcd | u32 | | The pagination number per PCD. |
|
||||
| pcd_item_enc_attribute_public_list | Vec<PcdItemEncAttributePublic> | | List of public encrypted attributes. |
|
||||
| pcd_item_enc_attribute_role_confidential_list | Vec<PcdItemEncAttributeRoleConfidential> | | List of role-confidential encrypted attributes. |
|
||||
| pcd_item_enc_attribute_private_list | Vec<PcdItemEncAttributePrivate> | | List of private encrypted attributes. |
|
||||
|
||||
### 7.7. <a name='RequestPcd'></a>RequestPcd
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|------------------------|--------|-------------------------------------------------------------------|
|
||||
| request | Request | | The request, assuming `Request` is a predefined struct. |
|
||||
| item_list | Vec<PcdItemGenericEnc> | | List of generic encrypted items. |
|
||||
| pagination | Pagination | | Pagination details, assuming `Pagination` is a predefined struct. |
|
||||
|
||||
## 8. <a name='PRD'></a>PRD
|
||||
|
||||
### 8.1. <a name='RequestPrdConfirm'></a>RequestPrdConfirm
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|-----------------------------------|------------|--------|-----------------------------------------------------|
|
||||
| prd | RequestPrd | | The PRD (Portable Request Document) request. |
|
||||
| code_confirm_enc_by_shared_secret | String | | The confirmation code encrypted by a shared secret. |
|
||||
|
||||
### 8.2. <a name='RequestPrdKeyBackup'></a>RequestPrdKeyBackup
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|------------------------------------------|------------|--------|-----------------------------------------------------------------------------|
|
||||
| prd | RequestPrd | | The PRD (Portable Request Document) request. |
|
||||
| device_footprint_enc_by_sp_shared_secret | String | | The device footprint encrypted by a service provider's shared secret. |
|
||||
| part_1_enc_hash_enc_by_sp_shared_secret | String | | The first part of the hash encrypted by a service provider's shared secret. |
|
||||
| shard_enc_by_sp_shared_secret | String | | The shard encrypted by a service provider's shared secret. |
|
||||
|
||||
### 8.3. <a name='RequestPrdKeyHello'></a>RequestPrdKeyHello
|
||||
|
||||
pub struct RequestPrdKeyHello {
|
||||
pub prd: RequestPrd,
|
||||
pub part_1_enc_hash_enc_by_sp_shared_secret: String,
|
||||
}
|
||||
|
||||
### 8.4. <a name='RequestPrdList'></a>RequestPrdList
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|------------|--------|-----------------------------------------|
|
||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
||||
|
||||
### 8.5. <a name='RequestPrdMessage'></a>RequestPrdMessage
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|------------|--------|-----------------------------------------|
|
||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
||||
|
||||
### 8.6. <a name='RequestPrdList-1'></a>RequestPrdList
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------|------------|--------|-----------------------------------------|
|
||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
||||
|
||||
### 8.7. <a name='RequestPrdResponse'></a>RequestPrdResponse
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|----------------------------------------|-----------------------|--------|--------------------------------------------------------------|
|
||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
||||
| sig_value | String | | The signature value for the response. |
|
||||
| pcd_origin_hash | Option<String> | Yes | Optional hash of the originating PCD. |
|
||||
| payment_method_enc_by_shared_secret | Option<String> | Yes | Encrypted payment method, encrypted with a shared secret. |
|
||||
| deposit_method_enc_by_shared_secret | Option<String> | Yes | Encrypted deposit method, encrypted with a shared secret. |
|
||||
| commitment_method_enc_by_shared_secret | Option<String> | Yes | Encrypted commitment method, encrypted with a shared secret. |
|
||||
| certif_key_enc_by_shared_secret | Option<String> | Yes | Encrypted certification key, encrypted with a shared secret. |
|
||||
| shared_secret_key | Option<KeyEncryption> | Yes | Optional encryption key used for shared secrets. |
|
||||
|
||||
### 8.8. <a name='RequestPrdUpdate'></a>RequestPrdUpdate
|
||||
|
||||
| Attribute Name | Type | Option | Description |
|
||||
|--------------------------|-------------|--------|-----------------------------------------------|
|
||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
||||
| pcd_new_version_hash | String | | The hash of the new version of the PCD. |
|
||||
| payment_pcd_hash_list | Vec<String> | | A list of hashes for payment-related PCDs. |
|
||||
| cap_pcd_hash_list | Vec<String> | | A list of hashes for capability-related PCDs. |
|
||||
| deposit_pcd_hash_list | Vec<String> | | A list of hashes for deposit-related PCDs. |
|
||||
| commitment_pcd_hash_list | Vec<String> | | A list of hashes for commitment-related PCDs. |
|
||||
| ask_payment_method | String | | The requested payment method. |
|
||||
| ask_deposit_method | String | | The requested deposit method. |
|
||||
| ask_commitment_method | String | | The requested commitment method. |
|
||||
|
||||
### 8.9. <a name='KeyRoleConfidential'></a>KeyRoleConfidential
|
||||
|
||||
### 8.10. <a name='RequestPrd'></a>RequestPrd
|
||||
|
||||
### 8.11. <a name='RoleArtefact'></a>RoleArtefact
|
||||
|
||||
### 8.12. <a name='Request'></a>Request
|
||||
|
||||
### 8.13. <a name='RoleDeposit'></a>RoleDeposit
|
||||
|
||||
### 8.14. <a name='RoleCommitment'></a>RoleCommitment
|
||||
|
||||
### 8.15. <a name='RoleMember'></a>RoleMember
|
||||
|
||||
### 8.16. <a name='RolePayment'></a>RolePayment
|
||||
|
||||
### 8.17. <a name='RoleProcess'></a>RoleProcess
|
||||
|
||||
### 8.18. <a name='Role'></a>Role
|
||||
|
||||
### 8.19. <a name='TransactionModeDistribution'></a>TransactionModeDistribution
|
||||
|
||||
### 8.20. <a name='TransactionModeDirect'></a>TransactionModeDirect
|
||||
|
||||
### 8.21. <a name='TransactionMode'></a>TransactionMode
|
||||
|
||||
### 8.22. <a name='RolesGroup'></a>RolesGroup
|
||||
|
||||
### 8.23. <a name='SharedProcess'></a>SharedProcess
|
||||
|
||||
### 8.24. <a name='SharedPeer'></a>SharedPeer
|
||||
|
||||
### 8.25. <a name='Relay'></a>Relay
|
||||
|
||||
### 8.26. <a name='L1Node'></a>L1Node
|
||||
|
||||
### 8.27. <a name='L1Miner'></a>L1Miner
|
||||
|
||||
### 8.28. <a name='L2Node'></a>L2Node
|
||||
|
||||
### 8.29. <a name='L2Certif'></a>L2Certif
|
||||
|
||||
### 8.30. <a name='SharedPeer-1'></a>SharedPeer
|
||||
|
||||
### 8.31. <a name='RolePeer'></a>RolePeer
|
||||
77
doc/Specs-Definition.md
Normal file
77
doc/Specs-Definition.md
Normal file
@ -0,0 +1,77 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Spécifique 4NK](#Spcifique4NK)
|
||||
* 2. [Bitcoin](#Bitcoin)
|
||||
* 3. [Chiffrement](#Chiffrement)
|
||||
* 4. [Data](#Data)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Définitions et abréviations
|
||||
|
||||
## 1. <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 (PCD)**: Format JSON chiffré destiné à contenir les données relatives aux accords entre parties.
|
||||
|
||||
* **Portable Request Document (PRD)**: Format JSON chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des PCD.
|
||||
|
||||
* **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 PRD et PCD 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.
|
||||
|
||||
* **Recover**: Action de recomposer une identité numérique (clés privées).
|
||||
|
||||
* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une adresse Silent Payment indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre.
|
||||
|
||||
* **Onboard**: Action de demander un `rôle` dans un `process`.
|
||||
|
||||
* **Member**: Une adresse Silent Payment, complétée de métadonnées, par `process` et d'une adresse supplémentaire pour la révocation.
|
||||
|
||||
* **Third parties**: Adresses Silent Payment 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 PRD.
|
||||
|
||||
* **ProcessKey**: la clé publique de chiffrement public d'un process (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`.
|
||||
|
||||
## 2. <a name='Bitcoin'></a>Bitcoin
|
||||
|
||||
* **UTXO (Unspent Transaction Output)**: Sortie de transaction non dépensée dans la blockchain, représentant des tokens ou des actifs numériques qui peuvent être utilisés dans de futures transactions.
|
||||
|
||||
* **HD Wallet (Hierarchical Deterministic Wallet)**: Un portefeuille cryptographique qui génère une structure d'arbres de clés à partir d'une graine unique, permettant une gestion sécurisée et organisée des multiples adresses et clés cryptographiques.
|
||||
|
||||
* **Timechain**: Terme préféré à "blockchain", désignant un intervalle de temps régulier entre des blocs de transactions cryptographiques, sécurisées par cryptographie pour une distribution de la sécurité et de l'ordre des événements de façon identique sur l'ensemble du réseau.
|
||||
|
||||
* **Silent Payment (SP)**: Méthode de paiement permettant d'envoyer et de recevoir des fonds sans réutiliser les adresses Bitcoin, améliorant ainsi la confidentialité des transactions.
|
||||
|
||||
## 3. <a name='Chiffrement'></a>Chiffrement
|
||||
|
||||
* **MPC (Multi-Party Computation)**: Technique de calcul qui permet à plusieurs parties de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées secrètes.
|
||||
|
||||
* **SHA256 (Secure Hash Algorithm 256)**: Fonction de hachage cryptographique utilisée pour assurer l'intégrité des données et générer des empreintes uniques des documents.
|
||||
|
||||
* **AES-GCM-256**: Implémente le codage et le décodage Rijndael en conformité avec la norme avancée de chiffrement (AES) du NIST. Il traite des blocs de 256 bits. Le mode Galois/Compteur (Galois/Counter Mode, GCM) est un mode d'opération pour les chiffrements par blocs à clé symétrique largement adopté pour sa performance. L'algorithme GCM fournit à la fois l'authenticité et la confidentialité des données et appartient à la classe des méthodes de chiffrement authentifié avec des données associées.
|
||||
|
||||
* **Diffie-Hellman key exchange**: Méthode d'échange sécurisé de clés cryptographiques sur un canal public, l'un des premiers protocoles de cryptographie à clé publique.
|
||||
|
||||
* **Shamir Secret Sharing**: Algorithme de cryptographie permettant de diviser un secret en plusieurs parties, nécessitant un certain nombre de ces parties pour le reconstituer.
|
||||
|
||||
* **Transport Layer Security**: Protocoles de sécurisation des échanges par réseau informatique, notamment par Internet.
|
||||
|
||||
## 4. <a name='Data'></a>Data
|
||||
|
||||
* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les process découverts et les pairs du réseau. Une fois identifié auprès des membres d'un process et avec son identité `member` récupérée, l'objet member et les PCD et PRD du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée.
|
||||
|
||||
* **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les PCD et PRD, dans les navigateurs web.
|
||||
9
doc/Specs-Deployment.md
Normal file
9
doc/Specs-Deployment.md
Normal file
@ -0,0 +1,9 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Specs - Maintenance, environnement de déploiement
|
||||
|
||||
Voir le git du projet `infra_node`.
|
||||
44
doc/Specs-References.md
Normal file
44
doc/Specs-References.md
Normal file
@ -0,0 +1,44 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [AES & Quantum resistant](#AESQuantumresistant)
|
||||
* 2. [Bitcoin Silent Payment](#BitcoinSilentPayment)
|
||||
* 3. [Bitcoin wallet](#Bitcoinwallet)
|
||||
* 4. [Data anchoring](#Dataanchoring)
|
||||
* 5. [Layers](#Layers)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
# Specs - References
|
||||
|
||||
## 1. <a name='AESQuantumresistant'></a>AES & Quantum resistant
|
||||
|
||||
* <https://medium.com/asecuritysite-when-bob-met-alice/why-is-128-bit-aes-insecure-for-a-quantum-computer-but-256-bit-is-not-814a8a9d6500>
|
||||
|
||||
## 2. <a name='BitcoinSilentPayment'></a>Bitcoin Silent Payment
|
||||
|
||||
* <https://github.com/bitcoin/bitcoin/issues/28536>
|
||||
* <https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki>
|
||||
* <https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki>
|
||||
* <https://gist.github.com/Kixunil/0ddb3a9cdec33342b97431e438252c0a>
|
||||
* <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>
|
||||
* <https://gnusha.org/taproot-bip-review/2020-01-23.log>
|
||||
* <https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406>
|
||||
|
||||
## 3. <a name='Bitcoinwallet'></a>Bitcoin wallet
|
||||
|
||||
* <https://river.com/learn/terms/b/bip-44-derivation-paths-for-p2pkh>
|
||||
* <https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md>
|
||||
* <https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki>
|
||||
|
||||
## 4. <a name='Dataanchoring'></a>Data anchoring
|
||||
|
||||
* <https://petertodd.org/2016/opentimestamps-announcement#fnref:rewrite>
|
||||
* <https://www.lopp.net/bitcoin-information/data-anchor.html>
|
||||
|
||||
## 5. <a name='Layers'></a>Layers
|
||||
|
||||
* <https://blackpaper.rgb.tech/consensus-layer/3.-client-side-validation/3.1.-proof-of-publication>
|
||||
* <https://milan2016.scalingbitcoin.org/files/presentations/D2%20-%20A%20-%20Peter%20Todd.pdf>
|
||||
* <https://www.lopp.net/bitcoin-information/other-layers.html>
|
||||
202
doc/Specs-Security-confidentiality.md
Normal file
202
doc/Specs-Security-confidentiality.md
Normal file
@ -0,0 +1,202 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Détails de conception](#Dtailsdeconception)
|
||||
* 1. [Mot de passe](#Motdepasse)
|
||||
* 2. [Cache](#Cache)
|
||||
* 3. [Chiffrement des communications](#Chiffrementdescommunications)
|
||||
* 4. [Confidentialité des PCD et PRD](#ConfidentialitdesPCDetPRD)
|
||||
* 5. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
|
||||
* 6. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
|
||||
* 6.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
|
||||
* 6.2. [Diffusion et confusion](#Diffusionetconfusion)
|
||||
* 6.3. [Non-linéarité](#Non-linarit)
|
||||
* 7. [Fonctions de hashage](#Fonctionsdehashage)
|
||||
* 8. [Exigences génériques](#Exigencesgnriques)
|
||||
* 8.1. [Pas de secret de la conception](#Pasdesecretdelaconception)
|
||||
* 8.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique)
|
||||
* 8.3. [Implémentation correcte](#Implmentationcorrecte)
|
||||
* 8.4. [Détermination](#Dtermination)
|
||||
* 8.5. [Rapidité de calcul](#Rapiditdecalcul)
|
||||
* 8.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche)
|
||||
* 8.7. [Résistance aux collisions](#Rsistanceauxcollisions)
|
||||
* 8.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles)
|
||||
* 8.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes)
|
||||
* 8.8. [Résistance à la pré-image](#Rsistancelapr-image)
|
||||
* 8.8.1. [Résistance à la pré-image](#Rsistancelapr-image-1)
|
||||
* 8.8.2. [Résistance à la seconde pré-image](#Rsistancelasecondepr-image)
|
||||
* 8.9. [Compression](#Compression)
|
||||
* 8.10. [Non réversibilité](#Nonrversibilit)
|
||||
* 8.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible)
|
||||
* 9. [Gestion sécurisée des clés](#Gestionscurisedescls)
|
||||
* 10. [Performance](#Performance)
|
||||
* 11. [Disponibilité](#Disponibilit)
|
||||
* 12. [Évolutivité](#volutivit)
|
||||
* 13. [Autres Mesures de sécurité](#AutresMesuresdescurit)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Exigences de sécurité et de confidentialité
|
||||
|
||||
|
||||
|
||||
### 1. <a name='Dtailsdeconception'></a>Détails de conception
|
||||
|
||||
Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits.
|
||||
|
||||
Tous les hash sont opérés avec l'algorithme SHA256.
|
||||
|
||||
La librairie Rust `Nakamoto`, permet de scanner les blocs (et bientôt la mempool) côté client et de détecter des transactions Bitcoin correspondant aux clés publiques des clés cryptographiques privées du HD Wallet Bitcoin contenant les clés Bitcoin de mainnet et de signet.
|
||||
|
||||
## 1. <a name='Motdepasse'></a>Mot de passe
|
||||
|
||||
Utilisation du mot de passe strictement en mémoire.
|
||||
|
||||
Mot de passe fort (18 caractères minimum avec minuscules, majuscules, lettre, nombres, et caractères spéciaux) ou mnémonique de 12 mots à noter ou certificat (ou équivalent) stocké de façon sécurisée.
|
||||
|
||||
## 2. <a name='Cache'></a>Cache
|
||||
|
||||
Stockage sécurisé du cache par un chiffrement par le mot de passe.
|
||||
|
||||
## 3. <a name='Chiffrementdescommunications'></a>Chiffrement des communications
|
||||
|
||||
Le chiffrement du transport des données se fait par TLS entre les clients et le noeuds entrants pour palier aux restrictions sur les flux non TLS par les navigateurs et les applications mobiles.
|
||||
|
||||
Néanmoins tous les messages chiffrent les PCD et PRD avec une clé de chiffrement conforme aux exigences suivantes et échangée dans le Diffie-Hellman de la transaction SP, en parallèle donc des flux PCD et PRD. Ces clés ne sont accessibles donc qu'avec la clé privée du destinataire ou de l'émetteur, qui ne sont jamais partagées.
|
||||
|
||||
## 4. <a name='ConfidentialitdesPCDetPRD'></a>Confidentialité des PCD et PRD
|
||||
|
||||
Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes.
|
||||
|
||||
Le chiffrement des PCD est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des clés de chiffrement dans les PRD est un chiffrement symétrique conformément aux exigences suivantes selon :
|
||||
|
||||
- **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer.
|
||||
|
||||
|
||||
- **Données confidentielles avec les membres d'un `role` d'un `process` dans les PCD**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un PCD.
|
||||
|
||||
- **Données confidentielles avec les membres d'un `role` d'un `process` dans les PRD**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les PCD et alors transmises par le PRD, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
|
||||
|
||||
- **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs).
|
||||
|
||||
## 5. <a name='Confidentialitdesmessagessurlesrelais'></a>Confidentialité des messages sur les relais
|
||||
|
||||
Les PCD et les PRD sont envoyés aux relais dans des enveloppes appelées `Message`.
|
||||
|
||||
Ces enveloppent communique les `PCD` et les `PRD` de façon chiffrée par la `ProcessKey`. Ainsi les messages sont rendus fongibles sur le réseau de relais.
|
||||
|
||||
Tous les `PRD` (sauf les `PRDKeyBackup`), sont confirmés par un et chiffrent les clés transamises par une `KeyConfiditial`.
|
||||
|
||||
Les relais peuvent déchiffrer les enveloppes avec la `ProcessKey`, le contenu étant chiffré en plus en fonction des niveaux de confidentialité. L'objectif du chiffrage des enveloppe est de donner, un temps, un coût et une complexité aux analyses systématiques des flux.
|
||||
|
||||
## 6. <a name='Cldechiffrementrobuste'></a>Clé de chiffrement robuste
|
||||
|
||||
La force d'un algorithme de chiffrement symétrique repose largement sur la complexité de sa clé. Une clé plus longue offre généralement une meilleure sécurité. Les tailles de clé typiques pour un chiffrement fort sont de 128 bits, 192 bits, ou 256 bits. Pour l'AES-GCM, les clés de 256 bits sont à ce stade réputées "quantum-resistant" et sont donc à privilégier, elles satisfont aussi les contraintes suivantes.
|
||||
|
||||
### 6.1. <a name='Rsistanceauxattaquescryptanalytiques'></a>Résistance aux attaques cryptanalytiques
|
||||
|
||||
Un algorithme fort doit résister à diverses attaques, y compris les attaques par force brute (où un attaquant essaie toutes les clés possibles), les attaques par texte clair connu, les attaques par texte clair choisi, les attaques par texte chiffré choisi, et plus encore. L'AES-GCM les clés de 256 bits n'est pas par design robuste à ces attaques, mais avec une clé suffisamment longue (de longueur quantique) le temps nécessaire est estimé comme équivalent à une résistance.
|
||||
|
||||
### 6.2. <a name='Diffusionetconfusion'></a>Diffusion et confusion
|
||||
|
||||
Ces deux principes, introduits par Claude Shannon, sont essentiels à la sécurité d'un algorithme. La diffusion vise à disperser l'influence d'un seul caractère du texte clair sur de nombreux caractères du texte chiffré, tandis que la confusion vise à complexifier la relation entre la clé de chiffrement et le texte chiffré.
|
||||
|
||||
### 6.3. <a name='Non-linarit'></a>Non-linéarité
|
||||
|
||||
L'algorithme doit incorporer des éléments non linéaires pour contrer les attaques linéaires et différentielles. Cela rend la prédiction du comportement de l'algorithme plus difficile pour un attaquant.
|
||||
|
||||
## 7. <a name='Fonctionsdehashage'></a>Fonctions de hashage
|
||||
|
||||
Les fonctions de hachage jouent un rôle crucial dans de nombreux domaines de la cryptographie et de la sécurité informatique, notamment dans la vérification de l'intégrité des données, l'authentification, la signature numérique, et la génération de jetons sécurisés. Pour être efficaces et sécurisées, ces fonctions doivent répondre à plusieurs exigences essentielles :
|
||||
|
||||
## 8. <a name='Exigencesgnriques'></a>Exigences génériques
|
||||
|
||||
### 8.1. <a name='Pasdesecretdelaconception'></a>Pas de secret de la conception
|
||||
|
||||
La sécurité d'un bon système cryptographique ne doit pas reposer sur le secret de son algorithme (principe de Kerckhoffs) et doit être basée sur des principes cryptographiques éprouvés.
|
||||
|
||||
### 8.2. <a name='Validparlacommunautscientifique'></a>Validé par la communauté scientifique
|
||||
|
||||
Un algorithme est considéré comme plus fort s'il a été soumis à l'examen et à l'analyse de la communauté cryptographique internationale, qui cherche des vulnérabilités potentielles.
|
||||
|
||||
### 8.3. <a name='Implmentationcorrecte'></a>Implémentation correcte
|
||||
|
||||
Une implémentation fautive d'un algorithme de chiffrement fort peut introduire des vulnérabilités. Il est crucial que l'implémentation soit vérifiée pour être sécurisée. La librairie utilisée doit avoir été l'objet d'un audit ([librairie aes-gcm de rust a été auditée](https://research.nccgroup.com/2020/02/26/public-report-rustcrypto-aes-gcm-and-chacha20poly1305-implementation-review/)).
|
||||
|
||||
### 8.4. <a name='Dtermination'></a>Détermination
|
||||
|
||||
Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie.
|
||||
|
||||
### 8.5. <a name='Rapiditdecalcul'></a>Rapidité de calcul
|
||||
|
||||
La fonction doit être capable de générer le hachage rapidement, même pour de grandes quantités de données.
|
||||
|
||||
### 8.6. <a name='Diffusionoueffetavalanche'></a>Diffusion (ou effet avalanche)
|
||||
|
||||
Un changement minime dans l'entrée (même un seul bit) doit entraîner un changement significatif et imprévisible dans la sortie. Cela garantit qu'il est difficile de prédire comment la sortie changera en fonction des modifications apportées à l'entrée.
|
||||
|
||||
### 8.7. <a name='Rsistanceauxcollisions'></a>Résistance aux collisions
|
||||
|
||||
Il doit être pratiquement impossible de trouver deux entrées distinctes qui produisent la même sortie. Cela se décline en deux sous-catégories :
|
||||
|
||||
#### 8.7.1. <a name='Rsistanceauxcollisionsfaibles'></a>Résistance aux collisions faibles
|
||||
|
||||
Il est difficile de trouver une seconde entrée qui a le même hachage qu'une entrée spécifiée.
|
||||
|
||||
#### 8.7.2. <a name='Rsistanceauxcollisionsfortes'></a>Résistance aux collisions fortes
|
||||
|
||||
Il est difficile de trouver deux entrées distinctes qui produisent le même hachage.
|
||||
|
||||
### 8.8. <a name='Rsistancelapr-image'></a>Résistance à la pré-image
|
||||
|
||||
Pour une sortie de hachage donnée, il doit être difficile de trouver une entrée qui correspond à cette sortie. Cela se décline également en deux sous-catégories :
|
||||
|
||||
#### 8.8.1. <a name='Rsistancelapr-image-1'></a>Résistance à la pré-image
|
||||
|
||||
Il est difficile de trouver une entrée qui hache vers une sortie de hachage spécifiée.
|
||||
|
||||
#### 8.8.2. <a name='Rsistancelasecondepr-image'></a>Résistance à la seconde pré-image
|
||||
|
||||
Étant donné une entrée, il est difficile de trouver une autre entrée qui produit le même hachage.
|
||||
|
||||
### 8.9. <a name='Compression'></a>Compression
|
||||
|
||||
La fonction de hachage doit pouvoir prendre une entrée de taille arbitraire et produire une sortie de taille fixe.
|
||||
|
||||
### 8.10. <a name='Nonrversibilit'></a>Non réversibilité
|
||||
|
||||
Il doit être infaisable de retrouver l'entrée à partir de la sortie du hachage. Cela signifie que la fonction est à sens unique.
|
||||
|
||||
### 8.11. <a name='Absencedetoutestructureprvisible'></a>Absence de toute structure prévisible
|
||||
|
||||
La fonction de hachage ne doit pas produire des sorties qui montrent des patterns ou des structures prévisibles, quelles que soient les entrées.
|
||||
|
||||
## 9. <a name='Gestionscurisedescls'></a>Gestion sécurisée des clés
|
||||
|
||||
La manière dont les clés sont générées, stockées, distribuées, révoquées, et détruites est tout aussi importante que l'algorithme de chiffrement lui-même.
|
||||
|
||||
Les clés seront générées strictement par l'utilisateur et feront l'objet d'un traitement `MPC` avec un chiffrement des parties par le mot de passe connu de l'utilisateur seul et jamais stocké.
|
||||
|
||||
Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `process` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande.
|
||||
|
||||
L'utilisateur seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé.
|
||||
|
||||
## 10. <a name='Performance'></a>Performance
|
||||
|
||||
Le temps de réponse doit être rapide pour les opérations de login. Ce temps sera estimé de façon empirique au fur et à mesure des implémentations.
|
||||
|
||||
## 11. <a name='Disponibilit'></a>Disponibilité
|
||||
|
||||
La haute disponibilité et la reprise après sinistre sont permises par la redondance des `relais` sans système central ou critique et robustes à la défaillance d'une partie des participants. C'est idem pour la redondance au sein des `membres` des gestionnaires des membres dans les `processus`, qui ont tous des actions égales et robustes à la défaillance d'une partie des participants.
|
||||
|
||||
En cas de perte, vol, corruption, ou expiration des clés, l'utilisateur peut de son initiative et en toute autonomie révoquer une identité et en générer une nouvelle.
|
||||
|
||||
## 12. <a name='volutivit'></a>Évolutivité
|
||||
|
||||
La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `process`.
|
||||
|
||||
## 13. <a name='AutresMesuresdescurit'></a>Autres Mesures de sécurité
|
||||
|
||||
Les mécanismes de défense contre les vulnérabilités courantes doivent être implémentés (CSRF, XSS).
|
||||
|
||||
À noter, que les seules bases de données sont dans l'IndexedDB des navigateurs et applications mobiles, côté utilisateur et écrasées des données confirmées reçues du réseau et toutes vérifiables. Tous les autres composants et utilisateurs ont un stockage en mémoire, non persisté (mais restauré à leur propre récupération de leur identité).
|
||||
575
doc/allstructs_tmp.rs
Normal file
575
doc/allstructs_tmp.rs
Normal file
@ -0,0 +1,575 @@
|
||||
pub struct CommitmentMethod {
|
||||
pub method: String,
|
||||
}
|
||||
|
||||
pub struct ConditionCap {
|
||||
pub role_deposit: String,
|
||||
pub role_transaction: TransactionMode,
|
||||
}
|
||||
|
||||
pub struct ConditionCommitment {
|
||||
pub role_artefact: String,
|
||||
pub role_transaction: TransactionMode,
|
||||
}
|
||||
|
||||
pub struct ConditionDeposit {
|
||||
pub role_deposit: String,
|
||||
pub role_transaction: TransactionMode,
|
||||
}
|
||||
|
||||
pub struct ConditionOrchestration {
|
||||
pub role_ok: String,
|
||||
pub role_ko: String,
|
||||
}
|
||||
|
||||
pub struct ConditionPayment {
|
||||
pub role_payment: String,
|
||||
pub role_transaction: TransactionMode,
|
||||
}
|
||||
|
||||
pub struct ConditionPrdAddressSet {
|
||||
pub from_role: String,
|
||||
pub prd_sp_address_list: Vec<String>,
|
||||
pub prd_sp_address_required_list: Vec<String>,
|
||||
pub prd_sp_address_quota: i32,
|
||||
pub prd_prd_value_ok_list: Vec<String>,
|
||||
pub prd_value_ko_list: Vec<String>,
|
||||
pub prd_value_none_list: Vec<String>,
|
||||
pub prd_sp_address_value_min: i64,
|
||||
pub prd_sp_address_value_min_per: i64,
|
||||
pub prd_sp_address_value_min_ok: bool,
|
||||
pub prd_sp_adddress_value_ok_min_per: i64,
|
||||
pub prd_sp_address_value_ok_max: i64,
|
||||
pub prd_sp_adderss_value_ko_max_per: i64,
|
||||
pub prd_sp_address_value_none_max: i64,
|
||||
pub prd_sp_adderss_value_none_max_per: i64,
|
||||
pub prd_sp_address_score_min: i32,
|
||||
pub prd_sp_address_score_min_min_required: i32,
|
||||
pub prd_sp_address_score_min_min_ok: bool,
|
||||
pub prd_sp_address_score_min_min_per: i64,
|
||||
pub prd_value_auto_ok: bool,
|
||||
pub prd_value_auto_ko: bool,
|
||||
pub prd_value_auto_none: bool,
|
||||
}
|
||||
|
||||
pub struct ConditionPublish {
|
||||
pub pcd_data_size_max_unit: String,
|
||||
pub pcd_data_size_max_total: i64,
|
||||
pub pcd_number_min: i32,
|
||||
pub pcd_number_max: i32,
|
||||
pub pcd_amount_max_total: Amount,
|
||||
pub prd_waiting_timeout: u64,
|
||||
pub pcd_waiting_timeout: u64,
|
||||
}
|
||||
|
||||
pub struct DepositMethod {
|
||||
pub method: String,
|
||||
}
|
||||
|
||||
pub struct ItemArtefact {
|
||||
pub item: Item,
|
||||
pub public_attribute_group: Vec<String>, // Assuming list of attributes
|
||||
pub role_confidential_attribute_group: Vec<String>,
|
||||
pub private_attribute_group: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemCommitmentPublicAttributeGroup {
|
||||
pub for_sp_address_list: Vec<String>,
|
||||
pub goal_list: Vec<String>,
|
||||
pub provider_type: String,
|
||||
pub commitment_pcd_hash_list: Vec<String>,
|
||||
pub ref_item_hash_list: Vec<String>,
|
||||
pub ref_pcd_hash_list: Vec<String>,
|
||||
pub payload_public_list: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemMemberPublicAttributeGroup {
|
||||
pub sp_address_public: String,
|
||||
pub sp_address_public_sig: String,
|
||||
pub sp_address_revoke_public: String,
|
||||
pub sp_address_revoke_public_sig: String,
|
||||
pub third_sp_address_list_public: Vec<String>,
|
||||
pub data_size_max: i64,
|
||||
pub payment_method_list_public: Vec<String>,
|
||||
pub succession_process_hash: String,
|
||||
}
|
||||
|
||||
pub struct ItemCommitmentPublicAttributeGroup {
|
||||
pub for_sp_address_list: Vec<String>,
|
||||
pub goal_list: Vec<String>,
|
||||
pub provider_type: String,
|
||||
pub commitment_pcd_hash_list: Vec<String>,
|
||||
pub ref_item_hash_list: Vec<String>,
|
||||
pub ref_pcd_hash_list: Vec<String>,
|
||||
pub payload_public_list: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemDepositPublicAttributeGroup {
|
||||
pub for_sp_address_list: Vec<String>,
|
||||
pub for_address_list: Vec<String>,
|
||||
pub goal_list: Vec<String>,
|
||||
pub provider_type: String,
|
||||
pub ref_item_hash_list: Vec<String>,
|
||||
pub ref_pcd_hash_list: Vec<String>,
|
||||
pub payload_list_public: Vec<String>,
|
||||
pub audit_code_list_public: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemCommitmentRoleConfidentialAttributeGroup {
|
||||
pub payload_list_confidential: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemCommitmentPrivateAttributeGroup {
|
||||
pub payload_list_private: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemCommitment {
|
||||
pub item: Item,
|
||||
pub public_attribute_group: ItemCommitmentPublicAttributeGroup,
|
||||
pub role_confidential_attribute_group: ItemCommitmentRoleConfidentialAttributeGroup,
|
||||
pub private_attribute_group: ItemCommitmentPrivateAttributeGroup,
|
||||
}
|
||||
|
||||
pub struct ItemDepositRoleConfidentialAttributeGroup {
|
||||
pub payload_list_confidential: Vec<String>,
|
||||
pub audit_code_list_confidential: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemDepositPrivateAttributeGroup {
|
||||
pub payload_list_private: Vec<String>,
|
||||
pub audit_code_private: String,
|
||||
}
|
||||
|
||||
pub struct ItemDeposit {
|
||||
pub item: Item,
|
||||
pub public_attribute_group: ItemDepositPublicAttributeGroup,
|
||||
pub role_confidential_attribute_group: ItemDepositRoleConfidentialAttributeGroup,
|
||||
pub private_attribute_group: ItemDepositPrivateAttributeGroup,
|
||||
}
|
||||
|
||||
pub enum ItemEnum {
|
||||
Process(ItemProcess),
|
||||
Peer(ItemPeer),
|
||||
Member(ItemMember),
|
||||
Payment(ItemPayment),
|
||||
Deposit(ItemDeposit),
|
||||
Artefact(ItemArtefact),
|
||||
Commitment(ItemCommitment),
|
||||
}
|
||||
|
||||
pub struct ItemPaymentPublicAttributeGroup {
|
||||
pub for_sp_address_list: Vec<String>,
|
||||
pub goal_list: Vec<String>,
|
||||
pub provider_type: String,
|
||||
pub commitment_pcd_hash_list: Vec<String>,
|
||||
pub order_pcd_hash_list: Vec<String>,
|
||||
pub invoice_pcd_hash_list: Vec<String>,
|
||||
pub pay_pcd_hash_list: Vec<String>,
|
||||
pub ref_item_hash_list: Vec<String>,
|
||||
pub ref_pcd_hash_list: Vec<String>,
|
||||
pub payload_list_public: Vec<String>,
|
||||
pub audit_code_list_public: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemPaymentRoleConfidentialAttributeGroup {
|
||||
pub payload_list_confidential: Vec<String>,
|
||||
pub audit_code_list_confidential: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemPaymentPrivateAttributeGroup {
|
||||
pub payload_list_private: Vec<String>,
|
||||
pub audit_code_private: String,
|
||||
}
|
||||
|
||||
pub struct ItemPayment {
|
||||
pub item: Item,
|
||||
pub public_attribute_group: ItemPaymentPublicAttributeGroup,
|
||||
pub role_confidential_attribute_group: ItemPaymentRoleConfidentialAttributeGroup,
|
||||
pub private_attribute_group: ItemPaymentPrivateAttributeGroup,
|
||||
}
|
||||
|
||||
pub struct ItemPeerPublicAttributeGroup {
|
||||
pub sp_address: String,
|
||||
pub domain: String,
|
||||
pub ip_address: String,
|
||||
pub pow_difficulty: u32,
|
||||
pub pow_pattern: String,
|
||||
pub pow_prefix: String,
|
||||
pub data_size_max: i64,
|
||||
pub timestamp_delay_max: u64,
|
||||
pub daily_hash_list: Vec<String>,
|
||||
pub daily_sp_tx_mine_list: Vec<String>,
|
||||
pub daily_sp_tx_mine_reward_list: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct ItemPeerPrivateAttributeGroup {
|
||||
pub config: String, // Assuming it's a simple string for now
|
||||
}
|
||||
|
||||
pub struct ItemPeer {
|
||||
pub item: Item,
|
||||
pub layer_list: Vec<String>,
|
||||
pub public_attribute_group: ItemPeerPublicAttributeGroup,
|
||||
pub private_attribute_group: ItemPeerPrivateAttributeGroup,
|
||||
}
|
||||
|
||||
pub struct ItemProcess {
|
||||
pub item: Item,
|
||||
pub item_process_public_attribute_group: ItemProcessPublicAttributeGroup,
|
||||
}
|
||||
|
||||
pub struct ItemProcessPublicAttributeGroup {
|
||||
// Fields for public attributes
|
||||
// Example field
|
||||
pub roles_group: RolesGroup,
|
||||
}
|
||||
|
||||
pub struct Item {
|
||||
pub uuid: String,
|
||||
pub version: i64,
|
||||
pub hash: Option<String>,
|
||||
pub item_type: String, // `type` is a reserved keyword in Rust, renamed to `item_type`
|
||||
pub name: String,
|
||||
pub pagination_number_per_pcd: u32,
|
||||
pub metadata_contract_public: MetadataContractPublic,
|
||||
pub metadata_role_confidential: MetadataRoleConfidential,
|
||||
pub metadata_private: MetadataPrivate,
|
||||
}
|
||||
|
||||
pub struct KeyEncryption {
|
||||
pub attribute_name: Option<String>,
|
||||
pub key: Option<String>,
|
||||
pub algorithm: Option<String>,
|
||||
}
|
||||
|
||||
pub struct Aes256GcmIv96Bit {
|
||||
pub key: GenericArray<u8, U32>,
|
||||
}
|
||||
|
||||
pub struct MessageClient {
|
||||
pub message: Message, // Assuming Message is a predefined struct
|
||||
pub request_enc: String,
|
||||
pub request_hash: String,
|
||||
}
|
||||
|
||||
pub struct MessageConnect {
|
||||
pub message: Message, // Assuming Message is a predefined struct
|
||||
}
|
||||
|
||||
pub struct Message {
|
||||
pub shared_peer_list: Vec<SharedPeer>,
|
||||
pub shared_process_list: Vec<SharedProcess>,
|
||||
pub faucet_sp_address: String,
|
||||
pub pow: Pow, // Assuming Pow is a predefined struct
|
||||
}
|
||||
|
||||
pub struct Pow {
|
||||
pub data_hash: String,
|
||||
timestamp: Option<u64>,
|
||||
pub nonce: Option<u64>,
|
||||
pub pathern: String,
|
||||
pub difficulty: usize,
|
||||
}
|
||||
|
||||
pub struct MetadataContractPublic {
|
||||
pub meta_data: MetaData,
|
||||
}
|
||||
|
||||
pub struct MetadataPrivate {
|
||||
pub meta_data: MetaData,
|
||||
}
|
||||
|
||||
pub struct MetadataRoleConfidential {
|
||||
pub meta_data: MetaData,
|
||||
}
|
||||
|
||||
pub struct MetaData {
|
||||
pub tag_list: Vec<String>,
|
||||
pub zone_list: Vec<String>,
|
||||
pub label_list: Vec<String>,
|
||||
pub ref_list: Vec<String>,
|
||||
pub data_list: Vec<String>,
|
||||
pub amount: Amount,
|
||||
pub number: Number,
|
||||
pub render_template_list: Vec<String>,
|
||||
pub legal_text_list: Vec<String>,
|
||||
pub key_list: Vec<KeyEncryption>,
|
||||
}
|
||||
|
||||
pub struct Amount {
|
||||
pub timestamp: u64,
|
||||
pub change_source_list: Vec<String>,
|
||||
pub amount_cent: i64,
|
||||
pub amount_unit: String,
|
||||
pub amount_unit_ref: String, // This can be a reference to an external unit system.
|
||||
}
|
||||
|
||||
pub struct Number {
|
||||
pub fixed_state: bool,
|
||||
pub number: i32,
|
||||
pub number_unit: String,
|
||||
}
|
||||
|
||||
pub struct Pagination {
|
||||
pub start: usize,
|
||||
pub number: usize,
|
||||
pub page_index: usize,
|
||||
}
|
||||
|
||||
pub struct PaymentMethod {
|
||||
pub method: String,
|
||||
}
|
||||
|
||||
pub struct PcdItemEncAttributePrivate {
|
||||
pub attribute_name: String,
|
||||
pub data_enc: String, // Assuming the encrypted data is represented as a String
|
||||
}
|
||||
|
||||
pub struct PcdItemEncAttributePublic {
|
||||
pub attribute_name: String,
|
||||
pub data_enc: String, // Assuming the encrypted data is represented as a String
|
||||
}
|
||||
|
||||
pub struct PcdItemEncAttributeRoleConfidential {
|
||||
pub attribute_name: String,
|
||||
pub data_enc: String, // Assuming the encrypted data is represented as a String
|
||||
pub key: KeyEncryption, // Assuming the encrypted data is represented as a String
|
||||
}
|
||||
|
||||
pub struct PcdItemGenericEnc {
|
||||
pub item_enc: PcdItemEnc,
|
||||
pub pcd_item_enc_attribute_public_list: Option<Vec<PcdItemEncAttributePublic>>,
|
||||
pub pcd_item_enc_attribute_role_confidential_list:
|
||||
Option<Vec<PcdItemEncAttributeRoleConfidential>>,
|
||||
pub pcd_item_enc_attribute_private_list: Option<Vec<PcdItemEncAttributePrivate>>,
|
||||
}
|
||||
|
||||
pub struct PcdItemEnc {
|
||||
pub version: i64,
|
||||
pub item_type: String,
|
||||
pub name: String,
|
||||
pub pagination_number_per_pcd: u32,
|
||||
pub pcd_item_enc_attribute_public_list: Vec<PcdItemEncAttributePublic>,
|
||||
pub pcd_item_enc_attribute_role_confidential_list: Vec<PcdItemEncAttributeRoleConfidential>,
|
||||
pub pcd_item_enc_attribute_private_list: Vec<PcdItemEncAttributePrivate>,
|
||||
}
|
||||
|
||||
pub struct RequestPcd {
|
||||
pub request: Request,
|
||||
pub item_list: Vec<PcdItemGenericEnc>,
|
||||
pub pagination: Pagination,
|
||||
}
|
||||
|
||||
pub struct RequestPrdConfirm {
|
||||
pub prd: RequestPrd,
|
||||
pub code_confirm_enc_by_shared_secret: String,
|
||||
}
|
||||
|
||||
pub struct RequestPrdKeyBackup {
|
||||
pub prd: RequestPrd,
|
||||
pub device_footprint_enc_by_sp_shared_secret: String,
|
||||
pub part_1_enc_hash_enc_by_sp_shared_secret: String,
|
||||
pub shard_enc_by_sp_shared_secret: String,
|
||||
}
|
||||
|
||||
pub struct RequestPrdKeyHello {
|
||||
pub prd: RequestPrd,
|
||||
pub part_1_enc_hash_enc_by_sp_shared_secret: String,
|
||||
}
|
||||
|
||||
pub struct RequestPrdList {
|
||||
pub prd: RequestPrd,
|
||||
}
|
||||
|
||||
pub struct RequestPrdMessage {
|
||||
pub prd: RequestPrd,
|
||||
}
|
||||
|
||||
pub struct RequestPrdResponse {
|
||||
pub prd: RequestPrd,
|
||||
pub sig_value: String,
|
||||
pub pcd_origin_hash: Option<String>,
|
||||
pub payment_method_enc_by_shared_secret: Option<String>,
|
||||
pub deposit_method_enc_by_shared_secret: Option<String>,
|
||||
pub commitment_method_enc_by_shared_secret: Option<String>,
|
||||
pub certif_key_enc_by_shared_secret: Option<String>,
|
||||
pub shared_secret_key: Option<KeyEncryption>,
|
||||
}
|
||||
|
||||
pub struct RequestPrdUpdate {
|
||||
pub prd: RequestPrd,
|
||||
pub pcd_new_version_hash: String,
|
||||
pub payment_pcd_hash_list: Vec<String>,
|
||||
pub cap_pcd_hash_list: Vec<String>,
|
||||
pub deposit_pcd_hash_list: Vec<String>,
|
||||
pub commitment_pcd_hash_list: Vec<String>,
|
||||
pub ask_payment_method: String,
|
||||
pub ask_deposit_method: String,
|
||||
pub ask_commitment_method: String,
|
||||
}
|
||||
|
||||
pub struct KeyRoleConfidential {
|
||||
pub attribute_name: String,
|
||||
pub key: KeyEncryption,
|
||||
pub algorithm_name: String,
|
||||
}
|
||||
|
||||
pub struct RequestPrd {
|
||||
pub request: Request, // Assuming Request is a predefined struct
|
||||
pub pcd_keys_role_confidential_list_enc_by_shared_secret: String,
|
||||
pub message_public: Option<String>,
|
||||
pub message_confidential: Option<String>,
|
||||
pub message_private: Option<String>,
|
||||
pub sp_address_to: String,
|
||||
pub sp_address_from: String,
|
||||
pub sp_address_reply: String,
|
||||
pub timestamp_declared: u64, // Assuming a Unix timestamp
|
||||
pub role_name_from: String,
|
||||
pub role_name_to: String,
|
||||
}
|
||||
|
||||
pub struct RoleArtefact {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct Request {
|
||||
pub item_name: Option<String>,
|
||||
pub request_type: String, // `type` is a reserved keyword in Rust, renamed to `request_type`
|
||||
pub version: i64,
|
||||
pub process_hash: String,
|
||||
pub pcd_reference_hash: Option<String>,
|
||||
pub item_reference_hash: Option<String>,
|
||||
}
|
||||
|
||||
pub struct RoleDeposit {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct RoleCommitment {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct RoleMember {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct RolePayment {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct RoleProcess {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
|
||||
pub struct Role {
|
||||
pub item: Item,
|
||||
pub required_2fa: bool,
|
||||
pub validation_timeout: u64,
|
||||
pub condition_prd_address_set_list: Vec<ConditionPrdAddressSet>, // Assuming ConditionPrdAddressSet is a predefined struct
|
||||
pub condition_publish: ConditionPublish, // Assuming ConditionPublish is a predefined struct
|
||||
pub condition_cap_list: Vec<ConditionCap>, // Assuming ConditionCap is a predefined struct
|
||||
pub condition_payment_list: Vec<ConditionPayment>, // Assuming ConditionPayment is a predefined struct
|
||||
pub condition_commitment_list: Vec<ConditionCommitment>, // Assuming ConditionCommitment is a predefined struct
|
||||
pub condition_attribute_encryption_list: Vec<String>,
|
||||
pub condition_orchestration: ConditionOrchestration, // Assuming ConditionOrchestration is a predefined struct
|
||||
pub role_succession: Option<String>,
|
||||
pub role_resolve: Option<String>,
|
||||
pub role_renew: Option<String>,
|
||||
}
|
||||
|
||||
pub struct TransactionModeDistribution {
|
||||
pub from_prd_update_from: String,
|
||||
pub from_role_list: Vec<String>,
|
||||
pub to_role_list: Vec<String>,
|
||||
pub from_prd_address_list: Vec<String>,
|
||||
pub to_prd_address_list: Vec<String>,
|
||||
pub method: String,
|
||||
}
|
||||
|
||||
pub struct TransactionModeDirect {
|
||||
pub from_prd_update_from: String,
|
||||
pub to_role_owner: String,
|
||||
}
|
||||
|
||||
pub struct TransactionMode {
|
||||
pub amount: Amount,
|
||||
pub role_transaction_distribution: TransactionModeDistribution,
|
||||
pub role_transaction_direct: TransactionModeDirect,
|
||||
}
|
||||
|
||||
pub struct RolesGroup {
|
||||
pub role_peer: RolePeer,
|
||||
pub role_member: RoleMember,
|
||||
pub role_process: RoleProcess,
|
||||
pub role_artefact_list: Vec<RoleArtefact>,
|
||||
}
|
||||
|
||||
pub struct SharedProcess {
|
||||
pub hash: String,
|
||||
pub key: KeyEncryption,
|
||||
pub role_process_sp_address_list: Vec<String>,
|
||||
}
|
||||
|
||||
pub struct SharedPeer {
|
||||
pub domain: String,
|
||||
pub address_ip: String,
|
||||
pub relay: Relay,
|
||||
pub l1_node: L1Node,
|
||||
pub l1_miner: L1Miner,
|
||||
pub l2_node: L2Node,
|
||||
pub l2_certif: L2Certif,
|
||||
}
|
||||
|
||||
pub struct Relay {
|
||||
pub address_port: u16,
|
||||
pub data_max_size: usize,
|
||||
pub pow_difficulty: u32,
|
||||
pub pow_pattern: String,
|
||||
pub pow_prefix: String,
|
||||
}
|
||||
|
||||
pub struct L1Node {
|
||||
pub address_port: u16,
|
||||
pub explorer_base_url: String,
|
||||
pub sp_address_anchorage: String,
|
||||
pub sp_address_reward: String,
|
||||
}
|
||||
|
||||
pub struct L1Miner {
|
||||
pub sp_address_rewarder: String,
|
||||
}
|
||||
|
||||
pub struct L2Node {
|
||||
pub address_port: u16,
|
||||
pub explorer_base_url: String,
|
||||
pub sp_address_anchorage: String,
|
||||
pub sp_address_reward: String,
|
||||
pub nbits: u32,
|
||||
pub magic_number: u32,
|
||||
pub challenge: String,
|
||||
}
|
||||
|
||||
pub struct L2Certif {
|
||||
pub sp_address_certif: String,
|
||||
}
|
||||
|
||||
pub struct SharedPeer {
|
||||
pub domain: String,
|
||||
pub address_ip: String,
|
||||
pub relay: Relay,
|
||||
pub l1_node: L1Node,
|
||||
pub l1_miner: L1Miner,
|
||||
pub l2_node: L2Node,
|
||||
pub l2_certif: L2Certif,
|
||||
}
|
||||
|
||||
pub struct RolePeer {
|
||||
pub item_name: String,
|
||||
pub role: Role,
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user