open-web-podcast.png

Diesmal mit Thomas Huhn, dem Mann hinter dem ersten deutschen OpenID-Provider MeinGuter.name und dem Mitbegründer von SpreadOpenID.org.

Themen des Podcastes sind unter Anderem die neuen OpenID-Provider Google und Microsoft, Vor- und Nachteile des Directed Identity Protokolls und die E-Mail Adresse als bessere OpenID (?).

Thomas hat sich nach dem Podcast übrigens noch ein paar interessante Gedanken über die Zukunft von OpenID gemacht (OpenID Germany ist übrigens auch ein Projekt von ihm).

Viel Spaß beim hören und lesen :)

Die Links zur Sendung gibt’s wie immer hier!

Den Podcast abonnieren:

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:

Sumit Kataria erklärt in seinem Blog die Funktionsweise von OAuth.

It is a standard method of authenticating users across different services means that mashup builders need only write one authentication process, then apply it to all data sources that support the standard. That’s hot and new, and it’s now spreading faster around the web than we thought.

…außerdem arbeitet er gerade an einer OAuth-Library für Drupal-Services.

Right now we are working with Andy Smith’s OAuth php library to implement OAuth to Drupal and Services API.

(via)

Nach seinem Artikel über DataPortability und Chris Saads Antwort, äußert sich Chris Messina nochmals sehr kritisch zu dem Thema in der DP Google-Group.

Gerade nach den Pressemeldungen über MySpaces “Data Availability”:

[...] MySpace is announcing a broad ranging embrace of data portability standards today, along with data sharing partnerships with Yahoo, Ebay, Twitter and their own Photobucket subsidiary. [...] #

…oder über Googles “Friend Connect”:

As we reported on Friday, Google will be launching its own data portability effort called Friend Connect. [...] #

…ist (meiner Meinung nach) einer der treffendsten Punkte in Chris’ Kommentar:

The behavior indicates [...] that the DP-PR machine is simply more effective at taking credit for big moves that they had nothing directly to do with than to promote smaller independent, more “grassroots” groups who are *actually* making moves towards effective data portability, like Dopplr, like TripIt, like Satisfaction and Twitter and the rest. I don’t believe I’ve seen any press releases go out about them, and yet I would consider them to be on the vanguard giving people access to their data in real-world, useful ways.

Ich muss Chris Messina leider recht geben, keines der groß angekündigten (und mit DataPortability in Verbindung gebrachten) Systeme betreibt wirklich DataPortability (zumindest zum aktuellen Zeitpunkt). Sowohl MySpace als auch Google verwenden zwar offene Standards (Facebook nutzt sogar keinen der erwähnten Standards für “Facebook Connect”) wie OAuth oder OpenID, aber bisher leider nur hinter ihren “Walled Gardens“.
Was ist mit den wahren DP “Helden” wie Dopplr, Magnolia oder Satisfaction, die wirkliche Anwendungsfälle schaffen und sich dem Ziel der portablen Daten Schritt für Schritt nähern?

Carsten Pötter beschreibt das bestehende Problem auch noch einmal von einer etwas anderen Seite:

DataPortability, Data Availability, Facebook Connect, Google Friend Connect, DiSo,… [...] All the mentioned initiatives just lead to confusion. We can’t be sure if we mean the same thing when talking about data portability anymore. It’s probably best to abandon that term and just focus on single issues. Can I export my profile or can it just be accessed by a third party?

Man sollte in Zukunft vielleicht etwas sparsamer mit dem Titel DataPortability umgehen und ihn nicht für jede “simple” hCard vergeben.

Da genießt man einmal ein internetfreies Pfingst-Wochenende und alle Welt macht DataPortability (naja, fast)… Das heißt, ich werde die nächsten Tage ne Menge zu lesen haben und sicherlich auch bald meinen Senf dazu geben ;)

Lesenswert ist außerdem noch Chris Messinas (DiSo) Artikel Thoughts on DataPortability und Chris Saads (DataPortability) Antwort Responses to DataPortability questions.

Anfang Februar habe ich einen interessanten Bericht über “How portable is your Skype data?” von Phil Wolff gelesen. Der Artikel befasst sich mit der Daten-Portabilität von Nicht-Web-Applikationen am Beispiel von Skype. Leider wird diese Art des Datenaustauschs (z.B. zwischen Desktop-Anwendungen und Web-Anwendungen) auch von DataPortability.org noch nicht ausreichend behandelt und es fehlen Formate die diese Art von Austausch ermöglichen (APML mal ausgenommen).

Genau diesen Bericht müssen auch Microsoft und Google gelesen haben bevor beide diesen Monat ihre Contacts-APIs veröffentlichten :)

Nach den Beschreibungen von Google:

  • Import a user’s Google contacts into their web or desktop application
  • Export their application’s contact list to Google
  • Write sync applications for mobile devices or popular, desktop-based contact management applications

…und Microsoft:

To tackle the issue of contact data portability it is important to reconcile the larger issue of data ownership. Who owns the data, like email addresses in a Windows Live Hotmail address book? We firmly believe that we are simply stewards of customers’ data and that customers should be able to choose how they control and share their data. We think customers should be able to share their data in the most safe and secure way possible, but historically this openness has been achieved largely through a mechanism called “screen-scraping,” which unduly puts customers at risk for phishing attacks, identity fraud, and spam. Now with the Windows Live Contacts API, we have provided an alternative to “screen-scraping” that is equally open but unequivocally safer and more secure for customers.

…könnte man fast meinen, dass die Hürde des Datenaustauschs zwischen Desktop-Anwendungen und Web-Anwendungen überwunden wäre.

Nicht ganz… Leider basieren beide Systeme “noch” auf proprietären Webservices und müssen unterschiedlich angesprochen werden, was eine Menge zusätzlichen Entwicklungsaufwand bedeutet. Die wesentlich bessere Lösung wäre natürlich eine einheitliche Contacts-API oder wie Carsten Pötter meint:

Of course, it was great if a more open protocol like OAuth was used, but the announcement might encourage more social networks and other corporations to pursue similar steps.

Immerhin gehören die Social-Network-Anti-Patterns durch diese Entwicklungen hoffentlich bald der Vergangenheit an…

Wie schon mehrfach berichtet wurde, hat Google mit der Social Graph API einen großen Schritt in Richtung DataPortability gemacht. Die Social Graph API ist eine weiterer Coup von Brad Fitzpatrick (Live Journal, memcached und OpenID) und bietet eine einfache API um “public connections” die man zu genüge im Netz erstellt hat zu interpretieren um wiederverwendbar zu machen.

With the Social Graph API, developers can now utilize public connections their users have already created in other web services. It makes information about public connections between people easily available and useful.

Social Graph API Die Google API setzt hauptsätzlich auf das Microformat XFN (V 1.1) zum darstellen des Sozialen Netzes.

XHTML Friends Network benutzt das rel Attribut von Links um Verbindungen zwischen Personen darzustellen. <a rel="me" /> kennzeichnet z.B. eine weitere Webseite des Verlinkenden. Weitere Formate (bei Google Edge Types) sind das auf RDF basierende FoaF und OpenID delegation Links <link rel="openid.delegate" />.

Die API ist recht simple und lässt sich komplett über URL Key/Value Paare konfigurieren…

http://socialgraph.apis.google.com/lookup?<parameter 1>&<parameter 2>&<parameter n>

…und stellt die Ergebnisse in JSON dar.

Social Graph API Client

Steve Ivy einer der Gründer des DiSo Projekts hat eine Social Graph API Client Klasse in PHP geschrieben und im DiSo SVN zur Verfügung gestellt.

I wrote a quick and dirty client in PHP that cosumes the JSON and returns it in a data structure. #

Weiterlesen…