# UserWallet iframe — cloisonnement des clés et du chiffrement

**Objectif**

Garantir qu’aucune clé secrète ne quitte l’iframe UserWallet et qu’aucune opération de signature ou de chiffrement n’est effectuée en dehors du domaine de l’iframe.

**Règles**

1. **Clés**
   - Seules les **clés publiques** peuvent sortir de l’iframe (via postMessage vers le parent).
   - Les clés privées (`privateKey`, `cle_privee`) ne doivent jamais être envoyées au parent ni à un autre domaine.

2. **Crypto**
   - Toutes les opérations de **signature**, **chiffrement** et **déchiffrement** sont réalisées **uniquement dans l’iframe** (UserWallet).
   - Le parent (site intégrateur, ex. skeleton) ne doit **jamais** signer, chiffrer ni déchiffrer. Il peut uniquement **vérifier** des signatures à l’aide des clés publiques (ex. `verifyLoginProof`).

**Implémentation**

- **iframeChannel** : `sendToChannel` appelle `assertNoSecretsInChannelPayload` avant `postMessage`. Toute présence de `privateKey` ou `cle_privee` dans le payload (récursif) lève une erreur ; le message n’est pas envoyé.
- **iframe.ts** : `sendMessageToParent` appelle aussi `assertNoSecretsInChannelPayload` sur le payload avant `postMessage`. Tous les envois vers le parent passent par cette vérification.
- **Messages envoyés au parent** : `auth-response` (signature, publicKey, message), `login-proof` (challenge, signatures avec `cle_publique`), `error`, `service-status`, `pairing-relay-status` (pairingSatisfied, relayOk). Aucun de ces messages ne contient de clé secrète.
- **Messages reçus du parent** : `auth-request`, `contract`. Le contrat peut contenir des `cle_publique` de service (validateurs) ; ce sont des clés publiques. Le parent n’envoie jamais de clé privée.
- **Parent (intégrateur)** : Ne doit jamais signer, chiffrer ni déchiffrer. Il peut uniquement **vérifier** des signatures (ex. `verifyLoginProof` avec clés publiques). Ex. skeleton : vérification uniquement, pas de crypto secrète.

**Contrôles**

- Avant tout envoi vers le parent : vérification systématique des payloads pour `privateKey` et `cle_privee`.
- Aucun usage de `privateKey` / `cle_privee` dans les types de messages définis pour le canal iframe (`AuthResponseMessage`, `LoginProofMessage`, etc.).

**Pages affectées**

- `userwallet/src/utils/iframeChannel.ts` (assertion, `sendToChannel`)
- `userwallet/src/utils/iframe.ts` (assertion, `sendMessageToParent`)
- `userwallet/features/userwallet-iframe-key-isolation.md` (ce document)