davidbgk
/
larlet-fr-david


<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">neolao</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J&#39;ai pensé exactement à la même chose quand j&#39;ai lu ce que faisait microID ...</p>

<p>Ca sert à rien.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Kevin</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Sisi, l&#39;appartenance fonctionne sous MicroID, mais c&#39;est du déclaratif, pas de la certification.</p>

<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>

<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>

<p>C&#39;est souvent suffisant pour pas mal de choses.</p>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">giz404</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Thesa</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Eric :</p>

<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>

<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>

<p>Franchement, si l&#39;OpenID finit comme le mail, je trouverai ça catastrophique pour Internet...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;L&#39;authentification cumule l&#39;identification et l&#39;autorisation pour un service donné&quot;</p>

<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>

<p>Après vient le problème du travestissement, des fausses déclarations, il faut authentifier cette identité.</p>

<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>

<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>

<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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@neolao : au moins ton avis est clair.</p>

<p>@Kevin : je ne connaissais pas LiquidID mais ça rejoint tout à fait le type de service qui peut graviter autour d&#39;OpenID.</p>

<p>@Eric :</p>

<p>&gt; C&#39;est souvent suffisant pour pas mal de choses.</p>

<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>

<p>Je ne connaissais pas botbouncer, merci.</p>

<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>

<p>@Thesa : et oui, bienvenue dans un monde basé sur le pouvoir.</p>

<p>@Damien B. :</p>

<p>&gt; Moui. Faut vouloir le dire vite.</p>

<p>J&#39;aime bien te tendre des perches dans mes billets :-).</p>

<p>Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.</p>

<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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.&quot;</p>

<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>

<p>&quot;Concernant OAuth, je t&#39;invite à lire ce thread récent&quot;</p>

<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>

<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>

<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>

<p>&quot;Initialisation&quot; =&gt; pas de notions de droits, c&#39;est du tout ou rien</p>

<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>

<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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Damien B:</p>

<p>&gt; L&#39;identification n&#39;est pas un but</p>

<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>

<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>

<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>

<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>

<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>

<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>

<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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

<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>

<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>

<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>

<p>Ajouter des droits à un jeton d&#39;accès existant. D&#39;où vient cette notion de droits ?</p>

<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>

<p>OAuth 2008.1 Core =&gt; pas de texte en ligne</p>

<p>Qu&#39;est ce qu&#39;on a d&#39;autre... OpenFile</p>

<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>

<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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

<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>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">webtik</span> le <span class="comment-date" property="schema:commentTime">18/12/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@David et comme le disait justement @Damien juste pour rajouter quelques choses à cela...</p>

<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>

<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>

<p>Mais si quelqu&#39;un peut me l&#39;expliquer différemment je suis preneur ;)</p>
    </div>
</div>