Editer le texte de cette page (date de la dernière modification: 12 Août, 2007 11:35 (diff))

Open ID

Page en cours d'écriture à la recherche de son mainteneur !

BlocRésumé

Désormais c'est avéré, OpenID s'impose de facto comme l'un des BlocsDeConstructionPourExperts.

OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant supporter la technologie) sans avoir à retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique identifiant OpenID. Le modèle OpenID se base sur des liens de confiance préalablement établis entre les fournisseurs de services (sites web utilisant OpenID par exemple) et les fournisseurs d’identité (OpenID providers).
WikiPediaFr:OpenID

Liens en français

Ressources en anglais

Discussion sur localisation de traductions :

Présentation de SimonWillison au Fowa 2007 qui mériterait localisation par les pairs francophones. A défaut de pairs, les FrèresPinko pourraient faire l'affaire --JeanChristopheCapelli 12 Mars, 2007 21:36 CET


Bonne idée. Le mieux serait que tu démarres la traduction sur une page wiki (par exemple AvenirOpenID ou quelque chose comme ça ?). Tout prêt à aider pour la recherche inconographique et l'emballage du tout dans un S5. Pour finir, cette page mérite un sacré remaniement. ArnaudFontaine (le méchant très méchant dans les métaverses) me signalant qu'OpenID est désormais une base simple et stupide pour d'autres protocoles internet comme les futures cartes de visite dans SecondLife et autres mondes. Par ailleurs suite à notre discussion d'hier, je pense détacher sous peu la branche Identité du BarCampBank et aimerait que le BarCampBank puisse financer la venue de SimonWillison en France pour animer un BarCamp et/ou un GeekDinner. -- ChristopheDucamp 13 Mars, 2007 6:13 CET

Extraction pour traduction de WikiPedia:OpenID à remanier une fois relue sur WikiPediaFr:OpenID

OpenID est un système décentralisé d'identité digitale, dans lequel n'importe quelle IdentitéEnLigne d'un utilisateur est donné par un URL (comme pour un Blog ou une page personnelle) ou un [[XRI]] dans la version la plus récente, et peut être vérifiée par tout serveur faisant fonctionner le protocole. Démarrée avec la version 1.1, OpenID utilise le protocole de service de découverte [[Yadis]]. Le travail en cours est actuellement le développement d'une Authentification OpenID 2.0, bien qu'OpenID se développe maintenant à l'intérieur d'un cadre bien plus complet qui supportera d'autres services d'identité en parallèle de l'[[authentification]].

Sur les sites permettant OpenID, les utilisateurs Internet n'ont pas besoin de créer et gérer un nouveau compte pour chaque site avant de pouvoir y accéder. Au lieu de cela, ils on simplement besoin de pouvoir s'identifier vai un site de confiance qui supporte OpenID? appelé le fournisseur d'identité (ou IdP, parfois appelé un [[i-broker]]). Le fournisseur d'identité peut ensuite confirmer la propriété de l'identifiant utilisateur OpenID à d'auters sites agréés OpenID, appelées les relying parties ou RPs. A la différence des architectures uniquement basées sur un unique "sign-on", OpenID ne spécifie pas le mécanisme d'[[authentication]]. Par conséquent, la force d'un login OpenID repose sur la manière dont une partie de confiance connaît les politiques d'authentification du fournisseur d'identité. Sans cette connaissance, OpenID ne pourrait être utilisé sur des comptes sensibles comme ([[banque]], [[e-commerce]] transactions, etc.), mais si un fournisseur d'identité utilise une [[authentification solide]], OpenID peut être utilisé pour tous types de transactions.

OpenID gagne de plus en plus l'adoption parmi les grands sites, avec des organisations comme Wikipedia et [[Technorati]] annonçant qu'elles supporteront OpenID.

Développement

Le système OpenID a été initialement développé par BradFitzpatrick de LiveJournal, même si [[David Recordon]] de [[VeriSign]], [[Josh Hoyt]] de [[JanRain]] et [[Dick Hardt]] de [[Sxip]] sont désormais des coauteurs. Les spécifications à venir d'OpenID sont en train de se développer dans un mode méritocratique sur specs@openid.net. Pour aider à propager le déploiement additionnel, un groupe de vendeurs a annoncé en août 2006 un programme doté d'une prime de $50 000 USD offrant $5 000 USD à chacun des 10 premiers projets OpenSource à fort dimensionnement pour implémenter le support d'OpenID.<ref>Le site marketing de communauté I Want My OpenID, y compris le programme de récompense ( voir bounty sponsors) </ref>

Terminologie

Un glossaire basique des termes utilisés avec OpenID :

  • utilisateur final — La personne qui veut faire valoir son identité sur un site.
  • identificateur — l'[[URL]] ou [[XRI]] choisi par l'utilisateur final comme son identificateur OpenID.
  • fournisseur d'identité — un fournisseur de services offrant le service d'enregistrements d'URLs OpenID ou de XRIs et fournissant une authentification OpenID (et possiblement d'autres services d'identité).
  • relying party[1] — Le site qui veut vérifier l'identificateur de l'utilisateur final.
  • serveur ou agent-serveur — Le serveur qui vérifie l'identificateur de l'utilisateur final. Ce peut être le propre serveur de l'utilisateur (comme son blog) ou un serveur opéré par un fournisseur d'identité.
  • agent-utilisateur — Le programme (comme un navigateur) que l'utilisateur final va utiliser pour accéder à un fournisseur d'identité ou une "relying party".

Comment fonctionne OpenID

Un site web, tel que <code>exemple.com</code>, qui veut permettre les logins OpenID à ses visiterus place un formulaire de login quelque part sur la page. A la différence d'un formulaire de connexion typique, qui invite l'utilisateur à rentre un NomUtilisateur et un MotDePasse, il n'y a seulement qu'un champ - pour l'identificateur OpenID. Le site peut choisir d'afficher un petit logo OpenID proche du champ de saisie. Ce formulaire est connecté à une implémentation d'une libraire client OpenID.

Si une utilisatrice appelée Alice veut se connecter sur <code>exemple.com</code> en utilisant l'identificateur OpenID <code>alice.openid-provider.org</code> qu'elle a enregistré avec le fournisseur d'idenité <code>openid-provider.org</code>, elle va simplement sur <code>exemple.com</code> et saisit <code>alice.openid-provider.org</code> dans la boîte de connexion OpenID. En commençant par l'Authentication 2.0 d'OpenID (et supportée dans quelques implémentations d'OpenID 1.1), Alice pourrai aussi se connecter en saisissant un [[i-name]] comme <code>=exemple.alice</code> ou <code>=exemple.community*alice</code>.

Si l'identificateur est un URL, le première chose que fait la "relying party" (<code>exemple.com</code> est de la transformer dans une forme canonique, c'est à dire, <code> http://alice.openid-provider.org/</code&gt;. Avec OpenID 1.0, la "relying party" requête ensuite la page web située sur cette URL et, via un tag lien HTML, découvre que le serveur fournisseur est, disons <code> http://openid-provider.org/openid-auth.php</code&gt;. Il découvre aussi si oui ou non il devrait utiliser une identité déléguée (voir en dessous). En démarrant avec OpenID 1.1, le client fait la découverte en requêtant le document XRDS (appelé aussi le document Yadis) avec le contenu type <code>application/xrds+xml</code> qui peut être disponible sur l'URL cible et toujours disponible pour un XRI cible.

Il existe deux modes dans lesquels la "relying party" peut communiquer avec le fournisseur d'identité :

  • <code>checkid immediate</code>, qui est orienté machine et dans lequel toutes les communications entre les deux serveurs sont faites est l'arrière-plan, sans la connaissance de l'utilisateur ;
  • <code>checkid setup</code>, dans lequel l'utilisateur communique avec le serveur fournisseur en utilisant directement le même navigateur utilisé pour accéder au site de la "relying party".

La seconde option est plus populaire sur le Web ; aussi, <code>checkid immediate</code> peut se replier sur <code>checkid setup</code> si l'opération ne peut pas être automatisée.

D'abord, la "relying party" et le fournisseur (en option) établissent un secret partagé - un "handle associé", que la "relying party" stockes ensuite. S'il utilise <code>checkid setup</code>, la "relying party" redirige le navigateur web de l'utilisateur au fournisseur. Dans ce cas, le navigateur d'Alice est redirigé vers <code>openid-provider.org</code> ainsi Alice peut s'authentifier elle-même avec le fournisseur.

La méthode de l'authentification peut varier, mais généralement, un fournisseur OpenID demande un mot de passe (et puis stocke possiblement la session de l'utilisateur en utilisant des cookies, comme le font beaucoup de sites web avec des authentifiations fondées sur le mot de passe). Alice peut être invitée à entrer son mot de passe si elle n'était pas connectée sur <code>openid-provider.org</code>, et puis on lui demande si elle fait confiance, disons, à <code> http://example.com/openid-return.php</code&gt; - la page désignée par <code>example.com</code> comme celle où l'utilisateur devrait revenir après avoir complété l'authentification - pour recevoir les détails sur son identité. Si elle répond positivement, l'authentification OpenID est considérée comme réussie et le navigateur est redirigé vers la page de retour désignée avec les certificats donnés. Si Alice décide de ne pas faire confiance au site "relying party", le navigateur est encore redirigé - néanmoins, la "relying party" est notifiée que sa requête a été rejetée, par conséquent <code>exemple.com</code> refuse d'authentifier Alice à son tour.

Néanmoins, le processus de connexion n'est pas encore terminé parce qu'à ce stade, <code>exemple.com</code> ne peut pas décider si les certificats reçus proviennent vraiment de <code>openid-provider.org</code>. S'il a pu établir précédemment un secret partagé (voir ci-dessus), le consommateur peut valider le secret partagé reçu avec les certificats contre celui précédemment stocké. Un tel consommateur est appelé stateful parce qu'il stocke le secret partagé entre les sessions. En comparaison, un consomamteur stateless ou dumb doit prendre une requête suppléntaire (<code>check authentication</code> pour garantir que les données proviennent vraiment de <code>openid-provider.org</code>.

Après que l'identificateur d'Alice ait pu être vérifié, elle est considérée connectée dans <code>example.com</code> sous <code>alice.openid-provider.org</code>. Le site peut alors ensuite stocker la session, si c'est sa première connexion, inviter Alice à saisir quelque information spécifique sur <code>exemple.com</code>, afin de terminer l'enregistrement.

Identificateurs OpenID

En démarrant avec OpenID Authentication 2.0 (et quelques implémentations 1.1), il y a deux types d'identificateurs qui peuvent être utilisés avec OpenID : les URLs et les XRIs.

URLs

Il existe deux façons d'objtenir une URL permettant OpenID qui puisse être utilisée pour se connecter sur tous les sites Web acceptant OpenID.

  1. D'abord, utiliser un URL existant que vous contrôlez (comme celle de votre blog ou page personnelle), et si vous savez éditer le HTML, vous pouvez insérer les instructions de code HTML à la spécification OpenID. Notez qu'utiliser un sous-domaine peut rendre votre OpenID plus mémorisable et plus facile à écrire, mais ce n'est pas obligatoire.
  2. La seconde option est d'enregistrer un identificateur OpenID avec un fournisseur d'identité. Ils offrent la capacité d'enregistrer un URL (généralement un domaine de troisième niveau) qui sera automatiquement configuré avec le service d'authentification OpenID.

XRIs

Les [[XRI]]s sont un nouvelle forme d'identificateurs Internet conçus spécifiquement pour l'identité numérique inter-domaines. Par exemple, les XRIs viennent sous deux formats -- les [[i-nom]]s et les [[i-nombre]]s -- qui sont généralement enregistrés simultanément comme synonymes. Les I-noms sont réassignables (comme les noms de domaines), alors que les i-nombres ne sont jamais réasssignables. Quand un i-nom XRI est utilisé comme un idenfificateur OpenID, il est immédiatement résolu vers le nombre synonyme i-nombre (l'élément d'IDcanonique du document XRDS). Ce i-nombre est l'identificateur OpenID stocké par la "relying party". En ce sens, tant l'utiliateur que la "relying party" sont protégés du fait que l'identité de l'utilisateur OpenID ne soit jamais prises par une autre partie comme cela peut arriver avec un URL fondé sur un nom de DNS réassignable.

Voir [[i-name]] pour en savoir plus sur l'enregistrement et la résolution des XRIs.

Voir aussi

  • [[Identity Centric Architecture]]
  • [[Identity 2.0]]
  • [[Light-Weight Identity]]
  • [[YADIS]]
  • [[i-name]]
  • [[Windows CardSpace]]
  • [[Liberty Alliance]]
  • [[Shibboleth (Internet2)]]
  • [[Whobar]]

Références

<references/>

Liens externes

<!-- Avant d'ajouter de nouveaux liens externes, considérez soigneusement si cela ajoute de la valeur à l'article. Wikipedia n'est pas un repository de liens externes, et de fait ce n'est pas un espace de publicité pour les fournisseurs d'OpenID.. --> [[Category:Identity management systems]]

[[de:OpenID]] [[it:OpenID]] [[no:OpenID]] [[pt:OpenID]] [[ru:OpenID]] [[zh:OpenID]]





[1] comment traduire ? confiance

IdentitéEnLigne Live


Une page personnelle ouverte en juillet 2006 devenue depuis une Branche dépendante du Groupe de Réflexion du BarCampBank.

Ce groupe toujours en amorçage prendra le temps de s'installer calmement. Différents contributeurs ont montré leur intérêt pour participer mais pas encore de comité canonique.

Nous n'avons donc pas ici encore d'EnoncéMission explicite, ni quelque WikiNode pour intégrer le WikiNet. Considérez à cette heure (juin 2008) cet espace comme une VilleFantôme destinée à devenir un espace en cours de structuration et d'architecture.

Pour nous retrouver et nous contacter, rejoignez-nous d'abord sur l'IdentitéNumériqueEnQuestion où nous réfléchirons avec OlivierIteanu sur les scénarios pour maîtriser juridiquement son Identité sur Internet. -- ChristopheDucamp