En Duniter v1 (je suis même pas sûr de ce que j’écris) :
Le délai de validation d’identité après demande d’adhésion est de 2 mois. Passé ce délai, la demande sort de la piscine et le même pseudo ou clé peut être utilisé
Le délai de révocation automatique d’identité après expiration d’adhésion est de 1 an. Le pseudo et la clé restent réservés à jamais.
En Duniter v2, on a discuté d’ajouter le statut “révoqué” à l’identité :
Comme c’était facile à faire et dans le sens de cette refacto, je l’ai fait, et en profite pour détailler certaines options possibles :
après expiration de la demande, veut-on rendre le pseudo à nouveau disponible ? les clés à nouveau disponible ?
après révocation automatique, souhaite-t-on conserver les identités révoquées indéfiniment ? ou libérer les clés après un délai donné ?
Veut-on que les utilisateurs puissent se fier au pseudo ? Ça me semble risqué, car on peut ne pas faire attention à du typosquatting comme JeanSebasteinDu33 à la place de JeanSebastienDu33. Les clients devront de toute façon ajouter des mécanismes et de l’UX pour éviter les problèmes liés au pseudo.
En même temps si on veut éviter qu’un usurpateur utilise notre pseudo il faut un blocage du pseudo pour au moins des années.
En cas de révocation automatique, il n’y a pas forcément eu de vol d’identifiants. Le pseudo pourrait donc rester réservé pour la clé publique en question par exemple pendant un an. La personne peut donc retenter plus tard sans devoir changer de pseudo si elle n’a pas perdu ses identifiants, ou un an plus tard sinon.
[EDIT] Le propriétaire d’une identité non-membre pourrait tout de même vouloir révoquer son identité pour bloquer son pseudo plus longtemps en cas de fuite d’identifiants, et s’assurer que les certifs accumulées ne puissent servir l’éventuel pirate. [/EDIT]
En cas de révocation manuelle, on ne peut pas se fier à la clé publique donc sauf mécanisme compliqué il n’y a pas le choix que de bloquer le pseudo pour par exemple 10 ans (ou sans expiration et on fait le ménage manuellement si besoin).
A priori je ne vois pas la nécessité ni l’intérêt de conserver les vieilles identités.
Il n’y a pas de réservation en piscine, plusieurs identités peuvent avancer en concurrence sur un pseudo ou une clé. L’identité V1 est identifiée par le trio : pseudo, clé publique, blockstamp.
Pour la révocation automatique, c’est correct.
Oui pour le pseudo, afin d’éviter le squat et d’accumuler dans le storage des données-déchets. Pareil pour la clé publique (bien que le squat n’ait pas vraiment de sens).
Je dirais comme tuxmain : pas indéfiniment, mais longtemps. Pourquoi pas 10 ans.
Oui voilà : le pseudo doit participer, mais n’est pas suffisant. Aux applications clients d’aider leurs utilisateurs sur ce plan-là.
Ok, donc j’ai maintenant quatre constantes dans la pallet identity :
/// Period during which the owner can confirm the new identity.
// something like 2 days but this should be done quickly as the first certifier is helping
#[pallet::constant]
type ConfirmPeriod: Get<Self::BlockNumber>;
/// Period before which the identity has to be validated (become member).
// this is the 2 month period in v1
#[pallet::constant]
type ValidationPeriod: Get<Self::BlockNumber>;
/// Period before which an identity who lost membership is automatically revoked.
// this is the 1 year period in v1
#[pallet::constant]
type AutorevocationPeriod: Get<Self::BlockNumber>;
/// Period after which a revoked identity is removed and the keys are freed.
#[pallet::constant]
type DeletionPeriod: Get<Self::BlockNumber>;
ConfirmPeriod de 2 jours
ValidationPeriod de 2 mois
AutorevocationPeriod de 1 an
DeletionPeriod à choisir, on pourrait mettre 10 ans ou juste enlever cette étape de nettoyage et le faire de manière manuelle