Simplification de la machine à état des identités

Protocols DUBP
#1

Voyant sur le forum monnaie-libre que @elois aussi souhaiterait simplifier la machine à état des identités, je me permet de lancer les réflexions.

Pour rappel, historiquement, on a voulu représenter dans cette machine à état toute la complexité d’une adhésion « humaine » à une communauté. C’est à dire :

  • La personne se fait connaitre (publication de l’identité)
  • La personne déclare demander à adhérer (publication d’adhésion)
  • La personne se fait certifier
  • La personne souhaite quitter la communauté (publication d’une sortie de l’adhésion)
  • La personne souhaite révoquer son identité (révocation de l’identité)
  • La personne renouvelle son adhésion (renouvellement)
  • La personne abandonne son identité (non renouvellement)
  • La personne a disparue et on considère son identité exclue (non renouvellement au bout de 2 ans)

Aujourd’hui, a priori la machine à état est la suivante :

@startuml
[*] --> UIDPublished
UIDPublished --> [*]
UIDPublished --> UIDIsRevoked : UID is revoked
UIDPublished -> NotAMember 
NotAMember : Awaits5Certs
NotAMember : SendsMembership
NotAMember --> UIDIsRevoked : UID is revoked

NotAMember -> MembershipSent
MembershipSent : Awaits5Certs
MembershipSent --> [*]
MembershipSent --> UIDIsRevoked : UID is revoked

MembershipSent -> IsMember : Got 5 certs
IsMember : Has To renew before 1 year
IsMember : UIDIsWritten

IsMember -> NoMoreMember : Does not renew
IsMember -> NoMoreMember : Leaving
IsMember -> NoMoreMember : Missing 5 certs
IsMember --> UIDIsRevoked : UID is revoked

NoMoreMember : Has to renew before 2 year
NoMoreMember --> UIDIsRevoked : UID is revoked
NoMoreMember --> UIDIsRevoked : Does not renew before 2 years
@enduml

identity-state
identity-state1129×290 30.6 KB

Avec le recul, on voit que cette machine à état est trop complexe et aboutit à :

  • Des interfaces logicielles compliquées
  • Une compréhension du fonctionnement de l’adhésion laborieux à expliquer et à comprendre

Je pense qu’on pourrait aboutir aux mêmes fonctionnalités utilisateurs, en simplifiant a minima l’adhésion. L’utilisateur ne verrait quasiment pas la différence, tandis que cette simplification stabiliserait les logiciels et rendrait les interfaces plus claires :

@startuml
[*] --> UIDPublished
UIDPublished --> [*]
UIDPublished --> UIDIsRevoked : UID is revoked
UIDPublished : Awaits5Certs

UIDPublished -> IsMember : Got 5 certs
IsMember : Has To renew before 1 year
IsMember : UIDIsWritten

IsMember -> NoMoreMember : Does not renew
IsMember -> NoMoreMember : Missing 5 certs
IsMember --> UIDIsRevoked : UID is revoked

NoMoreMember : Has to renew before 2 year
NoMoreMember --> UIDIsRevoked : UID is revoked
NoMoreMember --> UIDIsRevoked : Does not renew before 2 years
@enduml

identity-state2
identity-state2757×290 21 KB

Qu’en pensez-vous ?

4 « J'aime »
#2

Le membership leave ne sert effectivement à rien dans les faits, la révocation ayant un effet immédiat.

Pour l’adhésion initiale, c’était plutôt une protection supplémentaire pour l’utilisateur : en cas d’erreur, malgré les certifications reçues, le propritétaire de l’identité aurait encore une chance d’empêcher son identité d’être inscrite en blockchain sans son consentement. C’est une sorte de double validation.

Il est possible de retirer cette partie si dans les faits les utilisateurs considèrent qu’à partir du moment où leur identité est créée c’est que déjà qu’ils veulent entrer, et qu’au pire des cas cela ne les gêne pas d’effectuer une révocation après coup.

2 « J'aime »
#3

Ben je pense que moins on fait de changement de protocole plus ce sera simple a implémenter, donc je préconise dans un 1er temps de supprimer l’état “exclu” pour le remplacer par révoqué, point. C’est facile a coder et ça simplifiera déjà énormément de choses :slight_smile:

#4

Tu peux préciser le scénario que tu décris ? Tu veux supprimer le membership out ou bien tu parles de la sortie au bout de un an ?

#5

Non je veut garder le Membership, et tout les documents actuels en fait. Juste supprimer le statut “exclu”. Ce qui veut dire qu’il n’y aura plus que 3 statuts :

  • identité en attente
  • identité membre
  • identité révoquée
#6

Ok. Je ne sais pas encore quoi en penser, mais je suis d’accord avec le principe énoncé plus haut “moins on fait de changements et plus ce sera simple à implémenter”. Surtout concernant Duniter TypeScript :smiley:

1 « J'aime »
#7

C’est pas forcément la partie la plus complexe du protocole à vrai dire. C’est d’ailleurs la seule partie qui me semblait avoir un sens (la seule où on perdait vraiment quelque chose avec le modèle que je proposais).

En effet, cette partie permet à ceux qui oublient de renouveler de juste avoir à renouveler, et non à recréer une identité à zéro.

Du coup je suis un peu perplexe, parce que ça ne simplifie presque rien par rapport aux problèmes que j’évoquais (la complexité des interfaces et la complexité des explications aux utilisateurs):thinking:

#8

J’ai modifié le post pour parler d’identité plutôt que de compte, puisque le compte associé à l’identité est toujours accessible si on a les identifiants.

Le statut “exclu” n’apparaît pas dans le schéma UML. Il faudrait l’ajouter s’il est l’enjeu d’un débat et peut être amené à disparaître.

My two cents.

#9

C’est le statut “NoMoreMember”

1 « J'aime »