correction du français + todo (doc)
This commit is contained in:
parent
71cec27fb3
commit
5d6302047b
@ -51,43 +51,45 @@ La spécification couvre la conception, le développement, et l'application prat
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et RequestPrd
|
||||
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et `RequestPrd`
|
||||
|
||||
Encryption :
|
||||
|
||||
|
||||
|
||||
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
|
||||
w
|
||||
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 `ItemProcess` concerné.
|
||||
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de messages (`JSON`) via les `websockets` des relais.
|
||||
|
||||
Ces `Message` contiennent soit des `RequestPrd`, soit des `RequestPcd`, encapsulés dans l'attribut `request_enc`, lequel est chiffré à l'aide de la clé `ProcessKey` de l'`ItemProcess` concerné.
|
||||
|
||||
Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
|
||||
|
||||
### 4.2. <a name='Rception'></a>Réception
|
||||
|
||||
Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
Les `RequestPcd` et `RequestPrd` sont reçus sous forme de messages (`JSON`) via 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 `ItemProcess` concerné.
|
||||
Ces messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, lequel est chiffré avec la clé `ProcessKey` de l'`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é.
|
||||
À la réception des `Message`, ceux-ci sont déchiffrés puis conservés ou non, selon le `process_hash` du `RequestPcd` ou du `RequestPrd` (dans l'attribut `request`). Si le `process_hash` n'est pas reconnu, le message est ignoré.
|
||||
|
||||
Les types `RequestPrd` et `RequestPcd` sont distingués par l'attribut `request_type` dans le `Message`.
|
||||
|
||||
En cas de `RequestPcd` ou `RequestPrd` liés via `RequestPcd_reference_hash`, `request_prd_reference_hash`, `RequestPcd_origin_hash`, `request_prd_origin_hash` ou `item_reference_hash` (dans des `RequestPcd`), il est nécessaire d'avoir reçu ou d'attendre ces documents pour traiter le message.
|
||||
|
||||
Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
Les types `RequestPrd` et `RequestPcd` sont distingués par l'attribut `request_type` dans le `message`.
|
||||
|
||||
En cas de `RequestPcd` ou `RequestPrd` en relation via `RequestPcd_reference_hash` ou `request_prd_reference_hash` ou `RequestPcd_origin_hash` ou `request_prd_origin_hash` ou `item_reference_hash` (dans des RequestPcd), il avoir reçu ou attendre ces documents pour traiter le message.
|
||||
|
||||
**Réception du message**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
|
||||
|
||||
Pour les `RequestPcd` et les `RequestPrd` il faut vérifier que le hash du document n'est pas déjà en cas, si c'est le cas, le message est ignoré.
|
||||
Pour les `RequestPcd` et `RequestPrd`, il est nécessaire de vérifier si le hash du document est déjà enregistré ; si tel est le cas, le message est ignoré.
|
||||
|
||||
## 5. <a name='FonctiondesRequestPcd'></a>Fonction des RequestPcd
|
||||
|
||||
Les Portable Contract Documents ( RequestPcd) sont des documents JSON qui encapsulent les listes versionnées d'`Item` dont les attributs sont chiffrés soit en public, soit en confidentiel par rôles soit en privé (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
Les Portable Contract Documents (`RequestPcd`) sont des documents 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)).
|
||||
|
||||
Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés.
|
||||
Les `Item` échangés via les `RequestPcd` sont soumis à une vérification par les `RequestPrdResponse` dans le but de contrôler la validité de ces données et leur conformité avec les `ItemProcess` et les `member` du `Role` concerné.
|
||||
|
||||
### 5.1. <a name='Schmadesflux'></a>Schéma des flux
|
||||
|
||||
@ -98,79 +100,78 @@ Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `Reques
|
||||
La création d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage.
|
||||
2. Ajouts et modifications eventuelles des `Item`
|
||||
3. Chiffrement des attributs de chaque Item selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
2. Ajouts et modifications éventuelles des `Item`.
|
||||
3. Chiffrement des attributs de chaque `Item` selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
4. Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
5. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
5. Traitements communs aux `RequestPcd` et `RequestPrd`.
|
||||
|
||||
### 5.3. <a name='Rception-1'></a>Réception
|
||||
|
||||
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.
|
||||
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 `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.
|
||||
4. Déchiffrage des attributs confidentiels des `Item` des `RequestPcd` avec les clés de déchiffrement fournies par 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 le traitement des `RequestPrd`.
|
||||
|
||||
## 6. <a name='FonctiondesRequestPrd'></a>Fonction des RequestPrd
|
||||
## 6. <a name='FonctiondesRequestPrd'></a>Fonction des`RequestPrd`
|
||||
|
||||
Les Portable Request Documents ( RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
Les Portable Request Documents (RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour solliciter 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 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 clés permettant le chiffrement des attributs confidentiels par rôles des `Item` dans les `RequestPcd` sont elles-mêmes chiffrées dans les `RequestPrd` au moyen du chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une `transaction SP` (cf. [Specs-Security.md](Specs-Security.md)). Ces clés sont uniquement distribuées 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.
|
||||
Les `RequestPrd` se déclinent en plusieurs types, tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc., correspondant à différentes actions comme l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions.
|
||||
|
||||
### 6.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma.
|
||||
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma.
|
||||
|
||||
|
||||
|
||||
### 6.2. <a name='Fonctionnalitsoptionnelles'></a>Fonctionnalités optionnelles
|
||||
|
||||
L'attribut `sig_value` permet de donner une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess` avec des valeurs valant pour `OK` ou `KO` pour `none` pour les validations des `RequestPrd`.
|
||||
L'attribut `sig_value` permet d'attribuer une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess`, avec des valeurs pouvant être `OK`, `KO` ou `none` pour les validations des `RequestPrd`.
|
||||
|
||||
Lorsque que la réponse fait référence à un `RequestPcd` il est précisé dans `RequestPcd_reference_hash`, idem pour les `RequestPrd` avec `request_prd_reference_hash`.
|
||||
Lorsque la réponse fait référence à un `RequestPcd`, cela est précisé dans `RequestPcd_reference_hash`; de même pour les `RequestPrd` avec `request_prd_reference_hash`.
|
||||
|
||||
Lorsque que la réponse fait suite directement à un `RequestPcd` il est précisé dans `RequestPcd_origin_hash`, idem pour les `RequestPrd` avec `request_prd_origin_hash`.
|
||||
Lorsque la réponse fait suite directement à un `RequestPcd`, cela est indiqué dans `RequestPcd_origin_hash`; idem pour les `RequestPrd` avec `request_prd_origin_hash`.
|
||||
|
||||
Les `RequestPrdResponse` signalent de façon confidentielle :
|
||||
|
||||
* soient des conditions ad'hoc déjà remplies via l'attribut `payment_method_enc_by_shared_secret`, `deposit_method_enc_by_shared_secret`, `commitment_method_enc_by_shared_secret`, `commitment_request_pcd_hash_list` pour les paiements et preuves ad'hoc éventuellements associés aux `RequestPcd` de la nouvelle version.
|
||||
* soient des appels pour recevoir les moyens de satisfaire ces conditions via les attributs `ask_payment_method_enc_by_shared_secret`, `ask_deposit_method_enc_by_shared_secret`, `ask_commitment_method_enc_by_shared_secret`.
|
||||
* soit des conditions ad hoc déjà remplies via les attributs `payment_method_enc_by_shared_secret`, `deposit_method_enc_by_shared_secret`, `commitment_method_enc_by_shared_secret`, `commitment_request_pcd_hash_list` pour les paiements et les preuves ad hoc éventuellement associées aux `RequestPcd` de la nouvelle version.
|
||||
* soit des appels à recevoir les moyens de satisfaire ces conditions via les attributs `ask_payment_method_enc_by_shared_secret`, `ask_deposit_method_enc_by_shared_secret`, `ask_commitment_method_enc_by_shared_secret`.
|
||||
|
||||
Les `Item` associés sont référencés dans des `RequestPcd` identifiés par `payment_request_pcd_hash_list_enc_by_shared_secret`, `cap_request_pcd_hash_list_enc_by_shared_secret` (cas des payments temporaires en l'attente du passage d'un cap), `deposit_request_pcd_hash_list_enc_by_shared_secret` et `commitment_request_pcd_hash_list_enc_by_shared_secret`.
|
||||
Les `Item` associés sont référencés dans des `RequestPcd` identifiés par `payment_request_pcd_hash_list_enc_by_shared_secret`, `cap_request_pcd_hash_list_enc_by_shared_secret` (dans le cas de paiements temporaires en attente du passage d'un cap), `deposit_request_pcd_hash_list_enc_by_shared_secret` et `commitment_request_pcd_hash_list_enc_by_shared_secret`.
|
||||
|
||||
Des champs messages peuvent accompagner les `RequestPrd` via `message_public`, `message_confidential`, `message_private`.
|
||||
Des champs de messages peuvent accompagner les `RequestPrd` via `message_public`, `message_confidential`, `message_private`.
|
||||
|
||||
Il est aussi possible de partager des clés de chiffrement ad'hoc via `certif_key_enc_by_shared_secret`.
|
||||
Il est également possible de partager des clés de chiffrement ad hoc via `certif_key_enc_by_shared_secret`.
|
||||
|
||||
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.
|
||||
En plus des horodatages automatiques, il est possible de déclarer un timestamp dans `timestamp_declared`, qui ne sera pas pris en compte dans le traitement mais sera ainsi tracé dans les éléments de preuve.
|
||||
|
||||
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.
|
||||
Les adresses et les rôles sont précisés en cas d'utilisateurs ayant plusieurs rôles dans les `ItemProcess` et pour préciser les adresses de réponse en cas d'utilisation sur plusieurs dispositifs.
|
||||
|
||||
Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`.
|
||||
Tous les échanges sont complétés par l'empreinte du dispositif de l'émetteur, envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`.
|
||||
|
||||
### 6.3. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
La création d'un `RequestPrd` suit plusieurs étapes :
|
||||
|
||||
1. Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd.
|
||||
1. Récupération des clés de chiffrement confidentiel des attributs des items d'un `RequestPcd`.
|
||||
2. Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `ItemProcess` concerné.
|
||||
3. Création d'une`adresse SP` SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
||||
4. Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet
|
||||
5. Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées.
|
||||
6. Sélection de 4 noeuds de signet pour l'envoi de la`transaction SP`.
|
||||
7. Chiffrement des données confidentielles du `request_prd` avec la `KeyConfidential` de la`transaction SP`.
|
||||
8. Envoi du message aux relais
|
||||
9. Envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la`transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
||||
10. Mis à jour du cache avec les nouveaux `RequestPrd` envoyé (pas de mis en cache du `RequestPrdMessage`)
|
||||
3. Création d'une `adresse SP` pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
||||
4. Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, et l'adresse du faucet.
|
||||
5. Sélection de 4 relais pour le message selon l'historique des pings et des réponses obtenues.
|
||||
6. Sélection de 4 noeuds de signet pour l'envoi de la `transaction SP`.
|
||||
7. Chiffrement des données confidentielles du `RequestPrd` avec la `KeyConfidential` de la `transaction SP`.
|
||||
8. Envoi du message aux relais.
|
||||
9. Envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la `transaction SP` avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
||||
10. Mise à jour du cache avec les nouveaux `RequestPrd` envoyés (sans mise en cache du `RequestPrdMessage`).
|
||||
|
||||
Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
||||
|
||||
|
||||
| `request_type` | Notification user | `transaction SP` + `RequestPrdMessage` | `RequestPcd` to send | `request_type` send to | `RequestPcd` reply waiting | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting |
|
||||
|----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------|
|
||||
| `RequestPrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes |
|
||||
@ -183,17 +184,17 @@ Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md).
|
||||
|
||||
La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
2. Recherche des `RequestPcd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
1. Traitements communs aux `RequestPcd` et `RequestPrd`.
|
||||
2. Recherche des `RequestPcd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash`, attente si nécessaire et traitement de ceux-ci.
|
||||
3. Vérification de la conformité des `RequestPcd` en relation.
|
||||
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.
|
||||
4. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash`, 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. 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. Voir `RequestPrdConfirm` création et envoi.
|
||||
10. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md).
|
||||
11. Traitements spécifiques au type de RequestPrd.
|
||||
6. Recherche de l'`Item` associé via `item_reference_hash`, attente si nécessaire et traitement de celui-ci.
|
||||
7. Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la `transaction SP` correspondante via le hash du `RequestPrd` dans l'output `2` de la transaction.
|
||||
8. Mise à jour du cache pour le traitement des `RequestPrd`.
|
||||
9. Consultation du `RequestPrdConfirm` pour création et envoi.
|
||||
10. Validation des conditions définies dans le `ItemProcess` pour cet `Item`, avec le `Role` correspondant dans le `ItemProcess`, et dans ces rôles, les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md).
|
||||
11. Traitements spécifiques au type de `RequestPrd`.
|
||||
|
||||
| `request_type` | Notification user | `RequestPrdConfirm` to send | `RequestPcd` to send | `RequestPrdResponse` to send | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting (from `RequestPrdResponse` send ) |
|
||||
|----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------|
|
||||
@ -205,51 +206,50 @@ La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>RequestPrdList - Demande de Listes ( RequestPcd)
|
||||
|
||||
Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le résweau. Chaque `RequestPcd` liste des `Item` d'un même type, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
||||
Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `RequestPcd` liste des `Item` d'un même type, tels que les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
||||
|
||||
### 7.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma.
|
||||
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma.
|
||||
|
||||
|
||||
|
||||
### 7.2. <a name='Cration:Datasspcifiques'></a>Création : Datas spécifiques
|
||||
|
||||
1. Traitements des `RequestPrd`, avec le `type_request`
|
||||
2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouveau ItemMember (création d'un identité numérique), uniquement vers les gestionnaires des membres
|
||||
3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement ver les gestionnaires des membres
|
||||
1. Traitement des `RequestPrd`, avec le `type_request`.
|
||||
2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouvel `ItemMember` (création d'une identité numérique), uniquement destiné aux gestionnaires des membres.
|
||||
3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement destiné aux gestionnaires des membres.
|
||||
|
||||
### 7.3. <a name='Rception:Datasspcifiques'></a>Réception : Datas spécifiques
|
||||
|
||||
La réception d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Recherche en cache de la dernière version de la liste du type d'`Item` concerné (voir `RequestPcd` Création et envoi vers l'émetteur du `RequestPrdList`)
|
||||
3. Si `item_member_enc_by_sp_shared_secret` en cas de création d'un nouveau ItemMember (création d'un identité numérique), uniquement vers les gestionnaires des membres et ajout en cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé.
|
||||
4. Si `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement ver les gestionnaires des membres pour renvoi du shard correspondant dans le `RequestPrdResponse`
|
||||
1. Traitement des `RequestPrd`.
|
||||
2. Recherche en cache de la dernière version de la liste du type d'`Item` concerné (voir `RequestPcd` pour la création et l'envoi vers l'émetteur du `RequestPrdList`).
|
||||
3. En cas de `item_member_enc_by_sp_shared_secret`, pour la création d'un nouvel `ItemMember` (création d'une identité numérique), cette étape est réservée uniquement aux gestionnaires des membres. L'`ItemMember` est ajouté au cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé.
|
||||
4. En cas de `pre_id_sp_enc_by_shared_secret`, pour la connexion avec une identité numérique existante, cette étape est destinée uniquement aux gestionnaires des membres pour le renvoi du shard correspondant dans le `RequestPrdResponse`.
|
||||
|
||||
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages
|
||||
|
||||
Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
||||
|
||||
Permet la communication :
|
||||
Il permet la communication :
|
||||
|
||||
* directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties.
|
||||
* des`transaction SP` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain.
|
||||
* Directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties.
|
||||
* 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` (cas d'utilisation du afin de transaférer la `transaction SP` d'un autre `RequestPrd`).
|
||||
Les `RequestPrdMessage` peuvent répondre aux autres `RequestPrdMessage`, sauf en cas d'envoi de `raw_transaction_list` (dans le cas d'utilisation pour transférer la `transaction SP` depuis un autre `RequestPrd`).
|
||||
|
||||
### 8.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma.
|
||||
Cas d'un RequestPrdMesage avec `raw_transaction_list` vide (et son RequestPrdMessage avec `raw_transaction_list` non vide).
|
||||
Pour simplifier, les `RequestPrdConfirm` n'ont pas été inclus dans le schéma. Exemple d'un `RequestPrdMessage` avec `raw_transaction_list` vide, et son cas correspondant où le `RequestPrdMessage` contient une `raw_transaction_list` non vide.
|
||||
|
||||
|
||||
|
||||
### 8.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
|
||||
|
||||
1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage`
|
||||
2. Cas de la transmission d'une `Transaction SP` d'un autre vRequestPrd` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain.
|
||||
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué au `RequestPrdMessage`.
|
||||
2. Cas de la transmission d'une `Transaction SP` depuis un autre `RequestPrd` au format `raw` dans l'attribut `raw_transaction_list`, pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 8.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
|
||||
|
||||
@ -257,41 +257,41 @@ Cas d'un RequestPrdMesage avec `raw_transaction_list` vide (et son RequestPrdMes
|
||||
|
||||
## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
|
||||
|
||||
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `RequestPcd`.
|
||||
`RequestPrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `RequestPcd`.
|
||||
|
||||
Basé sur le `RequestPrd`. avec des additions pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour :
|
||||
Basé sur le `RequestPrd`, avec des ajouts pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour :
|
||||
|
||||
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 `ItemProcess` , la mise à jour de la liste des `ItemProcess` permettra de leur affecter un nouveau `Role`.
|
||||
Par exemple, la mise à jour de la liste des membres permet d'ajouter de nouveaux utilisateurs à un `ItemProcess`, et la mise à jour de la liste des `ItemProcess` permet de leur affecter un nouveau `Role`.
|
||||
|
||||
Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd.
|
||||
Les `RequestPrdUpdate` signalent au réseau, via l'attribut `RequestPcd_new_version_hash`, les nouvelles versions des `RequestPcd`.
|
||||
|
||||
### 9.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma.
|
||||
Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma.
|
||||
|
||||
|
||||
|
||||
### 9.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
|
||||
|
||||
1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdUpdate`
|
||||
2. Pas de data spécifiques.
|
||||
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdUpdate`.
|
||||
2. Pas de données spécifiques.
|
||||
|
||||
### 9.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
|
||||
|
||||
La réception d'un `RequestPrdUpdate` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Comparaison de la dernirère version du `RequestPcd` en cache et de nouvelle version du `RequestPcd` associé via `RequestPcd_new_version_hash` et attente si nécessaire.
|
||||
1. Traitement des `RequestPrd`.
|
||||
2. Comparaison de la dernière version du `RequestPcd` en cache avec la nouvelle version du `RequestPcd` associée, via `RequestPcd_new_version_hash`, et attente si nécessaire.
|
||||
|
||||
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>RequestPrdConfirm - Confirmation de Réception
|
||||
|
||||
Le `RequestPrdConfirm` est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau.
|
||||
|
||||
Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdResponse` et `RequestPrdKeyHello` reçoivent systématiquement un `RequestPrdConfirm` depuis leur réception par le destinataire.
|
||||
Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdResponse` et `RequestPrdKeyHello` reçoivent systématiquement un `RequestPrdConfirm` suite à leur réception par le destinataire.
|
||||
|
||||
`code_confirm_enc_by_shared_secret`: Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas un output spécifique chiffré par la clé `KeyConfidential` précise ce code, à confirmer dans le RequestPrdConfirm.
|
||||
`code_confirm_enc_by_shared_secret` : Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas, un output spécifique chiffré par la clé `KeyConfidential` précise ce code, lequel doit être confirmé dans le `RequestPrdConfirm`.
|
||||
|
||||
### 10.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
@ -299,45 +299,52 @@ Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdRespon
|
||||
|
||||
### 10.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
|
||||
|
||||
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm`
|
||||
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué aux `RequestPrdConfirm`.
|
||||
2. Communication éventuelle d'un `code_confirm_enc_by_shared_secret` à confirmer dans le `RequestPrdConfirm`.
|
||||
|
||||
### 10.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
|
||||
|
||||
1. Traitements des `RequestPrd`, pas de traitement suppplémentaire.
|
||||
1. Traitement des `RequestPrd`, sans traitement supplémentaire.
|
||||
2. Vérification du `code_confirm_enc_by_shared_secret` dans le `RequestPrdConfirm` reçu.
|
||||
|
||||
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>RequestPrdResponse - Répondre à une Demande
|
||||
|
||||
Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties.
|
||||
|
||||
Les `RequestPrdResponse` répondent aux `RequestPrdList`, `RequestPrdUpdate`.
|
||||
Les `RequestPrdResponse` sont utilisés pour répondre aux `RequestPrdList`, `RequestPrdUpdate`, facilitant la fourniture de feedbacks, de confirmations, ou d'instructions supplémentaires en réponse aux demandes initiales. Ils supportent une communication bidirectionnelle sécurisée et vérifiable.
|
||||
|
||||
Utilisé pour fournir des feedbacks, des confirmations, ou des instructions supplémentaires en réponse à des demandes initiales, supportant une communication bidirectionnelle sécurisée et vérifiable.
|
||||
|
||||
Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions.
|
||||
C'est également le moyen par lequel demander des moyens de paiement, de dépôt, ou de preuve, puis de partager le payload de ces actions.
|
||||
|
||||
### 11.1. <a name='Schmadesflux-1'></a>Schéma des flux
|
||||
|
||||
Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma.
|
||||
Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le schéma.
|
||||
|
||||
|
||||
|
||||
### 11.2. <a name='Cration:Datasspcifiques-1'></a>Création : Datas spécifiques
|
||||
|
||||
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse`
|
||||
2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si non automatique)
|
||||
3. En cas de réponse à `RequestPrdKeyList` :`pre_id_enc_by_sp_shared_secret` avec les shards correspondants à la `pre-id` demandée.
|
||||
4. (option) `shared_secret_key` paratage d'une clé de chiffrement ad'hoc
|
||||
1. Traitement des `RequestPrd`, avec le `type_request` spécifiquement attribué à `RequestPrdResponse`.
|
||||
2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si celle-ci n'est pas automatique).
|
||||
3. En cas de réponse à un `RequestPrdKeyList`, fourniture de `pre_id_enc_by_sp_shared_secret` avec les shards correspondant à la `pre-id` demandée.
|
||||
4. (Optionnel) Partage d'une clé de chiffrement ad hoc via `shared_secret_key`.
|
||||
|
||||
### 11.3. <a name='Rception:Datasspcifiques-1'></a>Réception : Datas spécifiques
|
||||
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Vérification des conditions de validation des RequestPcd associés.
|
||||
3. En cas de réponse reçue à `RequestPrdList` : Récupération des shards correspondants à la `pre-id` demandée et génération de la clé `KeyRecover`
|
||||
1. Traitement des `RequestPrd`.
|
||||
2. Vérification des conditions de validation des `RequestPcd` associés.
|
||||
3. En cas de réponse reçue pour un `RequestPrdList` : récupération des shards correspondant à la `pre-id` demandée et génération de la clé `KeyRecover`.
|
||||
|
||||
## 12. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 13. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Diagrammes de séquences
|
||||
[ ] Définition claire de ‘request-type’
|
||||
[ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’:
|
||||
[ ] Qu’y a-t-il dans le ‘request-type’?
|
||||
[ ] A quoi sert l’attribut X du ‘request-type’?
|
||||
[ ] Description un par un des contextes où le ‘request-type’ est utilisé.
|
||||
[ ] Description pas à pas de l’envoi du ‘request-type’.
|
||||
[ ] Que se passe-t-il dans le système lorsque le ‘request-type est envoyé?
|
||||
[ ] Description pas à pas de la réception du ‘request-type’.
|
||||
[ ] Que se passe-t-il dans le système lorsque le ‘request-type est reçu?
|
||||
[ ] Exemple d’utilisation.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user