Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233
  1. <div class="comment" typeof="schema:UserComments">
  2. <p class="comment-meta">
  3. <span class="comment-author" property="schema:creator">neolao</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  4. </p>
  5. <div class="comment-content" property="schema:commentText">
  6. <p>J&#39;ai pensé exactement à la même chose quand j&#39;ai lu ce que faisait microID ...</p>
  7. <p>Ca sert à rien.</p>
  8. </div>
  9. </div>
  10. <div class="comment" typeof="schema:UserComments">
  11. <p class="comment-meta">
  12. <span class="comment-author" property="schema:creator">Kevin</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  13. </p>
  14. <div class="comment-content" property="schema:commentText">
  15. <p>En parlant d&#39;OpenID, voilà un nouveau prestataire : LiquidID. Il offre la possibilité de créer un alias e-mail et de servir ainsi de filtre anti-spam. À voir.</p>
  16. <p><a href="http://www.readwriteweb.com/archives/liquidid_openid_email_aliasing.php">http://www.readwriteweb.com/archives/liquidid_openid_email_aliasing.php</a></p>
  17. <p>Sachant que GMail, à défaut d&#39;être totalement privé (mais qu&#39;ai-je à cacher ?), me bloque près de 1500 spams par mois, ce qui m&#39;en laisse un ou deux passer chaque mois alors que je publie mon adresse e-mail sans tabou ni <a href="mailto:prénomRETIREZMOI@ANTISPAMnomdefamille.com">prénomRETIREZMOI@ANTISPAMnomdefamille.com</a> :-)</p>
  18. </div>
  19. </div>
  20. <div class="comment" typeof="schema:UserComments">
  21. <p class="comment-meta">
  22. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  23. </p>
  24. <div class="comment-content" property="schema:commentText">
  25. <p>Sisi, l&#39;appartenance fonctionne sous MicroID, mais c&#39;est du déclaratif, pas de la certification.</p>
  26. <p>Tu sais juste que le propriétaire du Site XX affirme être propriétaire de l&#39;adresse email YY. Tu ne sais pas si effectivement c&#39;est vrai, par contre tu sais désormais que chaque fois que tu as le site XX en référence, tu peux rediriger les emails ou l&#39;adresse de contact vers YY.</p>
  27. <p>De même, si dans un email de YY le correspondant affirme être l&#39;auteur ou la personne référencée par le site XX, tu peux le vérifier. Si son email est correctement mise en microID sur le site XX, tu peux être sûr que c&#39;est vrai (ou alors il a trouvé une faille de sécurité sur XX).</p>
  28. <p>C&#39;est souvent suffisant pour pas mal de choses.</p>
  29. <p>Pour le whitelisting de providers openid peut être intelligent si c&#39;est fait correctement, c&#39;est à dire si les autres sont sur liste grise. Il s&#39;agit alors juste de dire &quot;je sais que le provider X fait son boulot pour bannir les robots et spammers de son réseau donc je vais publier immédiatement les commentaires de ses utilisateurs, les autres passeront la modération&quot;. C&#39;est ce qui est fait à deux ou trois endroits.<br />Si c&#39;est pour bannir les providers tiers comme HealthVault c&#39;est effectivement crétin.</p>
  30. <p>Sinon pour ajouter un minimum de couche de confiance anti-spam à openid j&#39;avais trouvé l&#39;idée de <a href="http://botbouncer.com/">http://botbouncer.com/</a> très bonne. Ca manque de quelques détails : genre que le service mette à jour leur test anti-robot régulièrement et qu&#39;on puisse dire &quot;je veux les utilisateurs qui ont passé le test 26 ou plus récent&quot; (parce que sinon dès que leur test anti-robot sera cassé c&#39;est tout le service qui devient inutile.</p>
  31. </div>
  32. </div>
  33. <div class="comment" typeof="schema:UserComments">
  34. <p class="comment-meta">
  35. <span class="comment-author" property="schema:creator">giz404</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  36. </p>
  37. <div class="comment-content" property="schema:commentText">
  38. <p>J&#39;étais justement en train d&#39;essayer de comprendre à quoi MicroID pouvait servir... Finalement, ça ne sert pas à grand chose... En fait, c&#39;est juste une sorte de microformat &quot;unifié&quot;, qui permettrait de rattacher des infos à une personne sans se prendre la tête (sans aucune considération de sécurité, d&#39;authentification ou de de notion d&#39;info public/privée.</p>
  39. </div>
  40. </div>
  41. <div class="comment" typeof="schema:UserComments">
  42. <p class="comment-meta">
  43. <span class="comment-author" property="schema:creator">Thesa</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  44. </p>
  45. <div class="comment-content" property="schema:commentText">
  46. <p>@Eric :</p>
  47. <p>&gt; Pour le whitelisting de providers openid peut être intelligent si c&#39;est fait correctement, c&#39;est à dire si les autres sont sur liste grise.</p>
  48. <p>Et mon PHPMyOpenID installé sur mon serveur, tu crois que j&#39;ai des chances de le voir passer en liste blanche ? Parce que rester en liste grise ad-vitam æternam, non merci...</p>
  49. <p>Franchement, si l&#39;OpenID finit comme le mail, je trouverai ça catastrophique pour Internet...</p>
  50. </div>
  51. </div>
  52. <div class="comment" typeof="schema:UserComments">
  53. <p class="comment-meta">
  54. <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
  55. </p>
  56. <div class="comment-content" property="schema:commentText">
  57. <p>&quot;L&#39;authentification cumule l&#39;identification et l&#39;autorisation pour un service donné&quot;</p>
  58. <p>Moui. Faut vouloir le dire vite. Par exemple, mon commentaire, celui-là. Qui est-ce qui l&#39;a écrit ? C&#39;est moi, le même moi qui fait habituellement des pâtés mal relus. Cette opération d&#39;association d&#39;un document à un autre, en disant que c&#39;est le même auteur, c&#39;est ça l&#39;identification.</p>
  59. <p>Après vient le problème du travestissement, des fausses déclarations, il faut authentifier cette identité.</p>
  60. <p>Ici on m&#39;identifie comme &quot;Damien B&quot;, et ailleurs, d&#39;autres &quot;Damien B&quot; oeuvrent, est-ce que ces &quot;Damien B&quot; déclarent être la même identité ? Est-ce que ces déclarations sont authentiques ?</p>
  61. <p>Le nom OpenID est trompeur, puisque qu&#39;il mixe une manière d&#39;identifier une personne (par une URL) et une manière d&#39;authentifier cette identité (par le protocole OpenID). D&#39;ailleurs, ils utilisent bien ce vocabulaire dans leur page de glossaire : <a href="http://openid.net/specs/openid-authentication-2_0.html#terminology">http://openid.net/specs/openid-authentication-2_0.html#terminology</a> .</p>
  62. <p>Le nom OAuth est mal choisi, car la chaîne &quot;auth&quot; n&#39;est pas discriminante entre authorization et authentication. Et d&#39;ailleurs, ils entretiennent cette confusion : sur la page d&#39;accueil &quot;An open protocol to allow secure API authentication&quot;, dans la spéc&quot;. Parce qu&#39;en fait, OAuth n&#39;est pas un système de droits comme on l&#39;entend de manière générale (ACL ou flags). Car qui gère les autorisations dans OAuth ? C&#39;est le Service Provider. Comment les gère-t-il ? Comme il veut. En fait, OAuth est uniquement un système d&#39;authentification. C&#39;est l&#39;utilisateur qui vient authentifier que le Consumer est bien celui qu&#39;il prétend être, et après le Service Provider décide ou non de laisser le Consumer accéder à la ressource, mais cette décision est hors du cadre de OAuth.</p>
  63. <p>Alors comment désigner un système complet identité/authentification/autorisations ? En fait le problème existe peu, car un tel système complet indique une idée de centralisation, hors, la course est effectivement à la décentralisation (et l&#39;a toujours été, les SSO ne gèrent quasiment jamais la partie autorisation, avec en exception notable Active Directory qui propose un tout en un, mais que serait Microsoft s&#39;il ne proposait pas un système centralisé ?).</p>
  64. <p>Alors que fait MicroID ? De l&#39;identification, point barre. Et de l&#39;identification sans authentification, à quoi ça sert sur le web ? Ca sert à tout, vu que c&#39;est ce qu&#39;on fait tous les jours en laissant un nom ! Bref, MicroID, c&#39;est de la branlette de µformateux (promis, c&#39;est de la dernière fois que je suis vulgaire ici).</p>
  65. </div>
  66. </div>
  67. <div class="comment" typeof="schema:UserComments">
  68. <p class="comment-meta">
  69. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
  70. </p>
  71. <div class="comment-content" property="schema:commentText">
  72. <p>@neolao : au moins ton avis est clair.</p>
  73. <p>@Kevin : je ne connaissais pas LiquidID mais ça rejoint tout à fait le type de service qui peut graviter autour d&#39;OpenID.</p>
  74. <p>@Eric :</p>
  75. <p>&gt; C&#39;est souvent suffisant pour pas mal de choses.</p>
  76. <p>En fait c&#39;est là où ça coince, je ne vois pas dans quelles utilisations c&#39;est plus pertinent (en terme de simplicité) qu&#39;OpenID, ça suffirait pour quoi concrètement ?</p>
  77. <p>Je ne connaissais pas botbouncer, merci.</p>
  78. <p>@giz404 : oui j&#39;ai vu ton commentaire juste avant de poster le billet. Si ça se trouve c&#39;est juste une collecte d&#39;emails déguisée... demain je lance un CardID qui crée un hash à partir de votre numéro de carte bleue ! ;-)</p>
  79. <p>@Thesa : et oui, bienvenue dans un monde basé sur le pouvoir.</p>
  80. <p>@Damien B. :</p>
  81. <p>&gt; Moui. Faut vouloir le dire vite.</p>
  82. <p>J&#39;aime bien te tendre des perches dans mes billets :-).</p>
  83. <p>Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.</p>
  84. <p>Concernant OAuth, je t&#39;invite à lire ce thread récent <a href="http://groups.google.com/group/oauth/browse_thread/thread/d8ec85782c46c23f">http://groups.google.com/group/oauth/browse_thread/thread/d8ec85782c46c23f</a></p>
  85. <p>Effectivement, je suis d&#39;accord sur le fait que l&#39;autorisation est laissée au provider mais si l&#39;on se place du point de vue utilisateur, il autorise bien l&#39;accès à une ressource (après s&#39;être authentifié, ce qui en fait une combinaison des deux, soit).</p>
  86. <p>Ta conclusion me fait penser à ce qui s&#39;est passé avec XFN et FOAF... rien de bon pour l&#39;utilisateur (et encore moins pour le développeur).</p>
  87. </div>
  88. </div>
  89. <div class="comment" typeof="schema:UserComments">
  90. <p class="comment-meta">
  91. <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
  92. </p>
  93. <div class="comment-content" property="schema:commentText">
  94. <p>&quot;Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.&quot;</p>
  95. <p>L&#39;identification n&#39;est pas un but, c&#39;est juste que c&#39;est par nature déclaratif. Par exemple, si on me croise dans la rue, je serais identifié en tant que &quot;le gros mal rasé avec des boutons bizarres autour des yeux&quot;. Mais plusieurs individus peuvent correspondre à cette identité déclarative, seule le processus d&#39;authentification (&quot;étiez vous le gros mal rasé à 10h jeudi dernier place de l&#39;Eglise ?&quot;) permet de faire quelque chose de validé avec cette identité.</p>
  96. <p>&quot;Concernant OAuth, je t&#39;invite à lire ce thread récent&quot;</p>
  97. <p>Oh ben oui, que des participants au projet, ça va être objectif :-)<br />Lisons une page liée dans ce fil :<br />&quot;OAuth offers safe delegation of authority. It allows you to authorize a service (the Consumer) to act on the your behalf at a second service (the Service Provider) -- but only within limits set by the you and the Service Provider.&quot; (fautes d&#39;origine)</p>
  98. <p>C&#39;est la partie &quot;limits set by the you and the Service Provider&quot;. Dans OAuth, il n&#39;y a *aucune* notion de gestion de droits. A savoir, comment un Consumer sait s&#39;il a le droit d&#39;accéder à telle ou telle ressource dans OAuth ?<br />Réponse 1 : échange de paramètres supplémentaires, spécifiques au Service Provider (car notion non codifiée dans OAuth)<br />Réponse 2 : il y va avec son jeton d&#39;accès au fusil, et ça passe ou ça casse</p>
  99. <p>Exemple concret d&#39;utilisation d&#39;une gestion simple des droits simple : droit lecture, droit écriture dans mixin.<br />Imaginons que je fasse un widget pour Mixin, mais que pour une raison X ou Y, je ne veuille pas que ce widget pour moi utilisateur authentifié utilisant ce widget, ait le droit de modifier mes données. Mais je veux quand même qu&#39;il les lise.<br />On repart de ton post :</p>
  100. <p>&quot;Initialisation&quot; =&gt; pas de notions de droits, c&#39;est du tout ou rien</p>
  101. <p>&quot;Interaction&quot; <br />&quot;Un autre avantage qui n&#39;a pas été mis en pratique afin de faciliter le cheminement de l&#39;utilisateur est de pouvoir limiter l&#39;accès à certaines ressources, voire de régler finement le type d&#39;accès (lecture/écriture).&quot;</p>
  102. <p>Avantage apporté par quoi ? Qui serait implémenté à quel niveau ? Est-ce que le widget peut connaître les droits de manière normalisée par le protocole normal OAuth ? Si oui, alors on peut parler d&#39;une début de gestion de droits *au niveau de OAuth*. Si non, c&#39;est juste une gestion de droits *spécifique* que tu appliques à un utilisateur (au sens Use Case) qui se trouvé avoir été authentifié par OAuth.</p>
  103. <p>&quot;mais si l&#39;on se place du point de vue utilisateur, il autorise bien l&#39;accès à une ressource (après s&#39;être authentifié, ce qui en fait une combinaison des deux, soit).&quot;</p>
  104. <p>Si l&#39;on se place du point de vue utilisateur final, l&#39;utilisateur autorise l&#39;accès à une ou des ressources. Mais l&#39;autorisation en elle-même n&#39;a pas grand chose à voir avec OAuth, il a surtout authentifié (CNRTL : &quot;Attester, certifier le caractère authentique de quelque chose ou de quelqu&#39;un.&quot;) que c&#39;était bien *lui-même* qui venait avec ce client externe *là*, taper dans ses données hébergées par le Service Provider. La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.</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">17/07/2008</span> :
  110. </p>
  111. <div class="comment-content" property="schema:commentText">
  112. <p>@Damien B:</p>
  113. <p>&gt; L&#39;identification n&#39;est pas un but</p>
  114. <p>En effet, je voulais parler de l&#39;objectif qui est la déclaration d&#39;identité mais j&#39;ai pas trouvé le bon terme.</p>
  115. <p>&gt; A savoir, comment un Consumer sait s&#39;il a le droit d&#39;accéder à telle ou telle ressource dans OAuth ?</p>
  116. <p>Dans mon implémentation, j&#39;ai ajouté le paramètre &#39;scope&#39; pour désigner la ressource considérée mais ce n&#39;est pas standard (même si Google l&#39;a fait aussi), il me semble que c&#39;est plutôt la solution 2 qui a été pensée à l&#39;origine. Espérons que tout ça soit normalisé dans une future version.</p>
  117. <p>&gt; Avantage apporté par quoi ? Qui serait implémenté à quel niveau ? Est-ce que le widget peut connaître les droits de manière normalisée par le protocole normal OAuth ?</p>
  118. <p>Bon je me rends compte que j&#39;ai peut-être pas été très clair sur cette partie et qu&#39;il faut différencier la spécification de mon implémentation.</p>
  119. <p>Concernant django-oauth, tu peux laisser le choix à l&#39;utilisateur lors de l&#39;initialisation de spécifier la ressource considérée et si elle est accessible en lecture/écriture (ce n&#39;est pas utilisé dans mixin mais c&#39;est générique dans la lib).</p>
  120. <p>En revanche la spécification ne mentionne/normalise pas ces problématiques (d&#39;où la partie limites de mon précédent billet).</p>
  121. <p>&gt; La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.</p>
  122. <p>Pas exactement car selon l&#39;implémentation un jeton peut être dédié à une ressource et/ou à un droit. C&#39;est le moment où une spec trop limitée est à l&#39;origine d&#39;extensions et d&#39;innovations de la part des devs qui sont ensuite réintégrées dans la spec. L&#39;éternel lombric théorie/pratique avançant par à coups.</p>
  123. </div>
  124. </div>
  125. <div class="comment" typeof="schema:UserComments">
  126. <p class="comment-meta">
  127. <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
  128. </p>
  129. <div class="comment-content" property="schema:commentText">
  130. <p>&gt; &gt; La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.<br />&gt; Pas exactement car selon l&#39;implémentation un jeton peut être dédié à une ressource et/ou à un droit.</p>
  131. <p>Donc IRC et le web ne sont pas orthogonaux, parce que selon l&#39;implémentation, tu peux avoir un navigateur web qui est client IRC. C&#39;est la non-orthogonalité 2.0 :-) Parce que selon l&#39;implémentation, ça veut dire selon le Service Provider, on retourne à la case départ :-)</p>
  132. <p>&gt; C&#39;est le moment où une spec trop limitée est à l&#39;origine d&#39;extensions et d&#39;innovations de la part des devs qui sont ensuite réintégrées dans la spec.</p>
  133. <p>Ah, &quot;innovation&quot;, c&#39;est donc ça le secret. Regardons la mailing list (je ne trouve pas de brouillon de la spéc en ligne)... qu&#39;est ce qu&#39;on va trouver dans les Common Extensions :<br />&quot;Session extension – Add a workflow allowing Service Providers to limit the lifetime and resources of Access Tokens and provide a method for Consumers to request to extend those limitations. The session extension will address two use cases: add additional rights to an existing Access Token, and extend the lifetime of an Access Token if the End User authorized a longer period than allocated for the token.&quot;</p>
  134. <p>Ajouter des droits à un jeton d&#39;accès existant. D&#39;où vient cette notion de droits ?</p>
  135. <p>Septembre 2007 :<br />&quot;By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer. A Consumer either has access to <br />Protected Resources or it doesn&#39;t.&quot;</p>
  136. <p>OAuth 2008.1 Core =&gt; pas de texte en ligne</p>
  137. <p>Qu&#39;est ce qu&#39;on a d&#39;autre... OpenFile</p>
  138. <p>&quot;The OpenFile idea is essentially the combination of: <br /> OAuth/Core + OAuth/Rights (TBD) + OAuth/Discovery + GrantedResources (represented as an Atom feed and an OAuth Protected <br />Resource)</p>
  139. <p>It has been difficult to decide what form this idea should be in. Currently the rights and granted resources &quot;resource&quot; are the new <br />elements and have been combined into the OpenFile spec, although I recognize that these are orthogonal components. We&#39;ve decided to put all these elements together to attempt to provide a single spec that <br />someone could implement against to support the intended use cases. It may be valid and important to separate the two, or not; your opinions will help in this.&quot;</p>
  140. <p>Tiens, lui a un concept d&#39;othogonalité très 1.0. Et encore une proposition pour réinventer WebDAV. Bon. Ca fleure bon le NIH quand même OAuth et la gestion des droits... Dans l&#39;attente d&#39;avoir des liens un poil plus convainquants (ou un papelard révolutionnaire du MIT :-) ), veuillez agréer monsieur blablabla. Et bonne nuit si tu es encore debout.</p>
  141. <p>C&#39;est pas mal ce système de mail en fin de compte. Dommage qu&#39;il n&#39;y ait pas de copie dans une quelconque boîte &quot;courrier envoyé&quot;. Ca s&#39;appelait comment déjà ce truc ? Cocomm.. ??</p>
  142. </div>
  143. </div>
  144. <div class="comment" typeof="schema:UserComments">
  145. <p class="comment-meta">
  146. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
  147. </p>
  148. <div class="comment-content" property="schema:commentText">
  149. <p>@Thesa: ah mais il ne s&#39;agit pas de te mettre en liste grise. Il s&#39;agit de t&#39;y laisser. Ce que je veux dire c&#39;est que avoir un provider connu est sérieux est un moyen (supplémentaire) de s&#39;assurer que tu n&#39;es pas un robot/spammeur.</p>
  150. <p>Il est donc logique qu&#39;on te mette plus facilement sur liste blanche. C&#39;est un point &quot;en plus&quot; pour ceux qui utilisent ces providers. Ce n&#39;est pas un point &quot;en moins&quot; pour les autres.</p>
  151. <p>Après si ça te gave de ne pas être white-list sur ton propre serveur openid à toi de proposer un truc qui permet de différencier les robots des utilisateurs et qui fonctionne pour toi. D&#39;autres s&#39;y sont essayés et ce n&#39;est pas si simple. Donc à défaut, proposer au moins une white-list pour ceux dont on sait qu&#39;ils sont clean (parce que d&#39;un provider sérieux qui fait son boulot sur le sujet), je me vois mal leur reprocher.</p>
  152. </div>
  153. </div>
  154. <div class="comment" typeof="schema:UserComments">
  155. <p class="comment-meta">
  156. <span class="comment-author" property="schema:creator">webtik</span> le <span class="comment-date" property="schema:commentTime">18/12/2008</span> :
  157. </p>
  158. <div class="comment-content" property="schema:commentText">
  159. <p>@David et comme le disait justement @Damien juste pour rajouter quelques choses à cela...</p>
  160. <p>l&#39;identification est ce que je suis - vérification 1 parmi N<br />On ne vérifie pas OpenID de cette manière donc authentification pour moi...</p>
  161. <p>l&#39;authentification est ce qui prouve ce que je suis (ce que je possède... un couple login/password, une carte à puce ... par exemple) vérification 1/1 OpenID authentification cadre à cela pour moi...</p>
  162. <p>Mais si quelqu&#39;un peut me l&#39;expliquer différemment je suis preneur ;)</p>
  163. </div>
  164. </div>