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

"Principe de fonctionnement" added dans Auth

Browse Source
This commit is contained in:
NicolasCantu 2024-04-04 13:50:36 +02:00
parent 2b8c018e42
commit 3c79a75819
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/Auth-Specs.md
View File

@ -113,6 +113,22 @@ Une image de révocation est générée à la création d'une identité pour pou
Le système ne maintiendra pas de session traditionnelle sur le serveur. La navigation de l'utilisateur persiste grâce à un cache local dans IndexedDB ou en mémoire, avec une politique de sécurité stricte forçant la resaisie du mot de passe après un rafraîchissement de la page ou une inactivité prolongée, déterminée par une durée maximale sans login.
## Principe de fonctionnement
A la création d'une identité numérique, l'utilisateur génère une clé privée Bitcoin pour les transactions SP (Silent Payments) et une clé privée pour la révocation de cette identité. Ces clés sont stockées dans les données exif d'une image de login et d'une image de révocation, respectivement.
En fonction du `Process` choisi, l'utilisateur devra remplir un formulaire pour compléter son `Member` avec les champs requis par le `Process`. Ces champs sont définis dans le champs "render_template_list" de l'attribut `metadata_contract_public` du `Item` du `Role` `Member` du `Process`.
Puis l'utilisateur envoi un `PCD` contenant la liste mise à jour des `Member` complété de son propre `Member`, des autres clés cryptographiques et des shards de sa clé de `spend` et un `PRDUpdate` à chaque `Member` de chaque `Role` de chaque `Member` pour leur demander de valider cette nouvelle version de la liste des `Member` (`PCD`).
Optionnellement, l'utilisateur envoi un `PCD` contenant la liste mise à jour des `Process` complété de son propre `address Silent Payments` dans un ou plusieurs `Role` du `Process` et un `PRDUpdate` à chaque `Member` de chaque `Role` de chaque `Process` pour leur demander de valider cette nouvelle version de la liste des `Process` (`PCD`).
En retour les `PRDConfirm` confirmeront la réception des `PRDUpdate`.
De même, les `PRDResponse` en réponse au `PRDUpdate` de la liste des `Member` contiendront les shards de clés de `spend` des `Member` de chaque `Role` de chaque `Member` pour permettre à l'utilisateur de recomposer sa clé de `spend` et la valeur de leur signature pour valider ou non la demande de mise à jourd de la liste des `Member` et les clés chiffrées des champs confidentiels des `Member`.
Si l'utilisateur a aussi envoyé un `PRDUpdate` de la liste des `Process`, les `PRDResponse` en réponse contiendront la valeur de leur signature pour valider ou non la demande de mise à jour de la liste des `Process` ainsi que les clés chiffrées des champs confidentiels des `Process`.
## 11. <a name='Wallet'></a>Wallet
Les transactions SP ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) :