Il y a quelques jours, Microsoft a présenté publiquement sa première itération de « ION ». Malgré un grand relais dans les médias spécialisés et malgré une forte adhérence à bitcoin, la communauté a finalement peu commenté cette annonce. Pourtant, avec des thèmes comme la décentralisation de l’identité et bitcoin, on devrait justement en parler beaucoup plus.
La faute à un communiqué (ici) réalisé par des techniciens à destinations d’autres techniciens et de la méconnaissance du fonctionnement actuel du web.
Avant de vous parler de ION, j’aborderai les notions de fédération d’identité et d’identité décentralisée.
La fédération d'identité
Hormis les développeurs d’applications, il est peu probable que la notion de fédération d’identité vous évoque grand chose… Et pourtant, vous en utilisez tous les jours en navigant sur le web.
N’avez-vous jamais été confronté à ce type d’écran en vous connectant à un site web ?
Il vous offre la possibilité d’accéder à votre application à l’aide de votre compte Facebook, Google ou encore Steemconnect (portail facilitant l’utilisation du réseau social steem).
Si les développeurs ont pris l’habitude d’utiliser ce type d’écran de connexion, ce n’est pas par paresse, mais parce que cela offre plusieurs avantages :
- L’utilisateur n’a pas à se rappeler d’un nouveau mot de passe
- L’application n’a pas gérer le mot de passe
- L’application peut récupérer des informations (comme le nom et prénom inscrit sur facebook)
Pour le dernier point, l’utilisateur doit autoriser explicitement l’application à avoir accès aux données.
OAUTH2.0 et plus particulièrement OpenID Connect sont des protocoles permettant la fédération de l’identité. Ils sont massivement utilisés sur le web et pour l’anecdote, France Connect l’utilise afin de faciliter les démarches administratives des citoyens Français.
- OAUTH2.0 décrit plusieurs acteurs :
- Le propriétaire des ressource (l’utilisateur)
- L’application cliente (page web, application serveur, application mobile etc…)
- Le serveur de ressource (celui qui détient les ressources)
- Le serveur d’autorisation (qui peut être également le serveur de ressource)
Dans cette architecture :
- l’application cliente a besoin d’informations du propriétaire de ressource.
- Cette dernière interroge le serveur d’autorisation qui demande au propriétaire de ressource son approbation.
- L’application cliente dispose d’un jeton d’accès lui permettant de récupérer les informations de l’utilisateur auprès du serveur de ressource.
Vous comprenez qu’ici en théorie, c’est bien l’utilisateur qui est maître de ces données.
L'identité décentralisée
Si le concept de fédération d’identité répond aux besoins du web actuel, il a cependant des limitations pour lequel un individu ne devrait pas être satisfait.
En effet, l’utilisateur est bien content de pouvoir se connecter à un nouveau service sans avoir à se créer un nouveau compte.
L’individu se rend bien compte qu’il n’est pas maître de ses données en utilisant facebook comme fournisseur d’identité et de donnée.
C’est en se sens qu’un groupe de travail a cherché à développer un outil permettant à un individu d’être autonome sur ses propres données (Self-Sovereign Identity). L’idée est bien de réunir le besoin de l’utilisateur et de l’individu en leur (re) donnant la main sur ses propres données par la suppression d’une l’autorité centrale.
Pour celles et ceux qui sont familier des cryptocurrencies et de la blockchain, ce concept doit vous rappeler quelque chose.
Le second avantage de posséder son identité est que cela ouvre la voie à la suppression du mot de passe qui est particulièrement critiqué. Une nouvelle chose que les habitués du bitcoin connaissent déjà avec (notamment) ECDSA et BIP39.
L’identité décentralisée s’appuie sur plusieurs acteurs/composants :
- Decentralized Identity (l’identité décentralisée): Possédée par l’individu
- Identity Hub: Composant stockant les données utilisateurs
- Un registre distribué: Stockant toutes les modifications d’une identité
- Universal resolver: Permet la découverte des identités ainsi que l’interconnexion entre les différents Identity Hub.
L'identité décentralisée pour stocker nos actifs
Un des enjeux de l‘identité décentralisée et fournir un standard pour sécuriser le stockage et l’accès à nos actifs (nos données). On peut aisément imaginer l’utiliser pour y stocker sa carte d’identité, son permis de conduire, ses derniers billets de trains, sa pratique sportive etc…
Etre souverain de ses actifs nous donne la possibilité d’autoriser ou de révoquer l’accès à chacune de ces informations.
A l’heure du RGPD, cela fait d’autant plus de sens même s’il faudra envisager une réglementation différente sur la marchandisation de ces données que cela risque d’engendrer.
La Decentralized Identity Foundation
La Decentralized Identity Foundation est un groupe de travail consistant à définir les standards et le spécification d’un système d’identité décentralisée.
Ce groupe est constitué de gros acteurs comme Microsoft, IBM, Masterdcard, RSA, mais également de plus petits acteurs comme ConsenSys, Ethereum Alliance et CIVIC.
Voici toutes les sources à mettre en évidence :
- Le site web : https://identity.foundation/
- Le répertoire Github : https://github.com/decentralized-identity
- Le blog de la DIF : https://medium.com/@decentralized.identity
ION - la proposition de Microsoft
ION (Identity Overlay Network) est la proposition d’identité décentralisée de Microsoft. Elle s’appuie sur les standards de la DIF et consiste à un réseau de niveau 2 s’appuyant sur la blockchain de bitcoin (réseau de niveau 1) afin d’ancrer chaque modification dans le registre distribué et non altérable.
Plus précisément, il s’agit d’une implémentation du protocole sidetree (repo GitHub) qui a pour objectif d’être compatible avec toutes les blockchains et registre distribué (comme Hyperledger).
Bien conscient des performances faibles du réseau bitcoin, Sidetree améliore nettement cet aspect là en faisant des lots modificatifs dans une même transaction bitcoin.
En l’état, bitcoin (testnet) est utilisé comme infrastructure à clef publique et Microsoft espère pouvoir prochainement sur le réseau principal (mainnet).
Autre point fort, ION utilise IPFS (stockage versionné et distribué) pour synchroniser les hub d’identity ION.
Bien évidemment, ION est opensource (Apache2) et Microsoft invite la communauté de développeur à contribuer au codes (accessible ici). D’autre part et bien que ION soit loin d’être finalisé, Microsoft l’a documenté (ici) et il est possible d’avoir des exemples de code fonctionnels comme une extension chrome (pour créer son identité décentralisée), un site web utilisant l’identification décentralisée et un hub d’identité.