anchorage_layer_simple/userwallet/docs/specs-champs-obligatoires-cnil.md
ncantu f9fe0e3419 Website-skeleton partie connectée, contrat en dur, navigate-login; UserWallet pairing-relay-status, redirect; website-data, proxy data, cryptographie, fixKnowledge
**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.
2026-01-29 00:55:58 +01:00

4.8 KiB
Raw Permalink Blame History

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).
  • Lidentification 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 lorsquils sappliquent.

2.1 Usage et partage avec les tiers

  • Raisons de lusage 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) :

{
  "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 dexpiration (durée de conservation des données).

Exemple :

{
  "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)