larlet-fr-david/david/biologeek/archives/20080716-combiner-openid-et-oauth/comments.html

<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Guillaume S.</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Pas mal, la comparaison des fournisseurs d&#39;openID... <br />Pour ce qui est de la combinaison d&#39;openID et OAuth, ça reste au delà de ma compréhension.</p>

<p>Rien à voir - de mon côté, j&#39;essaie de comprendre l&#39;interêt de MicroID.</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">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Les micro esprits se rencontrent : <a href="https://larlet.fr/david/biologeek/archives/20080716-differences-entre-identification-autorisation-et-authentification/">https://larlet.fr/david/biologeek/archives/20080716-differences-entre-identification-autorisation-et-authentification/</a> ;-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Got</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Cela pourra peut-être t&#39;intéresser : <a href="http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global">http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global</a> . Si, effectivement, la brique Trust du layer cake (<a href="http://www.w3.org/2007/03/layerCake.png">http://www.w3.org/2007/03/layerCake.png</a>) n&#39;est pas encore à l&#39;étude, je ne vois pas ce qui t&#39;empêche d&#39;ajouter une couche applicative (maintenant, je ne suis ni architecte, ni développeur, alors les tenants et les aboutissants m&#39;échappent peut-être...)</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">18/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Got : oui j&#39;ai lu avec intérêt les billets d&#39;Henry Story sur le sujet mais ça me semble plus compliqué que ce qui peut être fait avec OAuth.</p>

<p>Concernant la brique Trust, tant qu&#39;elle ne sera pas là les applications &quot;grand public&quot; ne pourront pas être développées... et c&#39;est bien dommage.</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">18/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;ça me semble plus compliqué que ce qui peut être fait avec OAuth&quot;</p>

<p>Oui, mais ça permet de faire des choses que ne permet pas OAuth : se passer de l&#39;interaction utilisateur sur le Service Provider à chaque nouvelle session du Customer.<br />Alors évidemment, ça fait revenir dans la boucle X.509, et la notion de chaîne de confiance, ce qui est lourd. Mais pour l&#39;instant on n&#39;a pas vraiment de meilleur modèle qui permet la montée en volume.</p>

<p>&quot;Concernant la brique Trust, tant qu&#39;elle ne sera pas là les applications &#39;grand public&#39; ne pourront pas être développées... et c&#39;est bien dommage.&quot;</p>

<p>Mouais, à quoi sert une application &quot;grand public&quot; si on ne peut pas récupérer les informations qui sont dedans ? Ce n&#39;est pas parce que la brique Trust est manquante qu&#39;on ne peut pas récupérer nos informations à gauche et à droite, à commencer par les informations de tracking nominatifs utilisées par certaines entreprises pour cibler leurs publicité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">19/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Damien B:</p>

<p>&gt; se passer de l&#39;interaction utilisateur sur le Service Provider à chaque nouvelle session du Customer.</p>

<p>Tu peux détailler ? (bon attend j&#39;augmente la taille des commentaires en base avant ;-))<br />Je vois pas où est l&#39;interaction de l&#39;utilisateur &quot;à chaque nouvelle session&quot; avec OAuth, ou alors pour des Customers différents ?</p>

<p>&gt; Mouais, à quoi sert une application &quot;grand public&quot; si on ne peut pas récupérer les informations qui sont dedans ?</p>

<p>L&#39;idée ce n&#39;est pas de bloquer l&#39;accès mais de restreindre en fonction du demandeur, c&#39;est un peu la base. J&#39;expose par exemple pas mal d&#39;infos dans mon FOAF, je voudrais pouvoir restreindre certaines parties aux personnes qui sont déclarées comme amies dans ce même fichier. Pas évident en l&#39;état actuel.</p>

<p></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">20/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&gt; &gt; se passer de l&#39;interaction utilisateur sur le Service Provider à chaque nouvelle session du Customer.</p>

<p>&gt; Tu peux détailler ?</p>

<p>A la base la phrase vient d&#39;une mauvaise lecture de OAuth Core 1.0, qui laisse sous-entendre dans le graphique que la convesation Request et la conversation Access se déroulent systématiquement dans une session ^^; C&#39;est un peu mal fait :-) Bref, je m&#39;ai trompé.</p>

<p>Effectivement, rien n&#39;est dit sur la longévité de l&#39;Access token. Mais de toute façon, il est difficilement pensable de le laisser vivre indéfiniment, déjà pour faciliter la gestion de la répudiation. Et là, pour en avoir un nouveau, il est obligé d&#39;avoir un nouveau Request token, et hop, on refait le cycle. (hop, quasi sauvé ^^;)</p>

<p>&gt; L&#39;idée ce n&#39;est pas de bloquer l&#39;accès mais de restreindre en fonction du demandeur [...]. J&#39;expose par exemple pas mal d&#39;infos dans mon FOAF, je voudrais pouvoir restreindre certaines parties aux personnes qui sont déclarées comme amies dans ce même fichier. Pas évident en l&#39;état actuel.</p>

<p>C&#39;est simple pourtant : FOAF + XACL (ou format perso, ça n&#39;est pas partagé de toute façon) + authentification avec login / mdp envoyé aux adresses mail des contacts. Présupposé : l&#39;adresse mail du contact est sécurisée. Inconvénient : authentification centralisé. Mais, authentification et ACL sont disjoints.</p>

<p>Sinon, si c&#39;est un partage par communication entre applications, on a plusieurs problématiques :<br />- authentification<br />- protocole de communication<br />- format d&#39;échange</p>

<p>Et... et... oui : CORBA, Tuxedo/Q, Tibco, RMI, EJB, SUN RPC, SOAP. On est en plein dedans. Je ne mets pas &quot;autorisation&quot; dans les problématiques, parce qu&#39;en fait, c&#39;est un problème strictement interne au fournisseur.<br />Authentification : en système &quot;non-web&quot;, c&#39;est Kerberos qui est sorti vainqueur. Evidemment, ça n&#39;est pas supporté par les serveurs et les navigateurs web, la priorité étant de se tordre la nouille avec HTML5.<br />Format d&#39;échange : REST, OAuth, OpenId, etc... disent : &quot;ce n&#39;est pas notre problème&quot;. SOAP impose XML, ce qui passe souvent par l&#39;utilisation de XLM Schema, vu que c&#39;est ce qui est craché par défaut quand on génère un WSDL, ce à quoi le web répond : &quot;ouin, c&#39;est trop dur, et les namespaces cémal&quot;. HTML5 dit &quot;les grammaires çapue, les namespaces çapue&quot;.<br />Solutions que tu as évoqué récemment : Thrift et Protocol Buffers. Les deux implémentant la partie protocole et format, les deux laissent de côté l&#39;authentification, à un point tel que la seule solution de refaire de la gestion de jetons à la main (ce que tu appelles orthgonalité 2.0 :) )<br />Bref, ce n&#39;est pas qu&#39;on ne sait pas faire, ou qu&#39;on n&#39;a jamais fait ça sur les 30 dernières années, c&#39;est juste que le web baigne dans un gros NIH, et en plus navigue constamment entre deux rives : bidouiller pour fonctionner avec les navigateurs existants, et forcer la mise à jour du client. Et pour l&#39;instant, c&#39;est l&#39;approche des pra-ma-ti-que qui a la cote : c&#39;est la fête à Mr. Bricolage.</p>
    </div>
</div>