neolao le 16/07/2008 :

J'ai pensé exactement à la même chose quand j'ai lu ce que faisait microID ...

Ca sert à rien.

Kevin le 16/07/2008 :

En parlant d'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.

http://www.readwriteweb.com/archives/liquidid_openid_email_aliasing.php

Sachant que GMail, à défaut d'être totalement privé (mais qu'ai-je à cacher ?), me bloque près de 1500 spams par mois, ce qui m'en laisse un ou deux passer chaque mois alors que je publie mon adresse e-mail sans tabou ni prénomRETIREZMOI@ANTISPAMnomdefamille.com :-)

Eric le 16/07/2008 :

Sisi, l'appartenance fonctionne sous MicroID, mais c'est du déclaratif, pas de la certification.

Tu sais juste que le propriétaire du Site XX affirme être propriétaire de l'adresse email YY. Tu ne sais pas si effectivement c'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'adresse de contact vers YY.

De même, si dans un email de YY le correspondant affirme être l'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'est vrai (ou alors il a trouvé une faille de sécurité sur XX).

C'est souvent suffisant pour pas mal de choses.

Pour le whitelisting de providers openid peut être intelligent si c'est fait correctement, c'est à dire si les autres sont sur liste grise. Il s'agit alors juste de dire "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". C'est ce qui est fait à deux ou trois endroits.
Si c'est pour bannir les providers tiers comme HealthVault c'est effectivement crétin.

Sinon pour ajouter un minimum de couche de confiance anti-spam à openid j'avais trouvé l'idée de http://botbouncer.com/ très bonne. Ca manque de quelques détails : genre que le service mette à jour leur test anti-robot régulièrement et qu'on puisse dire "je veux les utilisateurs qui ont passé le test 26 ou plus récent" (parce que sinon dès que leur test anti-robot sera cassé c'est tout le service qui devient inutile.

giz404 le 16/07/2008 :

J'étais justement en train d'essayer de comprendre à quoi MicroID pouvait servir... Finalement, ça ne sert pas à grand chose... En fait, c'est juste une sorte de microformat "unifié", qui permettrait de rattacher des infos à une personne sans se prendre la tête (sans aucune considération de sécurité, d'authentification ou de de notion d'info public/privée.

Thesa le 16/07/2008 :

@Eric :

> Pour le whitelisting de providers openid peut être intelligent si c'est fait correctement, c'est à dire si les autres sont sur liste grise.

Et mon PHPMyOpenID installé sur mon serveur, tu crois que j'ai des chances de le voir passer en liste blanche ? Parce que rester en liste grise ad-vitam æternam, non merci...

Franchement, si l'OpenID finit comme le mail, je trouverai ça catastrophique pour Internet...

Damien B le 16/07/2008 :

"L'authentification cumule l'identification et l'autorisation pour un service donné"

Moui. Faut vouloir le dire vite. Par exemple, mon commentaire, celui-là. Qui est-ce qui l'a écrit ? C'est moi, le même moi qui fait habituellement des pâtés mal relus. Cette opération d'association d'un document à un autre, en disant que c'est le même auteur, c'est ça l'identification.

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

Ici on m'identifie comme "Damien B", et ailleurs, d'autres "Damien B" oeuvrent, est-ce que ces "Damien B" déclarent être la même identité ? Est-ce que ces déclarations sont authentiques ?

Le nom OpenID est trompeur, puisque qu'il mixe une manière d'identifier une personne (par une URL) et une manière d'authentifier cette identité (par le protocole OpenID). D'ailleurs, ils utilisent bien ce vocabulaire dans leur page de glossaire : http://openid.net/specs/openid-authentication-2_0.html#terminology .

Le nom OAuth est mal choisi, car la chaîne "auth" n'est pas discriminante entre authorization et authentication. Et d'ailleurs, ils entretiennent cette confusion : sur la page d'accueil "An open protocol to allow secure API authentication", dans la spéc". Parce qu'en fait, OAuth n'est pas un système de droits comme on l'entend de manière générale (ACL ou flags). Car qui gère les autorisations dans OAuth ? C'est le Service Provider. Comment les gère-t-il ? Comme il veut. En fait, OAuth est uniquement un système d'authentification. C'est l'utilisateur qui vient authentifier que le Consumer est bien celui qu'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.

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'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'il ne proposait pas un système centralisé ?).

Alors que fait MicroID ? De l'identification, point barre. Et de l'identification sans authentification, à quoi ça sert sur le web ? Ca sert à tout, vu que c'est ce qu'on fait tous les jours en laissant un nom ! Bref, MicroID, c'est de la branlette de µformateux (promis, c'est de la dernière fois que je suis vulgaire ici).

David, biologeek le 17/07/2008 :

@neolao : au moins ton avis est clair.

@Kevin : je ne connaissais pas LiquidID mais ça rejoint tout à fait le type de service qui peut graviter autour d'OpenID.

@Eric :

> C'est souvent suffisant pour pas mal de choses.

En fait c'est là où ça coince, je ne vois pas dans quelles utilisations c'est plus pertinent (en terme de simplicité) qu'OpenID, ça suffirait pour quoi concrètement ?

Je ne connaissais pas botbouncer, merci.

@giz404 : oui j'ai vu ton commentaire juste avant de poster le billet. Si ça se trouve c'est juste une collecte d'emails déguisée... demain je lance un CardID qui crée un hash à partir de votre numéro de carte bleue ! ;-)

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

@Damien B. :

> Moui. Faut vouloir le dire vite.

J'aime bien te tendre des perches dans mes billets :-).

Je suis d'accord sur OpenID, il faut différencier le but et le protocole.

Concernant OAuth, je t'invite à lire ce thread récent http://groups.google.com/group/oauth/browse_thread/thread/d8ec85782c46c23f

Effectivement, je suis d'accord sur le fait que l'autorisation est laissée au provider mais si l'on se place du point de vue utilisateur, il autorise bien l'accès à une ressource (après s'être authentifié, ce qui en fait une combinaison des deux, soit).

Ta conclusion me fait penser à ce qui s'est passé avec XFN et FOAF... rien de bon pour l'utilisateur (et encore moins pour le développeur).

Damien B le 17/07/2008 :

"Je suis d'accord sur OpenID, il faut différencier le but et le protocole."

L'identification n'est pas un but, c'est juste que c'est par nature déclaratif. Par exemple, si on me croise dans la rue, je serais identifié en tant que "le gros mal rasé avec des boutons bizarres autour des yeux". Mais plusieurs individus peuvent correspondre à cette identité déclarative, seule le processus d'authentification ("étiez vous le gros mal rasé à 10h jeudi dernier place de l'Eglise ?") permet de faire quelque chose de validé avec cette identité.

"Concernant OAuth, je t'invite à lire ce thread récent"

Oh ben oui, que des participants au projet, ça va être objectif :-)
Lisons une page liée dans ce fil :
"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." (fautes d'origine)

C'est la partie "limits set by the you and the Service Provider". Dans OAuth, il n'y a *aucune* notion de gestion de droits. A savoir, comment un Consumer sait s'il a le droit d'accéder à telle ou telle ressource dans OAuth ?
Réponse 1 : échange de paramètres supplémentaires, spécifiques au Service Provider (car notion non codifiée dans OAuth)
Réponse 2 : il y va avec son jeton d'accès au fusil, et ça passe ou ça casse

Exemple concret d'utilisation d'une gestion simple des droits simple : droit lecture, droit écriture dans mixin.
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'il les lise.
On repart de ton post :

"Initialisation" => pas de notions de droits, c'est du tout ou rien

"Interaction"
"Un autre avantage qui n'a pas été mis en pratique afin de faciliter le cheminement de l'utilisateur est de pouvoir limiter l'accès à certaines ressources, voire de régler finement le type d'accès (lecture/écriture)."

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'une début de gestion de droits *au niveau de OAuth*. Si non, c'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.

"mais si l'on se place du point de vue utilisateur, il autorise bien l'accès à une ressource (après s'être authentifié, ce qui en fait une combinaison des deux, soit)."

Si l'on se place du point de vue utilisateur final, l'utilisateur autorise l'accès à une ou des ressources. Mais l'autorisation en elle-même n'a pas grand chose à voir avec OAuth, il a surtout authentifié (CNRTL : "Attester, certifier le caractère authentique de quelque chose ou de quelqu'un.") que c'é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'accès.

David, biologeek le 17/07/2008 :

@Damien B:

> L'identification n'est pas un but

En effet, je voulais parler de l'objectif qui est la déclaration d'identité mais j'ai pas trouvé le bon terme.

> A savoir, comment un Consumer sait s'il a le droit d'accéder à telle ou telle ressource dans OAuth ?

Dans mon implémentation, j'ai ajouté le paramètre 'scope' pour désigner la ressource considérée mais ce n'est pas standard (même si Google l'a fait aussi), il me semble que c'est plutôt la solution 2 qui a été pensée à l'origine. Espérons que tout ça soit normalisé dans une future version.

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

Bon je me rends compte que j'ai peut-être pas été très clair sur cette partie et qu'il faut différencier la spécification de mon implémentation.

Concernant django-oauth, tu peux laisser le choix à l'utilisateur lors de l'initialisation de spécifier la ressource considérée et si elle est accessible en lecture/écriture (ce n'est pas utilisé dans mixin mais c'est générique dans la lib).

En revanche la spécification ne mentionne/normalise pas ces problématiques (d'où la partie limites de mon précédent billet).

> La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d'accès.

Pas exactement car selon l'implémentation un jeton peut être dédié à une ressource et/ou à un droit. C'est le moment où une spec trop limitée est à l'origine d'extensions et d'innovations de la part des devs qui sont ensuite réintégrées dans la spec. L'éternel lombric théorie/pratique avançant par à coups.

Damien B le 17/07/2008 :

> > La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d'accès.
> Pas exactement car selon l'implémentation un jeton peut être dédié à une ressource et/ou à un droit.

Donc IRC et le web ne sont pas orthogonaux, parce que selon l'implémentation, tu peux avoir un navigateur web qui est client IRC. C'est la non-orthogonalité 2.0 :-) Parce que selon l'implémentation, ça veut dire selon le Service Provider, on retourne à la case départ :-)

> C'est le moment où une spec trop limitée est à l'origine d'extensions et d'innovations de la part des devs qui sont ensuite réintégrées dans la spec.

Ah, "innovation", c'est donc ça le secret. Regardons la mailing list (je ne trouve pas de brouillon de la spéc en ligne)... qu'est ce qu'on va trouver dans les Common Extensions :
"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."

Ajouter des droits à un jeton d'accès existant. D'où vient cette notion de droits ?

Septembre 2007 :
"By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer. A Consumer either has access to
Protected Resources or it doesn't."

OAuth 2008.1 Core => pas de texte en ligne

Qu'est ce qu'on a d'autre... OpenFile

"The OpenFile idea is essentially the combination of:
OAuth/Core + OAuth/Rights (TBD) + OAuth/Discovery + GrantedResources (represented as an Atom feed and an OAuth Protected
Resource)

It has been difficult to decide what form this idea should be in. Currently the rights and granted resources "resource" are the new
elements and have been combined into the OpenFile spec, although I recognize that these are orthogonal components. We've decided to put all these elements together to attempt to provide a single spec that
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."

Tiens, lui a un concept d'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'attente d'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.

C'est pas mal ce système de mail en fin de compte. Dommage qu'il n'y ait pas de copie dans une quelconque boîte "courrier envoyé". Ca s'appelait comment déjà ce truc ? Cocomm.. ??

Eric le 17/07/2008 :

@Thesa: ah mais il ne s'agit pas de te mettre en liste grise. Il s'agit de t'y laisser. Ce que je veux dire c'est que avoir un provider connu est sérieux est un moyen (supplémentaire) de s'assurer que tu n'es pas un robot/spammeur.

Il est donc logique qu'on te mette plus facilement sur liste blanche. C'est un point "en plus" pour ceux qui utilisent ces providers. Ce n'est pas un point "en moins" pour les autres.

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'autres s'y sont essayés et ce n'est pas si simple. Donc à défaut, proposer au moins une white-list pour ceux dont on sait qu'ils sont clean (parce que d'un provider sérieux qui fait son boulot sur le sujet), je me vois mal leur reprocher.

webtik le 18/12/2008 :

@David et comme le disait justement @Damien juste pour rajouter quelques choses à cela...

l'identification est ce que je suis - vérification 1 parmi N
On ne vérifie pas OpenID de cette manière donc authentification pour moi...

l'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...

Mais si quelqu'un peut me l'expliquer différemment je suis preneur ;)