Bonjour Éloi,
Je ne connais pas de méthode « clé-en-main » mais le W3C (World Wide Web Consortium) a plusieurs spécifications en cours de rédaction (did, verifiable credentials, etc.) qui pourraient peut-être jeter les bases d’un système d’authentification unique (SSO) différent qui rendrait le chiffrement de bout en bout (E2EE) plus simple à mettre en oeuvre.
l’écosystème - Ces specs sont aujourd’hui beaucoup promues/regardées/implémentées par les communautés blockchain et aussi les États. On peut facilement les regrouper sous le terme self-sovereign identity. Un exemple d’un projet avancé par exemple est sovrin qui se base sur hyperledger indy, une « blockchain permissioned », c’est à dire géré par un nombre défini d’acteurs.
mes réserves - Ma réserve principale par rapport au travail d’implémentation précédent se situe au niveau de la blockchain, permissioned ou public : dans tous les cas, c’est une base de donnée distribuée qui définit une seule vérité unique. Cette seule et unique vérité est gérée soit par l’argent et des règles froides (pensez aux gens qui se font voler leurs NFTs sans recours possible par exemple) ou par une seule organisation qui décide de qui a le droit de gérer la base de données (dans le cas des permissioned blockchains). Je trouve que cette vérité unique donne beaucoup trop de pouvoir à l’entité qui la définie, et qui plus est, n’est pas nécessaire ni même souhaitable (je tiens à mon pseudonymat qui est une identité parallèle).
application à l’E2EE - Si on repart de la spec du W3C, il n’est pas nécessaire d’avoir une blockchain/ledger pour bénéficier de certaines propriétés/avantages de DID, et ce n’est pas dit que c’est la vision blockchain/ledger qui l’emportera. Pour notre problème de E2EE & SSO, il y a un certains nombre de propositions qui pourraient même être intéressantes.
did est flexible - D’abord pour se convaincre de la flexibilité du protocole, il y a plein de « méthodes » d’authentification envisagées, en plus de toutes les blockchains, comme via une paire de clef publique/privée (did:key), via Tor (did:onion), via des endpoints web (did:web), via ActivityPub (did:orb), etc. Quelques unes de ces méthodes sont implémentées et testables via l’outil/bibliothèque didkit. Dans notre cas, did:key est tout à fait suffisante pour imaginer avancer sur l’E2EE.
did en pratique - En pratique, il est prévu que les identités des usagers soient stockés dans un wallet logiciel sur leurs terminaux. Ces identités sont des fichiers JSON signés par l’utilisateur lui-même ou une autorité de confiance et des clés publiques/privées. On pourrait imaginer une primitive rendue accessible par ces wallets pour chiffrer/déchiffrer du contenu, en plus de l’auth. Un peu comme une extension des « trousseaux de clés » qu’on trouve sur nos OS aujourd’hui (eg. gnome-keyring sur Linux). Le projet DIDKit a un prototype Android nommé Credible sur le sujet. Mais aussi un outil CLI avec une procédure pas à pas pour prendre les concepts en main.
perte des identifiants - Se pose la question de la perte/casse/inaccessibilités des terminaux. Il y a une spec identity hub qui parle de ce problème, c’est pas encore bien clair pour moi son rôle. Si tu ne donnes pas les identifiants & clés, alors pas très utile, si tu les donnes, bye bye pour l’E2EE. Sinon, l’autre approche que j’ai cru comprendre, c’est que tes identités doivent pouvoir être facilement regénérables depuis les fournisseurs d’identité, mais clairement bye bye la E2EE ici… C’est peut-être là où il y a encore le plus de travail. On pourrait imaginer un service standardisé qui permettrait de stocker ses identifiants/clés chiffrés avec un mot de passe fort, et, au choix de l’utilisateur, d’avoir une copie de ces clés chiffrée avec un secret réparti entre les administrateur-ices de la plateforme (ou entre tes ami-es/famille), ce qui permettrait une « récupération » par un groupe d’humains.
intégration avec l’existant - Pour la question de l’intégration avec les technologies existantes, il y a une spec qui permet d’utiliser DID avec OpenID : Self-Issued OpenID Provider v2. Mais ça ne donne pas l’E2EE qui nécessite de reconcevoir largement les applications.
en conclusion - Je ne sais pas si DID est une bonne ou une mauvaise idée, mais c’est le seul projet que je connaisse qui propose de formaliser/standardiser une base qui pourrait servir pour de l’E2EE et du SSO.
