* 1. [Objectif](#Objectif) * 2. [Portée](#Porte) * 3. [3. Documents de référence](#Documentsderfrence) * 3.1. [Worfklows](#Worfklows) * 3.2. [Transverse](#Transverse) * 3.3. [Structure des PCD et PRD et de leur attribut générique Request](#StructuredesPCDetPRDetdeleurattributgnriqueRequest) * 3.4. [Structure et Fonction des PCD](#StructureetFonctiondesPCD) * 3.4.1. [Structure de Base d'un PCD](#StructuredeBasedunPCD) * 3.4.2. [L'attribut des listes PcdItemGenericEnc `item_list`](#LattributdeslistesPcdItemGenericEncitem_list) * 3.5. [Types de PRD et Leur Fonction](#TypesdePRDetLeurFonction) * 3.5.1. [Structure de RequestPrd](#StructuredeRequestPrd) * 4. [Gestion et Échange des Documents](#GestionetchangedesDocuments) * 4.1. [Création et Distribution](#CrationetDistribution) * 4.2. [Validation et Mise à Jour](#ValidationetMiseJour) * 5. [Exemples de Code](#ExemplesdeCode) # PRD et PCD - Specs ## 1. 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. ## 2. 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. ## 3. 3. Documents de référence ### 3.1. Worfklows * **Authentification**: Auth-Specs.md * **Items**: Item-Specs.md * **Messages et transactions SP**: Message-SP-Specs.md * **Process et roles**: Process-Role-Specs.md ### 3.2. Transverse * **Définitions et abréviations.**: Specs-Definition.md * **Exigences de sécurité**: Specs-Security.md * **Code**: Specs-Code.md * **Maintenance, environnement de déploiement**: Specs-Deployment.md * **References**: Specs-References.md * **Diagramme d'architecture montrant les composants principaux du système de login.** [SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A) ### 3.3. Structure des PCD et PRD et de leur attribut générique Request La structure Request joue un rôle central dans la création des `PRD` et des `PCD`, servant de fondement pour formuler des demandes au sein du système 4NK. * **request**: Un champ encapsulant les détails de la demande, incluant le type, la version, et les références nécessaires pour l'identifier et la traiter présent dans les `PCD` et les `PRD`. Il contient les attributs suivants : * **item_name**: Optionnel, spécifie le nom de l'item concerné par la demande. * **request_type**: Identifie le type de la demande, tel que mise à jour, confirmation, ou autre action spécifique. * **version**: Indique la version de la demande, permettant de gérer la compatibilité et les mises à jour. * **process_hash**: Référence au hash du processus ItemProcess concerné, établissant le contexte de la demande. * **pcd_reference_hash et item_reference_hash**: Optionnels, fournissent des références aux PCD ou items spécifiques concernés par la demande. ### 3.4. Structure et Fonction des PCD #### 3.4.1. Structure de Base d'un PCD `Item`: Chaque `PCD` est associé à un type d'`item` spécifique, définissant le contexte et la portée des informations qu'il contient. `MetadataContractPublic`, `MetadataRoleConfidential`, `MetadataPrivate`: Ces métadonnées encapsulent les attributs des `items` au sein du `PCD`, classés selon leur niveau de confidentialité. Les métadonnées au sein des PCD jouent un rôle crucial en définissant le niveau de confidentialité et d'accès aux informations contractuelles. Elles permettent une segmentation claire des données selon qui peut y accéder et comment elles peuvent être utilisées. #### 3.4.2. L'attribut des listes PcdItemGenericEnc `item_list` Chaque Item dit "Enc" pour chiffré est une représentation d'un objet de type `Item` mais avec les attributs chiffrés. Ainsi voici la composition d'un item chiffré : * **item_enc**: Représente l'encapsulation d'un item au sein d'un PCD, y compris les informations de version, le type d'item, et son nom. Cette structure est la base pour les attributs chiffrés de l'item. * **pcd_item_enc_attribute_public_list**: Une liste d'attributs publics. * **pcd_item_enc_attribute_role_confidential_list**: Contient les attributs chiffrés destinés à être accessibles uniquement par les membres ayant un rôle spécifique dans le processus. * **pcd_item_enc_attribute_private_list**: Attributs chiffrés destinés uniquement au créateur de l'item ou à des parties spécifiquement autorisées. Voir Specs - Exigences de sécurité pour le détail des niveaux de sécurité. ### 3.5. Types de PRD et Leur Fonction `RequestPrd`: Structure de base pour toutes les demandes, contenant des informations chiffrées essentielles pour l'interaction sécurisée entre les parties. `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `PRD` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. #### 3.5.1. Structure de RequestPrd La structure RequestPrd sert de fondement pour tous les types de PRD, contenant les éléments suivants : * **pcd_keys_role_confidential_list_enc_by_shared_secret**: Liste des clés de chiffrement pour les attributs roleConfidential, permettant un accès sécurisé aux informations nécessaires. * **message_public, message_confidential, message_private**: Segments pour les messages, classés selon leur niveau de confidentialité, facilitant une communication sécurisée et ciblée. * **sp_address_to, sp_address_from, sp_address_reply**: Adresses Silent Payment spécifiant l'origine, la destination, et la réponse pour la transaction, assurant l'anonymat et la sécurité des participants. * **timestamp_declared**: Horodatage déclaré ne servant pas aux contrôles automatiques, fournissant un contexte temporel pour la demande qui peut être différent des horodatages automatiques. * **role_name_from et role_name_to**: Spécifient les rôles des participants à la demande, renforçant le contrôle d'accès et la segmentation des autorisations pour des identités (adresses SP) ayant plusieurs roles différents. ##### RequestPrdList - Demande de Listes (PCD) RequestPrdList spécifie une demande pour obtenir une liste d`Item` sous forme de `PCD`. ###### Composition et Fonction Basé sur le `RequestPrd`. ###### Cas d'utilisation Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le réseau. ##### RequestPrdMessage - Envoi de Messages Le RequestPrdMessage facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats. ###### Composition et Fonction Basé sur le `RequestPrd`. ###### Cas d'utilisation Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties. Les `PRDMessage` répondent aux `PRDMessage`. ##### RequestPrdUpdate - Mises à Jour de PCD `RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `PCD`. ###### Composition et Fonction Basé sur le `RequestPrd`. avec des additions pour spécifier les modifications demandées, y compris de nouveaux attributs ou valeurs à mettre à jour : * **pcd_new_version_hash**: , * **payment_pcd_hash_list**: , * **cap_pcd_hash_list**: , * **deposit_pcd_hash_list**: , * **commitment_pcd_hash_list**: , * **ask_payment_method**: , * **ask_deposit_method**: , * **ask_commitment_method**: , ###### Cas d'utilisation Essentiel pour les utilisateurs ou les processus nécessitant de mettre à jour des informations contractuelles ou des attributs d'items, assurant la pertinence et l'actualité des données dans le système. Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux utilisateurs sur un `process`, la mise à jour de la liste des `process` permettra de leur affecter un nouveau role. ##### 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 `PRDList`, `PRDUpdate`, `PRDMessage`, `PRDResponse` et `PRDKeyHello` reçoivent systématiquement un `PRDConfirm` depuis leur réception par le destinataire. ###### Composition et Fonction et code de confirmation Basé sur le `RequestPrd`, incluant les informations de la demande originale nécessitant confirmation. `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 PRDConfirm. ###### Cas d'utilisation Crucial pour les processus qui nécessitent une confirmation explicite de réception ou d'acceptation, comme la finalisation d'une transaction ou la validation d'un changement d'état dans un contrat. ##### RequestPrdResponse - Répondre à une Demande Le RequestPrdResponse 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 répondent aux `PRDList`, `PRDUpdate`, `PRDKeyBackup` et `PRDKeyHello`. ###### Composition et Fonction Basé sur le `RequestPrd`, complété par : * **sig_value**: Valeur de signature qui certifie l'authenticité de la réponse et de son émetteur. * **pcd_origin_hash**: Optionnel, fournit une référence au PCD d'origine concerné par la réponse, si applicable. * **payment_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential` * **deposit_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential` * **commitment_method_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential` * **certif_key_enc_by_shared_secret**: Détails sur la méthode ou l'action à prendre en réponse, chiffrée pour la sécurité par la clé `KeyConfidential` * **shared_secret_key**: une clé secrète partagée via le `PRD`. ###### Cas d'utilisation 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. ##### RequestPrdKeyHelloBakcup Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` . ###### Composition et Fonction Basé sur le `RequestPrd`, complété par : * **device_footprint_enc_by_sp_shared_secret**: String, * **part_1_enc_hash_enc_by_sp_shared_secret**: String, * **shard_enc_by_sp_shared_secret**: String, ###### Cas d'utilisation ##### RequestPrdKeyHello - Échange de Clés et d'Identités RequestPrdKeyHello est conçu pour initier ou répondre à des demandes d'échange de clés ou d'informations d'identité, essentiel pour la gestion sécurisée des accès et des identités au sein du réseau. ###### Composition et Fonction Basé sur le `RequestPrd`, complété par : * **part_1_enc_hash_enc_by_sp_shared_secret**: La première partie de la clé ou de l'identité, chiffrée avec le mot de passe en `pré-id`. ###### Cas d'utilisation Important pour les processus d'onboarding de nouveaux membres, de réinitialisation des accès, ou de renouvellement des clés, facilitant une intégration sécurisée et la mise à jour des identités dans le réseau. ## 4. Gestion et Échange des Documents ### 4.1. Création et Distribution Procédure de création des PCD et PRD, leur chiffrement, et les mécanismes de distribution sécurisée à travers le réseau 4NK. ### 4.2. Validation et Mise à Jour Processus de validation des informations contenues dans les PCD et PRD, ainsi que les procédures de mise à jour et de versioning des documents. ## 5. Exemples de Code Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.