## Constat Le call runtime `identity.change_owner_key` n’applique actuellement aucun contrôle sur le statut de l’identité. En l’état, une identité peut changer sa clé propriétaire tant qu’elle existe encore en storage et que les autres vérifications passent, même si son statut est : - `Unconfirmed` - `Unvalidated` - `Revoked` Ce comportement est incohérent avec les règles métier attendues. ## Comportement attendu `change_owner_key` doit refuser les identités dont le statut est : - `Unconfirmed` - `Unvalidated` - `Revoked` Le call doit rester autorisé uniquement pour les identités dont le statut est : - `Member` - `NotMember` ## Comportement observé Le call `change_owner_key` vérifie actuellement : - que l’origine est la clé propriétaire actuelle, - que la nouvelle clé n’est pas déjà utilisée, - que la période minimale entre deux changements est respectée, - qu’on ne revient pas à l’ancienne clé, - que la signature de la nouvelle clé est valide. Mais il ne vérifie pas `idty_value.status`. ## Impact Cela permet de changer la clé propriétaire d’identités qui ne devraient pas être éligibles au changement de clé : - identités créées mais non confirmées, - identités confirmées mais non validées, - identités révoquées encore présentes en storage avant pruning. Cela peut produire des données incohérentes côté chaîne et compliquer l’interprétation côté indexeur. ## Exemple de cas observés Des entrées `changeOwnerKeys` ont été observées sur des identités non membres, notamment : - `0000010553-6dace-000001` en statut `Unconfirmed` - `Brian` en statut `Unvalidated` Même si un indexeur peut éventuellement remonter aussi des calls échoués, le problème de fond reste que le runtime autorise actuellement ces statuts. ## Cause probable Dans l’implémentation de `change_owner_key`, il n’y a pas de garde sur le statut de l’identité avant l’application du changement. À l’inverse, `revoke_identity` filtre déjà explicitement certains statuts, ce qui renforce l’incohérence actuelle. ## Proposition de correctif Ajouter un contrôle explicite dans `change_owner_key` : - `Unconfirmed` => refus - `Unvalidated` => refus - `Revoked` => refus - `Member` => autorisé - `NotMember` => autorisé ## Critères d’acceptation - Un appel `change_owner_key` sur une identité `Unconfirmed` échoue. - Un appel `change_owner_key` sur une identité `Unvalidated` échoue. - Un appel `change_owner_key` sur une identité `Revoked` échoue. - Un appel `change_owner_key` sur une identité `Member` continue de fonctionner. - Un appel `change_owner_key` sur une identité `NotMember` continue de fonctionner. - Des tests unitaires couvrent explicitement ces 5 cas. ## Notes d’implémentation Prévoir une erreur explicite de type métier, par exemple : - `CanNotChangeOwnerKeyOfUnconfirmed` - `CanNotChangeOwnerKeyOfUnvalidated` - `CanNotChangeOwnerKeyOfRevoked` ou une erreur générique unique si préféré.