Réflexions sur un système d’authentification pour bénévoles

Les bénévoles qui représentent une institution ne sont pas toujours identifiables avec certitude. Pour éviter les impostures et les incompréhension, j’ai imaginé un système d’authentification simple et fiable.

Je l’avais appelé EREN-ID, parce que je travaille à temps partiel pour l’EREN (Église réformée évangélique du canton de Neuchâtel). Mais ces tests ont été faits bénévolement, à titre personnel, et n’engagent en rien mon employeur.

Il y a une année, j’ai rapidement réalisé un prototype fonctionnel. Comme ce projet n’a pas rencontré le succès, j’ai décidé de rendre public le dépôt GitHub EREN-ID.

Problématique

Des personnes peuvent être déléguées d’une institution ou la représenter dans être facilement identifiables. C’est par exemple le cas de celles et ceux qui effectuent des visites bénévoles dans des maisons de retraite.

Ces bénévoles légitimes ne disposent pas toujours d’une adresse mail de l’institution. Elles ne sont pas nécessairement listées dans un annuaire public (et elles peuvent souhaiter ne pas l’être). Elle ne peuvent donc pas prouver à quel titre elles «travaillent» pour cette organisation.

Certes, il est possible de disposer d’un courrier qui atteste d’une mission, d’une carte de visite, d’un badge, etc. Mais ces moyens de vérification ne sont pas très sûrs. Par exemple, une lettre peut attester de mon bénévolat il y a 6 mois, mais est-ce je suis toujours un·e bénévole reconnue aujourd’hui?

Un système de vérification immédiat, en ligne, m’apparaît à la fois plus simple et plus sûr.

Pistes de réponse

Pour authentifier une personne, je propose:

  • un adresse unique sur un nom de domaine précis, par exemple https://id.mondomaine.exemple/abcde/
  • le nom complet de cette personne
  • sa ou ses fonctions actuelles
  • la date de fin de fonction (si elle est prévisible)

Je pense qu’il vaut la peine d’ajouter:

  • un photo (pour éviter d’avoir à «prouver son nom» par une pièce d’identité, sinon je peux me faire passer pour Jean-François Michu)
  • le mail utilisé (si son nom de domaine n’est pas celui de l’organisation)
  • peut-être le numéro téléphone utilisé

Comme je ne souhaite pas lister les bénévoles publiquement, le site n’est pas référencé et les URL des pages ne peuvent pas être devinées facilement.

J’ai ajouté un code QR avec l’adresse de la page dont j’explique l’utilité plus bas.

J’avais fait un exemple: https://eren-id.netlify.app/qwertz/.

Utilisation par les bénévoles

Avec cette simple page, il est possible:

  • de l’imprimer et de la présenter ainsi (il suffit d’un scan du QR code pour s’assurer de sa validité à ce moment précis)
  • de ne garder que le QR code et inviter mes interlocuteurs et interlocutrices à le scanner
  • dicter l’adresse pour vérification
  • ouvrir/réactualiser la page sur mon téléphone, devant la personne à qui je parle
  • envoyer un lien vers ma page par SMS, messagerie instantanée ou mail
  • dans un mail (qui n’est donc pas envoyé avec le nom de domaine de l’institution), je peux ajouter un lien vers cette page qui «valide» mon adresse

Nous ne sommes pas dans la haute sécurité. Dans un tel contexte, ce que je dis ci-dessus ne serait pas vraiment adéquat.

Mais dans un monde de bénévolat institutionnel, la fiabilité de l’authentification me paraît suffisante. Et surtout un vrai plus par rapport à la situation actuelle.

Choix techniques

Le site est généré avec Hugo. Il est purement statique pour minimiser les risques de piratage.

Actuellement, le «slug» («qwertz» dans l’exemple précédent), n’est pas généré automatiquement. Je l’ai choisi à 6 caractères, mais on pourrait créer une chaîne aléatoire bien plus longue pour éviter de le trouver «au hasard».

L’image est redimensionnée automatiquement. Le QR code est généré automatiquement. La date d’expiration est déjà implémentée.

Il reste à choisir une politique pour les fiches expirées:

  • suppression (et recréation avec un autre slug en cas de besoin)
  • conservation en ligne mais barrée par une mention «expiré»
  • conservation hors ligne pour la réactiver avec le même «slug» en cas de besoin

Suite(?)

Voilà l’état de ma réflexion. Je suis ouvert à toute proposition. Peut-être que j’ai oublié quelque chose, peut-être que dois mieux expliquer certains choix, etc.

Merci de ne pas utiliser les sources du dépôt pour autre chose que des tests. Il faudrait d’abord corriger du code de Hugo. Mais je suis prêt à le faire, puis à verser le dépôt en dans le domaine public (licence libre CC0).