J’ai l’impression qu’on a du mal à se détacher de l’idée 1 identité = 1 paire de clés. Il y a plein de manières de faire autrement :
- lier plusieurs paires de clés à une identité
- déléguer certains calls avec la pallet proxy
Ce que suggère la sous-toile forgeron telle que formulée actuellement est que les clés avec lesquelles les calls forgeron sont appelés doivent être les clés actuelles déclarées par l’identité (“owner_key”). Sauf que vu comme c’est implémenté actuellement, ça interdit de changer les clés d’un forgeron.
Petite prise de recul : les “session_keys” sont les clés du noeud, on recommande que ça ne soit pas aussi les clés de l’identité, mais la pallet authority_members permet de faire le lien entre l’identité forgeron (et donc ses clés) et les session_keys. On pourrait faire pareil pour l’adhésion forgeron.
L’analogie des clés est d’ailleurs bonne : on peut en faire un double. Si j’ai chez moi :
- un garage à vélo
- une maison
- un coffre fort
je peux distribuer un double des clés du garage à vélo à tous mes voisins, un double des clés de ma maison à quelques amis, et être le seul à avoir les clés de mon coffre fort. Ce n’est pas parce que ma maison est ouverte que j’y suis.
Tout ce qu’on demande aux gens c’est de faire attention aux clés qui ont les droits d’accès sur leur identité et leur appartenance forgeron pour éviter que quelqu’un de mal intentionné s’en empare et nuise au réseau en usurpant leur trousseau de clé. Et c’est le sens de la toile de confiance : on s’engage à être le seul à avoir accès à ses clés.
Donc si on s’aperçoit que c’est pratique d’avoir :
- les clés d’un portefeuille sur son téléphone sans mot de passe
- les clés de son identité sur son téléphone, protégées par un mot de passe
- les clés forgeron dans son keepass ou sur un support matériel “hardware wallet”
- les clés de session de son nœud validateur dans un conteneur sécurisé sur son serveur et nulle part ailleurs
alors il faut qu’on fasse en sorte que ces clés soient différentes.
Concrètement, voici à quoi pourrait ressembler un nouveau comportement :
- quand une identité fait une demande d’adhésion forgeron, elle déclare des clés forgeron
- à partir de ce moment, les clés de l’identité ne peuvent plus être utilisées pour les actions forgeron
- seules les clés forgeron permettent d’effectuer des actions forgeron
En fait, l’intuition de elois d’avoir des métadonnées d’adhésion était bonne, mais c’était les clés forgeron qu’il fallait donner, pas les session_keys.
Autre proposition d’implémentation plus simple :
- à l’adhésion forgeron, les clés de l’identité sont utilisées
- à tout moment un forgeron peut changer ses clés
- seules les nouvelles clés pourront effectuer des actions forgeron