simplification (doc)

doc/Auth-Specs.md

@@ -192,6 +192,8 @@ C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet
 
 Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet.
 
+Les metadatas des membres propres au process sont décrits dans le process et doivent compléter les metadatas de l'`ItemMember`.
+
 L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md).
 
 1. Création d'un `ItemMember` correspondant à l'utilisateur.
@@ -229,46 +231,31 @@ L'envoi d'une révocation est identique à la création d'une nouvelle adresse v
 
 ##### Clés de third parties
 
-En plus, on peut générer d'autres paires de clés de dépense et de scan qui seront à exporter vers d'autres dispositifs pour du 2FA, avec leurs UTXO.
+Au moment de l'update de l'`ItemMember` il est possible de charger des addresses SP de third parties pour lesquelles l'utilisateur a un rôle dans un process. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
 
-Pour cela, il faut se connecter aux relais avec les adresses de faucet de ces nouvelles clés (adresses publiques classiques générées depuis ces clés privées). Comme pour les clés de `recover` et de `revoke`.
+Les clés privées associées sont générées lors de l'update d'un membre, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
-
-Les adresses SP de ces clés sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
-
-Ces clés sont générées lors de l'update d'un membre, avec déjà une identité créée sur un process, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
 
 Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les PRD concernés.
 
 #### 9.1.3. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
 
-Comme pour la création de compte, les relais partagent leur liste de relais et de process au setup du SDK (Wasm), ces listes sont stockées en cache sous forme d'objets `SharedPeer` et `SharedProcess`.
+Pour recrééer sa clé privée et envoyer un `PRDKeyHello` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes :
-
-Afin d'obtenir de nouveaux UTXO indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
-
-Dans l'ordre on réalise les opérations suivantes :
 
 1. Récupération de Part1Enc en cache
 2. Création de la pré-image avec le mot de passe
 
-Puis :
+Puis depuis la liste des membres du process, pour chacun des membres :
 
-1. Création de `PRDKeyHello` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+1. Création de `PRDKeyHello` à destination du membre 1.
-2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+2. Création de `Message` du `PRDKeyHello` à destination du membre.
-3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
+3. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination du membre.
-4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
+4. Envoi du `Message` du `PRDKeyHello` à destination du membre.
-5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
+5. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
-6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
+6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PRDResponse`.
-7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1.
+6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
-11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2.
+6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
-
+6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe
-1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
+6.4. Concaténation de `Part1` et `Part2`
-2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyHello`.
-3. Attente et réception des `pcd_reference_hash` des `PRDResponse` reçus avec le PCD des membres du processus (liste de `itemMember`).
-4. Recomposition de la clé selon :
-4.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
-4.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
-4.3 Recomposition de `Part2Enc` et déchiffrement par le mot de passe
-4.4 Concaténation de `Part1` et `Part2`
 
 Demande d'update de la liste des membres (PCD) d'un process :