4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
sdk_common/doc/PRD-PCD-Specs.md
NicolasCantu 7eb9f608ba index fixed (doc)
2024-04-14 20:12:58 +02:00

38 KiB
Raw Blame History

PRD PCD - Specifications

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

Cf. Git SDK COMMON

2. Table des matières

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 de messages publics, confidentiels ou privés. 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) pour valider ou non l'action demandée via l'attribut sig_value et fournir les éléments nécessaires (notamment dans le cas des demandes et réponses des moyens de paiements).
    • PrdUserCreate: Message dédié à la réation d'un User.
    • PrdUserRecover: Message dédié à à la récupération d'un User.

  • 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 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. Cette transaction SP est transmise au relais et aux autres utilisateurs via l'attribut raw_transaction_list des Envelope.

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 : Envoi d'un message, pouvant initier un échange 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.
  • PrdUserCreate: Envoi d'un message à des gestionnaires de membres pour demander la sauvegarde des shards d'un User en fonction de sa preId , le PrdResponse y répond avec une acception ou non dans l'attribut sig_value.
  • PrdUserRecover: Envoi d'un message à des gestionnaires de membres pour demander la récupération des shards d'un User en fonction de sa preId, le PrdResponse y répond avec les shards dans l'attribut shard_enc_by_sp_shared_secret

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 Envoi d'un message à son destinataire .
  • PrdUpdate : Envoyé aux gestionnaires du type d'Item concerné.
  • PrdConfirm : Envoyé à l'émetteur du Prd associé.
  • PrdResponse, 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.
    • Réponse à un PrdResponse : dans le cas des demandes et réponses des moyens de paiements, de dépôt ou de commit, envoyés par un précédent PrdResponse.
  • PrdUserCreate: envoyée à tous les Member du role Member d'un Process
  • PrdUserRecover: envoyée à tous les Member du role Member d'un Process

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 de l'envoi du Prd.
  • **transaction SP: Envoi d'une transaction SP, ou non.
  • Pcd to send : Envoi d'un Pcd en complément du Prd.
  • request_type send to : les Member 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 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 No a Member of the Process No No
PrdResponse waiting sig_value Yes No See Received No No Yes
PrdConfirm (option) Waiting code_confirm_confidential Yes No See Received No No No
PrdUserCreate No Yes No No No Yes Yes
PrdUserRecover No No No No No Yes 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 No No No No
PrdResponse Prd Yes No No No No
PrdConfirm Prd No No No No No
PrdUserCreate Yes Yes No Yes No Yes
PrdUserRecover No No No Yes No Yes

7.1. Envoyer les clés de déchiffrement des PCD dans les PRD

2 cas :

  • Envoi d'un PCD déjà validé: dans ce cas les PRDResponse déjà collectés sont renvoyés, ils contiennent ces clés dans l'attribut shared_secret_key_enc_by_sp_shared_secret de son objet PRD.
  • Proposition d'une mise à jour: dans ce cas le PRDUpdate qui accompagne la mise à jour contient ces clés dans l'attribut shared_secret_key_enc_by_sp_shared_secret de son objet PRD.

De même pour les champs confidentiels des PRD dont les clés sont envoyés dans l'attribut shared_secret_key_enc_by_sp_shared_secret de leur objet PRD.

7.2. Valider un PCD

2 cas :

  • Si la signature est automatique: alors la validité correspond strictement juste la conformité au Process qui ne dépend pas des données
  • Si la signature n’est pas automatique: alors la validité sera celle renvoyer par l’utilisateur après contrôle évenutel des données et la conformité au Process qui ne dépend pas des données.

8. Encryption

Schema :

PCD_PRD_encryption

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.

8.1. Utilisation des hash des PCD et PRD "d'origine"

Il y a 2 cas d’utilisation des hash des PCD et PRD "d'origine" :

  • Pour les mises à jour dont on mentionne l'origine c'est à dire la version précendente depuis laquelle la mise à jour a été faite.
  • Pour un message répond un autre, l’autre est dans mentionné avec son hash dans l'attribut.

8.2. Utilisation des hash des PCD, PRD et items "de référence"

Quant l’utilisateur aura besoin des références pour vérifier la data on utilisera les référérences ce qui dépend des cas d’usages.

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.

Schéma des flux :

Pcd

9.1. 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.2. 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'un message, 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'un message, 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 : Message public, chiffré par la clé ProcessKey du Process concerné.
  • message_confidential : Message confidentiel, chiffré par la clé ProcessKey du Process 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.
  • 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.

Prd

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:

PRDListFlows

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.

  • 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 :

  • 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.

Schéma des flux :

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

PrdList

12. PrdMessage - Envoi d'un message

Le PrdMessage facilite l'envoi d'un message sécurisé entre User.

Les PrdMessage peuvent répondre aux autres PrdMessage.

Note: Ce sont des objects génériques qui servent aux cas d’usages, le plus souvent cette messagerie est utilisée pour négocier les termes des process et des valiation.

Workflow : PRDMessageFlows

Principaux champs des PrdMessage :

  • request_prd : cf la descripton de la structure Prd.

Schéma des flux :

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

PrdMessage

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:

PRDUpdateFlows

Principaux champs des PrdUpdate :

  • request_prd : cf la descripton de la structure Prd.

Schéma des flux :

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

PrdUpdate

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.

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.

Schéma des flux :

PrdConfirm

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.

Schéma des flux :

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

PrdResponse

16. PrdUserCreate - Demande de sauvegarde des shards d'un User

Le PrdUserCreate est utilisé pour demander la sauvegarde des shards d'un User dans le réseau.

Workflow:

PRDUserCreateFlows

Principaux champs des PrdUserCreate :

  • 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.

Schéma des flux :

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

PrdUserCreate

17. PrdUserRecover - Demande de récupération des shards d'un User

Le PrdUserRecover est utilisé pour demander la récupération des shards d'un User dans le réseau.

Workflow:

PRDUserRecoverFlows

Principaux champs des PrdUserRecover :

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

Schéma des flux :

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

UserRecover

18. Exemples de Code

19. Todo