Je vais le traduire aujourd'hui sauf si David me dit qu'il l'a déjà fait.
"Il n'y a aucune notion de certification m'assurant que cette adresse correspond à une personne donnée [...] cette problématique n'est pas résolue par OpenID (du moins pour l'instant)."
Pour y arriver, il faudrait une vérification d'identité ET faire confiance au fournisseur OpenID dans cette vérification d'identité. Pour en arriver là, le plus simple est de jeter OpenID à la poubelle et faire une bonne vieille authentification par certificat :D
"OAuth permet uniquement de gérer plus finement les accès à ses données sur un service."
Wo l'aut', il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth :-)
@NiKo : mon niveau d'anglais m'interdit toute forme de publication sérieuse dans cette langue malheureusement... (et puis le but de ce blog c'était aussi de pouvoir communiquer en français sur ce genre de problématiques).
@Karl Dubost : je ne l'ai pas traduit, par contre c'est vrai qu'il y a quelques inexactitudes concernant la sécurité et OAuth, comme nous en discutons sur http://lists.w3.org/Archives/Public/public-social-web-talk/ (mais tu dois être au courant ;-)).
Ma conclusion c'est qu'il y a en effet un gain au niveau sécurité en théorie mais dans les faits ce n'est malheureusement pas le cas (en tout cas pour l'instant).
@Damien B : ah, tes commentaires me manquaient !
> il faudrait une vérification d'identité ET faire confiance au fournisseur OpenID dans cette vérification d'identité
Tout à fait, après peut-on faire confiance à des fournisseurs comme l'état ou les communes par exemple ? (ça va dépendre des pays, etc bien sûr)
La méthode des certificats est intéressante (et je suis de près ce qui se fait avec FOAF+SSL) mais ça reste très geek. Est-ce que les clés PGP ont une chance d'arriver à percer, je ne pense pas et c'est un peu la même chose là... enfin ça dépend de l'évolution des navigateurs en parallèle aussi.
> il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth
En effet, ça dépend de l'implémentation que l'on en fait, d'où le nombre d'extensions qui fleurissent pour spécifier quelles ressources sont concernées, etc. Note que c'est un peu mieux précisé dans la spec IETF:
http://oauth.googlecode.com/svn/spec/core/IETF/drafts/1/draft-hammer-oauth-00.txt
o The Service Provider presents to the User information about the
Consumer requesting access (as registered by the Consumer
Developer). The information includes the duration of the access
and the Protected Resources provided. The information MAY include
other details specific to the Service Provider.
Mais ça reste bien flou :-)
Merci beaucoup David, je vais mettre à jour mon dossier sur l'identité numérique ;-) .
Par contre, je vois mal l'état ou les communes comme Provider ou même une initiative permettant de certifier une identité… Une bonne alternative serait les FAI, qui eux ont au moins la certitude qu'on est la personne qu'on prétend être (ils ont des coordonnées bancaires et postales quand même). Mais ça pose d'autres problématiques…
Par contre pour OAuth, en quoi ce n'est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu'ils vont utiliser ?
Et voila, tu peux en faire ce que tu veux :)
http://www.la-grange.net/2009/01/26/openid-oauth
@David
"Est-ce que les clés PGP ont une chance d'arriver à percer"
Non, c'est du décentralisé :)
"Note que c'est un peu mieux précisé dans la spec IETF"
"draft-00.txt", ah ouais, ça fouette :) "The information MAY include other details " : oh, c'est précis comme une spécification de µFormat.
@Neovov : oui les deux autres entités que je vois qui pourraient avoir un rôle à jouer sont les banques et les fai, mais ça pose d'autres problèmes et je ne vois pas pourquoi l'état, qui nous représente déjà, ne pourrait pas certifier notre statut de citoyen du net (en théorie en tout cas, après vu l'inertie c'est pas près d'arriver...).
> Par contre pour OAuth, en quoi ce n'est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu'ils vont utiliser ?
Comme le soulignait Damien, la spec est très imprécise à ce niveau, le service provider peut faire ce qu'il veut : d'un gros bouton qui signifie "Donner toutes mes données en lecture/écriture à untel" à une gestion beaucoup plus fine par ressource. Bon en 1.0, tu n'as pas la possibilité non plus de spécifier en tant que consumer à quelles ressources est-ce que tu veux accéder (du moins de manière standard) ce qui est clairement limitant...
Maintenant sur la sécurité, il y a du bon et du moins bon. En fait, ça dépend pas mal du niveau des utilisateurs de ton appli. S'ils savent détecter un hameçonnage (phishing), alors OAuth est vraiment mieux. Sinon ça laisse toujours ta porte grande ouverte (comme l'était la demande de login/pass) mais tes fenêtre sont mieux renforcées (youpi).
@karl Dubost : merci ! Bon je sais pas quoi en faire du coup :p
Soit je la met à la suite du billet actuel, soit je fais un lien vers la-grange, ce que j'ai commencé à faire, mais il va falloir nettoyer un poil plus le html (au moins le title et les liens).
@Damien B : En même temps il faut reconnaître que c'est pas évident à spécifier non plus si tu veux rester assez générique.</avocatdudiable>
De mon point de vue l'avantage qu'apporte la "méthode" d'authentification Oauth en terme de sécurité est qu'elle certifie à l'utilisateur que ses identifiants permettant de se connecter au service auquel il souhaite accéder ne pourront pas être interceptés par l'application tierce à partir de laquelle il agit.
Tu veux pas donner ton mot de passe et ton login à un service tiers mais tu veux bien faire certifier ton identité sur le net par l'état... J'ai l'impression que cela va donner lieu à divers vagues problèmes sur la vie privée mais bon.
merci encore pour tous ces postes qui me rassure.
Twitter utilise exclusivement OAuth pour ses API depuis le 31 août 2010.
https://dev.twitter.com/docs/auth
=)
Tu devrais nous écrire tout ça... en anglais.
Parce que c'est juste essentiel ce que tu dis là.