Für den User heißt das im Klartext, dass man, nachdem man sich per openID angemeldet hat nicht mehr per Username/Passwort seine Daten nochmals zum Austausch freigeben muss, sondern die Datenfreigabe geschieht in einem Rutsch direkt bei der Anmeldung/Registrierung:

Die erneute Implementierung findet man bei www.huffingtonpost.com. Gut, die Seite interessiert den deutschen Nutzer vielleicht nicht wirklich wahnsinnig, funktioniert aber einwandfrei und zum ausprobieren mal ganz gut. Das einzige, was ich zu bemängeln weiß ist, dass ich innerhalb des Dialoges den Zugang zu meinen Daten nicht sperren konnte. Vielleicht war ich da aber nicht wirklich schlau genug, wer weiß.

Na dann hoffe ich doch, dass ich bald mal einen Post zustande bekomme, indem ich das Hybrid-Protokoll genauer erkläre

Feel free to Flattr this post at flattr.com, if you like it.

- Autorisierung und Austausch von Profildaten, also wer ist der User, der meinen Service benutzen möchte?
- Welche Daten dürfen wann und wo verwendet werden?
- Wie ist der User sozial vernetzt?
- Was treiben der User und seine Freunde gerade?

Demnach wird es wohl mal Zeit etwas Licht ins Dunkel zu bringen und die Möglichkeiten vorzustellen, zu evaluieren und (wenn möglich) miteinander zu vergleichen. Aber erstmal, was gibt es eigentlich miteinander zu vergleichen?

Open…

Von den offenen Technologien muss man an dieser Stelle wohl als erstes den Open Stack nennen. Der Open Stack ist eine Sammlung von Technologien, die Authentifizierung (openID), Autorisierung (oAuth), Kontaktaustausch(Portable Contacts) und Anwendungs-Portabilität(Open Social) beschreiben. Dazu gehört auch noch XRDS-Simple, dass für Discovery/’Routing’ zuständig ist. Der Herr Pfefferle hat den open stack mal als OSI-Modell der offenen Standards beschrieben, was ich ganz treffend finde und ich will meinen, dass damit ist ja schonmal eine ganze Menge abgehandelt ist. Und auch wenn der Begriff open stack in Internetzeit gerechnet schon fast aus dem Mittelalter stammt, gibt es bisher kaum vergleichbare Ideen und die dort enthaltenen Spezifikationen werden nach wie vor weiterenwickelt.

Neben den Open Stack-Technologien und Austauschmöglichkeiten rücken derweil die User-Aktivitäten, die plattformübergreifend ausgetauscht werden wollen, in den Vordergrund des Geschehens. Das wird sehr gut mit der (noch im Draft-Zustand befindlichen) Atom-Activity-Extension beschrieben und scheint mir sich zunehmend auch durchzusetzen.

Facebook Connect

Während die offenen Technologien für sich gekapselt sind und es für die einzelnen Probleme jeweils eine für sich geschlossene Lösung gibt, sieht das bei Facebook-Connect schon ganz anders aus. Natürlich gibt es auch hier für die unterschiedlichen Bedürfnisse unterschiedliche Möglichkeiten, die Daten auszutauschen, aber prinzipiell ist FBC eine in sich abgeschlossene API (für mich beim Einlesen eine eierlegende Wollmilch-Api ). Das bedeuted, dass der Austausch der unterschiedlichen Daten, nach der Authentifizierung mit dem facebook-eigenen Mechanismus, über ebenso facebook-eigene Technologien, wie die Facebook Markup Language(FBML), die Extended Facebook Markup Language (XFBML), die Facebook Query Language (FQL), eine RESTful Api oder über die Javascript-Library vonstatten geht.

Google Friend Connect

Google Friend Connect ist Googles Versuch in das soziale Web-Geschehen einzugreifen, was ja auch nicht unsinnvoll ist, da ja fast jeder einen Google-Account hat. Zum Datenaustausch setzt Google auch auf die oben schon z.Teil genannten Technologien, wie openID, oAuth, open social, Activity Extension und Portable Contacts (könnte vielleicht auch daran liegen, dass Google den Kram mehr oder weniger entwickelt hat oder zumindest stark beteiligt war).

MyspaceID

Ich wage mal zu behaupten, dass Myspace im großen und ganzen nicht so eine große Rolle in der hier erwähnten Angelegenheit spielt. Da die Jungs und Mädels sich dort aber auch sehr viel Mühe geben erwähne ich es mal der Vollständigkeit halber. Auserdem ist Myspace zwar auf dem absteigenden Ast, hat aber immernoch eine große Nutzer- und Fangemeinde.
MyspaceID ist ein Mittelding aus proprietärer und offener Lösung. Für Autorisierung und Benutzerdatenaustausch an sich wird dort eine eigene API (Javascript und REST) benutzt, während zur Authentifizierung, die Aktivitäten und die Apps je oAuth, die Atom-Extension und open social verwendet wird. Ich kann die Strategie hierbei nicht ganz nachvollziehen und denke, dass Myspace sich mit seiner proprietären MyspaceID statt openID keinen so großen gefallen getan hat, denn wer um Nutzerdaten kämpft sollte vielleicht nicht seine Energie in die Entwicklung eigener SignOn-Technologien stecken, die dann eh niemand implementiert (oder schonmal jemand einen: mit-myspace-einloggen-knopf gesehn?). Nja..Meinungen, Meinungen, Meinungen…..

Update: Wie ich auf Grund des Feedbacks gelernt habe benutzt Myspace komplett den open stack und nicht, wie von mir fehlerhaft dargestellt, eine teils eigene Lösung.

Soweit so gut. Wie unschwer zu erkennen ist kann man also feststellen, dass der Kampf des Datenaustauschs im Großen und Ganzen zwichen den offenen Standards, die eben auch von Google eingesetzt werden, und FacebookConnect abspielt. Dies könnte den Schluss zulassen, dass man sich näher damit beschäftigen müßte, da es ja nur Facebook ist, was offen geschlossen (hihi) agiert. Aber mit 300 Millionen Usern und der Funktion als Datenhub, denn jeder verknüpft ja Twitter, Flickr und Sonstiges mit Facebook, ist dies eine Tatsache, die keinesfalls vernachläßigt werden darf.

…und so gehts dann weiter

Der weiter Plan ist deswegen die Eingangs erwähnten Fragen hinsichtlich Datenqualität und -quantitität, Implementierung(theoretisch, denn ich hab ganz ehrlich keine Zeit spasseshalber mal alles zu implementieren) und Doku, Sicherheit/Transparenz/Usability zu beantworten. Dabei werde ich mich aber wohl auf Facebook vs. Open beschränken.

Feel free to Flattr this post at flattr.com, if you like it.