sdk_common/doc/PRD-PCD-Specs.md

PRD PCD - Specifications

1. Autheurs, validations, dates, versions, changement and historique

Cf. Git SDK COMMON

2. Table des matières

• 1. Autheurs, validations, dates, versions, changement and historique
• 2. Table des matières
• 3. Objectif
• 4. Portée
• 5. Documents de référence
• 6. Définitions
• 7. Principes d'une Envelope rie
• 8. Encryption
• 9. Fonction des Pcd
  • 9.1. Schéma des flux
  • 9.2. Création et envoi
  • 9.3. Réception
• 10. Fonction desPrd
  • 10.1. Schéma des flux
  • 10.2. Création d'un Prd
  • 10.3. Réception
• 11. PrdList - Demande de Listes
  • 11.1. Schéma des flux
• 12. PrdMessage - Envoi d'une Envelope
  • 12.1. Schéma des flux
• 13. PrdUpdate - Mises à Jour de Pcd
  • 13.1. Schéma des flux
• 14. PrdConfirm - Confirmation de Réception
  • 14.1. Schéma des flux
• 15. PrdResponse - Répondre à une Demande
  • 15.1. Schéma des flux
• 16. Exemples de Code
• 17. Todo

3. Objectif

Le but de cette section est d'introduire les Portable Contract Document (Pcd) et Portable Request Document (Prd) comme éléments fondamentaux du système 4NK. Ces documents jouent un rôle crucial dans la sécurisation des échanges de données et la gestion des User au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau.

4. Portée

La spécification couvre la conception, le développement, et l'application pratique des Pcd et Prd.Elle vise à expliquer leur fonctionnement, leur structure, et la manière dont ils contribuent à l'écosystème 4NK en offrant une méthode sécurisée et efficace pour le partage d'informations et la validation des transactions. Les Pcd et Prd encapsulent les données contractuelles et les requêtes dans un format standardisé, assurant l'intégrité, la confidentialité, l'authenticité et la validation des informations échangées.

5. Documents de référence

Voir _Doc_references.md.

6. Définitions

• Portable Contract Document (Pcd): Un format JSON chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (process_hash) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'Item dans le Process (item_type).

• Portable Request Document (Prd): Format JSON chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des Pcd. Les PrdResponse sont collectés pour vérifier le respect des conditions de Process. D'autres types de Prd incluent :

  • PrdList: Demande de listes d'Item. En réponse, une Pcd est reçue avec les PrdResponse correspondants.
  • PrdMessage: Envoi d'une Envelope publics, confidentiels ou privés et/ou de transactions Silent Payments des autres Prd à diffuser sur le réseau des nœuds de la side chain. Les PrdMessage peuvent répondre les uns aux autres.
  • PrdUpdate: Demande de mise à jour d'une liste d'Item (publiée via un PCD), qui sera déchiffrée et validée ou non par des PrdResponse en retour.
  • PrdConfirm: Confirmation de la réception des Prd (à l'exception de PrdConfirm eux-même).
  • PrdResponse: Réponse aux autres types de Prd (à l'exception de PrdConfirm, et PrdMessage).

• Envelope: Enveloppe commune pour les Prd et Pcd lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les Prd et Pcd sont chiffrés par la ProcessKey de Process (cf. Specs-Definition) et ajoutés au champs RequestEnc.

• KeyConfidential: Clé AES-GCM-256 issue du Diffie-Hellman de la transaction Silent Payments correspondant à un Prd.

• ProcessKey: La clé publique de chiffrement d'un Process (trouvée dans un Process, 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é privée de dépense de recover du signet, utilisée comme référence pour le User.

• pre-id: Pré-identifiant des User, constitué du hash de la partie 1 de la KeyRecover.

7. Principes d'une Envelope rie

Les Pcd sont envoyés à tous les participants connectés sans attente de retour spécifique et ne sont pas associés à une transaction SP.

Les Prd sont toujours accompagnés d'une transaction SP, transmise dans l'attribut raw_transaction_list d'un PrdMessage associé (à l'exception des PrdMessage eux-mêmes).

Les Prd sont des demandes d'actions ou des réponses à ces demandes, interagissant de la manière suivante :

• PrdList : Constitue généralement la première requête d'un workflow et ne répond pas à un autre Prd.
• PrdMessage, avec 2 cas de figure :
  • Demande de relais d'une transaction SP, dans ce cas, le PrdMessage ne répond pas à un autre Prd.
  • Envoi d'une Envelope , pouvant initier un échange d'une Envelope rie ou répondre à un autre PrdMessage.
• PrdUpdate : Souvent la première requête d'un workflow, un PrdUpdate ne répond pas à un autre Prd.
• PrdConfirm : Répond à tous les autres types de Prd (à l'exception des PrdConfirm eux-mêmes).
• PrdResponse : Répond à tous les autres types de Prd (à l'exception des PrdConfirm, PrdResponse eux-mêmes). Dans le cas d'une réponse à un PrdList ou d'un PrdUpdate, le PrdResponse doit obligatoirement être accompagné d'un Pcd.

Selon le type de Prd, les demandes peuvent s'adresser à tous les Members de Process, aux gestionnaires du type d'Item concerné ou simplement à l'émetteur, selon :

• PrdList : Envoyé aux gestionnaires du type d'Item concerné.
• PrdMessage, avec 2 cas de figure :
  • Demande de relais d'une transaction SP, dans ce cas, destinée au destinataire du Prd associé.
  • Envoi d'une Envelope au destinataire de l'Envelope .
• PrdUpdate : Envoyé aux gestionnaires du type d'Item concerné.
• PrdConfirm : Envoyé à l'émetteur du Prd associé.
• PrdResponse, avec 2 cas de figure :
  • Réponse à un PrdList : envoyée à l'émetteur du PrdList.
  • Réponse à un PrdUpdate : envoyée à tous les Members et à l'émetteur du PrdUpdate.

Les traitements pour l'envoi des Prd varient selon leur type, principalement autour des aspects suivants :

• request_type: Est un attribut des Prd et des Pcd permettant de connaître le type de requête.
• Notification user : Nécessité de notifier l'User courant, ou non.
• transaction SP + PrdMessage : Envoi d'une transaction SP dans un PrdMessage, ou non.
• Pcd to send : Envoi d'un Pcd en complément du Prd.
• request_type send to : Members qui recevront les transaction SP et les PrdMessage correspondants, avec les clés de déchiffrement pour les champs confidentiels.
• Pcd reply waiting : Attente d'un Pcd en retour, ou non.
• PrdResponse reply waiting : Attente d'un ou de plusieurs PrdResponse en retour, ou non.
• PrdConfirm reply waiting : Attente d'un PrdConfirm en retour, ou non.

Ce qui est résumé pour l'envoi :

request_type	Notification user	transaction SP + PrdMessage	Pcd to send	request_type send to	Pcd reply waiting	PrdResponse reply waiting	PrdConfirm reply waiting
PrdList	No	Yes	No	all the Members of the item_name Role into to Process	Yes	Yes	Yes
PrdUpdate	waiting sig_value	Yes	Yes	all the Members of all Role into to Process	No	Yes	Yes
PrdMessage	waiting sig_value + message_public, message_confidential, message_private	if no raw_transaction_list	No	a Member of the Process	No	No	if no raw_transaction_list
PrdResponse	waiting sig_value	Yes	No	See Received	No	No	Yes
PrdConfirm	(option) Waiting code_confirm_confidential	Yes	No	See Received	No	No	No

Les traitements pour la réception des Prd varient selon leur type, principalement autour des aspects suivants :

• Notification user : Nécessité de notifier l'User courant, ou non.
• PrdConfirm to send: Envoi d'une confirmation, ou non
• PrdResponse to send: Envoi d'un PrdResponse ou non.
• PrdResponse reply waiting: Attente d'un PrdResponse en retour ou non.
• PrdConfirm reply waiting (from PrdResponse send ): Attente d'un PrdConfirm en retour ou non.

Ce qui est résumé Pour la réception :

request_type	Notification user	PrdConfirm to send	Pcd to send	PrdResponse to send	PrdResponse reply waiting	PrdConfirm reply waiting (from PrdResponse send )
PrdList	No	Yes	Yes	all the Members of the item_name Role into to Process	No	Yes
PrdUpdate	Prd	Yes	No	all the Members of all Role into to Process	Yes (other Members)	Yes
PrdMessage	Waiting PrdMessage reply	if no raw_transaction_list	No	No	No	No
PrdResponse	Prd	Yes	No	No	No	No
PrdConfirm	Prd	No	No	No	No	No

8. Encryption

Schema :

Les Metadata des Item des Pcd et les attributs des Pcd et Prd sont chiffrés de la sorte :

• Données publiques : Utilisent un chiffrement symétrique basé sur la ProcessKey de Process (cf. Specs-Definition). Ces données sont ainsi accessibles à tous pour le déchiffrement.

• Données confidentielles destinées aux Members d'un role spécifique d'un Process dans les Pcd : Le chiffrement est réalisé symétriquement à partir d'une clé de chiffrement générée à la volée pour chaque champ et pour chaque item d'une liste d'un Pcd. Ces clés seront ensuite ajoutées aux Prd dans l'attribut Pcd_keys_role_confidential_list_confidential; lui même alors chiffré par la KeyConfidential.

• Données confidentielles destinées aux Members d'un role spécifique d'un Process dans les Prd : Utilisent un chiffrement symétrique basé sur les clés de chiffrement AES-GCM-256, générées à la volée dans les Pcd et transmises par le Prd, chiffrées par la KeyConfidential du Diffie-Hellman de la transaction Silent Payments associée à ce Prd (cf. Specs-Definition) d'une transaction SP.

• Données privées : Chiffrées symétriquement en utilisant la clé de dépense de connexion (recover) du signet (voir Login - Specs).

Principaux champs des Request contenus dans les Pcd et Prd chiffrés :

• request_type : Type de requête : Pcd, PrdList, PrdMessage, PrdUpdate, PrdConfirm, PrdResponse.
• item_name : Noms des items : peer, Member, process, Payments, deposit, commit, et les artefact personnalisés.
• version : Version de la requête.
• process_hash : Hash de Process concerné.
• request_pcd_reference_hash : Hash du Pcd auquel le Prd fait référence.
• request_pcd_origin_hash : Hash du Pcd à l'origine du Prd.
• request_prd_reference_hash : Hash du Prd auquel le Prd fait référence.
• request_prd_origin_hash : Hash du Prd à l'origine du Prd.
• item_reference_hash : Hash de Item auquel le Pcd fait référence.

9. Fonction des Pcd

Les Portable Contract Documents (Pcd) sont des documents au format JSON encapsulant des listes versionnées d'Item, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. Specs-Security.md).

Les Item échangés via les Pcd sont soumis à une vérification par les PrdResponse dans le but de contrôler la validité de ces données et leur conformité avec les Process et les Member du Role concerné.

Principaux champs des Pcd :

• request : cf la descripton de la structure Request.
• item_enc_list : Les Item chiffrés sous forme PcdItemGenericEnc par une clé symétrique générée à la volée pour chaque champ et pour chaque item d'une liste.
• pagination : La pagination de la liste des Item.

Principaux champs de la structure Pagination :

• start : Index du premier Item de la liste.
• number : Nombre d'Item à afficher.
• page_index : Index de la page.
• page_total : Nombre total de pages.

Principaux champs de la structure PcdItemGenericEnc :

• version : Version de Item.
• item_type : Type de Item.
• name : Nom de Item.
• request_pcd_item_enc_attribute_public_list : Liste d'objets PcdItemEncAttributePublic des attributs publics de Item chiffré.
• request_pcd_item_enc_attribute_role_confidential_list : Liste d'objets PcdItemEncAttributeRoleConfidential des attributs confidentiels de Item chiffré.
• request_pcd_item_enc_attribute_private_list : Liste d'objets PcdItemEncAttributePrivate des attributs privés de Item chiffré.

Principaux champs de la structure PcdItemEncAttributePublic :

• attribute_name : Nom de l'attribut.
• data_enc : Données chiffrées par la clé ProcessKey de Process concerné.
• key : [PRIVE] Clé de chiffrement, non partagée dans les Envelope. Données en clair.
• data : [PRIVE] Non partagé dans les Envelope. Données en clair.

Principaux champs de la structure PcdItemEncAttributeRoleConfidential :

• attribute_name : Nom de l'attribut.
• data_enc : Données chiffrées par une clé symétrique générée à la volée pour chaque champ et pour chaque item d'une liste.
• key : [PRIVE] Clé de chiffrement, non partagée dans les Envelope. Données en clair.
• data : [PRIVE] Non partagé dans les Envelope. Données en clair.

Principaux champs de la structure PcdItemEncAttributePrivate :

• attribute_name : Nom de l'attribut.
• data_enc : Données chiffrées par la clé privée KeyRecover.
• key : [PRIVE] Clé de chiffrement, non partagée dans les Envelope. Données en clair.
• data : [PRIVE] Non partagé dans les Envelope. Données en clair.

9.1. Schéma des flux

9.2. Création et envoi

La création d'un Pcd 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 éventuelles des Item.
3. Chiffrement cf Encryption.
4. Envoi de l'Envelope cf Envelope - Specs.

Schéma de finalisation de la création d'un Pcd :

PCD finalize

9.3. Réception

La réception d'un Pcd suit plusieurs étapes :

1. Recherche des Prd en relation via Pcd_reference_hash et Pcd_origin_hash de ces Prd, et attente si nécessaire.
2. Déchiffrement cf Encryption.

Schéma de finalisation de la réception d'un Pcd :

PCD Received

10. Fonction desPrd

Les Portable Request Documents (Prd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des Pcd via l'attribut Pcd_keys_role_confidential_list_confidential. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi d'une Envelope, la mise à jour des informations contractuelles, ou la confirmation de transactions.

Les clés permettant le chiffrement des attributs confidentiels par rôles des Item dans les Pcd sont elles-mêmes chiffrées dans les Prd au moyen du chiffrement du Prd par la clé KeyConfidential d'une transaction SP (cf. Specs-Security.md). Ces clés sont uniquement distribuées aux Members concernés par les Item des Pcd (rôles dans les Process).

Les Prd se déclinent en plusieurs types, tels que PrdList, PrdMessage, PrdUpdate, etc., correspondant à différentes actions comme l'envoi d'une Envelope, la mise à jour des informations contractuelles, ou la confirmation de transactions.

Principaux champs des Prd :

• request : cf la descripton de la structure Request.
• sig_value : Valeur de la signature (parmi les valeurs valant pour OK, KO ou none telles que définies dans Process).
• request_pcd_reference_keys_role_confidential_list_confidential : Clés de déchiffrement des attributs confidentiels des Item des Pcd chiffrées par la clé KeyConfidential d'une transaction SP.
• request_pcd_origin_hash_keys_role_confidential_list_confidential : Clés de déchiffrement des attributs confidentiels des Item des Pcd du PCD de référence, chiffrées par la clé KeyConfidential d'une transaction SP.
• message_public : Envelope public, chiffré par la clé ProcessKey du Process concerné.
• message_confidential : Envelope confidentiel, chiffré par la clé ProcessKey du Process concerné.
• message_private : Envelope privé, chiffré par la clé privée KeyRecover.
• sp_address_to : Adresse du destinataire.
• sp_address_from : Adresse de l'émetteur.
• sp_address_reply : Adresse de réponse à l'émetteur.
• timestamp_declared : Horodatage déclaré.
• role_name_from : Nom du rôle de l'émetteur.
• role_name_to : Nom du rôle du destinataire.
• Payments_request_pcd_hash_list_confidential : Liste des Pcd d'Item de nom paiement chiffrée par la clé KeyConfidential d'une transaction SP.
• cap_request_pcd_hash_list_confidential : Liste des Pcd d'Item de nom deposit chiffrée par la clé KeyConfidential d'une transaction SP servant à la validation des paiements temporaires en attente du passage d'un cap.
• deposit_request_pcd_hash_list_confidential : Liste des Pcd d'Item de nom deposit chiffrée par la clé KeyConfidential d'une transaction SP.
• commit_request_pcd_hash_list_confidential : Liste des Pcd d'Item de nom commit chiffrée par la clé KeyConfidential d'une transaction SP.
• ask_Payments_method_confidential : Demande de méthode de paiement chiffrée par la clé KeyConfidential d'une transaction SP.
• ask_deposit_method_confidential : Demande de méthode de dépôt chiffrée par la clé KeyConfidential d'une transaction SP.
• ask_commit_method_confidential : Demande de méthode d'engagement chiffrée par la clé KeyConfidential d'une transaction SP.
• Payments_method_confidential : Méthode de paiement chiffrée par la clé KeyConfidential d'une transaction SP, en réponse à une demande.
• deposit_method_confidential : Méthode de dépôt chiffrée par la clé KeyConfidential d'une transaction SP, en réponse à une demande.
• commit_method_confidential : Méthode d'engagement chiffrée par la clé KeyConfidential d'une transaction SP, en réponse à une demande.
• certif_key_confidential : Clé de certification chiffrée par la clé KeyConfidential d'une transaction SP.
• device_footprint_enc_by_sp_shared_secret : Empreinte du dispositif de l'émetteur, chiffrée par la clé KeyConfidential d'une transaction SP.

10.1. Schéma des flux

Pour simplifier, les PrdConfirm n'ont pas été inclus dans le schéma.

10.2. Création d'un Prd

1. Complétion des attributs
2. Création d'une adresse SP cf Silent Payments - Specs
3. Chiffrement cf Encryption.
4. Envoi de l'Envelope cf Envelope - Specs.

Schéma de finalisation de la création d'un Prd :

PRD finalize

10.3. Réception

La réception d'un Prd suit plusieurs étapes :

1. Parcours des Process pour trouver le Process correspondant au process_hash du Prd
2. Tentative de déchiffrement du Prd avec la clé ProcessKey du Process correspondant.
3. Recherche des Pcd en relation via Pcd_reference_hash et Pcd_origin_hash, attente si nécessaire et traitement de ceux-ci.
4. Vérification de la conformité des Pcd en relation.
5. Recherche des Prd en relation via request_prd_reference_hash et request_prd_origin_hash, attente si nécessaire et traitement de ceux-ci.
6. Vérification de la conformité des Prd en relation.
7. Recherche de Item associé via item_reference_hash, attente si nécessaire et traitement de celui-ci.
8. Déchiffrement voir Encryption.
9. Validation des conditions définies dans le Process pour cet Item, avec le Role correspondant dans le Process, et dans ces rôles, les conditions pour ce type de Prd (dans l'attribut request_prd_type)
10. Vérification du role de l'User courant dans le Process et dans le Item concerné.
11. Traitements spécifiques au type de Prd.

Schéma de finalisation de la réception d'un Prd :

PRD Received

11. PrdList - Demande de Listes

Utile pour les User souhaitant consulter ou explorer des listes de contrats, de membres ou d'autres items dans le réseau. Chaque Pcd liste des Item d'un même type, tels que les Process, les Member, les Peer, les Payments, etc.

Un PRDList concerne un seul type d'Item parmi Member, Peer, Process, Artefact, Payment… et demande le dernier PCD de ce type (la dernière liste validée). Ainsi, en retour d'un PRDList, on ne reçoit qu'une liste de membres (PCD) et les signatures qui la vérifient (PRDResponse). Il faudra, par exemple, un PRDList pour mettre à jour la liste d'un autre type d'Item.

Par exemple, à la connexion, on envoie des PRDList à chaque adresse SP de chaque Role, et l'on reçoit chaque liste (PCD) à jour pour tous les objets dont les Member et les Process. Lorsqu'il y a une mise à jour de la liste des Member et des Process et que l'on est connecté, alors on reçoit à jour ces listes en temps réel; donc, il y a peu de risques d'écarts entre, par exemple, la liste des Member et les adresse sp dans les Process. Une mise à jour est une nouvelle version d'un PCD et les PRDResponse qui ont répondu au PRDUpdate ayant demandé la mise à jour. Les PRDResponse permettront de vérifier la conformité de la nouvelle version du PCD avec les conditions du Process.

Note : dans les Process on ne connait que les adresse SP des gestionnaires; pour interagir avec les autres users, il faut utiliser la liste (PCD) des Member fournie par les PRDList envoyés par les gestionnaires de la liste des Member. Dans les process, nous n'avons besoin que des adresse SP des membres pour vérifier les PCD et les PRDResponse des PRDList et des PRDUpdate ou pour envoyer des PRD vers spécifiquement des Member d'un Role. Si dans les interfaces et services on a besoin du détail d'un membre comme son image d'avatar ou son nom, il faudra récupérer ces informations dans la dernière version du PCD des Member.

Workflow:

Principaux champs des PrdList :

• request_prd : cf la descripton de la structure Prd.
• pagination_start : Première "page" de résultats.
• pagination_stop : Dernière "page" de résultats.
• sub_pagination_start : Première "page" de résultats dans les items qui contiennent une liste.
• sub_pagination_stop : Dernière "page" de résultats dans les items qui contiennent une liste.

Dans le cas d'une création de compte :

• item_Member_enc_by_sp_shared_secret : Nouvel Member temporaire,chiffrée par la clé KeyConfidential d'une transaction SP.

Member temporaire contient les métadonnées de type Metadata suivantes :

• MetadataProcessPublic de type MemberPublicAttributeGroup :

• sp_address_public : Adresse publique de l'User, chiffré par la ProcessKey de Process.

• sp_address_revoke_public : Adresse publique de révocation de l'User, chiffré par la ProcessKey de Process.

• third_sp_address_list_public : Liste des adresses publiques de devices tiers, chiffré par la ProcessKey de Process.

• data_size_max : Taille maximale des données acceptée par l'User (par flux), chiffré par la ProcessKey de Process.

• Payments_method_list_public : Liste des méthodes de paiement acceptées par l'User, chiffré par la ProcessKey de Process.

• succession_process_hash : Hash du processus de succession de l'User (transmission du User et donc de tous les flux associés), chiffré par la ProcessKey de Process.

• device_footprint : Empreinte du dispositif de l'User, chiffré par la ProcessKey de Process.

• MetadataRoleConfidential de type MemberRoleConfidentialAttributeGroup :

• shard_confidential : Shard de l'User, chiffré par la clé KeyConfidential d'une transaction SP.

• pre_id_confidential : Pré empreinte du User, chiffrée par la clé KeyConfidential d'une transaction SP.

• MetadataPrivate de type MemberRolePrivateAttributeGroup :

• priv_key_mainnet_spend : Clé de dépense de l'User, chiffrée par la clé privée du mainnet, chiffrée par KeyRecover.

• priv_key_mainnet_scan : Clé de scan de l'User, chiffrée par la clé privée du mainnet, chiffrée par KeyRecover.

• priv_key_signet_scan : Clé de scan du signet de recoverde l'User, chiffrée KeyRecover.

11.1. Schéma des flux

Pour simplifier, les PrdConfirm n'ont pas été inclus dans le schéma.

12. PrdMessage - Envoi d'une Envelope

Le PrdMessage facilite l'envoi d'une Envelope sécurisés entre User ou entre User et processus/contrats.

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.

Les PrdMessage peuvent répondre aux autres PrdMessage, sauf en cas d'envoi de raw_transaction_list (dans le cas d'utilisation pour transférer la transaction SP depuis un autre Prd).

Workflow :

Principaux champs des PrdMessage :

• request_prd : cf la descripton de la structure Prd.
• raw_transaction_list : Liste des transaction SP au format raw pour la publication de la transaction dans la side chain.

12.1. Schéma des flux

Pour simplifier, les PrdConfirm n'ont pas été inclus dans le schéma. Exemple d'un PrdMessage avec raw_transaction_list vide, et son cas correspondant où le PrdMessage contient une raw_transaction_list non vide.

13. PrdUpdate - Mises à Jour de Pcd

PrdUpdate est conçu pour demander des mises à jour des listes via de nouvelles versions de Pcd.

Basé sur le Prd, avec des ajouts pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour :

Essentiel pour les User 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, la mise à jour de la liste des Members permet d'ajouter de nouveaux User à un Process, et la mise à jour de la liste des Process permet de leur affecter un nouveau Role.

Les PrdUpdate signalent au réseau, via l'attribut Pcd_new_version_hash, les nouvelles versions des Pcd.

Workflow:

Principaux champs des PrdUpdate :

• request_prd : cf la descripton de la structure Prd.

13.1. Schéma des flux

Pour simplifier, les PrdConfirm n'ont pas été représentés dans le schéma.

14. PrdConfirm - Confirmation de Réception

Le PrdConfirm est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau.

Les PrdList, PrdUpdate, PrdMessage, PrdResponse et PrdKeyHello reçoivent systématiquement un PrdConfirm suite à leur réception par le destinataire.

code_confirm_confidential : 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 PrdConfirm.

Worflow:

Voir les diagrammes PRDUpdateFlows, PRDUpdateFlows et PRDMessageFlows.

Principaux champs des PrdConfirm :

• request_prd : cf la descripton de la structure Prd.
• code_confirm_confidential : Code de confirmation chiffré par la clé KeyConfidential d'une transaction SP dans le cas d'un 2FA.

14.1. Schéma des flux

15. PrdResponse - Répondre à une Demande

Le PrdResponse permet de répondre spécifiquement à des Prd reçus, facilitant un échange interactif d'informations ou de décisions entre les parties.

Les PrdResponse sont utilisés pour répondre aux PrdList, PrdUpdate, 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.

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.

Workflow:

Voir les diagrammes PRDUpdateFlows et PRDUpdateFlows.

Principaux champs des PrdResponse :

• request_prd : cf la descripton de la structure Prd.
• shared_secret_key_enc_by_sp_shared_secret : Clé de chiffrement partagée chiffrée par la clé KeyConfidential d'une transaction SP.
• shard_enc_by_sp_shared_secret : Shard chiffré par la clé KeyConfidential d'une transaction SP.

15.1. Schéma des flux

Pour simplifier, les PrdConfirm n'ont pas été représentés dans le schéma.

16. Exemples de Code

17. Todo