sdk_common/doc/PRD-PCD-Specs.md

PRD PCD - Specifications

1. Autheurs, validations, dates, versions, changes and history

Cf. Git SDK COMMON

2. Table des matières

• 1. Autheurs, validations, dates, versions, changes and history
• 2. Table des matières
• 3. Objectif
• 4. Portée
• 5. Documents de référence
• 6. Définitions
• 7. Principes de messagerie
• 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 de Messages
  • 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 identités numériques au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau.

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 ItemProcess (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 l'ItemProcess. 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 de messages 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).

• Message: 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 l'ItemProcess (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 ItemProcess (trouvée 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é privée de dépense de recover du signet, utilisée comme référence pour l'identité.

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

7. Principes de messagerie

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

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 de message, pouvant initier un échange de messagerie 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 membres de l'ItemProcess, 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 de message au destinataire du message.
• 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 membres 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'utilisateur 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 : Membres 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 ItemProcess	Yes	Yes	Yes
PrdUpdate	waiting sig_value	Yes	Yes	all the members of all Role into to ItemProcess	No	Yes	Yes
PrdMessage	waiting sig_value + message_public, message_confidential, message_private	if no raw_transaction_list	No	a member of the ItemProcess	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'utilisateur 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 ItemProcess	No	Yes
PrdUpdate	Prd	Yes	No	all the members of all Role into to ItemProcess	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 l'ItemProcess (cf. Specs-Definition). Ces données sont ainsi accessibles à tous pour le déchiffrement.

• Données confidentielles destinées aux membres d'un role spécifique d'un ItemProcess 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 membres d'un role spécifique d'un ItemProcess 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, commitment, et les artefact personnalisés.
• version : Version de la requête.
• process_hash : Hash de l'ItemProcess 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 l'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 ItemProcess 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 l'Item.
• item_type : Type de l'Item.
• name : Nom de l'Item.
• request_pcd_item_enc_attribute_public_list : Liste d'objets PcdItemEncAttributePublic des attributs publics de l'Item chiffré.
• request_pcd_item_enc_attribute_role_confidential_list : Liste d'objets PcdItemEncAttributeRoleConfidential des attributs confidentiels de l'Item chiffré.
• request_pcd_item_enc_attribute_private_list : Liste d'objets PcdItemEncAttributePrivate des attributs privés de l'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 l'ItemProcess concerné.
• key : [PRIVE] Clé de chiffrement, non partagée dans les messages. Données en clair.
• data : [PRIVE] Non partagé dans les messages. Données en clair.

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 messages. Données en clair.
• data : [PRIVE] Non partagé dans les messages. 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 messages. Données en clair.
• data : [PRIVE] Non partagé dans les messages. 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 du message cf Messages - Specs.

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.

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 de messages, 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 ItemProcess).

Les Prd se déclinent en plusieurs types, tels que PrdList, PrdMessage, PrdUpdate, etc., correspondant à différentes actions comme l'envoi de messages, 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 l'ItemProcess).
• 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 : Message public, chiffré par la clé ProcessKey du ItemProcess concerné.
• message_confidential : Message confidentiel, chiffré par la clé ProcessKey du ItemProcess concerné.
• message_private : Message 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.
• commitment_request_pcd_hash_list_confidential : Liste des Pcd d'Item de nom commitment 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_commitment_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.
• commitment_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 du message cf Messages - Specs.

10.3. Réception

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

1. Parcours des ItemProcess pour trouver le ItemProcess correspondant au process_hash du Prd
2. Tentative de déchiffrement du Prd avec la clé ProcessKey du ItemProcess 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 l'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 ItemProcess pour cet Item, avec le Role correspondant dans le ItemProcess, 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'utilisateur courant dans le ItemProcess et dans le Item concerné.
11. Traitements spécifiques au type de Prd.

11. PrdList - Demande de Listes

Utile pour les utilisateurs souhaitant consulter ou explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque Pcd liste des Item d'un même type, tels que les ItemProcess, les ItemMember, les ItemPeer, les ItemPayments, etc.

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 ItemMember temporaire,chiffrée par la clé KeyConfidential d'une transaction SP.

L'ItemMember temporaire contient les métadonnées de type Metadata suivantes :

• MetadataProcessPublic de type ItemMemberPublicAttributeGroup :

• sp_address_public : Adresse publique de l'utilisateur, chiffré par la ProcessKey de l'ItemProcess.

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

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

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

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

• succession_process_hash : Hash du processus de succession de l'utilisateur (transmission de l'identité numérique et donc de tous les flux associés), chiffré par la ProcessKey de l'ItemProcess.

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

• MetadataRoleConfidential de type ItemMemberRoleConfidentialAttributeGroup :

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

• pre_id_confidential : Pré empreinte de l'identité numérique de l'utilisateur, chiffrée par la clé KeyConfidential d'une transaction SP.

• MetadataPrivate de type ItemMemberRolePrivateAttributeGroup :

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

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

• priv_key_signet_scan : Clé de scan du signet de recoverde l'utilisateur, 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 de Messages

Le PrdMessage facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs 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 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, 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 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