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 :
1- L’application cliente a besoin d’informations du propriétaire de ressource.
2- Cette dernière interroge le serveur d’autorisation qui demande au propriétaire de ressource son approbation.
3- 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.
Lisez la suite sur Bloguable. Posté avec SteemPress