Précisions SP & PRD (doc)
This commit is contained in:
parent
dd2592e306
commit
634105d245
@ -37,19 +37,19 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 4. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
|
||||
|
||||
Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `process`.
|
||||
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` .
|
||||
|
||||
Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payment pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties`.
|
||||
|
||||
Les utilisateurs sont reconnus par une adresse Silent Payment dans un ou plusieurs rôles dans un process. Ces process préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`.
|
||||
Les utilisateurs sont reconnus par une`adresse SP` dans un ou plusieurs rôles dans un `ItemProcess`. Ces `ItemProcess` préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`.
|
||||
|
||||
Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par process dans lequel l'utilisateur a un rôle (`onboarding`).
|
||||
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`).
|
||||
|
||||
## 5. <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 process 4NK.
|
||||
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.
|
||||
|
||||
## 6. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
|
||||
|
||||
@ -134,7 +134,7 @@ Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Vo
|
||||
|
||||
1.1. `Part1`, c'est la partie qui sera chiffrée (AES-GCM 256 bits) par le mot de passe et stockée en cache dans une image dite de login.
|
||||
|
||||
1.2. `Part2`, c'est la partie qui sera décomposée par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres du process.
|
||||
1.2. `Part2`, c'est la partie qui sera décomposée par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres du `ItemProcess`.
|
||||
|
||||
2. Une `pre-id Part1EncHash` qui identifie l'utilisateur est générée par le hash (SHA 256) de la `Part1` et du mot de passe de l'utilisateur.
|
||||
|
||||
@ -161,7 +161,7 @@ Dans l'ordre on réalise donc les opérations suivantes donc :
|
||||
|
||||
#### 9.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 les membres du rôle `member` du `process` choisi.
|
||||
Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant les membres du rôle `member` du `ItemProcess` choisi.
|
||||
|
||||
Chacun de ses membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `RequestPrdResponse` en réponse à un `RequestPrdKeyBackup`.
|
||||
|
||||
@ -174,7 +174,7 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
|
||||
5. Atttente de la réception des `RequestPrdResponse` en réponse aux `RequestPrdKeyBackup` (confirmations).
|
||||
6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`.
|
||||
6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
|
||||
6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du process.
|
||||
6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du `ItemProcess`.
|
||||
6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
|
||||
@ -183,17 +183,17 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
|
||||
Pour être `onboard` dans un process, c'est-à-dire avoir un rôle, il faut :
|
||||
|
||||
1. s'ajouter (objet `Member`) dans la liste des membres et
|
||||
2. s'ajouter son adresse SP dans les adresses d'un des rôles du process.
|
||||
2. s'ajouter son adresse SP dans les adresses d'un des rôles du `ItemProcess`.
|
||||
|
||||
###### Mise à jour de la liste des membres
|
||||
|
||||
Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce `RequestPrd` devra recevoir des membres du rôle `Member` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce `RequestPrd` devra recevoir des membres du rôle `Member` du `ItemProcess` les `RequestPrdResponse` correspondant aux critères de validation du `ItemProcess` .
|
||||
|
||||
C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que `metadadata` privée (chiffrée par la clé de dépense du signet) dans un `RequestPcd` (et les `RequestPrdUpdate` correspondant).
|
||||
|
||||
Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet.
|
||||
|
||||
Les metadatas des membres propres au process sont décrits dans le process et doivent compléter les metadatas de l'`ItemMember`.
|
||||
Les metadatas des membres propres au `ItemProcess` sont décrits dans le `ItemProcess` et doivent compléter les metadatas de l'`ItemMember`.
|
||||
|
||||
L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
@ -208,11 +208,11 @@ L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Dat
|
||||
|
||||
###### Mise à jour de la liste des process
|
||||
|
||||
Pour mettre à jour la liste des process il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `process`. Ce `RequestPrd` devra recevoir des membres du rôle `Process` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
Pour mettre à jour la liste des `ItemProcess` il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `ItemProcess` . Ce `RequestPrd` devra recevoir des membres du rôle `ItemProcess` du `ItemProcess` les `RequestPrdResponse` correspondant aux critères de validation du `ItemProcess` .
|
||||
|
||||
L'`ItemProcess` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
Demande d'update de la liste des membres ( RequestPcd) d'un process vers chaque membre du rôle `Member` du process.:
|
||||
Demande d'update de la liste des membres ( RequestPcd) d'un `ItemProcess` vers chaque membre du rôle `Member` du `ItemProcess`.:
|
||||
|
||||
1. Création d'un `ItemProcess` correspondant à l'utilisateur.
|
||||
2. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemProcess` créé.
|
||||
@ -222,7 +222,7 @@ Demande d'update de la liste des membres ( RequestPcd) d'un process vers chaque
|
||||
6. Envoi du `Message` du `RequestPrdKeyHello` à destination du membre.
|
||||
7. Réception des `RequestPrdResponse` en réponse aux `RequestPrdKeyHello` et mise à jour des listes depuis les `RequestPcd` correspondants.
|
||||
8. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`.
|
||||
9. Redirection vers la page du process sur le relai.
|
||||
9. Redirection vers la page du `ItemProcess` sur le relai.
|
||||
|
||||
##### Clés de révocation (`revoke`)
|
||||
|
||||
@ -232,7 +232,7 @@ L'envoi d'une révocation est identique à la création d'une nouvelle adresse v
|
||||
|
||||
##### 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 process. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
|
||||
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`.
|
||||
|
||||
Les clés privées associées sont générées lors de l'update d'un membre, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
|
||||
|
||||
@ -254,17 +254,17 @@ Puis depuis la liste des membres du process, pour chacun des membres :
|
||||
5. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`.
|
||||
6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`.
|
||||
6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
|
||||
6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du process.
|
||||
6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du role `Member`du `ItemProcess`.
|
||||
6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
|
||||
Demande d'update de la liste des membres ( RequestPcd) d'un process :
|
||||
Demande d'update de la liste des membres ( RequestPcd) d'un `ItemProcess` :
|
||||
|
||||
1. Création et envoi des `RequestPrdList`.
|
||||
2. Réception des `RequestPrdResponse` en réponse aux `RequestPrdList` et mise à jour des listes depuis les `RequestPcd` correspondants.
|
||||
3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
|
||||
4. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemMember` créé.
|
||||
5. Redirection vers la page du process sur le relai.
|
||||
5. Redirection vers la page du `ItemProcess` sur le relai.
|
||||
|
||||
## 10. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
* **Authentification**: [Auth.md](Auth-Specs.md)
|
||||
* **Items**: [Item-Specs.md](Item-Specs.md)
|
||||
* **RequestPrd et RequestPcd**: [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md)
|
||||
* **Messages et transactions SP**: [Message-SP-Specs.md]
|
||||
* **Messages des relais**: [Message-Specs.md]
|
||||
* **Process et roles**: [Process-Role-Specs.md](Process-Role-Specs.md)
|
||||
* **Transactions Silent Payment**: [Silent-Payment-Specs.md](Silent-Payment-Specs.md)
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé
|
||||
* **Process**: Définit un ensemble de règles et de procédures pour gérer des interactions spécifiques au sein du réseau.
|
||||
* **Member**: Représente les utilisateurs ou entités participant à un processus.
|
||||
* **Peer**: Identifie les nœuds ou participants du réseau qui aident à faciliter les communications et les transactions.
|
||||
* **Artefact** : Un type d'objet générique personnalisable dans les `process`, il peut y avoir une quantité infinie de type d'`artefacts` différents par process.
|
||||
* **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`.
|
||||
* **Payment, Deposit, Commitment**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques.
|
||||
|
||||
### 3.2. <a name='CompositionetFonction'></a> Composition et Fonction
|
||||
|
||||
@ -90,13 +90,13 @@ Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (d
|
||||
Le cache est constitué de 2 parties :
|
||||
|
||||
1. `public` :
|
||||
* Liste partagée des process avec les relais (agrégée au fil des relais découverts par le partage des listes de process dans les messages).
|
||||
* Liste partagée des process complets reçus depuis les mises à jour des parties prenantes.
|
||||
* Liste partagée des `ItemProcess` avec les relais (agrégée au fil des relais découverts par le partage des listes de `ItemProcess` dans les messages).
|
||||
* Liste partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes.
|
||||
2. `private` :
|
||||
* Liste non partagée des process (agrégée à partir de process communiqués de façon confidentielle).
|
||||
* Liste non partagée des process complets reçus depuis les mises à jour des parties prenantes.
|
||||
* Liste non partagée des `ItemProcess` (agrégée à partir de `ItemProcess` communiqués de façon confidentielle).
|
||||
* Liste non partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes.
|
||||
|
||||
Dans chaque partie, les process sont stockés sous forme d'objets `SharedProcess` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)).
|
||||
Dans chaque partie, les `ItemProcess` sont stockés sous forme d'objets `SharedProcess` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)).
|
||||
|
||||
### 5.3. <a name='Listedeshashsdesmessagesreus'></a>5.3. Liste des hashs des messages reçus
|
||||
|
||||
@ -125,7 +125,7 @@ Le cache contient une liste des sockets ouverts, répartie en 2 parties :
|
||||
|
||||
### 6.2. <a name='SharedProcessList'></a>6.2. SharedProcessList
|
||||
|
||||
`SharedProcessList` est une liste de process. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de process.
|
||||
`SharedProcessList` est une liste de `ItemProcess`. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de `ItemProcess`.
|
||||
|
||||
### 6.3. <a name='Tailledesdonnes'></a>6.3. Taille des données
|
||||
|
||||
@ -137,7 +137,7 @@ Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail
|
||||
|
||||
### 6.5. <a name='AdresseSPdefaucet'></a>6.5. Adresse SP de faucet
|
||||
|
||||
L'utilisateur fournit aux relais une adresse Silent Payment (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client).
|
||||
L'utilisateur fournit aux relais une`adresse SP` (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client).
|
||||
|
||||
L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction contient un output supplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant.
|
||||
|
||||
@ -163,31 +163,19 @@ Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` o
|
||||
|
||||
#### 7.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>7.1.2. Envoi du message de type `MessageConnect` à chaque relais
|
||||
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
Il n'y a pas de retour attendu pour ce message.
|
||||
|
||||
### 7.2. <a name='EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message`
|
||||
|
||||
Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||
Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
### 7.3. <a name='EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage'></a>7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message`
|
||||
|
||||
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur des outputs aux indexs suivants:
|
||||
|
||||
1. Le hash du message de type `Message` correspondant
|
||||
2. Le hash du `RequestPrd`
|
||||
3. Le hash du process
|
||||
4. Le hash de l'`item_name` de l'`Item` concerné
|
||||
5. Le hash de la valeur de la signature (attribut `sig_value` du RequestPrd)
|
||||
6. Le hash du `RequestPrd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
7. Le hash du `RequestPcd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
8. Le hash du `RequestPcd` de référence associé au `RequestPrd` (le cas échéant)
|
||||
9. Le hash d'un `Amount` de paiement (le cas échéant)
|
||||
10. Le hash d'un `Amount`de dépôt (le cas échéant)
|
||||
11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant)
|
||||
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés (voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md)). :
|
||||
|
||||
La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les champs suivants :
|
||||
|
||||
@ -217,9 +205,9 @@ Pour les `RequestPrd` de type `RequestPrdKeyHello` :
|
||||
|
||||
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||
|
||||
Puis le `RequestPrd` est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||
Puis le `RequestPrd` est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
### 7.4. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>7.4. Traitement des messages de type `Message` par les clients
|
||||
|
||||
@ -232,9 +220,9 @@ Le client réalise les contrôles suivants :
|
||||
Le client met à jour ses propres listes suivantes :
|
||||
|
||||
* Liste des relais depuis la liste partagée par le relais `SharedPeerList`.
|
||||
* Liste des process depuis la liste partagée par le relais `SharedProcessList`.
|
||||
* Liste des `ItemProcess` depuis la liste partagée par le relais `SharedProcessList`.
|
||||
|
||||
Déchiffrement du message avec la `ProcessKey` du process et contrôles suivants :
|
||||
Déchiffrement du message avec la `ProcessKey` du `ItemProcess` et contrôles suivants :
|
||||
|
||||
* Calcul du hash du `RequestPcd` ou `RequestPrd` et vérification de la non-existence du hash dans le cache.
|
||||
* Voir [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md) pour les détails des contrôles.
|
||||
@ -256,7 +244,7 @@ Le relais réalise les contrôles suivants :
|
||||
Le relais met à jour ses propres listes suivantes :
|
||||
|
||||
* Liste des relais depuis la liste partagée par le client `SharedPeerList`.
|
||||
* Liste des process depuis la liste partagée par le client `SharedProcessList`.
|
||||
* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`.
|
||||
|
||||
Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
|
||||
|
||||
@ -266,7 +254,7 @@ Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse d
|
||||
|
||||
### 8.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
|
||||
|
||||
Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
|
||||
Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
|
||||
|
||||
@ -285,7 +273,7 @@ Le relais réalise les contrôles suivants :
|
||||
Le relais met à jour ses propres listes suivantes :
|
||||
|
||||
* Liste des relais depuis la liste partagée par le client `SharedPeerList`.
|
||||
* Liste des process depuis la liste partagée par le client `SharedProcessList`.
|
||||
* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`.
|
||||
|
||||
Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
|
||||
|
||||
@ -295,19 +283,19 @@ Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse d
|
||||
|
||||
### 9.1. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>9.1. Broadcast des messages de type `Message` vers les relais
|
||||
|
||||
Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
|
||||
Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
|
||||
|
||||
Envoi vers chaque relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant.
|
||||
|
||||
Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de process (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai).
|
||||
Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess` (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai).
|
||||
|
||||
Il n'y a pas de retour attendu pour ce message.
|
||||
|
||||
### 9.2. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>9.2. Broadcast des messages de type `Message` vers les clients connectés
|
||||
|
||||
Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de process.
|
||||
Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess`.
|
||||
|
||||
Envoi vers chaque client d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant.
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
* 5.2. [Réception](#Rception-1)
|
||||
* 6. [Fonction des RequestPrd](#FonctiondesRequestPrd)
|
||||
* 6.1. [Fonctionnalités optionnelles](#Fonctionnalitsoptionnelles)
|
||||
* 6.2. [Fonction des transactions silent payment SP associées aux RequestPrd](#FonctiondestransactionssilentpaymentSPassociesauxRequestPrd)
|
||||
* 6.2. [Fonction des`transaction SP` associées aux RequestPrd](#FonctiondestransactionssilentpaymentSPassociesauxRequestPrd)
|
||||
* 6.3. [Création et envoi](#Crationetenvoi-1)
|
||||
* 6.4. [Réception](#Rception-1)
|
||||
* 7. [RequestPrdList - Demande de Listes ( RequestPcd)](#RequestPrdList-DemandedeListesRequestPcd)
|
||||
@ -61,7 +61,7 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
|
||||
**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
|
||||
|
||||
@ -69,7 +69,7 @@ Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l
|
||||
|
||||
Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
|
||||
A la réception des messages, ils sont tous déchiffrés puis conservés ou non en fonction du `process hash` du `RequestPcd` ou du `RequestPrd` (dans l'attribut `request`). Si le `process hash` n'est pas reconnu, le message est ignoré.
|
||||
|
||||
@ -87,7 +87,7 @@ Pour les `RequestPcd` et les `RequestPrd` il faut vérifier que le hash du docum
|
||||
|
||||
Les Portable Contract Documents ( RequestPcd) sont des documents JSON qui encapsulent les listes versionnées d'`Item` dont les attributs sont chiffrés soit en public, soit en confidentiel par rôles soit en privé (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
|
||||
Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `process` et les `members` concernés.
|
||||
Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés.
|
||||
|
||||
### 5.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
@ -96,7 +96,7 @@ La création d'un `RequestPcd` suit plusieurs étapes :
|
||||
1. **Chargement de la dernière version de la liste ( RequestPcd)**: Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage.
|
||||
2. **Mise à jour**: Ajouts et modifications eventuelles des `Item`
|
||||
3. **Chiffrement des attributs**: Chiffrement des attributs de chaque Item selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
4. **Chiffrement du RequestPcd**: Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `process` concerné.
|
||||
4. **Chiffrement du RequestPcd**: Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
5. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
|
||||
### 5.2. <a name='Rception-1'></a>Réception
|
||||
@ -105,7 +105,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
2. Recherche des `RequestPrd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` de ces `RequestPrd` et attente si nécessaire.
|
||||
3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `process` concerné.
|
||||
3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `ItemProcess` concerné.
|
||||
4. Déchiffrage des attributs confidentiels des `Item` des `RequestPcd` avec les clés de déchiffrement depuis l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret` des RequestPrd.
|
||||
5. Déchiffrage des attributs privés des `Item` des `RequestPcd` avec la clé privée `KeyRecover`
|
||||
6. Mise à jour du cache pour les traitement des RequestPrd.
|
||||
@ -114,7 +114,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
Les Portable Request Documents ( RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
|
||||
Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `RequestPcd` sont chiffrées dans les `RequestPrd` avec le chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une transaction Silent Payment SP (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `process`).
|
||||
Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `RequestPcd` sont chiffrées dans les `RequestPrd` avec le chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une`transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `ItemProcess` ).
|
||||
|
||||
Les `RequestPrd` sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `RequestPrd` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
|
||||
@ -139,30 +139,25 @@ Il est aussi possible de partager des clés de chiffrement ad'hoc via `certif_ke
|
||||
|
||||
En plus des horodatages automatique, il est possible de déclarer un timestamp dans `timestamp_declared` qui ne sera pas pris en compte dans le traitement mais qui est ainsi tracé dans les éléments de preuves.
|
||||
|
||||
Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs roles dans les process et pour préciser les adresses de réponses en cas d'utilisations en multi-devices.
|
||||
Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs roles dans les `ItemProcess` et pour préciser les adresses de réponses en cas d'utilisations en multi-devices.
|
||||
|
||||
Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`.
|
||||
|
||||
### 6.2. <a name='FonctiondestransactionssilentpaymentSPassociesauxRequestPrd'></a>Fonction des transactions silent payment SP associées aux RequestPrd
|
||||
|
||||
La clé `KeyConfidential` d'une transaction Silent Payment SP est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges.
|
||||
|
||||
La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des `RequestPrd` donc de la validation des données des `RequestPcd`.Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et `RequestPrd` (sauf `RequestPrdKeyBackup`) et des `RequestPcd`.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.
|
||||
|
||||
Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des `RequestPrd` sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).
|
||||
|
||||
### 6.3. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
La création d'un `RequestPrd` suit plusieurs étapes :
|
||||
|
||||
1. **Chargement des clés de chiffrement confidentiel'**: Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd.
|
||||
2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `process` concerné.
|
||||
3. **Création de l'adresse SP**: (Sauf `RequestPRDKeyBackup`) Création d'une adresse Silent Payment SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
||||
2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
3. **Création de l'adresse SP**: Création d'une`adresse SP` SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
||||
4. **Création du message**: Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet
|
||||
5. **Sélection des relais pour le message**: Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées.
|
||||
6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP.
|
||||
7. **Envoi du message**: Envoi du message aux relais
|
||||
8. **Envoi de la transaction**: (Sauf `RequestPRDKeyBackup`) envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la transaction Silent Payment SP avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
||||
6. **Sélection des noeuds de signet pour la transaction silent Payment (SP) \***: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la`transaction SP`.
|
||||
7. **Chiffrement des données confidentielles du `request_prd`**: Chiffrement des données confidentielles du `request_prd` avec la `KeyConfidential` de la`transaction SP`.
|
||||
8. **Envoi du message**: Envoi du message aux relais
|
||||
9. **Envoi de la transaction**: envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la`transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
||||
|
||||
Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
||||
|
||||
### 6.4. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -174,9 +169,10 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
4. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
5. Vérification de la conformité des `RequestPrd` en relation.
|
||||
6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci.
|
||||
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du `RequestPrd` dans l'output `2` de la transaction.
|
||||
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la`transaction SP` correspondante via hash du `RequestPrd` dans l'output `2` de la transaction.
|
||||
8. Mise à jour du cache pour les traitement des RequestPrd.
|
||||
9. Traitements spécifiques au type de RequestPrd.
|
||||
9. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md).
|
||||
10. Traitements spécifiques au type de RequestPrd.
|
||||
|
||||
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd)
|
||||
|
||||
@ -184,16 +180,14 @@ Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de
|
||||
|
||||
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
L'envoi d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 7.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la transaction Silent Payment SP associée avec
|
||||
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la`transaction SP` associée avec
|
||||
3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
||||
4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné.
|
||||
5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdRResponse` avec :
|
||||
@ -207,13 +201,13 @@ Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateu
|
||||
|
||||
Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties.
|
||||
|
||||
Permet la communication des transactions Silent Payment SP au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain.
|
||||
Permet la communication des`transaction SP` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain.
|
||||
|
||||
Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`.
|
||||
|
||||
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la transaction Silent Payment SP via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la`transaction SP` via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 8.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -221,11 +215,9 @@ La réception d'un `RequestPrdMessage` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`.
|
||||
3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
||||
4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné.
|
||||
5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdResponse` avec :
|
||||
5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash`
|
||||
5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash`
|
||||
3. Notificaiton et attente du retour de l'utilisateur (valeur de la signature et message de réponse)
|
||||
4. Le cas échéant : création et envoi à l'émetteur du `RequestPrdMessage` d'un `RequestPrdMessage` avec :
|
||||
5.1. le hash du `RequestPrdMessage` reçu dans l'attribut `request_prd_origin_hash`
|
||||
|
||||
## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
|
||||
|
||||
@ -235,13 +227,13 @@ Basé sur le `RequestPrd`. avec des additions pour spécifier les modifications
|
||||
|
||||
Essentiel pour les utilisateurs ou les processus nécessitant de mettre à jour des informations contractuelles ou des attributs d'items, assurant la pertinence et l'actualité des données dans le système.
|
||||
|
||||
Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `process`, la mise à jour de la liste des `process` permettra de leur affecter un nouveau role.
|
||||
Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `ItemProcess` , la mise à jour de la liste des `ItemProcess` permettra de leur affecter un nouveau role.
|
||||
|
||||
Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd.
|
||||
|
||||
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 9.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -257,7 +249,7 @@ Crucial pour les processus qui nécessitent une confirmation explicite de récep
|
||||
|
||||
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 10.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -273,7 +265,7 @@ Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, pui
|
||||
|
||||
### 11.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 11.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -283,7 +275,7 @@ Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards as
|
||||
|
||||
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 12.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
@ -295,7 +287,7 @@ Important pour les processus d'onboarding de nouveaux membres, de réinitialisat
|
||||
|
||||
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` incluant l'envoi de la`transaction SP` via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 13.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Process et roles
|
||||
<!-- /vscode-markdown-toc --># `ItemProcess` et roles
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
@ -43,7 +43,7 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 4. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
|
||||
|
||||
Les rôles déterminent les permissions et les responsabilités des participants dans le système 4NK. Ils sont essentiels pour contrôler l'accès aux données et les autorisations au sein des `process`. Les `rôles` principaux incluent :
|
||||
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 :
|
||||
|
||||
* **RolePeer**: Conditions des listes de relais participants qui facilitent les communications et les transactions et des versions de ces listes.
|
||||
* **RoleMember**: Conditions des listes des utilisateurs ou entités ayant une participation directe dans un processus spécifique et des versions de ces listes.
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
<!-- vscode-markdown-toc -->
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Structure des outputs](#Structuredesoutputs)
|
||||
|
||||
<!-- vscode-markdown-toc-config
|
||||
numbering=true
|
||||
@ -10,9 +11,62 @@
|
||||
<!-- /vscode-markdown-toc -->
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 4. <a name='Structuredesoutputs'></a> Fontion
|
||||
|
||||
La transaction SP à plusieurs objectifs :
|
||||
|
||||
1. Permettre l'horodatage de l'empreinte des `RequestPrd` sur la side chain (hors `RequestPrdKeyBackup` et les `RequestPrdKeyMessage` sans message confidentiel).
|
||||
2. Permettre le partage de la `keyConfidential` pour les `RequestPrd` afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le `RequestPrd`.
|
||||
|
||||
La clé `KeyConfidential` d'une`transaction SP` est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction.
|
||||
|
||||
Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges.
|
||||
|
||||
La`transaction SP` a aussi une fonction d'horodate et de preuve de publication des `RequestPrd` donc de la validation des données des `RequestPcd`.Les outputs de la`transaction SP` contiennent les empreintes cryptographiques des `messages` et `RequestPrd` et des `RequestPcd`.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.
|
||||
|
||||
Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des `RequestPrd` sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).
|
||||
|
||||
Il y a une `transactions SP` pour tous les types de `RequestPrd` sauf pour les `RequestPrdKeyBackup` et les `RequestPrdKeyMessage` ayant l'attribut `raw_transaction_list` non vide.
|
||||
|
||||
## 4. <a name='Structuredesoutputs'></a> Structure des outputs
|
||||
|
||||
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:
|
||||
|
||||
0. L'output 0 est toujours un paiment au destinataire
|
||||
1. L'output 1 c'est toujours l'op_return avec un tableau de hashs en clair selon un tableau de hashs en JSON :
|
||||
1.1. Le hash du message de type `Message` correspondant
|
||||
1.2. Le hash du `RequestPrd`
|
||||
1.3. Le hash du process
|
||||
1.4. Le hash de la valeur de la signature (attribut `sig_value` du RequestPrd)
|
||||
1.5. Le hash de l'`item_name` de l'`Item` concerné (le cas échéant)
|
||||
1.6. Le hash du `RequestPrd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
1.7. Le hash du `RequestPcd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
1.8. Le hash du `RequestPcd` de référence associé au `RequestPrd` (le cas échéant)
|
||||
1.9. Le hash d'un `Amount` de paiement (le cas échéant)
|
||||
1.10. Le hash d'un `Amount`de dépôt (le cas échéant)
|
||||
1.11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant)
|
||||
|
||||
Pour des raison de confidentialité, le role associé à l'`item_name` du `RequestPrd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`.
|
||||
|
||||
## 5. 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 `RequestPrdMessage` à un membre du rôle `member` du `ItemProcess` concerné et
|
||||
2. Dans le `Message` du `RequestPrdMessage` sur les relais
|
||||
|
||||
### Dans un `RequestPrdMessage`
|
||||
|
||||
Dans l'attribut `raw_transaction_list` du `RequestPrdMessage` 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.
|
||||
|
||||
### Dans un `Message` du `RequestPrdMessage`
|
||||
|
||||
Dans l'attribut `raw_transaction_list` du `Message` associé à la transaction SP.
|
||||
La transaction sera broadcastée par les noeuds de signet des relais.
|
||||
|
||||
@ -34,13 +34,13 @@ Tous les flux sont reçus par autant de relais et de membres de même rôles. Un
|
||||
|
||||
Les arrêts de la blockchain dans son ensemble n'entraînent pas d'interruption de service, car les horodatages sont non bloquants, l'impact est une diminution de la preuve le temps de "ré-ancrer" ce qui n'aurait pas pu l'être. L'arrêt de nœuds de la blockchain pourrait ralentir la propagation des informations dans les scénarios les plus critiques, sans impact majeur sur le fonctionnement.
|
||||
|
||||
Les arrêts des membres dans les process dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des process pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des process est en charge de l'arbitrage pour la bonne restitution des actions.
|
||||
Les arrêts des membres dans les `ItemProcess` dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des `ItemProcess` pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des `ItemProcess` est en charge de l'arbitrage pour la bonne restitution des actions.
|
||||
|
||||
Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques.
|
||||
|
||||
## 3. <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 `RequestPcd` sont les listes à jour de l'état de validation de tous les éléments échangés, et les `RequestPrd` sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un process (possible de segmenter par zones et services).
|
||||
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 `RequestPcd` sont les listes à jour de l'état de validation de tous les éléments échangés, et les `RequestPrd` 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).
|
||||
|
||||
Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -37,17 +37,17 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
* **Recover**: Action de recomposer une identité numérique (clés privées).
|
||||
|
||||
* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une adresse Silent Payment indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre.
|
||||
* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une`adresse SP` indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre.
|
||||
|
||||
* **Onboard**: Action de demander un `rôle` dans un `process`.
|
||||
* **Onboard**: Action de demander un `rôle` dans un `ItemProcess` .
|
||||
|
||||
* **Member**: Une adresse Silent Payment, complétée de métadonnées, par `process` et d'une adresse supplémentaire pour la révocation.
|
||||
* **Member**: Une adresse Silent Payment, complétée de métadonnées, par `ItemProcess` et d'une adresse supplémentaire pour la révocation.
|
||||
|
||||
* **Third parties**: Adresses Silent Payment complétant un `member` pour reconnaître d'autres dispositifs du `member`.
|
||||
* **Third parties**:`adresse SP` complétant un `member` pour reconnaître d'autres dispositifs du `member`.
|
||||
|
||||
* **KeyConfidential**: Clé AES-GCM-256 du Diffie-Hellman de la transaction Silent Payment correspondant à un RequestPrd.
|
||||
|
||||
* **ProcessKey**: la clé publique de chiffrement public d'un process (dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément).
|
||||
* **ProcessKey**: la clé publique de chiffrement public d'un `ItemProcess` (dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément).
|
||||
|
||||
* **KeyRecover**: la clé prive de spend de `recover` du signet, qui sert de référence pour l'identité.
|
||||
|
||||
@ -81,7 +81,7 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 5. <a name='Data'></a>Data
|
||||
|
||||
* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les process découverts et les pairs du réseau. Une fois identifié auprès des membres d'un process et avec son identité `member` récupérée, l'objet member et les `RequestPcd` et `RequestPrd` 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.
|
||||
* **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 `RequestPcd` et `RequestPrd` 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 `RequestPcd` et RequestPrd, dans les navigateurs web.
|
||||
|
||||
|
||||
@ -48,6 +48,7 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 6. <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>
|
||||
|
||||
|
||||
@ -76,9 +76,9 @@ Le chiffrement des `RequestPcd` est un chiffrement symétrique conformément aux
|
||||
|
||||
* **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer.
|
||||
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un RequestPcd.
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les RequestPcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un RequestPcd.
|
||||
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `RequestPcd` et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `RequestPcd` et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
|
||||
|
||||
* **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs).
|
||||
|
||||
@ -180,7 +180,7 @@ La manière dont les clés sont générées, stockées, distribuées, révoquée
|
||||
|
||||
Les clés seront générées strictement par l'utilisateur et feront l'objet d'un traitement `MPC` avec un chiffrement des parties par le mot de passe connu de l'utilisateur seul et jamais stocké.
|
||||
|
||||
Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `process` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande.
|
||||
Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `ItemProcess` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande.
|
||||
|
||||
L'utilisateur seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé.
|
||||
|
||||
@ -196,7 +196,7 @@ En cas de perte, vol, corruption, ou expiration des clés, l'utilisateur peut de
|
||||
|
||||
## 14. <a name='volutivit'></a>Évolutivité
|
||||
|
||||
La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `process`.
|
||||
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é
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user