Onboarding details
This commit is contained in:
parent
5faf6547af
commit
6d9ade843e
@ -3,18 +3,22 @@
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [Documents de référence](#Documentsderfrence)
|
||||
* 4. [Schématisation des processus](#Schmatisationdesprocessus)
|
||||
* 4.1. [Création d'une identité](#Crationduneidentit)
|
||||
* 4.2. [Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover)
|
||||
* 4.1. [Création d'une identité](#Crationduneidentit)
|
||||
* 4.2. [Onboarding](#Onboarding)
|
||||
* 4.3. [Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover)
|
||||
* 5. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
|
||||
* 6. [Connexion via des tiers](#Connexionviadestiers)
|
||||
* 7. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
|
||||
* 8. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
|
||||
* 9. [Wallet](#Wallet)
|
||||
* 9.1. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
|
||||
* 9.1. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
|
||||
* 10. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
|
||||
* 10.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
|
||||
* 10.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover)
|
||||
* 10.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc)
|
||||
* 10.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
|
||||
* 10.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover)
|
||||
* 10.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc)
|
||||
* 10.1.3. [Onboarding](#Onboarding-1)
|
||||
* 10.2. [ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process](#ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess)
|
||||
* 10.3. [ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process](#ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess)
|
||||
* 11. [Clés de révocation (`revoke`)](#Clsdervocationrevoke)
|
||||
* 12. [Clés de third parties](#Clsdethirdparties)
|
||||
* 13. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
|
||||
@ -27,35 +31,35 @@
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># Auth - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
Développer un système de login sécurisé utilisant les clés cryptographiques de Bitcoin et sa timechain (via un réseau Signet personnalisé, appelé "side chain") ainsi qu'un système de relais de messages entre parties prenantes. Le concept de Silent Payment est employé pour authentifier les utilisateurs sans réutilisation d'adresses, tout en utilisant une approche de `calcul multipartite (MPC)` pour une gestion sécurisée et distribuée des clés. Déployer une interface de login conforme aux wireframes :
|
||||
|
||||
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
Ce système couvrira la conception et le développement de l'architecture d'authentification, incluant la génération, la gestion, et la validation des identités numériques à travers des formats de conformité spécifiques (Portable Contract Document et Portable Request Document). Il intégrera également l'authentification des utilisateurs, la connexion via des tiers, la récupération d'identités, et une gestion de session basée sur un cache avec des contraintes de sécurité renforcées. La solution sera conçue pour des environnements hautement sécurisés, nécessitant une haute disponibilité, performance, et évolutivité.
|
||||
|
||||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||||
|
||||
Voir [_Doc_references.md](_Doc_references.md).
|
||||
|
||||
## 4. <a name='Schmatisationdesprocessus'></a>Schématisation des processus
|
||||
## 4. <a name='Schmatisationdesprocessus'></a>Schématisation des processus
|
||||
|
||||
### 4.1. <a name='Crationduneidentit'></a>Création d'une identité
|
||||
### 4.1. <a name='Crationduneidentit'></a>Création d'une identité
|
||||
|
||||
|
||||
|
||||
### Onboarding
|
||||
### 4.2. <a name='Onboarding'></a>Onboarding
|
||||
|
||||
|
||||
|
||||
### 4.2. <a name='Connexionavecuneidentitcrerecover'></a>Connexion avec une identité créée (`recover`)
|
||||
### 4.3. <a name='Connexionavecuneidentitcrerecover'></a>Connexion avec une identité créée (`recover`)
|
||||
|
||||
|
||||
|
||||
## 5. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
|
||||
## 5. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
|
||||
|
||||
Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `ItemProcess` .
|
||||
|
||||
@ -65,23 +69,23 @@ Les utilisateurs sont reconnus par une`adresse SP` dans un ou plusieurs rôles d
|
||||
|
||||
Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par `ItemProcess` dans lequel l'utilisateur a un rôle (`onboarding`).
|
||||
|
||||
## 6. <a name='Connexionviadestiers'></a>Connexion via des tiers
|
||||
## 6. <a name='Connexionviadestiers'></a>Connexion via des tiers
|
||||
|
||||
Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience utilisateur.
|
||||
|
||||
Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux `ItemProcess` 4NK.
|
||||
|
||||
## 7. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
|
||||
## 7. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
|
||||
|
||||
En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis.
|
||||
|
||||
Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux `RequestPcd` et `RequestPrd` correspondants.
|
||||
|
||||
## 8. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
|
||||
## 8. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
|
||||
|
||||
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.
|
||||
|
||||
## 9. <a name='Wallet'></a>Wallet
|
||||
## 9. <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) :
|
||||
|
||||
@ -110,7 +114,7 @@ Dans l'ordre on génère donc :
|
||||
5. Clé privée de dépense mainnet `spend_mainnet`.
|
||||
6. Clé privée de scan du mainnet `scan_mainnet`.
|
||||
|
||||
### 9.1. <a name='Rcuprationdesjetonsdefaucet'></a>Récupération des jetons de faucet
|
||||
### 9.1. <a name='Rcuprationdesjetonsdefaucet'></a>Récupération des jetons de faucet
|
||||
|
||||
Le relais retournent des jetons à la connexion et à l'envoi de messages afin de créer les `UTXO` nécessaires pour les transactions SP.
|
||||
|
||||
@ -120,11 +124,11 @@ A chaque nouveau message il génère de nouvelles addresses pour la clé qui va
|
||||
|
||||
Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envoyés aux relais.
|
||||
|
||||
## 10. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
|
||||
## 10. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
|
||||
|
||||
### 10.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
|
||||
### 10.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
|
||||
|
||||
#### 10.1.1. <a name='GestiondelaclservantlIDspend_recover'></a>Gestion de la clé servant à l'ID `spend_recover`
|
||||
#### 10.1.1. <a name='GestiondelaclservantlIDspend_recover'></a>Gestion de la clé servant à l'ID `spend_recover`
|
||||
|
||||
Les clés font 256 bits.
|
||||
|
||||
@ -187,7 +191,7 @@ Dans l'ordre on réalise donc les opérations suivantes donc :
|
||||
5. Chiffrement AES de `Part2`.
|
||||
6. Sharding de `Part2Enc`.
|
||||
|
||||
#### 10.1.2. <a name='BackupdePart2Enc'></a>Backup de `Part2Enc`
|
||||
#### 10.1.2. <a name='BackupdePart2Enc'></a>Backup de `Part2Enc`
|
||||
|
||||
Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant l'`ItemProcess` choisi.
|
||||
|
||||
@ -206,13 +210,33 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
|
||||
6.3. Recomposition de `Part2Enc` et déchiffrement par le mot de passe
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
|
||||
## 11. <a name='Clsdervocationrevoke'></a>Clés de révocation (`revoke`)
|
||||
#### 10.1.3. <a name='Onboarding-1'></a>Onboarding
|
||||
|
||||
### 10.2. <a name='ItemMembercompltdeschampsduprocessslectionnetmisejourdelalistedesmembresduprocess'></a>ItemMember complété des champs du process sélectionné et mise à jour de la liste des membres du process
|
||||
|
||||
Le role `member` de l'`itemProcess` sélectionné contient un `Item` avec des `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` contenant chacun une `render_template_list` dont le premier élément du tableau est le formulaire de création de l'identité pour champs concernés (publiques ou confidentiels ou privés).
|
||||
|
||||
Ces formulaires permettront de créé les champs attendus par `condition_attribute_encryption_list` dans le role `Member` de l'`ItemProcess` sélectionné, dans l`ItemMember` de l'utilisateur (champs dans `data` des attribut `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` correpsondants).
|
||||
|
||||
Une fois l'`ItemMember` complété, il est ajouté à la liste des membres pour créer un nouveau `RequestPcd` envoyé pour mises à jours aux managers du rôle `Member` du `ItemProcess` sélectionné via un `RequestPrdUpdate`.
|
||||
|
||||
### 10.3. <a name='ItemProcesscompltdeladdressSPdelutilisateuretmisejourdelalistedesversionduprocess'></a>ItemProcess complété de l'address SP de l'utilisateur et mise à jour de la liste des version du process
|
||||
|
||||
Pour le ou les roles sélectionnés, l'attribut `request_prd_sp_address_list` de `condition_prd_address_set_list` est complété par l'adresse SP de l'utilisateur.
|
||||
|
||||
Une fois l'`ItemProcess` complété, il est ajouté à la liste des membres pour créer un nouveau `RequestPcd` envoyé pour mises à jours aux managers du rôle `Process` du `ItemProcess` sélectionné via un `RequestPrdUpdate`.
|
||||
|
||||
### Réception des RequestPcd et RequestPrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné)
|
||||
|
||||
Envoi d'un `RequestPrdList` pour chaque membre de chaque rôle du process sélectionné.
|
||||
|
||||
## 11. <a name='Clsdervocationrevoke'></a>Clés de révocation (`revoke`)
|
||||
|
||||
Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif.
|
||||
|
||||
L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `RequestPrdList` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface).
|
||||
|
||||
## 12. <a name='Clsdethirdparties'></a>Clés de third parties
|
||||
## 12. <a name='Clsdethirdparties'></a>Clés de third parties
|
||||
|
||||
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 `ItemProcess`. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
|
||||
|
||||
@ -220,7 +244,7 @@ Les clés privées associées sont générées lors de l'update d'un membre, à
|
||||
|
||||
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 `RequestPrd` concernés.
|
||||
|
||||
## 13. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
|
||||
## 13. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
|
||||
|
||||
Pour recrééer sa clé privée et envoyer un `RequestPrdList` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes :
|
||||
|
||||
@ -241,8 +265,8 @@ Puis depuis la liste des membres du process, pour chacun des membres :
|
||||
6.4. Concaténation de `Part1` et `Part2`
|
||||
7. Réception des flux PCD et PRDResponse des gestionnaires des membres
|
||||
|
||||
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
## 14. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 15. <a name='Todo'></a>Todo
|
||||
## 15. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user