Bug: change_owner_key autorise des identités Unconfirmed, Unvalidated et Revoked

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é.