Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.

index.html 17KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211
  1. <!doctype html>
  2. <html lang=fr>
  3. <head>
  4. <!-- Always define the charset before the title -->
  5. <meta charset=utf-8>
  6. <title>Les défauts d&#39;OpenID — Biologeek — David Larlet</title>
  7. <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  8. <meta name="viewport" content="width=device-width, initial-scale=1"/>
  9. <!-- Fake favicon, to avoid extra request to the server -->
  10. <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  11. <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  12. <link rel="manifest" href="/manifest.json">
  13. <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  14. <noscript>
  15. <style type="text/css">
  16. /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
  17. body {
  18. font-family: 'EquityTextB', serif;
  19. }
  20. h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
  21. font-family: 'EquityCapsB', sans-serif;
  22. font-variant: normal;
  23. }
  24. </style>
  25. </noscript>
  26. <!-- Canonical URL for SEO purposes -->
  27. <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20080701-les-defauts-dopenid">
  28. </head>
  29. <body>
  30. <div>
  31. <header>
  32. <nav>
  33. <p>
  34. <small>
  35. Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
  36. </small>
  37. </p>
  38. </nav>
  39. </header>
  40. <section>
  41. <h1 property="schema:name">Les défauts d&#39;OpenID</h1>
  42. <article typeof="schema:BlogPosting">
  43. <div property="schema:articleBody">
  44. <p>Un <a href="http://idcorner.org/2007/08/22/the-problems-with-openid/">ancien billet sur Identity Corner</a> fait un résumé très pertinent des problèmes soulevés par OpenID :</p>
  45. <ul>
  46. <li>sécurité : problème de phishing dont <a href="https://larlet.fr/david/biologeek/archives/200719-openid-et-phishing-sont-dans-un-bateau/">j'ai eu l'occasion de parler ici</a> ;</li>
  47. <li>confidentialité : peut-on faire confiance aux providers OpenID qui peuvent tout savoir de votre navigation en ligne ? Qui peuvent même utiliser votre identité ;</li>
  48. <li>confiance : aucun moyen de savoir qui est derrière un identifiant OpenID (l'état aurait un rôle à jouer à ce niveau...) ;</li>
  49. <li>usabilité : le processus n'est pas évident pour un néophyte ;</li>
  50. <li>adoption : sur ce point, et avec le recul d'une année, je pense que les prédictions étaient fausses. Par contre la monétisation des identités ne fait que commencer...</li>
  51. <li>disponibilité : il faut que les deux sites soient accessibles pour pouvoir accéder à une seule ressource ;</li>
  52. <li>brevets : je sais pas où ça en est ça.</li>
  53. </ul>
  54. <p>En conclusion, il n'y a pas (encore) de solution miracle mais ça reste à mon avis utile. Après c'est sûr qu'il vaut mieux avoir confiance en son provider... ou créer le sien. Je suis surpris qu'il n'y ait pas encore (à ma connaissance) de provider éthique comme l'APINC pour pouvoir naviguer sereinement.</p>
  55. </div>
  56. </article>
  57. <footer>
  58. <h6 property="schema:datePublished">— 01/07/2008</h6>
  59. </footer>
  60. </section>
  61. <section>
  62. <div>
  63. <h3>Articles peut-être en rapport</h3>
  64. <ul>
  65. <li><a href="/david/biologeek/archives/20080628-exemple-dutilisation-de-dbpedia/" title="Accès à Exemple d&#39;utilisation de DBpedia">Exemple d&#39;utilisation de DBpedia</a></li>
  66. <li><a href="/david/biologeek/archives/20080624-bbc-microformats-rdfa/" title="Accès à La BBC va passer des microformats à RDFa">La BBC va passer des microformats à RDFa</a></li>
  67. <li><a href="/david/biologeek/archives/20080623-itunes-store-apple-major-mondial-du-disque/" title="Accès à iTunes Store, Apple major mondial du disque ?">iTunes Store, Apple major mondial du disque ?</a></li>
  68. </ul>
  69. </div>
  70. </section>
  71. <section>
  72. <div id="comments">
  73. <h3>Commentaires</h3>
  74. <div class="comment" typeof="schema:UserComments">
  75. <p class="comment-meta">
  76. <span class="comment-author" property="schema:creator">Kevin</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  77. </p>
  78. <div class="comment-content" property="schema:commentText">
  79. <p>Ça rejoint un peu le point sur la disponibilité, mais il m&#39;arrive souvent de vouloir me logger sur un site en utilisant mon OpenID, et le fournisseur que j&#39;utilise est parfois très lent à réagir... Quand je suis pressé, je sacrifie l&#39;avenir et je me concentre pour retrouver mon login &quot;normal&quot;.</p>
  80. <p>D&#39;autre part, mon provider OpenID permet de &quot;Toujours faire confiance&quot; à un site. Cependant, j&#39;ai toujours besoin de le confirmer.</p>
  81. <p>Enfin, je voulais savoir s&#39;il était simple de mettre en place son propre serveur OpenID.</p>
  82. </div>
  83. </div>
  84. <div class="comment" typeof="schema:UserComments">
  85. <p class="comment-meta">
  86. <span class="comment-author" property="schema:creator">LeRenard</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  87. </p>
  88. <div class="comment-content" property="schema:commentText">
  89. <p>Un problème que l&#39;on voit venir avec par exemple le Health Vault de Microsoft est l&#39;obligation d&#39;utiliser les quelques (2 dans le cas de microsoft) providers choisis par le site. En gros, chaque site pourrait choisir 2 ou 3 providers et donc imposer aux utilisateurs de se recréer une identité chez un provider &quot;certifié&quot;.</p>
  90. <p>Certains (<a href="http://simonwillison.net/2008/Jun/24/openid/">http://simonwillison.net/2008/Jun/24/openid/</a>) semblent ne pas s&#39;en inquiéter mais un des avantages d&#39;OpenID étant la centralisation des identités, ce que je vois me fait un peu mal au coeur.</p>
  91. </div>
  92. </div>
  93. <div class="comment" typeof="schema:UserComments">
  94. <p class="comment-meta">
  95. <span class="comment-author" property="schema:creator">Eric D.</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  96. </p>
  97. <div class="comment-content" property="schema:commentText">
  98. <p>Je continue à penser que le pishing est un faux problème pour OpenId. Les techos savent faire attention et pourquoi. Les autres utilisent de toutes façons dors et déjà le même mot de passe partout donc s&#39;il y a un site web malicieux il peut déjà se connecter partout sous le nom de la victime. Après on commence à voir des systèmes d&#39;authentification /sécurisation alternatifs, soit basés sur la reconnaissance d&#39;images, soit basés sur des certificats / cardspace / extension du navigateur. En fait je ne devrais pas dire que le problème n&#39;existe pas. Il existe, il est concret, il est sérieux, mais globalement le système openid est plus &quot;sécurisé&quot; que les procédures qu&#39;utilisent au jour le jour la plupart des utilisateurs web.</p>
  99. <p>Le problème de confidentialité est le même pour le FAI et pas mal de prestataire technique. Ce n&#39;est pas inutile d&#39;en parler, mais à chacun de choisir un prestataire technique qui lui convient et en qui il a confiance. Vu les données que tout le monde met chez Microsoft, Google et les autres, je doute que ce soit réellement le problème. Ici le fait d&#39;avoir du décentralisé limite la casse. A la limite même les gens pas très techniciens peuvent installer un serveur openid en quelques clicks sur un compte free.fr.</p>
  100. <p>Pour la confiance dans l&#39;identifiant ... il nous manque une couche de confiance, et je regrette qu&#39;aucune des startup de type &quot;réseau social&quot; ne se soit lancée là dedans. J&#39;avais un temps souhaité monter un truc mais par manque de temps .... Toujours est-il que oui, openid ne résoud pas la question de la confiance. Ca n&#39;est simplement pas fait pour. les anciens systèmes d&#39;authentifications ne faisaient pas mieux de ce côté là et tout ce qu&#39;on fait c&#39;est bien uniquement remplacer l&#39;authentification, rien d&#39;autre.</p>
  101. <p>Pour la disponibilité je fais assez confiance aux gros prestataires pour ça. Je ne pense pas que ce soit un réel bloqueur, surtout si openid est là &quot;en alternative&quot; au login existant (tu as un compte sur le site, et tu y associes un openid, au pire tu as toujours l&#39;ancien compte).</p>
  102. <p>Brevets on n&#39;est jamais sûr de rien, mais sauf erreur de ma part ceux qui ont participé ont assuré qu&#39;ils n&#39;avaient pas de brevets dessus. Bref, ça n&#39;est pas plus &quot;risqué&quot; que quoi que ce soit d&#39;autre en informatique.</p>
  103. <p>Non, les deux gros problèmes sont l&#39;usabilité, et l&#39;adoption. L&#39;usabilité parce que la plupart des interfaces restent assez cryptiques. L&#39;idée d&#39;avoir pris une url comme identifiant y est pour quelque chose aussi (même si je n&#39;ai pas mieux à proposer). Il y a du boulot d&#39;ergonomie à faire mais aucun provider ne m&#39;a montré des interfaces vraiment claires pour un non techos.<br />L&#39;adoption est aussi un problème. Mis à part quelques sites Web 2.0 openid n&#39;a pas percé. Ca aurait été bien que les outils de blog et les plateformes de commentaires proposent openid par défaut. Ce sont ces plateforme qui auraient pu intégrer openid facilement : Elles acceptent les commentaires sans authentification donc permettre en plus openid ne cassera rien même si peu s&#39;en servent. Ca aurait été une intégration zéro risque. Et ces plateformes ont déjà beaucoup de problèmes d&#39;usurpation d&#39;identité ou à gérer inutilement des comptes, openid aurait pu résoudre une partie du problème.<br />Les seconds à qui j&#39;en veux c&#39;est ceux comme Yahoo! qui intègrent openid uniquement comme provider, pour donner des identifiants, mais qui n&#39;acceptent pas les openid tiers au login. Même si je comprend pourquoi ils le font côté business, ce n&#39;est clairement pas comme ça qu&#39;on va avancer. Il faut aussi accepter la prise de risque &quot;j&#39;authentifie chez les autres mais en contre-partie j&#39;accepte les identifiants tiers afin d&#39;augmenter ma base d&#39;utilisateurs&quot;. Les pires étant ceux qui définissent une liste fixe de provider &quot;acceptés&quot;, ceux là cassent tout l&#39;intérêt d&#39;openid et de la décentralisation.</p>
  104. <p>Et toi ? pourquoi n&#39;acceptes tu pas openid dans tes commentaires ? qu&#39;as tu à y perdre ?</p>
  105. </div>
  106. </div>
  107. <div class="comment" typeof="schema:UserComments">
  108. <p class="comment-meta">
  109. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  110. </p>
  111. <div class="comment-content" property="schema:commentText">
  112. <p>@Kévin : j&#39;ai jamais fait mais ça ne m&#39;a pas l&#39;air insurmontable : <a href="http://wiki.openid.net/Run_your_own_identity_server">http://wiki.openid.net/Run_your_own_identity_server</a></p>
  113. <p>Sinon concernant ton provider OpenID, je n&#39;ai aucun des problèmes que tu mentionnes avec myOpenID.</p>
  114. <p>@LeRenard : je suis tout à fait d&#39;accord avec toi, ce n&#39;est pas avec des white/blacklists que l&#39;on arrivera à établir cette couche de confiance. Il manque une brique énorme à ce niveau.</p>
  115. <p>@Eric D.: pour les startup qui ajoutent la confiance, je sais que myid.is travaille là-dessus par exemple.</p>
  116. <p>Après concernant le &quot;mieux&quot; je ne nie pas, bien au contraire, mais c&#39;est loin d&#39;être la panacée non plus.</p>
  117. <p>Je ne suis pas d&#39;accord sur la solution d&#39;identifiant alternative avec mot de passe, l&#39;intérêt ça serait justement de n&#39;avoir plus que des OpenID...</p>
  118. <p>Pour l&#39;usabilité, ce sont surtout les navigateurs qui sont franchement à la traine ! Ça me semble pourtant pas énorme à implémenter pour cacher la complexité mais tant que ça restera pour les geeks et que les navigateurs compteront en parts de marché c&#39;est pas gagné.</p>
  119. <p>&gt; Et toi ? pourquoi n&#39;acceptes tu pas openid dans tes commentaires ? qu&#39;as tu à y perdre ?</p>
  120. <p>Juste du temps et il est assez précieux en ce moment, mais c&#39;est prévu...</p>
  121. </div>
  122. </div>
  123. <div class="comment" typeof="schema:UserComments">
  124. <p class="comment-meta">
  125. <span class="comment-author" property="schema:creator">esion</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  126. </p>
  127. <div class="comment-content" property="schema:commentText">
  128. <p>Après reflexion, je me demande pourquoi on ne s&#39;est pas plus dirigé vers openpgp.</p>
  129. </div>
  130. </div>
  131. <div class="comment" typeof="schema:UserComments">
  132. <p class="comment-meta">
  133. <span class="comment-author" property="schema:creator">Sunny</span> le <span class="comment-date" property="schema:commentTime">01/07/2008</span> :
  134. </p>
  135. <div class="comment-content" property="schema:commentText">
  136. <p>&quot;sécurité : problème de phishing dont j&#39;ai eu l&#39;occasion de parler ici&quot;</p>
  137. <p>Sur ce problème ça avance, il y aujourd&#39;hui des tas de moyens d&#39;empêcher le phishing (ne pas mettre de lien sur la page d&#39;arrivée, utiliser une extension de son navigateur, une image liée au cookie, certificats ssl à la place d&#39;un mot de passe, générateur de clef hardware, …).</p>
  138. <p>&quot;confidentialité : peut-on faire confiance aux providers OpenID qui peuvent tout savoir de votre navigation en ligne ? Qui peuvent même utiliser votre identité&quot;</p>
  139. <p>On ne peut certainement pas avoir confiance en tous les providers OpenID tout comme on ne peut donner le même login/mot-de-passe partout. On peut tout de même avoir confiance dans les providers les plus scrutés et pour les plus paranos d&#39;entre nous peuvent créer leur provider.</p>
  140. <p>&quot;confiance : aucun moyen de savoir qui est derrière un identifiant OpenID (l&#39;état aurait un rôle à jouer à ce niveau...)&quot;</p>
  141. <p>Sait-on qui se trouve derrière un login/mot-de-passe ? Ou derrière un compte MSN Passport ? Au contraire je pense qu&#39;OpenID pourrait être le moyen par lequel un état pourrait relier une identité sur internet à une identité réelle.</p>
  142. <p>&quot;usabilité : le processus n&#39;est pas évident pour un néophyte&quot;</p>
  143. <p>Là aussi les providers se penchent sur la question. Outre les extensions et utilisations de certificats, avec Yahoo! par exemple il suffit de taper &quot;yahoo.com&quot; ou de cliquer sur un lien &quot;se connecter avec Yahoo!&quot;, cela simplifie énormément le principe pour les néophytes. En prime cela donne un identifiant openid unique, qu&#39;on ne peut associer aux autres identités.</p>
  144. <p>Il ne faut pas oublier que des solutions continent d&#39;apparaître et que les providers OpenID jouent d&#39;inventivité pour être les plus sûrs possible. La compétition a du bon.</p>
  145. </div>
  146. </div>
  147. <div class="comment" typeof="schema:UserComments">
  148. <p class="comment-meta">
  149. <span class="comment-author" property="schema:creator">brunto</span> le <span class="comment-date" property="schema:commentTime">12/08/2008</span> :
  150. </p>
  151. <div class="comment-content" property="schema:commentText">
  152. <p>Très bon article et je suis tout à fait d&#39;accord yahoo n&#39;a pas vraiment compris l&#39;intérêt d&#39;openid (même si je comprend aussi la démarche commerciale) dommage.</p>
  153. </div>
  154. </div>
  155. </div>
  156. </section>
  157. <footer>
  158. <nav>
  159. <p>
  160. <small>
  161. Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
  162. </small>
  163. </p>
  164. </nav>
  165. </footer>
  166. </div>
  167. <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  168. <script data-no-instant>InstantClick.init()</script>
  169. </body>
  170. </html>