Spätestens jetzt sollte ja wirklich jeder Internet-Bewohner seine eigene OpenID haben… ob er weiß ist eine andere Geschichte 🙂

…und das sollte doch wiederum Grund genug sein seine Seite sofort OpenID tauglich zu machen, nachher wissen die armen Menschen gar nicht wohin mit ihrer OpenID…

Spaß beiseite… natürlich besteht generell nicht das Problem an fehlenden OpenID-Providern, aber die Ankündigungen von Microsoft und Google sollten bisherigen Zweifeln dennoch signalisieren, dass OpenID der aktuelle de facto Standard für Single Sign-On im Web sein dürfte.

Mehr zu dem Thema:

Sollte das das Ende der proprietären Formate sein?

Hier klicken, um den Inhalt von Vimeo anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von Vimeo.

Wer es selbst ausprobieren möchte und lieber liest anstatt Videos zu schauen, der findet im Microsoft Live Services Blog eine ausführliche Anleitung.

(via)

Will Norris hat vorgestern ausführlich über die neuen Features seines WordPress-Plugins berichtet. Das wohl interessanteste Feature von wp-openid 3.0 ist der neue OpenID-Provider:

The next major release of wp-openid includes a built-in OpenID provider and delegation engine. This will certainly be the most exciting feature of this release for most people, so let me explain a bit how it works. Each authorized user on the WordPress blog will have an OpenID at the author posts URL (ie. http://example.com/author/admin). Authorization to use the OpenID provider is controlled based on user roles and is managed in the main OpenID settings page.

Das Plugin kann in zwei verschiedenen Modi betrieben werden. Multi-user erstellt aus jeder Autor-URL (z.B. http://example.com/author/admin/) eine OpenID während blog-owner für Private-Blogs mit nur einem Autor gedacht ist und die Home-URL zur OpenID (z.B. http://example.com) macht:

In multi-user, the default configuration, the server supports a feature in OpenID 2.0 called OpenID Provider driven identifier selection. What this means is that ANY user on that blog can enter the home URL as their OpenID, and the OpenID provider itself will make sure that the correct identifier is returned to the relying party. The final identifier will still be something like http://example.com/author/admin/, but the user only needs to enter example.com at a relying party. If you’ve used ever used Yahoo’s OpenID provider, then you’ve probably seen how this works.

Zwei weitere spannende Features sind die Hooks, als Schnittstelle für z.B. andere Plugins…

I haven’t sat down to document them all yet, but I’m adding in more hooks for other plugins to add functionality. Want to pull profile data from FOAF instead of sreg? No problem, now you have a hook you can implement. This makes everything in the plugin much more lightweight and “loosely joined” which is always good. All of the existing non-core OpenID functionality (like SREG) is currently using these hooks.

…und die Unterstützung des OpenID-Firefox-Plugins (welches übrigens auch mit der Version 2.x funktioniert) über das DiSo XRDS-Simple Plugin.

Ich habe das Plugin bisher nur einmal ausprobiert, da es noch einige kleine Fehler hat und die Admin-Oberfläche des OpenID-Providers noch gänzlich fehlt. Trotz dieser kleinen Fehler merkt man, dass sich Will Norris für diese Version sehr viel Zeit (die er sicherlich auch hatte) genommen hat und ich bin sehr gespannt auf die fertige Version.

Wer sich nochmal ausführlich mit den Features beschäftigen will, sollte unbedingt Will Norris‘ Artikel darüber lesen: