4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

simplification (doc)

Browse Source
This commit is contained in:
NicolasCantu 2024-02-14 16:49:42 +01:00
parent f994e9cf55
commit da3155022b
1 changed files with 17 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
doc/Auth-Specs.md
View File

@ -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.
@ -218,7 +220,7 @@ Demande d'update de la liste des membres (PCD) d'un process vers chaque membre d
5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination du membre.
6. Envoi du `Message` du `PRDKeyHello` à destination du membre.
7. Réception des `PRDResponse` en réponse aux `PRDKeyHello` et mise à jour des listes depuis les `PCD` correspondants.
8. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
8. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
9. Redirection vers la page du process sur le relai.
##### Clés de révocation (`revoke`)
@ -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 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.
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.
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`.
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 :
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 :
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`.
2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1.
11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2.
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.
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`
1. Création de `PRDKeyHello` à destination du membre 1.
2. Création de `Message` du `PRDKeyHello` à destination du membre.
3. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination du membre.
4. Envoi du `Message` du `PRDKeyHello` à destination du membre.
5. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `PRDResponse`.
6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
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
6.4. Concaténation de `Part1` et `Part2`
Demande d'update de la liste des membres (PCD) d'un process :