f9fe0e3419
**Motivations:** - Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications). - Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login. - Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com. - Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture. **Root causes:** - Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console. - Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services. - Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data. **Correctifs:** - Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton). - Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ». - Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre). - UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER. **Evolutions:** - Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications. - Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid. - UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel. - Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build. - website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com. - fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation). **Pages affectées:** - website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README). - userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese). - website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
110 lines
4.8 KiB
Markdown
110 lines
4.8 KiB
Markdown
# Complément de specs – Champs obligatoires et attributs CNIL
|
||
|
||
**Author:** Équipe 4NK
|
||
**Date:** 2026-01-26
|
||
|
||
Référence : `specs.md` (Contrat, Champ, MessageBase, DataJson).
|
||
|
||
---
|
||
|
||
## 1. Champs obligatoires des contrats (rôles)
|
||
|
||
Tous les contrats ont **certains** des champs (objets `Champ`) suivants. Chaque type correspond à un **rôle** / usage métier précis ; un contrat donné en possède un sous-ensemble selon le contexte.
|
||
|
||
| Type de Champ (rôle) | Description |
|
||
|----------------------|-------------|
|
||
| Partage avec les institutions | Partage de données avec des institutions |
|
||
| Messages au RSSI | Messages au RSSI de la société responsable du service |
|
||
| Messages au Correspondant CNIL | Messages au Correspondant CNIL de la société responsable du service |
|
||
| Messages au Responsable cybersécurité | Messages au Responsable cybersécurité de la société responsable du service |
|
||
| Messages de support infogérant | Support infogérant (peut inclure membre du miner pour clés API) |
|
||
| Messages de support administrateur système | Support admin système du service |
|
||
| Messages de support niveau 1 | Support N1 du service |
|
||
| Messages de support niveau 2 | Support N2 du service |
|
||
| Messages de support niveau 3 | Support N3 du service |
|
||
| **Validation (contrat)** | Validation du contrat ; validateurs du contrat (`contrat.validateurs.membres_du_role`) |
|
||
| **Validation du login** | Validation du login ; validateurs de l'action login (`action.validateurs_action.membres_du_role`) |
|
||
|
||
- Les `Champ` sont des `MessageAValider` avec `contrats_parents_uuid` (au moins 1).
|
||
- L’identification du type / rôle (partage, RSSI, CNIL, cybersécurité, support N1/N2/N3, validation, validation login, etc.) se fait via `types.types_names_chiffres` / `types_uuid` ou via des métadonnées dans `datajson`, selon les conventions du catalogue.
|
||
|
||
---
|
||
|
||
## 2. Attributs CNIL dans `datajson`
|
||
|
||
Pour les objets concernés (ex. contrats, champs), la partie **`datajson`** peut contenir des attributs **CNIL** supplémentaires. Ceux-ci sont optionnels au sens du schéma de base mais requis pour la conformité CNIL lorsqu’ils s’appliquent.
|
||
|
||
### 2.1 Usage et partage avec les tiers
|
||
|
||
- **Raisons de l’usage avec les tiers et description du tiers**
|
||
Tableau de couples `[raisons, tiers]` : pour chaque usage avec un tiers, les raisons et la description du tiers.
|
||
- **Raisons du partage avec les tiers et description du tiers**
|
||
Tableau de couples `[raisons, tiers]` : pour chaque partage avec un tiers, les raisons et la description du tiers.
|
||
|
||
Structure suggérée (à préciser dans le catalogue) :
|
||
|
||
```json
|
||
{
|
||
"raisons_usage_tiers": [
|
||
{ "raisons": ["…"], "tiers": "…" }
|
||
],
|
||
"raisons_partage_tiers": [
|
||
{ "raisons": ["…"], "tiers": "…" }
|
||
]
|
||
}
|
||
```
|
||
|
||
### 2.2 Conditions de conservation
|
||
|
||
- **Conditions de conservation**
|
||
Objet JSON contenant **au moins** le **délai d’expiration** (durée de conservation des données).
|
||
|
||
Exemple :
|
||
|
||
```json
|
||
{
|
||
"conditions_conservation": {
|
||
"delai_expiration": "P1Y",
|
||
"unite": "annees"
|
||
}
|
||
}
|
||
```
|
||
|
||
(`P1Y` : ISO 8601 duration, ou équivalent selon le catalogue.)
|
||
|
||
---
|
||
|
||
## 3. Synthèse
|
||
|
||
| Domaine | Contenu |
|
||
|--------|---------|
|
||
| Champs obligatoires (rôles) | Sous-ensemble des 11 types : partage, RSSI, CNIL, cybersécurité, support infogérant / admin / N1 / N2 / N3, **validation (contrat)**, **validation du login** |
|
||
| `datajson` CNIL | `raisons_usage_tiers`, `raisons_partage_tiers` (tableaux [raisons, tiers]) ; `conditions_conservation` (JSON avec au moins `delai_expiration`) |
|
||
|
||
---
|
||
|
||
## 4. Types (userwallet)
|
||
|
||
- **`DataJson`** : champs optionnels `raisons_usage_tiers`, `raisons_partage_tiers` (`RaisonsTiers[]`), `conditions_conservation` (`ConditionsConservation`), `membre_miner_uuid` (référence au membre du miner pour les champs infogérant). Voir `src/types/message.ts`.
|
||
|
||
### 4.1 Membre du miner dans les champs infogérant
|
||
|
||
Pour les champs de type "Messages de support infogérant", le `datajson` peut contenir un champ `membre_miner_uuid` qui référence un membre du miner.
|
||
|
||
**Caractéristiques du membre du miner :**
|
||
- Membre unique (sans 2FA, seul)
|
||
- Créé spécifiquement pour le miner
|
||
- Fait office de backend pour les clés API qu'il recevra et devra gérer (fonctionnalité à implémenter ultérieurement)
|
||
|
||
**Usage :**
|
||
- Le champ `membre_miner_uuid` est optionnel dans `DataJson`
|
||
- Il doit référencer un `Membre` valide avec `types_names_chiffres` incluant "membre"
|
||
- Ce membre sera utilisé pour la gestion des clés API du miner (à documenter et implémenter ultérieurement)
|
||
|
||
## 5. Références
|
||
|
||
- `userwallet/docs/specs.md` (MessageBase, DataJson, Champ, Contrat)
|
||
- `userwallet/docs/specs-champs-obligatoires-cnil.md` (ce document)
|
||
- `userwallet/src/types/message.ts` (DataJson, RaisonsTiers, ConditionsConservation)
|
||
- `userwallet/src/types/contract.ts` (Champ)
|