tables of contents (doc)
This commit is contained in:
parent
799d87d560
commit
cf01eb38ee
@ -1,77 +1,88 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
# Auth - Specifications
|
||||
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Schématisation des processus](#Schmatisationdesprocessus)
|
||||
* 4.1. [Création d'une identité](#Crationduneidentit)
|
||||
* 4.2. [Onboarding](#Onboarding)
|
||||
* 4.3. [Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover)
|
||||
* 5. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
|
||||
* 6. [Connexion via des tiers](#Connexionviadestiers)
|
||||
* 7. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
|
||||
* 8. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
|
||||
* 9. [Wallet](#Wallet)
|
||||
* 9.1. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
|
||||
* 10. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
|
||||
* 10.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
|
||||
* 10.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover)
|
||||
* 10.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc)
|
||||
* 10.1.3. [Onboarding](#Onboarding-1)
|
||||
* 10.2. [ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process](#ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess)
|
||||
* 10.3. [ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess)
|
||||
* 10.4. [Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)](#RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn)
|
||||
* 11. [Clés de révocation (`revoke`)](#Clsdervocationrevoke)
|
||||
* 12. [Clés de third parties](#Clsdethirdparties)
|
||||
* 13. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
|
||||
* 14. [Exemples de Code](#ExemplesdeCode)
|
||||
* 15. [Todo](#Todo)
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
# Auth - Specs
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [Schématisation des processus](#Schmatisationdesprocessus)
|
||||
* 5.1. [Création d'une identité](#Crationduneidentit)
|
||||
* 5.2. [Onboarding](#Onboarding)
|
||||
* 5.3. [Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover)
|
||||
* 5.4. [Extension de l'entropie du mot de passe (PBKDF2)](#ExtensiondelentropiedumotdepassePBKDF2)
|
||||
* 5.5. [Chiffrement AES quantique résistant (AES-GCM-256)](#ChiffrementAESquantiquersistantAES-GCM-256)
|
||||
* 5.6. [Génération des clés privées](#Gnrationdesclsprives)
|
||||
* 6. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
|
||||
* 7. [Connexion via des tiers](#Connexionviadestiers)
|
||||
* 8. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
|
||||
* 9. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
|
||||
* 10. [Wallet](#Wallet)
|
||||
* 10.1. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
|
||||
* 11. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
|
||||
* 11.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
|
||||
* 11.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover)
|
||||
* 11.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc)
|
||||
* 11.1.3. [Onboarding](#Onboarding-1)
|
||||
* 11.2. [ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process](#ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess)
|
||||
* 11.3. [ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess)
|
||||
* 11.4. [Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)](#RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn)
|
||||
* 12. [Clés de révocation (`revoke`)](#Clsdervocationrevoke)
|
||||
* 13. [Clés de third parties](#Clsdethirdparties)
|
||||
* 14. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
|
||||
* 15. [Exemples de Code](#ExemplesdeCode)
|
||||
* 16. [Todo](#Todo)
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 2. <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 Payments 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 :
|
||||
|
||||
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
## 3. <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='Documentsderfrence'></a>Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Wireframes :
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='Schmatisationdesprocessus'></a>Schématisation des processus
|
||||
## 5. <a name='Schmatisationdesprocessus'></a>Schématisation des processus
|
||||
|
||||
### 4.1. <a name='Crationduneidentit'></a>Création d'une identité
|
||||
### 5.1. <a name='Crationduneidentit'></a>Création d'une identité
|
||||
|
||||
|
||||
|
||||
### 4.2. <a name='Onboarding'></a>Onboarding
|
||||
### 5.2. <a name='Onboarding'></a>Onboarding
|
||||
|
||||
|
||||
|
||||
### 4.3. <a name='Connexionavecuneidentitcrerecover'></a>Connexion avec une identité créée (`recover`)
|
||||
### 5.3. <a name='Connexionavecuneidentitcrerecover'></a>Connexion avec une identité créée (`recover`)
|
||||
|
||||
|
||||
|
||||
### Extension de l'entropie du mot de passe (PBKDF2)
|
||||
### 5.4. <a name='ExtensiondelentropiedumotdepassePBKDF2'></a>Extension de l'entropie du mot de passe (PBKDF2)
|
||||
|
||||
|
||||
|
||||
### Chiffrement AES quantique résistant (AES-GCM-256)
|
||||
### 5.5. <a name='ChiffrementAESquantiquersistantAES-GCM-256'></a>Chiffrement AES quantique résistant (AES-GCM-256)
|
||||
|
||||
|
||||
|
||||
### Génération des clés privées
|
||||
### 5.6. <a name='Gnrationdesclsprives'></a>Génération des clés privées
|
||||
|
||||
|
||||
|
||||
## 5. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
|
||||
## 6. <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 `ItemProcess` .
|
||||
|
||||
@ -81,23 +92,23 @@ Les utilisateurs sont reconnus par une`adresse SP` dans un ou plusieurs rôles d
|
||||
|
||||
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 `ItemProcess` dans lequel l'utilisateur a un rôle (`onboarding`).
|
||||
|
||||
## 6. <a name='Connexionviadestiers'></a>Connexion via des tiers
|
||||
## 7. <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`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux `ItemProcess` 4NK.
|
||||
|
||||
## 7. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
|
||||
## 8. <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.
|
||||
|
||||
## 8. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
|
||||
## 9. <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.
|
||||
|
||||
## 9. <a name='Wallet'></a>Wallet
|
||||
## 10. <a name='Wallet'></a>Wallet
|
||||
|
||||
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) :
|
||||
|
||||
@ -126,7 +137,7 @@ Dans l'ordre on génère donc :
|
||||
5. Clé privée de dépense mainnet `spend_mainnet`.
|
||||
6. Clé privée de scan du mainnet `scan_mainnet`.
|
||||
|
||||
### 9.1. <a name='Rcuprationdesjetonsdefaucet'></a>Récupération des jetons de faucet
|
||||
### 10.1. <a name='Rcuprationdesjetonsdefaucet'></a>Récupération des jetons de faucet
|
||||
|
||||
Le relais retournent des jetons à la connexion et à l'envoi de messages afin de créer les `UTXO` nécessaires pour les transactions SP.
|
||||
|
||||
@ -136,11 +147,11 @@ A chaque nouveau message il génère de nouvelles addresses pour la clé qui va
|
||||
|
||||
Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envoyés aux relais.
|
||||
|
||||
## 10. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
|
||||
## 11. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
|
||||
|
||||
### 10.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
|
||||
### 11.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
|
||||
|
||||
#### 10.1.1. <a name='GestiondelaclservantlIDspend_recover'></a>Gestion de la clé servant à l'ID `spend_recover`
|
||||
#### 11.1.1. <a name='GestiondelaclservantlIDspend_recover'></a>Gestion de la clé servant à l'ID `spend_recover`
|
||||
|
||||
Les clés font 256 bits.
|
||||
|
||||
@ -203,7 +214,7 @@ Dans l'ordre on réalise donc les opérations suivantes donc :
|
||||
5. Chiffrement AES de `Part2`.
|
||||
6. Sharding de `Part2Enc`.
|
||||
|
||||
#### 10.1.2. <a name='BackupdePart2Enc'></a>Backup de `Part2Enc`
|
||||
#### 11.1.2. <a name='BackupdePart2Enc'></a>Backup de `Part2Enc`
|
||||
|
||||
Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant l'`ItemProcess` choisi.
|
||||
|
||||
@ -222,9 +233,9 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
|
||||
6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
|
||||
#### 10.1.3. <a name='Onboarding-1'></a>Onboarding
|
||||
#### 11.1.3. <a name='Onboarding-1'></a>Onboarding
|
||||
|
||||
### 10.2. <a name='ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess'></a>ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process
|
||||
### 11.2. <a name='ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess'></a>ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process
|
||||
|
||||
Le role `member` de l'`itemProcess` sélectionné contient un `Item` avec des `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` contenant chacun une `render_template_list` dont le premier élément du tableau est le formulaire de création de l'identité pour champs concernés (publiques ou confidentiels ou privés).
|
||||
|
||||
@ -232,23 +243,23 @@ Ces formulaires permettront de créé les champs attendus par `condition_attribu
|
||||
|
||||
Une fois l'`ItemMember` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Member` du `ItemProcess` sélectionné via un `PrdUpdate`.
|
||||
|
||||
### 10.3. <a name='ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess'></a>ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process
|
||||
### 11.3. <a name='ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess'></a>ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process
|
||||
|
||||
Pour le ou les roles sélectionnés, l'attribut `request_prd_sp_address_list` de `condition_prd_address_set_list` est complété par l'adresse SP de l'utilisateur.
|
||||
|
||||
Une fois l'`ItemProcess` complété, il est ajouté à la liste des membres pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Process` du `ItemProcess` sélectionné via un `PrdUpdate`.
|
||||
|
||||
### 10.4. <a name='RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn'></a>Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)
|
||||
### 11.4. <a name='RceptiondesPcdetPrdResponseentenantcomptedesmisesjoursrceptiondesclsdedchiffrementdurolechoisidansleprocessslectionn'></a>Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)
|
||||
|
||||
Envoi d'un `PrdList` pour chaque membre de chaque rôle du process sélectionné.
|
||||
|
||||
## 11. <a name='Clsdervocationrevoke'></a>Clés de révocation (`revoke`)
|
||||
## 12. <a name='Clsdervocationrevoke'></a>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 `PrdList` 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).
|
||||
|
||||
## 12. <a name='Clsdethirdparties'></a>Clés de third parties
|
||||
## 13. <a name='Clsdethirdparties'></a>Clés de third parties
|
||||
|
||||
Au moment de l'update de l'`ItemMember` il est possible de charger des addresses SP de third parties pour lesquelles l'utilisateur a un rôle dans un `ItemProcess`. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
|
||||
|
||||
@ -256,7 +267,7 @@ Les clés privées associées sont générées lors de l'update d'un membre, à
|
||||
|
||||
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. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
|
||||
## 14. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
|
||||
|
||||
Pour recrééer sa clé privée et envoyer un `PrdList` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes :
|
||||
|
||||
@ -277,8 +288,8 @@ Puis depuis la liste des membres du process, pour chacun des membres :
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
7. Réception des flux PCD et PRDResponse des gestionnaires des membres
|
||||
|
||||
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 15. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 15. <a name='Todo'></a>Todo
|
||||
## 16. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels.
|
||||
|
||||
@ -1,30 +1,40 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 3.1. [Types d'Items](#TypesdItems)
|
||||
* 3.2. [Composition et Fonction](#CompositionetFonction)
|
||||
* 3.2.1. [Cas d'utilisation](#Casdutilisation)
|
||||
* 3.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems)
|
||||
* 3.3.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 3.3.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 4. [ItemProcess](#ItemProcess)
|
||||
* 5. [Exemples de Code](#ExemplesdeCode)
|
||||
* 6. [Todo](#Todo)
|
||||
|
||||
# Item - Specifications
|
||||
|
||||
# Item - Specs
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 4.1. [Types d'Items](#TypesdItems)
|
||||
* 4.2. [Composition et Fonction](#CompositionetFonction)
|
||||
* 4.2.1. [Cas d'utilisation](#Casdutilisation)
|
||||
* 4.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems)
|
||||
* 4.3.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 4.3.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 5. [ItemProcess](#ItemProcess)
|
||||
* 6. [Exemples de Code](#ExemplesdeCode)
|
||||
* 7. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 2. <a name='Objectif'></a>Objectif
|
||||
|
||||
Les transactions Silent Payments SP intègrent directement dans l'architecture web de l'application, comme démontré dans le client web. La gestion et l'intégration des SP sont conçues pour être fluides avec les systèmes front-end, assurant une expérience utilisateur transparente tout en maintenant la sécurité et la confidentialité au cœur de l'interaction utilisateur.
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
## 3. <a name='Porte'></a>Portée
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
### 3.1. <a name='TypesdItems'></a>Types d'Items
|
||||
### 4.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 :
|
||||
|
||||
@ -34,7 +44,7 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé
|
||||
* **Artefact** : Un type d'objet générique personnalisable dans les `ItemProcess` , il peut y avoir une quantité infinie de type d'`artefacts` différents par `ItemProcess`.
|
||||
* **Payments, 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.
|
||||
|
||||
### 3.2. <a name='CompositionetFonction'></a> Composition et Fonction
|
||||
### 4.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.
|
||||
@ -44,33 +54,33 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé
|
||||
* **pagination_number_per_request_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é.
|
||||
|
||||
#### 3.2.1. <a name='Casdutilisation'></a>Cas d'utilisation
|
||||
#### 4.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.
|
||||
|
||||
### 3.3. <a name='MetaData-GestiondesAttributsdItems'></a>MetaData - Gestion des Attributs d'Items
|
||||
### 4.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.
|
||||
|
||||
#### 3.3.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
#### 4.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.
|
||||
|
||||
#### 3.3.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
#### 4.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.
|
||||
|
||||
## 4. <a name='ItemProcess'></a>ItemProcess
|
||||
## 5. <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.
|
||||
|
||||
## 5. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 6. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 6. <a name='Todo'></a>Todo
|
||||
## 7. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -1,94 +1,93 @@
|
||||
# Messages - Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [1. Objectif](#Objectif)
|
||||
* 3. [2. Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [4. Variable `SharedPeerList` du SDK (Wasm)](#VariableSharedPeerListduSDKWasm)
|
||||
* 6. [6. Caractéristiques générales des messages de type `Message` et `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetMessageConnect)
|
||||
* 6.1. [6.1. SharedPeerList](#SharedPeerList)
|
||||
* 6.2. [6.2. SharedProcessList](#SharedProcessList)
|
||||
* 6.3. [6.3. Taille des données](#Tailledesdonnes)
|
||||
* 6.4. [6.4. Preuve de travail](#Preuvedetravail)
|
||||
* 6.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet)
|
||||
* 6.6. [Objets `MessageGeneric` contenu dans les types `Message` et `MessageConnect`](#ObjetsMessageGenericcontenudanslestypesMessageetMessageConnect)
|
||||
* 7. [7. Traitements par les clients](#Traitementsparlesclients)
|
||||
* 7.1. [7.1. Connexion d'un client à sa liste de relais via les messages de type `MessageConnect`](#ConnexiondunclientsalistederelaisvialesmessagesdetypeMessageConnect)
|
||||
* 7.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
||||
* 7.1.2. [7.1.2. Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
|
||||
* 7.2. [7.2. Envoi de `Request` sur les relais via les messages de type `Message`](#EnvoideRequestsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.3. [7.4. Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
|
||||
* 8. [8. Traitements par les relais](#Traitementsparlesrelais)
|
||||
* 8.1. [8.1. Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 8.2. [8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 9. [9. Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais)
|
||||
* 10. [10. Connexions aux réseaux de noeuds de Bitcoin, de réseaux side chain ou mainnet](#ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet)
|
||||
* 10.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
|
||||
* 10.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
|
||||
* 10.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
|
||||
* 10.4. [10.4. Validation et relais](#Validationetrelais)
|
||||
* 10.5. [10.5. Gestion des Forks](#GestiondesForks)
|
||||
* 10.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain)
|
||||
* 10.6.1. [10.6.1. Clients](#Clients)
|
||||
* 10.6.2. [10.6.2. Relais](#Relais)
|
||||
* 10.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1)
|
||||
* 10.8. [10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)](#HorodatageetancragedesPrdvialestransactionsSilentPaymentsSP)
|
||||
* 11. [11. Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin)
|
||||
* 11.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 11.2. [11.2. Remboursement des frais d'horodatage et ancrage](#Remboursementdesfraisdhorodatageetancrage)
|
||||
* 12. [Exemples de Code](#ExemplesdeCode)
|
||||
* 13. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 4. [## Variable `SharedPeerList` du SDK (Wasm)](#VariableSharedPeerListduSDKWasm)
|
||||
* 5. [Structure du stockage en cache](#Structuredustockageencache)
|
||||
* 5.1. [Relais](#Relais)
|
||||
* 5.2. [Process](#Process)
|
||||
* 5.3. [Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
|
||||
* 5.4. [Liste des sockets ouverts](#Listedessocketsouverts)
|
||||
* 6. [Caractéristiques générales des messages de type `Message` et de type `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect)
|
||||
* 6.1. [SharedPeerList](#SharedPeerList)
|
||||
* 6.2. [SharedProcessList](#SharedProcessList)
|
||||
* 6.3. [Taille des données](#Tailledesdonnes)
|
||||
* 6.4. [Preuve de travail](#Preuvedetravail)
|
||||
* 6.5. [Adresse SP de faucet](#AdresseSPdefaucet)
|
||||
* 7. [Traitements par les clients](#Traitementsparlesclients)
|
||||
* 7.1. [Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
|
||||
* 7.1.1. [Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
||||
* 7.1.2. [Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
|
||||
* 7.2. [Envoi de `Pcd` sur les relais via les messages de type `Message`](#EnvoidePcdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.3. [Envoi de `Prd` sur les relais via les messages de type `Message`](#EnvoidePrdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.4. [Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
|
||||
* 8. [Traitements par les relais](#Traitementsparlesrelais)
|
||||
* 8.1. [Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 8.2. [Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 9. [Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais)
|
||||
* 9.1. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
|
||||
* 9.2. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
|
||||
* 10. [Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet)
|
||||
* 10.1. [Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
|
||||
* 10.2. [Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
|
||||
* 10.3. [Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
|
||||
* 10.4. [Validation et relais](#Validationetrelais)
|
||||
* 10.5. [Gestion des Forks](#GestiondesForks)
|
||||
* 10.6. [Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain)
|
||||
* 10.6.1. [Clients](#Clients)
|
||||
* 10.6.2. [Relais](#Relais-1)
|
||||
* 10.7. [Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1)
|
||||
* 10.8. [Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)](#HorodatageetancragedesPrdvialestransactionsSilentPaymentsP)
|
||||
* 11. [Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin)
|
||||
* 11.1. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 11.2. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 12. [Exemples de Code](#ExemplesdeCode)
|
||||
* 13. [Todo](#Todo)
|
||||
|
||||
## 1. <a name='Objectif'></a>1. Objectif
|
||||
## 2. <a name='Objectif'></a>1. Objectif
|
||||
|
||||
L'objectif de ce document est de décrire les spécifications techniques des messages de type `Message` et `MessageConnect` pour le réseau de relais et les clients.
|
||||
|
||||
## 2. <a name='Porte'></a>2. Portée
|
||||
## 3. <a name='Porte'></a>2. Portée
|
||||
|
||||
Ce document concerne les messages de type `Message` et `MessageConnect` pour le réseau de relais et les clients.
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='VariableSharedPeerListduSDKWasm'></a>4. Variable `SharedPeerList` du SDK (Wasm)
|
||||
## 5. <a name='VariableSharedPeerListduSDKWasm'></a>4. Variable `SharedPeerList` du SDK (Wasm)
|
||||
|
||||
La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, constituant la première liste disponible, fournie en dur par le relais auquel on est connecté.
|
||||
|
||||
## 5. <a name='CaractristiquesgnralesdesmessagesdetypeMessageetMessageConnect'></a>6. Caractéristiques générales des messages de type `Message` et `MessageConnect`
|
||||
## 6. <a name='CaractristiquesgnralesdesmessagesdetypeMessageetMessageConnect'></a>6. Caractéristiques générales des messages de type `Message` et `MessageConnect`
|
||||
|
||||
### 5.1. <a name='SharedPeerList'></a>6.1. SharedPeerList
|
||||
### 6.1. <a name='SharedPeerList'></a>6.1. SharedPeerList
|
||||
|
||||
`SharedPeerList` est une liste de relais partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux relais.
|
||||
|
||||
### 5.2. <a name='SharedProcessList'></a>6.2. SharedProcessList
|
||||
### 6.2. <a name='SharedProcessList'></a>6.2. SharedProcessList
|
||||
|
||||
`SharedProcessList` est une liste de `ItemProcess` partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux `ItemProcess`.
|
||||
|
||||
### 5.3. <a name='Tailledesdonnes'></a>6.3. Taille des données
|
||||
### 6.3. <a name='Tailledesdonnes'></a>6.3. Taille des données
|
||||
|
||||
Les objets `SharedPeer` spécifient la taille maximale des données pour les messages de type `Message` et `MessageConnect` dans l'attribut `data_max_size` du sous-attribut `relay`. Les messages excédant cette taille sont rejetés.
|
||||
|
||||
### 5.4. <a name='Preuvedetravail'></a>6.4. Preuve de travail
|
||||
### 6.4. <a name='Preuvedetravail'></a>6.4. Preuve de travail
|
||||
|
||||
Les objets `SharedPeer` définissent les caractéristiques de la preuve de travail pour les messages de type `Message` et `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous-attribut `relay`. Les messages ne respectant pas la preuve de travail sont rejetés.
|
||||
|
||||
### 5.5. <a name='AdresseSPdefaucet'></a>6.5. Adresse SP de faucet
|
||||
### 6.5. <a name='AdresseSPdefaucet'></a>6.5. Adresse SP de faucet
|
||||
|
||||
L'utilisateur fournit aux relais une adresse SP (Silent Payments) dite de faucet `faucet_sp_address`. Un portefeuille est généré en mémoire pour chaque relais à la réception des fonds, les fonds sont ensuite transférés vers l'adresse SP de l'utilisateur et le portefeuille est supprimé.
|
||||
|
||||
L'utilisateur reçoit en retour une transaction Silent Payments (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction inclut un output supplémentaire avec le hash du message de type `MessageConnect` ou `Message` correspondant.
|
||||
|
||||
### Objets `MessageGeneric` contenu dans les types `Message` et `MessageConnect`
|
||||
### 6.6. <a name='ObjetsMessageGenericcontenudanslestypesMessageetMessageConnect'></a>Objets `MessageGeneric` contenu dans les types `Message` et `MessageConnect`
|
||||
|
||||
`MessageGeneric` fournit une structure générale pour les messages, incluant les pairs partagés et les processus, et des détails comme les défis de PoW, soutenant des besoins de communication diversifiés. Les attributs ont les fonctions suivantes :
|
||||
|
||||
@ -178,11 +177,11 @@ La structure `BlockCertif` spécifie un bloc certifié. Les attributs ont les f
|
||||
* **`l2_block_hash_list`** : Liste des hashes de blocs.
|
||||
* **`l1_tx`** : Transaction de niveau 1.
|
||||
|
||||
## 6. <a name='Traitementsparlesclients'></a>7. Traitements par les clients
|
||||
## 7. <a name='Traitementsparlesclients'></a>7. Traitements par les clients
|
||||
|
||||
### 6.1. <a name='ConnexiondunclientsalistederelaisvialesmessagesdetypeMessageConnect'></a>7.1. Connexion d'un client à sa liste de relais via les messages de type `MessageConnect`
|
||||
### 7.1. <a name='ConnexiondunclientsalistederelaisvialesmessagesdetypeMessageConnect'></a>7.1. Connexion d'un client à sa liste de relais via les messages de type `MessageConnect`
|
||||
|
||||
#### 6.1.1. <a name='Rcuprationetchoixdesrelais'></a>7.1.1. Récupération et choix des relais
|
||||
#### 7.1.1. <a name='Rcuprationetchoixdesrelais'></a>7.1.1. Récupération et choix des relais
|
||||
|
||||
Pour discuter avec les relais du réseau et faire relayer des `Pcd` et des `Prd` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, quatre par défaut.
|
||||
|
||||
@ -198,7 +197,7 @@ Les relais "browsers" possèdent un nom de domaine et un certificat SSL pour sat
|
||||
|
||||
Les connexions utilisent le protocole WebSocket avec ou sans SSL (URL commençant par `ws://` ou `wss://`), et les messages sont au format JSON.
|
||||
|
||||
#### 6.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>7.1.2. Envoi du message de type `MessageConnect` à chaque relais
|
||||
#### 7.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>7.1.2. Envoi du message de type `MessageConnect` à chaque relais
|
||||
|
||||
|
||||
|
||||
@ -210,7 +209,7 @@ Objet de type `MessageConnect`. Les attributs ont les fonctions suivantes :
|
||||
|
||||
* ***message** : Contient le `MessageGeneric`
|
||||
|
||||
### 6.2. <a name='EnvoidePcdsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de `Request` sur les relais via les messages de type `Message`
|
||||
### 7.2. <a name='EnvoideRequestsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de `Request` sur les relais via les messages de type `Message`
|
||||
|
||||
|
||||
|
||||
@ -221,93 +220,93 @@ Objet de type `Message`, Les attributs ont les fonctions suivantes :
|
||||
* **`message`** : Contient le `MessageGeneric`
|
||||
* **`request_enc`** : Contient le `Pcd` ou un `Prd` chiffré par la `ProcessKey`
|
||||
|
||||
### 6.4. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>7.4. Traitement des messages de type `Message` par les clients
|
||||
### 7.3. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>7.4. Traitement des messages de type `Message` par les clients
|
||||
|
||||
|
||||
|
||||
Le client reçoit un nouveau message via le socket ouvert avec le relais et effectue divers contrôles, notamment le calcul du hash du message et sa vérification dans le cache. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour en conséquence. Le message est ensuite déchiffré avec la `ProcessKey` du `ItemProcess`, et d'autres contrôles sont réalisés. Les données pertinentes sont mises à jour dans le cache.
|
||||
|
||||
## 7. <a name='Traitementsparlesrelais'></a>8. Traitements par les relais
|
||||
## 8. <a name='Traitementsparlesrelais'></a>8. Traitements par les relais
|
||||
|
||||
|
||||
|
||||
### 7.1. <a name='TraitementdesmessagesdetypeMessageConnectparlesrelais'></a>8.1. Traitement des messages de type `MessageConnect` par les relais
|
||||
### 8.1. <a name='TraitementdesmessagesdetypeMessageConnectparlesrelais'></a>8.1. Traitement des messages de type `MessageConnect` par les relais
|
||||
|
||||
|
||||
|
||||
À la réception d'un message de type `MessageConnect`, le relais enregistre le socket du client et réalise divers contrôles, y compris la vérification de la preuve de travail et la taille des données. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour. En retour, le relais envoie quelques jetons à l'adresse SP de faucet communiquée par le client et met à jour les données dans le cache.
|
||||
|
||||
### 7.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
|
||||
### 8.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
|
||||
|
||||
Les relais se connectent à de nouveaux relais en utilisant `MessageConnect`, partageant à leur tour leur liste de relais et de `ItemProcess`. Aucun retour n'est attendu pour ce message.
|
||||
|
||||
## 8. <a name='TraitementdesmessagesdetypeMessageparlesrelais'></a>9. Traitement des messages de type `Message` par les relais
|
||||
## 9. <a name='TraitementdesmessagesdetypeMessageparlesrelais'></a>9. Traitement des messages de type `Message` par les relais
|
||||
|
||||
|
||||
|
||||
Le relais reçoit un nouveau message de type `Message` du client, effectue les contrôles nécessaires, et met à jour ses listes. En retour, le relais envoie quelques jetons à l'adresse SP de faucet du client. Le message est ensuite relayé aux autres relais et clients connectés, favorisant ainsi sa propagation.
|
||||
|
||||
## 9. <a name='ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet'></a>10. Connexions aux réseaux de noeuds de Bitcoin, de réseaux side chain ou mainnet
|
||||
## 10. <a name='ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet'></a>10. Connexions aux réseaux de noeuds de Bitcoin, de réseaux side chain ou mainnet
|
||||
|
||||
Pour plus de détails, voir : [Specs-References.md](Specs-References.md).
|
||||
|
||||
Bitcoin et les side chains utilisent divers protocoles pour la découverte de pairs, la transmission des transactions, et le partage des blocs, adaptés aux besoins spécifiques de 4NK.
|
||||
|
||||
### 9.1. <a name='ProtocoledeDcouvertedesPairs'></a>10.1. Protocole de Découverte des Pairs
|
||||
### 10.1. <a name='ProtocoledeDcouvertedesPairs'></a>10.1. Protocole de Découverte des Pairs
|
||||
|
||||
Bitcoin facilite la découverte de nouveaux nœuds via des DNS seeds et une liste de nœuds codée en dur. 4NK utilise la `SharedPeerList` comme équivalent pour faciliter la découverte de relais dans le réseau.
|
||||
|
||||
### 9.2. <a name='ProtocoledeTransmissiondesTransactions'></a>10.2. Protocole de Transmission des Transactions
|
||||
### 10.2. <a name='ProtocoledeTransmissiondesTransactions'></a>10.2. Protocole de Transmission des Transactions
|
||||
|
||||
* **Mempool et Transactions Orphelines** : Les transactions sont ajoutées au mempool en attente de confirmation. Les transactions dépendantes d'autres transactions non confirmées sont considérées comme orphelines jusqu'à résolution.
|
||||
* **Protocole P2P de Bitcoin** : Définit la communication entre nœuds pour échanger informations sur les transactions et blocs, incluant les messages `version`, `verack`, `inv`, `getdata`, `tx`, et `block`.
|
||||
|
||||
### 9.3. <a name='ProtocoledePartagedesBlocs'></a>10.3. Protocole de Partage des Blocs
|
||||
### 10.3. <a name='ProtocoledePartagedesBlocs'></a>10.3. Protocole de Partage des Blocs
|
||||
|
||||
* **Propagation des Blocs** : Les nouveaux blocs sont rapidement transmis à travers le réseau via un mécanisme de propagation.
|
||||
* **Compact Blocks** : Optimise la transmission des blocs en utilisant les données déjà présentes dans le mempool des nœuds récepteurs.
|
||||
|
||||
### 9.4. <a name='Validationetrelais'></a>10.4. Validation et relais
|
||||
### 10.4. <a name='Validationetrelais'></a>10.4. Validation et relais
|
||||
|
||||
Les transactions et les blocs sont validés selon les règles de consensus avant d'être relayés aux autres pairs, assurant l'intégrité et la sécurité du réseau.
|
||||
|
||||
### 9.5. <a name='GestiondesForks'></a>10.5. Gestion des Forks
|
||||
### 10.5. <a name='GestiondesForks'></a>10.5. Gestion des Forks
|
||||
|
||||
Bitcoin gère les bifurcations temporaires de la blockchain, permettant une réorganisation basée sur la chaîne avec le plus de travail cumulé.
|
||||
|
||||
### 9.6. <a name='Connexionaurseaudenudsdesidechain'></a>10.6. Connexion au réseau de nœuds de side chain
|
||||
### 10.6. <a name='Connexionaurseaudenudsdesidechain'></a>10.6. Connexion au réseau de nœuds de side chain
|
||||
|
||||
#### 9.6.1. <a name='Clients'></a>10.6.1. Clients
|
||||
#### 10.6.1. <a name='Clients'></a>10.6.1. Clients
|
||||
|
||||
Les clients se connectent au réseau de nœuds de side chain pour recevoir les blocs et les transactions, y compris les transactions Silent Payments (SP) liées aux `Prd`.
|
||||
|
||||
#### 9.6.2. <a name='Relais'></a>10.6.2. Relais
|
||||
#### 10.6.2. <a name='Relais'></a>10.6.2. Relais
|
||||
|
||||
Les relais fonctionnent comme des nœuds complets de la side chain, facilitant la communication et la validation des transactions.
|
||||
|
||||
### 9.7. <a name='Connexionaurseaudenudsdelayer1'></a>10.7. Connexion au réseau de nœuds de layer 1
|
||||
### 10.7. <a name='Connexionaurseaudenudsdelayer1'></a>10.7. Connexion au réseau de nœuds de layer 1
|
||||
|
||||
Les relais maintiennent également une connexion au réseau principal (mainnet) pour des opérations d'ancrage et d'horodatage.
|
||||
|
||||
### 9.8. <a name='HorodatageetancragedesPrdvialestransactionsSilentPaymentsP'></a>10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)
|
||||
### 10.8. <a name='HorodatageetancragedesPrdvialestransactionsSilentPaymentsSP'></a>10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)
|
||||
|
||||
Les `Prd` sont ancrés dans la side chain à travers des transactions SP, offrant une preuve immuable de leur existence et de leur intégrité.
|
||||
|
||||
## 10. <a name='TransactionsmainnetBitcoin'></a>11. Transactions mainnet Bitcoin
|
||||
## 11. <a name='TransactionsmainnetBitcoin'></a>11. Transactions mainnet Bitcoin
|
||||
|
||||
### 10.1. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin
|
||||
### 11.1. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin
|
||||
|
||||
Les blocs de la side chain sont ancrés sur le mainnet de Bitcoin à intervalles réguliers, fournissant une preuve temporelle et augmentant la sécurité.
|
||||
|
||||
### 10.2. <a name='Remboursementdesfraisdhorodatageetancrage'></a>11.2. Remboursement des frais d'horodatage et ancrage
|
||||
### 11.2. <a name='Remboursementdesfraisdhorodatageetancrage'></a>11.2. Remboursement des frais d'horodatage et ancrage
|
||||
|
||||
Le processus de minage "vert" de 4NK génère les jetons nécessaires pour couvrir les frais d'horodatage et d'ancrage sur le réseau Bitcoin, assurant ainsi la viabilité financière de ces opérations.
|
||||
|
||||
Ces spécifications techniques fournissent une vue d'ensemble de la façon dont 4NK s'intègre avec les réseaux Bitcoin et side chain, utilisant des protocoles éprouvés tout en introduisant de nouvelles méthodes pour améliorer la sécurité, la transparence, et l'efficacité des transactions et des communications au sein du réseau.
|
||||
|
||||
## 11. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 12. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 12. <a name='Todo'></a>Todo
|
||||
## 13. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -1,46 +1,55 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Définitions](#Dfinitions)
|
||||
* 5. [Principes de messagerie](#Principesdemessagerie)
|
||||
* 6. [Encryption](#Encryption)
|
||||
* 7. [Fonction des Pcd](#FonctiondesPcd)
|
||||
* 7.1. [Schéma des flux](#Schmadesflux)
|
||||
* 7.2. [Création et envoi](#Crationetenvoi)
|
||||
* 7.3. [Réception](#Rception)
|
||||
* 8. [Fonction des`Prd`](#FonctiondesPrd)
|
||||
* 8.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 8.2. [Création d'un `Prd`](#CrationdunPrd)
|
||||
* 8.3. [Réception](#Rception-1)
|
||||
* 9. [PrdList - Demande de Listes](#PrdList-DemandedeListes)
|
||||
# PRD PCD - Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [Définitions](#Dfinitions)
|
||||
* 6. [Principes de messagerie](#Principesdemessagerie)
|
||||
* 7. [Encryption](#Encryption)
|
||||
* 8. [Fonction des Pcd](#FonctiondesPcd)
|
||||
* 8.1. [Schéma des flux](#Schmadesflux)
|
||||
* 8.2. [Création et envoi](#Crationetenvoi)
|
||||
* 8.3. [Réception](#Rception)
|
||||
* 9. [Fonction des`Prd`](#FonctiondesPrd)
|
||||
* 9.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 10. [PrdMessage - Envoi de Messages](#PrdMessage-EnvoideMessages)
|
||||
* 9.2. [Création d'un `Prd`](#CrationdunPrd)
|
||||
* 9.3. [Réception](#Rception-1)
|
||||
* 10. [PrdList - Demande de Listes](#PrdList-DemandedeListes)
|
||||
* 10.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 11. [PrdUpdate - Mises à Jour de Pcd](#PrdUpdate-MisesJourdePcd)
|
||||
* 11. [PrdMessage - Envoi de Messages](#PrdMessage-EnvoideMessages)
|
||||
* 11.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 12. [PrdConfirm - Confirmation de Réception](#PrdConfirm-ConfirmationdeRception)
|
||||
* 12. [PrdUpdate - Mises à Jour de Pcd](#PrdUpdate-MisesJourdePcd)
|
||||
* 12.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 13. [PrdResponse - Répondre à une Demande](#PrdResponse-RpondreuneDemande)
|
||||
* 13. [PrdConfirm - Confirmation de Réception](#PrdConfirm-ConfirmationdeRception)
|
||||
* 13.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 14. [Exemples de Code](#ExemplesdeCode)
|
||||
* 15. [Todo](#Todo)
|
||||
* 14. [PrdResponse - Répondre à une Demande](#PrdResponse-RpondreuneDemande)
|
||||
* 14.1. [Schéma des flux](#Schmadesflux-1)
|
||||
* 15. [Exemples de Code](#ExemplesdeCode)
|
||||
* 16. [Todo](#Todo)
|
||||
|
||||
# `Prd` et `Pcd` - Specs
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
## 2. <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
|
||||
## 3. <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='Documentsderfrence'></a>Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='Dfinitions'></a>Définitions
|
||||
## 5. <a name='Dfinitions'></a>Définitions
|
||||
|
||||
* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `ItemProcess` (`item_type`).
|
||||
|
||||
@ -61,7 +70,7 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
* **pre-id**: Pré-identifiant des utilisateurs, constitué du hash de la partie 1 de la `KeyRecover`.
|
||||
|
||||
## 5. <a name='Principesdemessagerie'></a>Principes de messagerie
|
||||
## 6. <a name='Principesdemessagerie'></a>Principes de messagerie
|
||||
|
||||
Les `Pcd` sont envoyés à tous les participants connectés sans attente de retour spécifique et ne sont pas associés à une `transaction SP`.
|
||||
|
||||
@ -128,7 +137,7 @@ Ce qui est résumé Pour la réception :
|
||||
| `PrdResponse` | Prd | Yes | No | No | No | No |
|
||||
| `PrdConfirm` | Prd | No | No | No | No | No |
|
||||
|
||||
## 6. <a name='Encryption'></a>Encryption
|
||||
## 7. <a name='Encryption'></a>Encryption
|
||||
|
||||
Schema :
|
||||
|
||||
@ -156,7 +165,7 @@ Principaux champs des `Request` contenus dans les `Pcd` et `Prd` chiffrés :
|
||||
* **`request_prd_origin_hash`** : Hash du `Prd` à l'origine du `Prd`.
|
||||
* **`item_reference_hash`** : Hash de l'`Item` auquel le `Pcd` fait référence.
|
||||
|
||||
## 7. <a name='FonctiondesPcd'></a>Fonction des Pcd
|
||||
## 8. <a name='FonctiondesPcd'></a>Fonction des Pcd
|
||||
|
||||
Les Portable Contract Documents (`Pcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
|
||||
@ -205,11 +214,11 @@ Principaux champs de la structure `PcdItemEncAttributePrivate` :
|
||||
* **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair.
|
||||
* **`data`** : [PRIVE] Non partagé dans les messages. Données en clair.
|
||||
|
||||
### 7.1. <a name='Schmadesflux'></a>Schéma des flux
|
||||
### 8.1. <a name='Schmadesflux'></a>Schéma des flux
|
||||
|
||||
|
||||
|
||||
### 7.2. <a name='Crationetenvoi'></a>Création et envoi
|
||||
### 8.2. <a name='Crationetenvoi'></a>Création et envoi
|
||||
|
||||
La création d'un `Pcd` suit plusieurs étapes :
|
||||
|
||||
@ -218,14 +227,14 @@ La création d'un `Pcd` suit plusieurs étapes :
|
||||
3. Chiffrement cf Encryption.
|
||||
4. Envoi du message cf [Messages - Specs](Messages-Specs.md).
|
||||
|
||||
### 7.3. <a name='Rception'></a>Réception
|
||||
### 8.3. <a name='Rception'></a>Réception
|
||||
|
||||
La réception d'un `Pcd` suit plusieurs étapes :
|
||||
|
||||
1. Recherche des `Prd` en relation via `Pcd_reference_hash` et `Pcd_origin_hash` de ces `Prd`, et attente si nécessaire.
|
||||
2. Déchiffrement cf Encryption.
|
||||
|
||||
## 8. <a name='FonctiondesPrd'></a>Fonction des`Prd`
|
||||
## 9. <a name='FonctiondesPrd'></a>Fonction des`Prd`
|
||||
|
||||
Les Portable Request Documents (Prd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `Pcd` via l'attribut `Pcd_keys_role_confidential_list_confidential`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
|
||||
@ -261,20 +270,20 @@ Principaux champs des `Prd` :
|
||||
* **`certif_key_confidential`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
||||
* **`device_footprint_enc_by_sp_shared_secret`** : Empreinte du dispositif de l'émetteur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
||||
|
||||
### 8.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 9.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma.
|
||||
|
||||
|
||||
|
||||
### 8.2. <a name='CrationdunPrd'></a>Création d'un `Prd`
|
||||
### 9.2. <a name='CrationdunPrd'></a>Création d'un `Prd`
|
||||
|
||||
1. Complétion des attributs
|
||||
2. Création d'une `adresse SP` cf [Silent Payments - Specs](Silent-Payments-Specs.md)
|
||||
3. Chiffrement cf Encryption.
|
||||
4. Envoi du message cf [Messages - Specs](Messages-Specs.md).
|
||||
|
||||
### 8.3. <a name='Rception-1'></a>Réception
|
||||
### 9.3. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un `Prd` suit plusieurs étapes :
|
||||
|
||||
@ -290,7 +299,7 @@ La réception d'un `Prd` suit plusieurs étapes :
|
||||
10. Vérification du role de l'utilisateur courant dans le `ItemProcess` et dans le `Item` concerné.
|
||||
11. Traitements spécifiques au type de `Prd`.
|
||||
|
||||
## 9. <a name='PrdList-DemandedeListes'></a>PrdList - Demande de Listes
|
||||
## 10. <a name='PrdList-DemandedeListes'></a>PrdList - Demande de Listes
|
||||
|
||||
Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayments`, etc.
|
||||
|
||||
@ -333,13 +342,13 @@ L'`ItemMember` temporaire contient les métadonnées de type `Metadata` suivante
|
||||
* **`priv_key_mainnet_scan`** : Clé de scan de l'utilisateur, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`.
|
||||
* **`priv_key_signet_scan`** : Clé de scan du signet de `recover`de l'utilisateur, chiffrée `KeyRecover`.
|
||||
|
||||
### 9.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma.
|
||||
|
||||
|
||||
|
||||
## 10. <a name='PrdMessage-EnvoideMessages'></a>PrdMessage - Envoi de Messages
|
||||
## 11. <a name='PrdMessage-EnvoideMessages'></a>PrdMessage - Envoi de Messages
|
||||
|
||||
Le `PrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
||||
|
||||
@ -358,13 +367,13 @@ Principaux champs des `PrdMessage` :
|
||||
* **`request_prd`** : cf la descripton de la structure `Prd`.
|
||||
* **`raw_transaction_list`** : Liste des `transaction SP` au format `raw` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `PrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `PrdMessage` contient une `raw_transaction_list` non vide.
|
||||
|
||||
|
||||
|
||||
## 11. <a name='PrdUpdate-MisesJourdePcd'></a>PrdUpdate - Mises à Jour de Pcd
|
||||
## 12. <a name='PrdUpdate-MisesJourdePcd'></a>PrdUpdate - Mises à Jour de Pcd
|
||||
|
||||
`PrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `Pcd`.
|
||||
|
||||
@ -384,13 +393,13 @@ Principaux champs des `PrdUpdate` :
|
||||
|
||||
* **`request_prd`** : cf la descripton de la structure `Prd`.
|
||||
|
||||
### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 12.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma.
|
||||
|
||||
|
||||
|
||||
## 12. <a name='PrdConfirm-ConfirmationdeRception'></a>PrdConfirm - Confirmation de Réception
|
||||
## 13. <a name='PrdConfirm-ConfirmationdeRception'></a>PrdConfirm - Confirmation de Réception
|
||||
|
||||
Le `PrdConfirm` 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.
|
||||
|
||||
@ -407,11 +416,11 @@ Principaux champs des `PrdConfirm` :
|
||||
* **`request_prd`** : cf la descripton de la structure `Prd`.
|
||||
* **`code_confirm_confidential`** : Code de confirmation chiffré par la clé `KeyConfidential` d'une `transaction SP` dans le cas d'un 2FA.
|
||||
|
||||
### 12.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 13.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
|
||||
|
||||
## 13. <a name='PrdResponse-RpondreuneDemande'></a>PrdResponse - Répondre à une Demande
|
||||
## 14. <a name='PrdResponse-RpondreuneDemande'></a>PrdResponse - Répondre à une Demande
|
||||
|
||||
Le `PrdResponse` permet de répondre spécifiquement à des `Prd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties.
|
||||
|
||||
@ -429,12 +438,12 @@ Principaux champs des `PrdResponse` :
|
||||
* **`shared_secret_key_enc_by_sp_shared_secret`** : Clé de chiffrement partagée chiffrée par la clé `KeyConfidential` d'une `transaction SP`.
|
||||
* **`shard_enc_by_sp_shared_secret`** : Shard chiffré par la clé `KeyConfidential` d'une `transaction SP`.
|
||||
|
||||
### 13.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
### 14.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma.
|
||||
|
||||
|
||||
|
||||
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 15. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 15. <a name='Todo'></a>Todo
|
||||
## 16. <a name='Todo'></a>Todo
|
||||
|
||||
@ -1,54 +1,64 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 4. [Rôles et Sous-Rôles](#RlesetSous-Rles)
|
||||
* 5. [Précisions sur les rôles](#Prcisionssurlesrles)
|
||||
* 5.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
|
||||
* 5.1.1. [Composition et Fonction](#CompositionetFonction)
|
||||
* 5.1.2. [Cas d'utilisation](#Casdutilisation)
|
||||
* 5.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect)
|
||||
* 5.3. [TransactionModeDistribution](#TransactionModeDistribution)
|
||||
* 5.3.1. [TransactionModeDirect](#TransactionModeDirect)
|
||||
* 5.4. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 5.4.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 5.4.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 5.5. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
|
||||
* 5.5.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 5.5.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 6. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
|
||||
* 6.1. [RoleCommitment](#RoleCommitment)
|
||||
* 6.2. [RoleDeposit et RolePayments](#RoleDepositetRolePayments)
|
||||
* 7. [Sécurisation des Communications](#ScurisationdesCommunications)
|
||||
* 7.1. [Composition et Utilisation](#CompositionetUtilisation)
|
||||
* 8. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
|
||||
* 9. [Condition PrdAddressSet](#ConditionPrdAddressSet)
|
||||
* 9.1. [ Participants](#Participants)
|
||||
* 9.2. [ Valeurs des signatures (`sig_value`)](#Valeursdessignaturessig_value)
|
||||
* 9.3. [Minimums et maximums de valeurs "OK", "KO" et "NONE"](#MinimumsetmaximumsdevaleursOKKOetNONE)
|
||||
* 9.4. [Minimums et maximums de scores](#Minimumsetmaximumsdescores)
|
||||
* 10. [ConditionPublish : conditions de publication](#ConditionPublish:conditionsdepublication)
|
||||
* 11. [ConditionPayments : conditions de paiement](#ConditionPayments:conditionsdepaiement)
|
||||
* 12. [ConditionCommitment : conditions d'engagement](#ConditionCommitment:conditionsdengagement)
|
||||
* 13. [ConditionDeposit : conditions de dépôt de garantie](#ConditionDeposit:conditionsdedptdegarantie)
|
||||
* 14. [ConditionOrchestration : conditions d'orchestration des processus](#ConditionOrchestration:conditionsdorchestrationdesprocessus)
|
||||
* 15. [ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement](#ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement)
|
||||
* 16. [Exemples de Code](#ExemplesdeCode)
|
||||
* 17. [Todo](#Todo)
|
||||
# `ItemProcess` et `Role` - Specifications
|
||||
|
||||
# `ItemProcess` et roles
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [Rôles et Sous-Rôles](#RlesetSous-Rles)
|
||||
* 6. [Précisions sur les rôles](#Prcisionssurlesrles)
|
||||
* 6.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
|
||||
* 6.1.1. [Composition et Fonction](#CompositionetFonction)
|
||||
* 6.1.2. [Cas d'utilisation](#Casdutilisation)
|
||||
* 6.2. [TransactionModeDistribution et TransactionModeDirect](#TransactionModeDistributionetTransactionModeDirect)
|
||||
* 6.3. [TransactionModeDistribution](#TransactionModeDistribution)
|
||||
* 6.3.1. [TransactionModeDirect](#TransactionModeDirect)
|
||||
* 6.4. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 6.4.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 6.4.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 6.5. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
|
||||
* 6.5.1. [Composition et Fonction](#CompositionetFonction-1)
|
||||
* 6.5.2. [Cas d'utilisation](#Casdutilisation-1)
|
||||
* 7. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
|
||||
* 7.1. [RoleCommitment](#RoleCommitment)
|
||||
* 7.2. [RoleDeposit et RolePayments](#RoleDepositetRolePayments)
|
||||
* 8. [Sécurisation des Communications](#ScurisationdesCommunications)
|
||||
* 8.1. [Composition et Utilisation](#CompositionetUtilisation)
|
||||
* 9. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
|
||||
* 10. [Condition PrdAddressSet](#ConditionPrdAddressSet)
|
||||
* 10.1. [Participants](#Participants)
|
||||
* 10.2. [Valeurs des signatures (`sig_value`)](#Valeursdessignaturessig_value)
|
||||
* 10.3. [Minimums et maximums de valeurs "OK", "KO" et "NONE"](#MinimumsetmaximumsdevaleursOKKOetNONE)
|
||||
* 10.4. [Minimums et maximums de scores](#Minimumsetmaximumsdescores)
|
||||
* 11. [ConditionPublish : conditions de publication](#ConditionPublish:conditionsdepublication)
|
||||
* 12. [ConditionOrchestration : conditions d'orchestration des processus](#ConditionOrchestration:conditionsdorchestrationdesprocessus)
|
||||
* 13. [ConditionPayments : conditions de paiement](#ConditionPayments:conditionsdepaiement)
|
||||
* 14. [ConditionCommitment : conditions d'engagement](#ConditionCommitment:conditionsdengagement)
|
||||
* 15. [ConditionDeposit : conditions de dépôt de garantie](#ConditionDeposit:conditionsdedptdegarantie)
|
||||
* 16. [ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement](#ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement)
|
||||
* 17. [TransactionMode](#TransactionMode)
|
||||
* 18. [Exemples de Code](#ExemplesdeCode)
|
||||
* 19. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 2. <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='Porte'></a>Portée
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
|
||||
## 5. <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 `ItemProcess` . Les `rôles` principaux incluent :
|
||||
|
||||
@ -59,36 +69,36 @@ Les rôles déterminent les permissions et les responsabilités des participants
|
||||
|
||||
Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayments`, `RoleDeposit`, et `RoleCommitment`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent.
|
||||
|
||||
## 5. <a name='Prcisionssurlesrles'></a>Précisions sur les rôles
|
||||
## 6. <a name='Prcisionssurlesrles'></a>Précisions sur les rôles
|
||||
|
||||
### 5.1. <a name='RolesGroup-GestiondesRles'></a>RolesGroup - Gestion des Rôles
|
||||
### 6.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.
|
||||
|
||||
#### 5.1.1. <a name='CompositionetFonction'></a>Composition et Fonction
|
||||
#### 6.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.
|
||||
|
||||
#### 5.1.2. <a name='Casdutilisation'></a>Cas d'utilisation
|
||||
#### 6.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.
|
||||
|
||||
### 5.2. <a name='TransactionModeDistributionetTransactionModeDirect'></a>TransactionModeDistribution et TransactionModeDirect
|
||||
### 6.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.
|
||||
|
||||
### 5.3. <a name='TransactionModeDistribution'></a>TransactionModeDistribution
|
||||
### 6.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.
|
||||
|
||||
#### 5.3.1. <a name='TransactionModeDirect'></a>TransactionModeDirect
|
||||
#### 6.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.
|
||||
|
||||
### 5.4. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
### 6.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.
|
||||
|
||||
@ -96,72 +106,72 @@ Ces modes supportent divers scénarios de communication, de la diffusion large d
|
||||
|
||||
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.
|
||||
|
||||
#### 5.4.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
#### 6.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.
|
||||
|
||||
#### 5.4.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
#### 6.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.
|
||||
|
||||
### 5.5. <a name='Role-DfinitionetGestiondesRlesSpcifiques'></a>Role - Définition et Gestion des Rôles Spécifiques
|
||||
### 6.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.
|
||||
|
||||
#### 5.5.1. <a name='CompositionetFonction-1'></a>Composition et Fonction
|
||||
#### 6.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.
|
||||
|
||||
#### 5.5.2. <a name='Casdutilisation-1'></a>Cas d'utilisation
|
||||
#### 6.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.
|
||||
|
||||
## 6. <a name='GestiondesEngagementsetTransactions'></a>Gestion des Engagements et Transactions
|
||||
## 7. <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 RolePayments, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties.
|
||||
|
||||
### 6.1. <a name='RoleCommitment'></a>RoleCommitment
|
||||
### 7.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.
|
||||
|
||||
### 6.2. <a name='RoleDepositetRolePayments'></a>RoleDeposit et RolePayments
|
||||
### 7.2. <a name='RoleDepositetRolePayments'></a>RoleDeposit et RolePayments
|
||||
|
||||
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.
|
||||
|
||||
## 7. <a name='ScurisationdesCommunications'></a>Sécurisation des Communications
|
||||
## 8. <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.
|
||||
|
||||
### 7.1. <a name='CompositionetUtilisation'></a>Composition et Utilisation
|
||||
### 8.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.
|
||||
|
||||
## 8. <a name='IntgrationetOrchestrationdesProcessus'></a>Intégration et Orchestration des Processus
|
||||
## 9. <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.
|
||||
|
||||
## 9. <a name='ConditionPrdAddressSet'></a>Condition PrdAddressSet
|
||||
## 10. <a name='ConditionPrdAddressSet'></a>Condition PrdAddressSet
|
||||
|
||||
A l'issue d'un délai `validation_timeout` par `Role` et par * `request_prd_type`, les `PrdRequest` sont collectés afin de vérifier les conditions de validation par roles sont définies en fonction des critères suivants :
|
||||
|
||||
Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
|
||||
### 9.1. <a name='Participants'></a> Participants
|
||||
### 10.1. <a name='Participants'></a> Participants
|
||||
|
||||
* `request_prd_sp_address_list`: Liste des `adresse SP` (cumulatif avec `from_role`)
|
||||
* `request_prd_sp_address_required_list`: Liste des `adresse SP` requises (toutes valeurs confondues)
|
||||
* `request_prd_sp_address_quota`: Quota minmum de `adresse SP` participantes (toutes valeurs confondues)
|
||||
* `request_prd_sp_address_score_min`: Score minimal des membres participants (toutes valeurs confondues)
|
||||
|
||||
### 9.2. <a name='Valeursdessignaturessig_value'></a> Valeurs des signatures (`sig_value`)
|
||||
### 10.2. <a name='Valeursdessignaturessig_value'></a> Valeurs des signatures (`sig_value`)
|
||||
|
||||
* (option)`request_prd_value_ok_list`: Liste des valeurs valant pour "OK"
|
||||
* (option)`request_prd_value_ko_list`: Liste des valeurs valant pour "KO"
|
||||
@ -170,7 +180,7 @@ Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
* (option)`request_prd_value_auto_ko`: Valeur automatique valant pour "KO"
|
||||
* (option)`request_prd_value_auto_none`: Valeur automatique valant pour "NONE"
|
||||
|
||||
### 9.3. <a name='MinimumsetmaximumsdevaleursOKKOetNONE'></a>Minimums et maximums de valeurs "OK", "KO" et "NONE"
|
||||
### 10.3. <a name='MinimumsetmaximumsdevaleursOKKOetNONE'></a>Minimums et maximums de valeurs "OK", "KO" et "NONE"
|
||||
|
||||
* (option)`request_prd_sp_address_value_min_ok`: Nombre minimal de valeurs valant pour "OK"
|
||||
* (option)`request_prd_sp_adddress_value_ok_min_per`: Pourcentage minimal de valeurs valant pour "OK"
|
||||
@ -182,7 +192,7 @@ Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
* (option)`request_prd_sp_address_value_none_max`: Nombre maximal de valeurs valant pour "NONE"
|
||||
* (option)`request_prd_sp_adderss_value_none_max_per`: Pourcentage maximal de valeurs valant pour "NONE"
|
||||
|
||||
### 9.4. <a name='Minimumsetmaximumsdescores'></a>Minimums et maximums de scores
|
||||
### 10.4. <a name='Minimumsetmaximumsdescores'></a>Minimums et maximums de scores
|
||||
|
||||
* (option)`request_prd_sp_address_score_min_min_ok`: Nombre de membres avec un score minimum et une valeur valant pour "OK"
|
||||
* (option)`request_prd_sp_address_score_min_min_per`:: Pourcentage de membres avec un score minimum et une valeur valant pour "OK"
|
||||
@ -190,7 +200,7 @@ Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
* (option)`request_prd_sp_address_value_min`: Valeur minimal valant pour "OK" (cas de nombres)
|
||||
* (option) `from_role` : `address SP` de ce `Role` (pour éviter de dupliquer les `addresse SP`)
|
||||
|
||||
## 10. <a name='ConditionPublish:conditionsdepublication'></a>ConditionPublish : conditions de publication
|
||||
## 11. <a name='ConditionPublish:conditionsdepublication'></a>ConditionPublish : conditions de publication
|
||||
|
||||
* (option)`request_pcd_data_size_max_unit`: Taille maximale des données de chaque `Pcd` en Mo
|
||||
* (option)`request_pcd_data_size_max_total`: Taille maximale des données des `Pcd` en Mo
|
||||
@ -200,33 +210,32 @@ Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
* (option)`request_prd_waiting_timeout`: Délai d'attente pour la réception des `Prd`
|
||||
* (option)`request_pcd_waiting_timeout`: Délai d'attente pour la réception des `Pcd`
|
||||
|
||||
|
||||
## 14. <a name='ConditionOrchestration:conditionsdorchestrationdesprocessus'></a>ConditionOrchestration : conditions d'orchestration des processus
|
||||
## 12. <a name='ConditionOrchestration:conditionsdorchestrationdesprocessus'></a>ConditionOrchestration : conditions d'orchestration des processus
|
||||
|
||||
* (option) `role_ok`: `Role` à vérifier en cas de résulats final "OK"
|
||||
* (option) `role_ko`: `Role` à vérifier en cas de résulats final "KO"
|
||||
|
||||
## 11. <a name='ConditionPayments:conditionsdepaiement'></a>ConditionPayments : conditions de paiement
|
||||
## 13. <a name='ConditionPayments:conditionsdepaiement'></a>ConditionPayments : conditions de paiement
|
||||
|
||||
* (option) `Payments_method_list`: Liste des modes de paiement acceptés
|
||||
* (option) `role_transaction` : voir `TransactionMode`
|
||||
|
||||
## 12. <a name='ConditionCommitment:conditionsdengagement'></a>ConditionCommitment : conditions d'engagement
|
||||
## 14. <a name='ConditionCommitment:conditionsdengagement'></a>ConditionCommitment : conditions d'engagement
|
||||
|
||||
* (option) `role_artefact`
|
||||
* (option) `role_transaction` : voir `TransactionMode`
|
||||
|
||||
## 13. <a name='ConditionDeposit:conditionsdedptdegarantie'></a>ConditionDeposit : conditions de dépôt de garantie
|
||||
## 15. <a name='ConditionDeposit:conditionsdedptdegarantie'></a>ConditionDeposit : conditions de dépôt de garantie
|
||||
|
||||
* (option) `role_deposit`
|
||||
* (option) `role_transaction` : voir `TransactionMode`
|
||||
|
||||
## 15. <a name='ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement'></a>ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement
|
||||
## 16. <a name='ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement'></a>ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement
|
||||
|
||||
* (option) `role_deposit`
|
||||
* (option) `role_transaction` : voir `TransactionMode`
|
||||
|
||||
## TransactionMode
|
||||
## 17. <a name='TransactionMode'></a>TransactionMode
|
||||
|
||||
* `value`: Montant du paiement (objet `Amount` ou `Number`)
|
||||
* `from_list` : Liste des adresses ou des rôles qui doivent opérer le paiement
|
||||
@ -236,9 +245,9 @@ Les membres concernés sont identifiés par leurs `adresse SP`.
|
||||
* `to_type` : Soit "addresses" soit "roles"
|
||||
* `to_method` : Méthode de distribution de la somme des versements : "Amount divided" ou "Same Amount"
|
||||
|
||||
## 16. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 18. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 17. <a name='Todo'></a>Todo
|
||||
## 19. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -1,27 +1,32 @@
|
||||
# Relay - Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Interface Client Web](#InterfaceClientWeb)
|
||||
* 4.1. [Structure HTML de Base](#StructureHTMLdeBase)
|
||||
* 4.2. [Page de création d'une identité numérique (create)](#Pagedecrationduneidentitnumriquecreate)
|
||||
* 4.2.1. [Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover`](#PagedeslectiondelItemProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover)
|
||||
* 4.2.2. [Page d'enrolement dans un `ItemProcess` (`onboarding`)](#PagedenrolementdansunItemProcessonboarding)
|
||||
* 4.2.3. [Page de téléchargement des images de login des third parties](#Pagedetlchargementdesimagesdelogindesthirdparties)
|
||||
* 4.3. [Page de récupération d'une identité numérique (`recover`)](#Pagedercuprationduneidentitnumriquerecover)
|
||||
* 4.4. [Page de révocation d'une identité numérique (`revoke`)](#Pagedervocationduneidentitnumriquerevoke)
|
||||
* 4.5. [Page de la liste des `ItemProcess`](#PagedelalistedesItemProcess)
|
||||
* 4.6. [Page de Détail d'un `ItemProcess`](#PagedeDtaildunItemProcess)
|
||||
* 4.7. [Page socle des `ItemProcess`](#PagesocledesItemProcess)
|
||||
* 4.7.1. [4.7. Page de la liste d'un type d'`Item`](#PagedelalisteduntypedItem)
|
||||
* 4.7.2. [4.7. Page de détail d'un `Item`](#PagededtaildunItem)
|
||||
* 4.7.3. [4.7. Page de la liste des notifications](#Pagedelalistedesnotifications)
|
||||
* 4.7.4. [4.7. Page de détail d'une notifications](#Pagededtaildunenotifications)
|
||||
* 4.8. [Page d'import d'une image de login](#Pagedimportduneimagedelogin)
|
||||
* 4.9. [Page de validation d'un code de confirmation (2FA)](#Pagedevalidationduncodedeconfirmation2FA)
|
||||
* 5. [5. SDK Typescript](#5.SDKTypescript)
|
||||
* 6. [5. SDK Web Assembly](#5.SDKWebAssembly)
|
||||
* 7. [5. Serveur web](#5.Serveurweb)
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [Interface Client Web](#InterfaceClientWeb)
|
||||
* 5.1. [Structure HTML de Base](#StructureHTMLdeBase)
|
||||
* 5.2. [Page de création d'une identité numérique (create)](#Pagedecrationduneidentitnumriquecreate)
|
||||
* 5.2.1. [Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover`](#PagedeslectiondelItemProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover)
|
||||
* 5.2.2. [Page d'enrolement dans un `ItemProcess` (`onboarding`)](#PagedenrolementdansunItemProcessonboarding)
|
||||
* 5.2.3. [Page de téléchargement des images de login des third parties](#Pagedetlchargementdesimagesdelogindesthirdparties)
|
||||
* 5.3. [Page de récupération d'une identité numérique (`recover`)](#Pagedercuprationduneidentitnumriquerecover)
|
||||
* 5.4. [Page de révocation d'une identité numérique (`revoke`)](#Pagedervocationduneidentitnumriquerevoke)
|
||||
* 5.5. [Page de la liste des `ItemProcess`](#PagedelalistedesItemProcess)
|
||||
* 5.6. [Page de Détail d'un `ItemProcess`](#PagedeDtaildunItemProcess)
|
||||
* 5.7. [Page socle des `ItemProcess`](#PagesocledesItemProcess)
|
||||
* 5.7.1. [4.7. Page de la liste d'un type d'`Item`](#PagedelalisteduntypedItem)
|
||||
* 5.7.2. [4.7. Page de détail d'un `Item`](#PagededtaildunItem)
|
||||
* 5.7.3. [4.7. Page de la liste des notifications](#Pagedelalistedesnotifications)
|
||||
* 5.7.4. [4.7. Page de détail d'une notifications](#Pagededtaildunenotifications)
|
||||
* 5.8. [Page d'import d'une image de login](#Pagedimportduneimagedelogin)
|
||||
* 5.9. [Page de validation d'un code de confirmation (2FA)](#Pagedevalidationduncodedeconfirmation2FA)
|
||||
* 6. [5. SDK Typescript](#5.SDKTypescript)
|
||||
* 7. [5. SDK Web Assembly](#5.SDKWebAssembly)
|
||||
* 8. [5. Serveur web](#5.Serveurweb)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
@ -29,15 +34,13 @@
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
# Auth - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
## 2. <a name='Objectif'></a>Objectif
|
||||
|
||||
L'objectif de cette spécification est de définir les exigences et les fonctionnalités de l'interface client web pour l'authentification et l'identification des utilisateurs sur la plateforme 4NK Web5 Solution.
|
||||
|
||||
Tous les relais ont les mêmes pages, et partagent le SDK en Wasm de 4NK, leur liste d'`ItemPeer` et leur liste `ItemProcess`.
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
## 3. <a name='Porte'></a>Portée
|
||||
|
||||
La portée de cette spécification comprend les exigences et les fonctionnalités suivantes pour l'interface client web.
|
||||
|
||||
@ -45,13 +48,13 @@ Wireframes :
|
||||
|
||||
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='InterfaceClientWeb'></a>Interface Client Web
|
||||
## 5. <a name='InterfaceClientWeb'></a>Interface Client Web
|
||||
|
||||
### 4.1. <a name='StructureHTMLdeBase'></a>Structure HTML de Base
|
||||
### 5.1. <a name='StructureHTMLdeBase'></a>Structure HTML de Base
|
||||
|
||||
Pour créer une application client web interactive qui communique efficacement avec les relais, une structure de base HTML est nécessaire. Voici les éléments clés à inclure dans votre fichier HTML pour démarrer avec l'application 4NK :
|
||||
|
||||
@ -95,38 +98,38 @@ Cadre HML commun aux pages des relais :
|
||||
* **Conteneur Principal** : Un div conteneur avec un identifiant unique (id="containerId") sert de point d'ancrage pour l'injection de contenu dynamique ou d'interfaces utilisateur spécifiques à l'application.
|
||||
* **Intégration des composants WASM dans l'interface utilisateur**: Un module permet d'intégrer un wrapper js avec le Wasm pour une interaction fluide avec les relais via le WebAssembly.
|
||||
|
||||
### 4.2. <a name='Pagedecrationduneidentitnumriquecreate'></a>Page de création d'une identité numérique (create)
|
||||
### 5.2. <a name='Pagedecrationduneidentitnumriquecreate'></a>Page de création d'une identité numérique (create)
|
||||
|
||||
#### 4.2.1. <a name='PagedeslectiondelItemProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover'></a>Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover`
|
||||
#### 5.2.1. <a name='PagedeslectiondelItemProcessetdesmembresenchargederenvoyerlesshardsdelaclrecover'></a>Page de sélection de l'`ItemProcess` et des membres en charge de renvoyer les shards de la clé `recover`
|
||||
|
||||
#### 4.2.2. <a name='PagedenrolementdansunItemProcessonboarding'></a>Page d'enrolement dans un `ItemProcess` (`onboarding`)
|
||||
#### 5.2.2. <a name='PagedenrolementdansunItemProcessonboarding'></a>Page d'enrolement dans un `ItemProcess` (`onboarding`)
|
||||
|
||||
#### 4.2.3. <a name='Pagedetlchargementdesimagesdelogindesthirdparties'></a>Page de téléchargement des images de login des third parties
|
||||
#### 5.2.3. <a name='Pagedetlchargementdesimagesdelogindesthirdparties'></a>Page de téléchargement des images de login des third parties
|
||||
|
||||
### 4.3. <a name='Pagedercuprationduneidentitnumriquerecover'></a>Page de récupération d'une identité numérique (`recover`)
|
||||
### 5.3. <a name='Pagedercuprationduneidentitnumriquerecover'></a>Page de récupération d'une identité numérique (`recover`)
|
||||
|
||||
### 4.4. <a name='Pagedervocationduneidentitnumriquerevoke'></a>Page de révocation d'une identité numérique (`revoke`)
|
||||
### 5.4. <a name='Pagedervocationduneidentitnumriquerevoke'></a>Page de révocation d'une identité numérique (`revoke`)
|
||||
|
||||
### 4.5. <a name='PagedelalistedesItemProcess'></a>Page de la liste des `ItemProcess`
|
||||
### 5.5. <a name='PagedelalistedesItemProcess'></a>Page de la liste des `ItemProcess`
|
||||
|
||||
### 4.6. <a name='PagedeDtaildunItemProcess'></a>Page de Détail d'un `ItemProcess`
|
||||
### 5.6. <a name='PagedeDtaildunItemProcess'></a>Page de Détail d'un `ItemProcess`
|
||||
|
||||
### 4.7. <a name='PagesocledesItemProcess'></a>Page socle des `ItemProcess`
|
||||
### 5.7. <a name='PagesocledesItemProcess'></a>Page socle des `ItemProcess`
|
||||
|
||||
#### 4.7.1. <a name='PagedelalisteduntypedItem'></a>4.7. Page de la liste d'un type d'`Item`
|
||||
#### 5.7.1. <a name='PagedelalisteduntypedItem'></a>4.7. Page de la liste d'un type d'`Item`
|
||||
|
||||
#### 4.7.2. <a name='PagededtaildunItem'></a>4.7. Page de détail d'un `Item`
|
||||
#### 5.7.2. <a name='PagededtaildunItem'></a>4.7. Page de détail d'un `Item`
|
||||
|
||||
#### 4.7.3. <a name='Pagedelalistedesnotifications'></a>4.7. Page de la liste des notifications
|
||||
#### 5.7.3. <a name='Pagedelalistedesnotifications'></a>4.7. Page de la liste des notifications
|
||||
|
||||
#### 4.7.4. <a name='Pagededtaildunenotifications'></a>4.7. Page de détail d'une notifications
|
||||
#### 5.7.4. <a name='Pagededtaildunenotifications'></a>4.7. Page de détail d'une notifications
|
||||
|
||||
### 4.8. <a name='Pagedimportduneimagedelogin'></a>Page d'import d'une image de login
|
||||
### 5.8. <a name='Pagedimportduneimagedelogin'></a>Page d'import d'une image de login
|
||||
|
||||
### 4.9. <a name='Pagedevalidationduncodedeconfirmation2FA'></a>Page de validation d'un code de confirmation (2FA)
|
||||
### 5.9. <a name='Pagedevalidationduncodedeconfirmation2FA'></a>Page de validation d'un code de confirmation (2FA)
|
||||
|
||||
## 5. <a name='5.SDKTypescript'></a> 5. SDK Typescript
|
||||
## 6. <a name='5.SDKTypescript'></a> 5. SDK Typescript
|
||||
|
||||
## 6. <a name='5.SDKWebAssembly'></a> 5. SDK Web Assembly
|
||||
## 7. <a name='5.SDKWebAssembly'></a> 5. SDK Web Assembly
|
||||
|
||||
## 7. <a name='5.Serveurweb'></a> 5. Serveur web
|
||||
## 8. <a name='5.Serveurweb'></a> 5. Serveur web
|
||||
|
||||
@ -1,27 +1,33 @@
|
||||
# Silent Payments - Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Fonction](#Fonction)
|
||||
* 5. [Structure des outputs](#Structuredesoutputs)
|
||||
* 6. [Envoi de la transaction SP](#EnvoidelatransactionSP)
|
||||
* 6.1. [Dans un `PrdMessage`](#DansunPrdMessage)
|
||||
* 6.2. [Dans un `Message` du `PrdMessage`](#DansunMessageduPrdMessage)
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Objectif](#Objectif)
|
||||
* 3. [Portée](#Porte)
|
||||
* 4. [Documents de référence](#Documentsderfrence)
|
||||
* 5. [ Fonction](#Fonction)
|
||||
* 6. [ Structure des outputs](#Structuredesoutputs)
|
||||
* 7. [Envoi de la transaction SP](#EnvoidelatransactionSP)
|
||||
* 7.1. [Dans un `PrdMessage`](#DansunPrdMessage)
|
||||
* 7.2. [Dans un `Message` du `PrdMessage`](#DansunMessageduPrdMessage)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
## 2. <a name='Objectif'></a>Objectif
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 3. <a name='Porte'></a>Portée
|
||||
|
||||
## 4. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='Fonction'></a> Fonction
|
||||
## 5. <a name='Fonction'></a> Fonction
|
||||
|
||||
La transaction SP à plusieurs objectifs :
|
||||
|
||||
@ -38,7 +44,7 @@ Les `PrdConfirm` qui sont des accusés automatiques de réception des `Prd` sont
|
||||
|
||||
Il y a une `transactions SP` pour tous les types de `Prd`.
|
||||
|
||||
## 5. <a name='Structuredesoutputs'></a> Structure des outputs
|
||||
## 6. <a name='Structuredesoutputs'></a> Structure des outputs
|
||||
|
||||
Une fois le `Prd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:
|
||||
|
||||
@ -58,19 +64,19 @@ Une fois le `Prd` finalisé, une transaction SP est réalisée, dans cette trans
|
||||
|
||||
Pour des raison de confidentialité, le `Role` associé à l'`item_name` du `Prd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`.
|
||||
|
||||
## 6. <a name='EnvoidelatransactionSP'></a>Envoi de la transaction SP
|
||||
## 7. <a name='EnvoidelatransactionSP'></a>Envoi de la transaction SP
|
||||
|
||||
Afin d'améliorer la rélisience du broadcast des transactions, la transaction est envoyée à la fois :
|
||||
|
||||
1. Dans un `PrdMessage` à un membre du rôle `member` du `ItemProcess` concerné et
|
||||
2. Dans le `Message` du `PrdMessage` sur les relais
|
||||
|
||||
### 6.1. <a name='DansunPrdMessage'></a>Dans un `PrdMessage`
|
||||
### 7.1. <a name='DansunPrdMessage'></a>Dans un `PrdMessage`
|
||||
|
||||
Dans l'attribut `raw_transaction_list` du `PrdMessage` associé à la transaction SP.
|
||||
La transaction sera broadcastée par les noeuds de signet du membre du `Role` `member` du `ItemProcess` concerné qui a reçu ce message, il devra alors avoir un noeud de signet pour le broadcast.
|
||||
|
||||
### 6.2. <a name='DansunMessageduPrdMessage'></a>Dans un `Message` du `PrdMessage`
|
||||
### 7.2. <a name='DansunMessageduPrdMessage'></a>Dans un `Message` du `PrdMessage`
|
||||
|
||||
Dans l'attribut `raw_transaction_list` du `Message` associé à la transaction SP.
|
||||
La transaction sera broadcastée par les noeuds de signet des relais.
|
||||
|
||||
@ -1,30 +1,35 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Documents de référence](#Documentsderfrence)
|
||||
* 2. [Gestion des erreurs](#Gestiondeserreurs)
|
||||
* 3. [Journalisation et monitoring](#Journalisationetmonitoring)
|
||||
* 4. [Tests](#Tests)
|
||||
* 4.1. [Stratégie de test](#Stratgiedetest)
|
||||
* 4.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires)
|
||||
* 4.3. [Plan d'intégration](#Plandintgration)
|
||||
* 4.4. [Plan de charge](#Plandecharge)
|
||||
* 5. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser)
|
||||
* 6. [Critères d'acceptation](#Critresdacceptation)
|
||||
* 7. [CI/CD](#CICD)
|
||||
* 8. [Maintenance](#Maintenance)
|
||||
* 9. [Exemples de Code](#ExemplesdeCode)
|
||||
* 10. [Todo](#Todo)
|
||||
# Code
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Documents de référence](#Documentsderfrence)
|
||||
* 3. [Gestion des erreurs](#Gestiondeserreurs)
|
||||
* 4. [Journalisation et monitoring](#Journalisationetmonitoring)
|
||||
* 5. [Tests](#Tests)
|
||||
* 5.1. [Stratégie de test](#Stratgiedetest)
|
||||
* 5.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires)
|
||||
* 5.3. [Plan d'intégration](#Plandintgration)
|
||||
* 5.4. [Plan de charge](#Plandecharge)
|
||||
* 6. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser)
|
||||
* 7. [Critères d'acceptation](#Critresdacceptation)
|
||||
* 8. [CI/CD](#CICD)
|
||||
* 9. [Maintenance](#Maintenance)
|
||||
* 10. [Exemples de Code](#ExemplesdeCode)
|
||||
* 11. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Specs - Code
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 1. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 2. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 2. <a name='Gestiondeserreurs'></a>Gestion des erreurs
|
||||
## 3. <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.
|
||||
|
||||
@ -38,7 +43,7 @@ Les arrêts des membres dans les `ItemProcess` dans leur ensemble n'entraînent
|
||||
|
||||
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.
|
||||
|
||||
## 3. <a name='Journalisationetmonitoring'></a>Journalisation et monitoring
|
||||
## 4. <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 `ItemProcess` (possible de segmenter par zones et services).
|
||||
|
||||
@ -46,27 +51,27 @@ Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents s
|
||||
|
||||
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.
|
||||
|
||||
## 4. <a name='Tests'></a>Tests
|
||||
## 5. <a name='Tests'></a>Tests
|
||||
|
||||
### 4.1. <a name='Stratgiedetest'></a>Stratégie de test
|
||||
### 5.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.
|
||||
|
||||
### 4.2. <a name='Planpourlestestsunitaires'></a>Plan pour les tests unitaires
|
||||
### 5.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.
|
||||
|
||||
### 4.3. <a name='Plandintgration'></a>Plan d'intégration
|
||||
### 5.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.
|
||||
|
||||
### 4.4. <a name='Plandecharge'></a>Plan de charge
|
||||
### 5.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.
|
||||
|
||||
## 5. <a name='Outilsetleslibrairiesutiliser'></a>Outils et les librairies à utiliser
|
||||
## 6. <a name='Outilsetleslibrairiesutiliser'></a>Outils et les librairies à utiliser
|
||||
|
||||
Respect des normes de syntaxe Rust.
|
||||
|
||||
@ -84,7 +89,7 @@ Utilisation de Visual Studio (pour le partage de configurations).
|
||||
|
||||
* **Librairies de tests** : Cargo test
|
||||
|
||||
## 6. <a name='Critresdacceptation'></a>Critères d'acceptation
|
||||
## 7. <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 :
|
||||
|
||||
@ -98,15 +103,15 @@ Critères de validation pour que le système puisse être considéré comme prê
|
||||
* Documentation manquante clairement précisée.
|
||||
* Autres tests manquants clairement précisés.
|
||||
|
||||
## 7. <a name='CICD'></a>CI/CD
|
||||
## 8. <a name='CICD'></a>CI/CD
|
||||
|
||||
GitLab CI : TBD
|
||||
|
||||
## 8. <a name='Maintenance'></a>Maintenance
|
||||
## 9. <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.
|
||||
|
||||
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 10. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 10. <a name='Todo'></a>Todo
|
||||
## 11. <a name='Todo'></a>Todo
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,23 +1,28 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Documents de référence](#Documentsderfrence)
|
||||
* 2. [Spécifique 4NK](#Spcifique4NK)
|
||||
* 3. [Bitcoin](#Bitcoin)
|
||||
* 4. [Chiffrement](#Chiffrement)
|
||||
* 5. [Data](#Data)
|
||||
* 6. [Exemples de Code](#ExemplesdeCode)
|
||||
* 7. [Todo](#Todo)
|
||||
# Définition
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Documents de référence](#Documentsderfrence)
|
||||
* 3. [Spécifique 4NK](#Spcifique4NK)
|
||||
* 4. [Bitcoin](#Bitcoin)
|
||||
* 5. [Chiffrement](#Chiffrement)
|
||||
* 6. [Data](#Data)
|
||||
* 7. [Exemples de Code](#ExemplesdeCode)
|
||||
* 8. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Définitions et abréviations
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
## 1. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 2. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 2. <a name='Spcifique4NK'></a>Spécifique 4NK
|
||||
## 3. <a name='Spcifique4NK'></a>Spécifique 4NK
|
||||
|
||||
* **Web 5.0.** : Une plateforme décentralisée innovante développée par 4NK, combinant les technologies de blockchain et de contrats intelligents pour révolutionner la manière dont les applications web interagissent avec les données et les transactions sécurisées.
|
||||
|
||||
@ -66,7 +71,7 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
* **Autres termes propres à 4nk**: voir Specs-Datas.md.
|
||||
|
||||
## 3. <a name='Bitcoin'></a>Bitcoin
|
||||
## 4. <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.
|
||||
|
||||
@ -76,7 +81,7 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
* **Silent Payments (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.
|
||||
|
||||
## 4. <a name='Chiffrement'></a>Chiffrement
|
||||
## 5. <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.
|
||||
|
||||
@ -94,12 +99,12 @@ Cette norme est aujourd'hui utilisée pour le hachage de mot de passe (associé
|
||||
|
||||
* **Transport Layer Security**: Protocoles de sécurisation des échanges par réseau informatique, notamment par Internet.
|
||||
|
||||
## 5. <a name='Data'></a>Data
|
||||
## 6. <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 `ItemProcess` découverts et les pairs du réseau. Une fois identifié auprès des membres d'un `ItemProcess` 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.
|
||||
|
||||
## 6. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 7. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 7. <a name='Todo'></a>Todo
|
||||
## 8. <a name='Todo'></a>Todo
|
||||
|
||||
@ -1,25 +1,28 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Documents de référence](#Documentsderfrence)
|
||||
* 2. [Code repository](#Coderepository)
|
||||
* 3. [Exemples de Code](#ExemplesdeCode)
|
||||
* 4. [Todo](#Todo)
|
||||
# Maintenance, environnement de déploiement - Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Documents de référence](#Documentsderfrence)
|
||||
* 3. [Code repository](#Coderepository)
|
||||
* 4. [Exemples de Code](#ExemplesdeCode)
|
||||
* 5. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Specs - Maintenance, environnement de déploiement
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
# Deployement
|
||||
|
||||
## 1. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 2. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 2. <a name='Coderepository'></a>Code repository
|
||||
## 3. <a name='Coderepository'></a>Code repository
|
||||
|
||||
Voir le git du projet `infra_node`.
|
||||
|
||||
## 3. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 4. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 4. <a name='Todo'></a>Todo
|
||||
## 5. <a name='Todo'></a>Todo
|
||||
|
||||
@ -1,34 +1,38 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Documents de référence](#Documentsderfrence)
|
||||
* 2. [AES & Quantum resistant](#AESQuantumresistant)
|
||||
* 3. [Crypto](#Crypto)
|
||||
* 4. [Bitcoin Silent Payments](#BitcoinSilentPayments)
|
||||
* 5. [Bitcoin wallet](#Bitcoinwallet)
|
||||
* 6. [Bitcoin protocols](#Bitcoinprotocols)
|
||||
* 7. [Data anchoring](#Dataanchoring)
|
||||
* 8. [Layers](#Layers)
|
||||
* 9. [Todo](#Todo)
|
||||
# Specs - References
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Documents de référence](#Documentsderfrence)
|
||||
* 3. [AES & Quantum resistant](#AESQuantumresistant)
|
||||
* 4. [Crypto](#Crypto)
|
||||
* 5. [Bitcoin Silent Payments](#BitcoinSilentPayments)
|
||||
* 6. [Bitcoin wallet](#Bitcoinwallet)
|
||||
* 7. [Bitcoin protocols](#Bitcoinprotocols)
|
||||
* 8. [Data anchoring](#Dataanchoring)
|
||||
* 9. [Layers](#Layers)
|
||||
* 10. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc -->
|
||||
# Specs - References
|
||||
|
||||
## 1. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 2. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 2. <a name='AESQuantumresistant'></a>AES & Quantum resistant
|
||||
## 3. <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>
|
||||
|
||||
## 3. <a name='Crypto'></a>Crypto
|
||||
## 4. <a name='Crypto'></a>Crypto
|
||||
|
||||
* <https://en.wikipedia.org/wiki/Scrypt>
|
||||
|
||||
## 4. <a name='BitcoinSilentPayments'></a>Bitcoin Silent Payments
|
||||
## 5. <a name='BitcoinSilentPayments'></a>Bitcoin Silent Payments
|
||||
|
||||
* <https://github.com/bitcoin/bitcoin/issues/28536>
|
||||
* <https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki>
|
||||
@ -38,7 +42,7 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
* <https://gnusha.org/taproot-bip-review/2020-01-23.log>
|
||||
* <https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406>
|
||||
|
||||
## 5. <a name='Bitcoinwallet'></a>Bitcoin wallet
|
||||
## 6. <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>
|
||||
@ -46,21 +50,21 @@ Voir [_Doc_references.md](_Doc_references.md).
|
||||
* <https://en.bitcoin.it/wiki/BIP_0032>
|
||||
* <https://en.bitcoin.it/wiki/BIP_0044>
|
||||
|
||||
## 6. <a name='Bitcoinprotocols'></a>Bitcoin protocols
|
||||
## 7. <a name='Bitcoinprotocols'></a>Bitcoin protocols
|
||||
|
||||
* <https://en.bitcoin.it/wiki/Protocol_specification>
|
||||
* <https://en.bitcoin.it/wiki/Protocol_specification#Inventory_Vectors>
|
||||
|
||||
## 7. <a name='Dataanchoring'></a>Data anchoring
|
||||
## 8. <a name='Dataanchoring'></a>Data anchoring
|
||||
|
||||
* <https://bitcoin.stackexchange.com/questions/78572/op-return-max-bytes-clarification>
|
||||
* <https://petertodd.org/2016/opentimestamps-announcement#fnref:rewrite>
|
||||
* <https://www.lopp.net/bitcoin-information/data-anchor.html>
|
||||
|
||||
## 8. <a name='Layers'></a>Layers
|
||||
## 9. <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>
|
||||
|
||||
## 9. <a name='Todo'></a>Todo
|
||||
## 10. <a name='Todo'></a>Todo
|
||||
|
||||
@ -1,51 +1,56 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Documents de référence](#Documentsderfrence)
|
||||
* 2. [Détails de conception](#Dtailsdeconception)
|
||||
* 3. [Mot de passe](#Motdepasse)
|
||||
* 4. [Cache](#Cache)
|
||||
* 5. [Chiffrement des communications](#Chiffrementdescommunications)
|
||||
* 6. [Confidentialité des `Pcd` et Prd](#ConfidentialitdesPcdetPrd)
|
||||
* 7. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
|
||||
* 8. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
|
||||
* 8.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
|
||||
* 8.2. [Diffusion et confusion](#Diffusionetconfusion)
|
||||
* 8.3. [Non-linéarité](#Non-linarit)
|
||||
* 9. [Fonctions de hashage](#Fonctionsdehashage)
|
||||
* 10. [Exigences génériques](#Exigencesgnriques)
|
||||
* 10.1. [Pas de secret de la conception](#Pasdesecretdelaconception)
|
||||
* 10.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique)
|
||||
* 10.3. [Implémentation correcte](#Implmentationcorrecte)
|
||||
* 10.4. [Détermination](#Dtermination)
|
||||
* 10.5. [Rapidité de calcul](#Rapiditdecalcul)
|
||||
* 10.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche)
|
||||
* 10.7. [Résistance aux collisions](#Rsistanceauxcollisions)
|
||||
* 10.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles)
|
||||
* 10.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes)
|
||||
* 10.8. [Résistance à la pre_id](#Rsistancelapre_id)
|
||||
* 10.8.1. [Résistance à la pre_id](#Rsistancelapre_id-1)
|
||||
* 10.8.2. [Résistance à la seconde pre_id](#Rsistancelasecondepre_id)
|
||||
* 10.9. [Compression](#Compression)
|
||||
* 10.10. [Non réversibilité](#Nonrversibilit)
|
||||
* 10.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible)
|
||||
* 11. [Gestion sécurisée des clés](#Gestionscurisedescls)
|
||||
* 12. [Performance](#Performance)
|
||||
* 13. [Disponibilité](#Disponibilit)
|
||||
* 14. [Évolutivité](#volutivit)
|
||||
* 15. [Autres Mesures de sécurité](#AutresMesuresdescurit)
|
||||
* 16. [Todo](#Todo)
|
||||
# Exigences de sécurité et de confidentialité
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Documents de référence](#Documentsderfrence)
|
||||
* 3. [Détails de conception](#Dtailsdeconception)
|
||||
* 4. [Mot de passe](#Motdepasse)
|
||||
* 5. [Cache](#Cache)
|
||||
* 6. [Chiffrement des communications](#Chiffrementdescommunications)
|
||||
* 7. [Confidentialité des `Pcd` et Prd](#ConfidentialitdesPcdetPrd)
|
||||
* 8. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
|
||||
* 9. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
|
||||
* 9.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
|
||||
* 9.2. [Diffusion et confusion](#Diffusionetconfusion)
|
||||
* 9.3. [Non-linéarité](#Non-linarit)
|
||||
* 10. [Fonctions de hashage](#Fonctionsdehashage)
|
||||
* 11. [Exigences génériques](#Exigencesgnriques)
|
||||
* 11.1. [Pas de secret de la conception](#Pasdesecretdelaconception)
|
||||
* 11.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique)
|
||||
* 11.3. [Implémentation correcte](#Implmentationcorrecte)
|
||||
* 11.4. [Détermination](#Dtermination)
|
||||
* 11.5. [Rapidité de calcul](#Rapiditdecalcul)
|
||||
* 11.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche)
|
||||
* 11.7. [Résistance aux collisions](#Rsistanceauxcollisions)
|
||||
* 11.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles)
|
||||
* 11.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes)
|
||||
* 11.8. [Résistance à la pre_id](#Rsistancelapre_id)
|
||||
* 11.8.1. [Résistance à la pre_id](#Rsistancelapre_id-1)
|
||||
* 11.8.2. [Résistance à la seconde pre_id](#Rsistancelasecondepre_id)
|
||||
* 11.9. [Compression](#Compression)
|
||||
* 11.10. [Non réversibilité](#Nonrversibilit)
|
||||
* 11.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible)
|
||||
* 12. [Gestion sécurisée des clés](#Gestionscurisedescls)
|
||||
* 13. [Performance](#Performance)
|
||||
* 14. [Disponibilité](#Disponibilit)
|
||||
* 15. [Évolutivité](#volutivit)
|
||||
* 16. [Autres Mesures de sécurité](#AutresMesuresdescurit)
|
||||
* 17. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Exigences de sécurité et de confidentialité
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
|
||||
## 1. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 2. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 2. <a name='Dtailsdeconception'></a>Détails de conception
|
||||
## 3. <a name='Dtailsdeconception'></a>Détails de conception
|
||||
|
||||
Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits.
|
||||
|
||||
@ -53,23 +58,23 @@ 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.
|
||||
|
||||
## 3. <a name='Motdepasse'></a>Mot de passe
|
||||
## 4. <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.
|
||||
|
||||
## 4. <a name='Cache'></a>Cache
|
||||
## 5. <a name='Cache'></a>Cache
|
||||
|
||||
Stockage sécurisé du cache par un chiffrement par le mot de passe.
|
||||
|
||||
## 5. <a name='Chiffrementdescommunications'></a>Chiffrement des communications
|
||||
## 6. <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.
|
||||
|
||||
## 6. <a name='ConfidentialitdesPcdetPrd'></a>Confidentialité des `Pcd` et Prd
|
||||
## 7. <a name='ConfidentialitdesPcdetPrd'></a>Confidentialité des `Pcd` et Prd
|
||||
|
||||
Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes.
|
||||
|
||||
@ -83,7 +88,7 @@ Le chiffrement des `Pcd` est un chiffrement symétrique conformément aux exigen
|
||||
|
||||
* **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).
|
||||
|
||||
## 7. <a name='Confidentialitdesmessagessurlesrelais'></a>Confidentialité des messages sur les relais
|
||||
## 8. <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`.
|
||||
|
||||
@ -93,89 +98,89 @@ Tous les `Prd` sont confirmés par un et chiffrent les clés transamises par une
|
||||
|
||||
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.
|
||||
|
||||
## 8. <a name='Cldechiffrementrobuste'></a>Clé de chiffrement robuste
|
||||
## 9. <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.
|
||||
|
||||
### 8.1. <a name='Rsistanceauxattaquescryptanalytiques'></a>Résistance aux attaques cryptanalytiques
|
||||
### 9.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.
|
||||
|
||||
### 8.2. <a name='Diffusionetconfusion'></a>Diffusion et confusion
|
||||
### 9.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é.
|
||||
|
||||
### 8.3. <a name='Non-linarit'></a>Non-linéarité
|
||||
### 9.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.
|
||||
|
||||
## 9. <a name='Fonctionsdehashage'></a>Fonctions de hashage
|
||||
## 10. <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 :
|
||||
|
||||
## 10. <a name='Exigencesgnriques'></a>Exigences génériques
|
||||
## 11. <a name='Exigencesgnriques'></a>Exigences génériques
|
||||
|
||||
### 10.1. <a name='Pasdesecretdelaconception'></a>Pas de secret de la conception
|
||||
### 11.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.
|
||||
|
||||
### 10.2. <a name='Validparlacommunautscientifique'></a>Validé par la communauté scientifique
|
||||
### 11.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.
|
||||
|
||||
### 10.3. <a name='Implmentationcorrecte'></a>Implémentation correcte
|
||||
### 11.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/)).
|
||||
|
||||
### 10.4. <a name='Dtermination'></a>Détermination
|
||||
### 11.4. <a name='Dtermination'></a>Détermination
|
||||
|
||||
Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie.
|
||||
|
||||
### 10.5. <a name='Rapiditdecalcul'></a>Rapidité de calcul
|
||||
### 11.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.
|
||||
|
||||
### 10.6. <a name='Diffusionoueffetavalanche'></a>Diffusion (ou effet avalanche)
|
||||
### 11.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.
|
||||
|
||||
### 10.7. <a name='Rsistanceauxcollisions'></a>Résistance aux collisions
|
||||
### 11.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 :
|
||||
|
||||
#### 10.7.1. <a name='Rsistanceauxcollisionsfaibles'></a>Résistance aux collisions faibles
|
||||
#### 11.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.
|
||||
|
||||
#### 10.7.2. <a name='Rsistanceauxcollisionsfortes'></a>Résistance aux collisions fortes
|
||||
#### 11.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.
|
||||
|
||||
### 10.8. <a name='Rsistancelapre_id'></a>Résistance à la pre_id
|
||||
### 11.8. <a name='Rsistancelapre_id'></a>Résistance à la pre_id
|
||||
|
||||
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 :
|
||||
|
||||
#### 10.8.1. <a name='Rsistancelapre_id-1'></a>Résistance à la pre_id
|
||||
#### 11.8.1. <a name='Rsistancelapre_id-1'></a>Résistance à la pre_id
|
||||
|
||||
Il est difficile de trouver une entrée qui hache vers une sortie de hachage spécifiée.
|
||||
|
||||
#### 10.8.2. <a name='Rsistancelasecondepre_id'></a>Résistance à la seconde pre_id
|
||||
#### 11.8.2. <a name='Rsistancelasecondepre_id'></a>Résistance à la seconde pre_id
|
||||
|
||||
Étant donné une entrée, il est difficile de trouver une autre entrée qui produit le même hachage.
|
||||
|
||||
### 10.9. <a name='Compression'></a>Compression
|
||||
### 11.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.
|
||||
|
||||
### 10.10. <a name='Nonrversibilit'></a>Non réversibilité
|
||||
### 11.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.
|
||||
|
||||
### 10.11. <a name='Absencedetoutestructureprvisible'></a>Absence de toute structure prévisible
|
||||
### 11.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.
|
||||
|
||||
## 11. <a name='Gestionscurisedescls'></a>Gestion sécurisée des clés
|
||||
## 12. <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.
|
||||
|
||||
@ -185,24 +190,24 @@ Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffr
|
||||
|
||||
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é.
|
||||
|
||||
## 12. <a name='Performance'></a>Performance
|
||||
## 13. <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.
|
||||
|
||||
## 13. <a name='Disponibilit'></a>Disponibilité
|
||||
## 14. <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.
|
||||
|
||||
## 14. <a name='volutivit'></a>Évolutivité
|
||||
## 15. <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 `ItemProcess` .
|
||||
|
||||
## 15. <a name='AutresMesuresdescurit'></a>Autres Mesures de sécurité
|
||||
## 16. <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é).
|
||||
|
||||
## 16. <a name='Todo'></a>Todo
|
||||
## 17. <a name='Todo'></a>Todo
|
||||
|
||||
@ -1,20 +1,22 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
|
||||
* 1. [Worfklows](#Worfklows)
|
||||
* 2. [Transverse](#Transverse)
|
||||
* 3. [Diagrammes d'architecture](#Diagrammesdarchitecture)
|
||||
* 4. [Todo](#Todo)
|
||||
# <a name='Documentsderfrence'></a>Documents de référence- Specifications
|
||||
|
||||
## 1. <a name='Tabledesmatires'></a>Table des matières
|
||||
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Table des matières](#Tabledesmatires)
|
||||
* 2. [Worfklows](#Worfklows)
|
||||
* 3. [Transverse](#Transverse)
|
||||
* 4. [Diagrammes d'architecture](#Diagrammesdarchitecture)
|
||||
* 5. [Todo](#Todo)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
|
||||
<!-- /vscode-markdown-toc -->
|
||||
|
||||
# <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
## 1. <a name='Worfklows'></a>Worfklows
|
||||
## 2. <a name='Worfklows'></a>Worfklows
|
||||
|
||||
* **Authentification**: [Auth.md](Auth-Specs.md)
|
||||
* **Items**: [Item-Specs.md](Item-Specs.md)
|
||||
@ -23,7 +25,7 @@
|
||||
* **Process et roles**: [Process-Role-Specs.md](Process-Role-Specs.md)
|
||||
* **Transactions Silent Payments**: [Silent-Payments-Specs.md](Silent-Payments-Specs.md)
|
||||
|
||||
## 2. <a name='Transverse'></a>Transverse
|
||||
## 3. <a name='Transverse'></a>Transverse
|
||||
|
||||
* **Datamodel**: [Specs-Datamodel.md](Specs-Datamodel.md)
|
||||
* **Définitions et abréviations.**: [Specs-Definition.md]
|
||||
@ -32,9 +34,9 @@
|
||||
* **Maintenance, environnement de déploiement**: [Specs-Deployment.md]
|
||||
* **References**: [Specs-References.md](Specs-References.md)
|
||||
|
||||
## 3. <a name='Diagrammesdarchitecture'></a>Diagrammes d'architecture
|
||||
## 4. <a name='Diagrammesdarchitecture'></a>Diagrammes d'architecture
|
||||
|
||||
* **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)
|
||||
|
||||
## 4. <a name='Todo'></a>Todo
|
||||
## 5. <a name='Todo'></a>Todo
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user