Archive for the ‘OpenID’ Category

Wer bin ich und wenn ja mit wem? – Authentifizierung mit FbConnect oder OpenID

Wie angekündigt werde ich nun heute endlich den “Kampf” eröffnen und dabei die offenen Technologien und im Gegenzug Facebook-Connect mal etwas genauer anschauen (Achtung, im Vergleich zu sonst wird es etwas technischer) :

“Authentifizierung und Austausch von Profildaten. Wer ist der User, der meinen Service nutzen möchte?”

Dank yiid durfte ich mich in letzter Zeit etwas näher mit Facebook und dessen APIs auseinandersetzen (man kann sich jetzt seine Facebook-Aktivitäten in yiid anzeigen lassen). Dies war, nach anfänglich sehr hoher Motivation meinerseits, nicht unbedingt der Spass, den ich erwartet hatte, sondern ist zur etwas größeren Herausforderung mutiert. Wie auch immer hoffe ich, dass ich jetzt nicht zu (negativ) vorbelastet bin und meine Voreingenommenheit sich in Grenzen hält. Sollte ich zu kritisch werden, dann bitte ich dies zu entschuldigen und auf jeden Fall in den Kommentaren anzumerken.

OpenID integrieren

Unter wiki.openid.net/Libraries sind neben den Bibliotheken für alle gängigen Programmiersprachen (Java, C#, Python, Ruby….) auch insgesamt 7 PHP-Bibliotheken gelistet. Für welche man sich dabei entscheiden mag, ist sicherlich letztendlich Geschmacksache. So gibt es bspw. sowohl Plugins für diverse Frameworks wie Symfony oder auch Drupal, als aber auch unabhängige Klassen, die ich persönlich bevorzugen würde, da Plugins, wie für Symfony, meistens doch nicht genau das machen was man will oder nicht zur Projektkonfiguration passen. Meine Empfehlung deswegen sind die PHPOpenID-Klassen von JanRain, mit denen man meiner Ansicht nach nicht viel falsch machen kann (denn ja quasi von den OpenID-Machern gemacht :) ). PHPOpenId bringen eigentlich alles mit, was man für einen lauffähigen Client braucht und für ambitionierte bietet die Bibliothek auch die Möglichkeit, selbst einen Provider zu implementieren. Die Extensions für sReg und Attribute Exchange sind in den Klassen ebenfalls mit enthalten.

Leider habe ich selbst noch nie einen OpenID-Consumer in ein bestehendes Projekt eingebaut. Um mir aber doch eine Meinung bilden zu können habe ich mir heute mal die Mühe gemacht, zumindest mal etwas näher draufzuschauen und bin dem -meiner Ansicht nach großartigen- Tutorial auf Dr. Web gefolgt, um mal eine grobe Consumer-Implementierung bei mir Lokal zu “simulieren”. Dank des Tutorials war dies denkbar einfach und ich habe keine halbe Stunde gebraucht, um einen Login mit meiner OpenID hinzubekommen und die sReg-Daten gabs obendrein noch gratis dazu. (Aufgrund des erwähnten Tutorials spare ich mir an dieser Stelle weitere Details zur Implentierung, denn ich würde sowieso nur das wiedergeben, was dort steht.). Die komplette OpenId-Integration läuft auf der Server-Seite ab, was die Sache auch nochmal vereinfacht und ich musste mich eigentlich lediglich mit dem anständigen Includieren der Klassen und der Kommunikation zwischen meinem Client und dem Provider kümmern und sonst nichts (Warum das erwähnenswert ist sehen wir nachher bei der Facebook Connect – Integration).

Natürlich kann man dies als eine kleine Milchmädchenrechnung auslegen, denn ich habe ja kein komplexes Framework, in das das Ganze integriert werden muss. Doch auf Grund der Einfachheit und der Aussagen anderer Entwickler schätze ich den Aufwand auf keinesfalls höher als einen Tag, womit sich der Arbeitsaufwand in Grenzen hält will ich meinen.

Ist man absoluter Neuling auf dem Gebiet OpenID, dann fällt die Auseinandersetzung mit der Thematik sicherlich im ersten Moment ein wenig schwerer. Aber mittlerweile ist OpenID aus den Kinderschuhen entwachsen und es existieren zahlreiche Erklärungen, Tutorials und Dokumentationen zu OpenID. Hier eine kleine Liste:

OpenID als Consumer für den SingleSignOn zu implementieren scheint mir verhältnismäßig einfach und schnell zu gehen. Mit einem Gewissen Basiswissen und den ausreichenden Dokumentationen fühle ich mich gut gewappnet und konnte schnell und erfolgreich einen Login/Registrierung bauen. Die Integration in ein komplexes Framework kann ich zwar nicht hundertprozentig beurteilen, scheint aber auch vom Aufwand überschaubar. Wenn die Bibliotheken in anderen Programmiersprachen ähnlich komfortabel sind, wie die für PHP, dann fallen mir wenig bis keine Argumente gegen eine Implentierung ein.

Facebook Connect ingetrieren

Während ich mich bei der OpenID-Imlementierung lediglich um die serverseitige Implementierung und damit auf PHP konzentrieren konnte, scheinen die Bedürfnisse für Facebook doch ein wenige vielfältiger zu sein. Für den Registrierungs- und Login-Prozess empfiehlt Facebook in seinen Getting-Startet-Dokus die Implementierung mit Javascript, der FacebookMarkupLanguage UND einer serverseitigen Programmiersprache wie PHP. Die serverseitigen Clien-Libraries sind dabei, wie bei OpenID in jeder gängigen Programmiersprache vorhanden, wobei es allerdings von Seiten Facebooks nur für einige wenige einen Support gibt (z.B. für PHP5). Um überhaupt mit der Facebook-Implementierung beginnen zu können, muss man neben den Library-Include noch eine App innerhalb von Facebook selbst anlegen und korrekt konfigurieren, dort erhält man dann auch die unbedingt notwendige application id und das application secret. Beim erstellen der App wird man aufgefordert, die sogenannte  xd_receiver.htm herunterzuladen und gebeten, diese im Verzeichnisroot der eigenen Applikation abzulegen. Hat man dies alles gemacht, dann kann man mit der eigentlichen Implementierung beginnen.

Leider muss ich an dieser Stelle sagen, dass es den Rahmen dieses ohnehin schon wieder sehr langen Artikels definitiv sprengen würde, eine komplette Facebook-Connect-Implementierung zu beschreiben. Deswegen muss ich vorerst  auf die (englischen) Tutorials, die von Facebook selbst bereitgestellt werden verweisen:

Auf deutsch habe ich dazu noch nichts wirklich Gutes gefunden (wenn ihr eins kennt, bitte in den Kommentaren posten), plane aber in den nächsten Wochen selbst Eines zu schreiben und hier zu veröffentlichen, also noch ein wenig Geduld :) . Grob erklärt läuft das Ganze aber über die Facebook-Session-Cookies ab, und es wird überprüft, ob der User gerade bei Facebook eingeloggt ist. Wenn ja, dann muss man nachschauen, ob man innerhalb des Systems eine passende Fb-UserId hat, wenn ja, dann kann man den User einloggen, wenn nein, dann muss der User den FB-Button klicken (ebenso, wenn er gerade nicht bei Fb eingeloggt ist). Nach dem Klicken auf den Button, dem Login bei Facebook und ggf. der Autorisierung der App kommt der User dann zurück auf den eigenen Service und man überpüft erneut die userid. Gibt es den User tatsächlich noch nicht, dann bietet man eine Registrierung an und speichert daraufhin die Daten und die UserId, gibt es ihn, dann kann man ihn einloggen.

Diese Kommunikation wird insgesamt, wie gesagt mit Javascript, FBML und PHP abgefrühstückt. Sicherlich ist auch eine Implenetierung nur mit PHP und HTML möglich, habe ich aber nur kurz ausprobiert und hat nicht besonders gut geklappt (was auch an mir liegen kann).

Hat man nun alles geschafft und erfolgreich eingebaut und alles funktioniert, dann bekommt man (dank der freizügigen FB privacy policies) auch hier eine Fülle von Informationen über den gerade angemeldeten User. Einen kompletten Überblick darüber findet ihr hier. Vorraussetzung hierfür ist allerdings unbedingt, dass der User eure App hinzugefügt und autorisiert hat.

Die Facebook-Connect-Integration ist mir persönlich sehr schwer gefallen, da mich der Mischmasch aus JS/FBML und PHP extrem irritiert hat. Die Dokumentation der gesamten Facebook-APIs ist zwar unglaublich umfangreich, aber in diesem Fall ist weniger vielleicht manchmal mehr. Beim lesen kommt man von Hölzchen auf Stöckchen und findet eigentlich nie raus, was man jetzt wirklich braucht oder gar falsch macht, wenn etwas nicht klappt. Klar klingt das jetzt sehr schwarz-weiß-malerisch, aber ich habe doch hin und wieder mal irgendwelche APIs angebunden und mir eigentlich selten so schwer getan. Ich schiebe dies auf den Overkill an Informationen, den man bekommt, denn auch die Schritt für Schritt-Anweisungen innerhalb der Doku verweisen einen immer wieder auf weiterführende Informationen und am Ende weiß man gar nicht mehr, wo man vorne angefangen hat.

Genervt hat auch die Registrierung der App innerhalb von Facebook, denn es gibt dann doch ne ganze Menge, die man konfigurieren muss oder jedenfalls kann. Und auch hier hilft einem die Dokumentation nicht so wirklich weiter, denn um komplett zu verstehen, was man wofür braucht oder auch nicht ist man eine ganze ganze Weile erstmal beschäftig. Gefühlt war es so, als hätte ich vorher erstmal ne ein paar Tage recherchieren und Facebook Connect KOMPLETT verstehen müssen, um endlich vernünftig anfangen zu können (und wie gesagt, war jetzt auch nicht meine erste API).

Und leider muss ich noch ein weiteres Minus für Facebook vergeben, denn so schnell ich eben ganz fix den OpenID-Client bei mir lokal implementieren und auch testen konnte, so wenig ging dies mit Facebook Connect, denn die Entwicklung des FB-Logins innerhalb einer lokalen Testumgebung hat nach stundenlangem Rumgefummel immer wieder bloss eine Endlosschleife hervorgebracht. Kann sein, dass es Möglichkeiten gibt, FB lokal zu testen. Wenn ja, dann weiß ich allerdings nicht wie und scheint auch ein wenig mehr Aufwand zu sein. Hinzukommt, dass Facebook den Firebug blockiert, was bedeutet, dass bei angeschaltetem Firebug kein Facebook-Javascript  ausgeführt wird, was das Entwickeln und Debuggen nicht unbedingt besser macht.

Fazit:

  • OpenID – Klar abgegrenzt, übersichtlich und überschaubar im Aufwand mit wenigen Implementierungshürden und guten Dokus. Zudem gut zu entwickeln, weil lokal test- und ausführbar.
  • FacebookConnect – Relativ viele Hürden vorab und Information-Overkill während der Implentierung und bei der Doku. Zudem nicht besonders entwicklerfreundlich durch komplizierte oder nicht mögliche lokale Integration und Testbarkeit. Allerdings: Hat mans mal Verstanden und die Einstiegshürden überwunden, dann ist es ok damit zu arbeiten und warscheinlich sogar relativ einfach :) -> Übrigends auch ein Satz der mir relativ oft beim Einlesen begegnet ist (‘Wenn mans erst verstanden hat…..’)

Jaja, ich weiß, die die mich kennen und die Kritiker unter Euch werden jetzt sagen: “War ja klar, dass sie Facebook per se negativer Beurteilen wird”. Stimmt, ich mag Facebook und seine, von mir als arrogant empfundene, Politik nicht besonders. Aber als ich angefangen habe mich damit zu beschäftigen, war ich hoch motiviert und auch einigermaßen vorurteilsfrei (ausser,dass es eben proprietär ist). Nach einigen Tagen war ich allerdings so frustriert wie noch nie in meinem Entwicklerdasein, was mich eben zu diesem ein wenig schwarz-weiß-malerischen Urteil gebracht hat.

Auserdem muss ich noch dazu sagen, dass es beim nächsten mal um die Autorisierung von Daten geht, also Facebook vs. oAuth und ich habe den Verdacht, dass Facebook dabei etwas besser abschneiden könnte ;) .

Yahoo! als Zwitter

Nachdem ich im letzten Post Yahoo! unverschämter Weise verschwiegen hab bekommen die eben jetzt ihren Eigenen. Nachdem sie bereits im September letzten Jahres eine Referenzimplementierung des openID-oAuth-Hybrid-Protokolls mit Plaxo vollzogen hatten, gab es letzte Woche die Nachricht, dass es nun eine erneute Implementierung des Protokolls gibt, welches eine openID-Authentifizierung direkt mit  oAuth-Autorisierung kombiniert.

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:

hybrid-dialog

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 :)

Ring frei

Datenaustausch (Data Portability) ist mittlerweile ein vielgenutztes Buzz-Word und wird auf unterschiedliche Art und Weisen vollzogen. Ein Konkurrenzkampf zwischen den Protokollen, Spezifikationen und API’s ist in vollem Gange und eine Einigung scheint nicht in Sicht. So arbeiten Facebook, Google und aber auch die Open-Web-Gemeinde an Lösungen, Userdaten auszutauschen und die verschiedenen Services untereinander zu vernetzen. Allen Lösungen liegen dabei die gleichen Problemstellungen zu Grunde:

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

Willkommen in der wirklichen Welt!

Nein, es gab nicht nur schlechte Nachrichten was OpenID betrifft in meiner Blog-Abstinenz. Auch wenn sich die Implementierungen in Grenzen halten ist der Begriff OpenID doch wenigstens etwas populärer geworden.

Sogar Facebook, das eigentlich eher für die Entwicklung proprietärer Lösungen bekannt ist, ist mit viel Tamtam und Getöse der OpenId Foundation beigetreten und hat seine Zusammenarbeit und Unterstützung zugesichert. Zudem ging ein Raunen durch die Netzwelt, als es auf einmal hieß: Facebook implementiert die openID – Relaying Party (Artikel leider auf Englisch, sorry). Denn wenn die Netzriesen wie Facebook, Google und Co. nicht nur ihre Unterstützung zusagen, sondern auch Taten folgen lassen, ist das für jede Technologie ein großer Schritt und kann eine Menge in Gang setzen, da dann plötzlich nicht mehr nur die sowieso schon Interessierten auf etwas aufmerksam werden, sonder auch der Rest der Welt.

Die Freude darüber wurde allerdings schnell wieder gebremst, denn auch hier hat Facebook es wieder geschafft, eine proprietäre Lösung bei der Implementierung der Relaying-Party auf die Beine zu stellen, die eigentlich jeden Gedanken über diese Technologie irgendwie ad absurdum stellt (so zumindest meine persönliche und bescheidene Meinung). Facebook merkt sich nämlich den Provider über ein Browser-Cookie und immer wenn ich mit einem anderen Browser daher komme muss ich mich auf herkömmlichem Weg anmelden, meine openID hinzufügen, um das Cookie zu erhalten und dann funktioniert das Ganze wieder. Richtig, das war irgendwie nicht das was ich wollte, oder?

Da ich nach den Testberichten von den Herren Pfefferle und Pötter den Facebook-Login mit openID gar nicht erst ausprobiert habe, wollte ich dem Ganzen eben eine zweite Chance geben und einfach mal ausprobieren, ob sich etwas entwickelt und vllt. verbessert hat, ist ja jetzt auch alles schon ne Weile her. Leider bin ich schon direkt an der Usability gescheitert und finde einfach nicht die Stelle, wo ich die openID meinem Account hinzufügen kann. Vielleicht weiss ja einer von Euch da draussen, wie derweil der Stand der Dinge ist und möchte seine Erfahrungen in den Kommentaren mit mir Teilen (oder mir auch zumindest verraten, wie und vor allem wo in Facebook ich es selbst testen kann).

Wat macht eigentlich nochmal….openID?

Klar, ich habe lange nichts geschrieben und man könnte den Eindruck bekommen, dass ich damit vllt. auch ein wenig die Kompetenz verloren habe, mir ein Urteil über die Details zum Thema openID zu bilden. Doch eigentlich halte ich es gerade für gut, mit ein wenig Abstand noch einmal auf die Dinge zu blicken, da dadurch die Sicht der Dinge meistens wieder etwas an Objektivität gewinnt. Und diese Sicht der Dinge will ich Euch natürlich nicht vorenthalten.

Was ist also aus der guten alten openID im letzten halben Jahr geworden?
Mein erste stille Antwort dazu war für einen kurzen Moment: “Nichts ist draus geworden”. Doch dies stimmt natürlich nicht ganz. OpenID hat in der letzten Zeit einiges an Bekanntheitsgrad hinzugewonnen und man wird nicht mehr ununterbrochen wie ein Bewohner eines fremden Planeten angeschaut, wenn man davon spricht oder schreibt. Dank Aktionen wie dem Beitritt des US-Governments und Webriesen wie Facebook (dazu folgt noch ein etwas ausführlicherer Artikel) in der openID-Foundation hat der Bekanntheitsgrad, der -meiner Meinung nach- immernoch großartigen Technologie in einige Köpfe mehr geschafft. Und langsam aber sicher scheint sich das Single-Sign-On-System -zumindest in der Theorie- durchzusetzen.

Soweit die Theorie, aber was ist mit der Praxis?
Und auf diese Frage passt auch meine Antwort wieder: “Nichts ist draus geworden”. Denn mal Hand aufs Herz, wie oft im Otto-Normal Webleben begegnet uns das Single-Sign-On-System tatsächlich? Richtig, so gut wie nie. Auf meiner täglichen Webreise, die aus dem Absurfen von einigen Email-Konten und Sozialen Netzwerken besteht kommt es so gut wie nie vor, dass ich die Möglichkeit bekomme, mich ohne Passwort und mit einem Klick irgendwo einzuloggen und grad schon gar nicht mit einer frei wählbaren openID, sondern allenfalls mal mit fest vorgegebenen Möglichkeiten via Facebook oder Twitter. Und es ist nicht wirklich so, als wäre ich ständig auf irgendwelchen Nischen-Platformen unterwegs, sondern auch ich bin vom Grundprinzip her nur ein 0815-Webuser.
Sicherlich melde ich mich – berufsbedingt- warscheinlich im Schnitt bei mehr neuen Services an, als so manch Anderer, was aber nicht unbedingt zu einem positiveren Meinungsbild führt. Ich kann mich nicht an eine einzige Platform in den letzten Monaten erinnern, wo ich mich neu angemeldet habe und ich nicht gezwungen war, Benutzerdaten auszufüllen und ein Passwort zu vergeben.

Und die Dichter und Denker?
Vor allem und gerade bei deutschen Services scheint bisher die Thematik und damit verbundene Technologie mal sowas von nicht angekommen zu sein. Die Ignoranz der deutschen Unternehmen gegenüber webtechnischen Neuerungen scheint mir ungebrochen und da können Xing und Co. dreimal opensocial einbinden, einen Vorreiter-Status in Sachen offenes Web erreichen sie dadurch noch lange nicht. Neue Technologien werden einfach nicht voran getrieben oder gar mitentwickelt. Schön brav abwarten was aus dem Valley kommt und dann vllt. mal nachmachen lautet immernoch die Devise. So gut wie jedem deutschen Internetunternehmen scheint jegliche Weitsicht und Vision komplett abzugehen. Es wird nicht riskiert und nicht investiert und das Land der Dichter und Denker verharrt -webtechnisch betrachtet- in einem Stillstand, der schon fast erschreckend ist.
So muss man sich beispielsweise mal reinziehen, dass ich mich TÄGLICH auf VIER Email-Konten des größten deutschen Internetanbieters mit VIER verschiedenen Passwörtern anmelde. Da bringt es mir rein gar nichts, dass mir jetzt auch das Facebookkonto eines Absenders vorgeschlagen wird.

Ok…genug..bevor ich mich weiter in Extase schreibe. Ich denke ich habe auch so deutlich machen können, was ich meine.

Sorry, dass bei meiner heutigen Bilanz relativ viel Pessimismus mitschwingt, aber ich glaub es musst mal raus, damit ich mir nicht ganz so doof vorkomme, wenn ich diesen Blog wieder zum Leben erwecke und über Dinge schreibe, die sowieso keinen Interessieren :) .

Vielleicht seht Ihr das ja alles komplett anders und natürlich freue ich mich über zahlreiche Meinungen, Meinungen, Meinungen…..

OpenID – So isset!

Nachdem wir nun grob wissen, was OpenID ist, wie es funktioniert und was man alles damit anstellen kann, dachte ich, es wäre ganz nett, einmal ein paar Expertenmeinungen über OpenID zu hören. Carsten Pötter, der unter www.spreadopenid.org über OpenID bloggt und Matthias Pfefferle, der mit seinem Notizblog alles Rund ums offene Web unter die Lupe nimmt, waren so freundlich mir ein paar Fragen zu OpenID zu beantworten. Die Antworten darauf möchte ich Euch natürlich nicht vorenthalten:

Welchen Vorteil siehst Du für den Nutzer in OpenID?

C.P.:
Registrierungsformulare gehören der Vergangenheit an. In den kommenden Jahren werden immer mehr Aufgaben und Dienste in das Netz verlagert, Stichwort Cloud Computing. Bereits heute haben viele Menschen ihre Bookmarks, Fotos, Adressbücher, Kalender,… im Netz. Dieser Trend wird sich in den nächsten Jahren noch weiter verstärken. Noch mehr Benutzernamen und Passwörter. Die Nutzer werden das nicht länger hinnehmen.

OpenID kann sicherer sein als bisher bekannte Login Verfahren. Mit der Wahl eines geeigneten Providers ist OpenID resistent gegen Phishing (Login mit Browserzertifikaten, Information Cards,…).

Mit der Zunahme von Diensten im Netz und der weiteren Nutzung von Social Networks wird der Aufbau einer Identität im Netz für viele Menschen immer wichtiger. OpenID bildet hier einen wesentlichen Bestandteil für eine Onlineidentität.

OpenID ist zusammen mit OAuth und OpenSocial – der sogenannte Open Stack – ebenfalls ein essentieller Bestandteil des Open Web. Wollen Nutzer ihre Daten zwischen Diensten austauschen oder zusammen führen, haben sie die Wahl zwischen einer auf offenen Standards aufbauenden Lösung oder proprietären Lösungen wie Facebook Connect. Die Frage ist, ob jeder alle Daten z.B. Facebook anvertrauen möchte. Mit Hilfe des Open Stack wird es möglich sein, die Daten auf verschiedene Anbieter aufzuteilen.

M.P.:
Richtig implementiert, ersetzt OpenID den kompletten Anmelde- und Registrierungs-Prozess ohne ein einziges Passwort angeben zu müssen.

Welche Risiken könnten sich aus Plattform übergreifenden Lösungen wie OpenID ergeben?

C.P.:
Es kann schlechte Implementationen geben, die nicht kompatibel zu Lösungen anderer Anbieter sind. Hier liegt der Vorteil klar bei einem fertigen Produkt wie Facebook Connect.

Nutzer könnten mit dem Konzept der Daten Portabilität dazu verleitet werden, zuviel ihrer Privatsphäre preis zu geben. Das betrifft aber nicht nur Lösungen mit offenen Standards, sondern auch proprietäre Lösungen wie Facebook Connect. Hier müssen die Nutzer noch weiter aufgeklärt werden.

M.P.:
Man sollte sich immer bewusst sein, dass OpenID zur zentralen Account-Verwaltung wird… geht das Passwort verloren, schließt der OpenID-Betreiber seinen Service oder wird der OpenID-Account gehackt, verliert man im schlimmsten Fall den Zugang zu all seinen Online-Profilen.

Gerade in Deutschland setzt sich OpenID eher schleppend durch und auch die meisten Plattformbetreiber kochen lieber ihr eigens Süppchen. Wo siehst Du solche Technologien wie OpenID in Zukunft? Wird sie sich durchsetzen? Kannst Du eine Prognose abgeben?

C.P.:
Es ist schwer zu prognostizieren, ob sich OpenID, etc durchsetzen werden. Die Chancen stehen jedoch nicht schlecht, da von vielen großen Anbietern im Netz diese Technologien bereits unterstützt werden. Des Weiteren öffnen sich große Content Anbieter wie die BBC diesen Technologien (die BBC ist Mitglied der OpenID Foundation). Dadurch werden sie früher oder später auch Nutzern bekannt und zugänglich, die das Netz bislang nur sporadisch nutzen.

M.P.:
Ich glaube dass viele Firmen (nicht alle) eigene Systeme entwickeln, weil sie es einfach nicht besser wissen. Das Thema OpenID oder allgemein „Open Web“ ist immer noch ein eher spärlich behandeltes Thema in deutschen Weblogs oder auf deutschen Barcamps. Trotzdem glaube ich dass sich OpenID über längere Zeit auch hier durchsetzen wird, da keine vergleichbaren Alternativen vorhanden sind und deutsche Plattformen in Zugzwang geraten werden wenn große amerikanische Firmen wie Google und Yahoo! ihre OpenID-Dienste weiter ausbauen werden.

Warum sollte ein Betreiber einer Plattform Ressourcen aufbringen, um OpenID zu implementieren? Was genau hat der Betreiber davon?

C.P.:
Der Zeitaufwand für die Implementierung von OpenID dürfte sehr überschaubar sein; ein Tag wahrscheinlich. Natürlich sollte sich ein Betreiber zuvor Gedanken über Usability, User Experience, etc gemacht haben, d.h. da geht auch Zeit verloren. Aber die reine Implementierung geht sehr schnell, da auf fertige Bibliotheken zurückgegriffen werden kann (PHP, Java, Python, Perl, C++, Ruby,…).

Betreiber senken die Eintritthürden für neue Nutzer erheblich, da die Nutzer nicht mehr nervige Registrierungsformulare ausfüllen müssen. Die wichtigsten (oder gar die meisten) Daten lassen sich über die Simple Registration Erweiterung bzw. über Attribute Exchange direkt vom OpenID Provider abrufen. Da eine Plattform bei jedem Login des Nutzers diese Daten erneut abrufen kann, hat sie immer aktuelle Daten, da diese im Idealfall nur noch beim OpenID Provider gepflegt werden müssen.
Je nach Anwendungsfall kann die komplette Userverwaltung auf den OpenID Provider ausgelagert werden, d.h. die Plattform muss keine Nutzerdaten speichern. Das spart Kosten.

M.P.:
Es ist erwiesen dass eine ganze Reihe an potenziellen Usern, durch zu lange oder komplizierte Anmeldevorgänge schon während der Registrierung abspringen. Mit OpenID würde man eventuell auch Kunden anziehen die sich die Plattform nur mal kurz von innen anschauen wollen.
Für Internetshops könnte man über OpenID und PayPal z.B. auch Bestellungen tätigen ohne sich zuvor umständlich registrieren zu müssen, was sich gerade für kleinere Online-Kaufhäuser lohnen könnte.

Zusatzfrage: Was erzählst Du Deiner Oma, wenn sie Dich fragt, was Du beruflich machst?

C.P.:
Die Rente ist sicher. ;)
Ich arbeite für die Deutsche Rentenversicherung Hessen und habe beruflich nichts mit dem Web, etc. zu tun.

M.P.:
Omi, ich versuche das Internet etwas einfacher zu gestalten (Das Internet hab ich ihr schon erklärt).


Ich bedanke mich bei den Beiden, dass sie sich die Zeit genommen haben, um meine Fragen zu beantworten. Wie man deutlich aus den Antworten herauslesen kann, gibt es eigentlich kaum Risiken und Nachteile an einer OpenID-Implementierung und auch der Zeitaufwand, einen Client zu implementieren ist überschaubar. Solche Ausreden von Plattformbetreibern werden damit ab sofort also nicht mehr gelten gelassen :) .

Dies bringt mich dann auch zum nächsten Punkt meiner (durchaus noch ausbaufähigen) journalistischen Fähigkeiten. Ich habe mir einmal erlaubt, die für mich größten und verbreitesten Communities innerhalb Deutschlands anzuschreiben und zu erfragen, ob sie in der nächsten Zeit Schritte in Richtung OpenID planen. Das waren: Xing, StudiVZ, Wer kennt wen? und LastFm. Leider war das Ergebnis sehr dürftig bis nicht vorhanden. Keinen Plan, woran es lag. Wie gesagt, ich schließe meine mangelenden journalistischen Fähigkeiten nicht aus, allerdings hege ich auch den Verdacht, das der jeweilige Support nicht wußte, was ich wollte und damit keine Ahnung hatte, was man mir Antworten sollte. Nun gut, immerhin eine Antwort habe ich bekommen, und zwar von den netten Menschen von Xing. Die Antwort ist allerdings eher erheiternd als aufschlußreich, aber auch diese möchte ich gerne mit Euch teilen:

Ich hätte gerne gewußt, ob auch Sie demnächst die Integration eines OpenID-Login planen, da es für den Nutzer sicherlich einige Vorteile bietet?

Xing-Support: vielen Dank für Ihre Nachricht.
Die Anregungen unserer Mitglieder sind uns sehr wichtig, da wir diese für Überlegungen zur Optimierung der Plattform gerne berücksichtigen. Wir werden Ihren Vorschlag an die zuständige Abteilung weiterleiten.


Hm..nun nicht unbedingt das, was ich mir erhofft hatte, aber immerhin haben sie Interesse geheuchelt. Im Vergleich zu den anderen jede Menge mehr, denn die hab ich sogar zweimal angeschrieben und beim zweiten mal sogar ausführlicher erleutert, worum es geht. Ich lasse das jetzt mal kommentarlos so stehen.

Zum Schluß kommen aber noch ein paar gute Nachrichten. Und zwar hat es insgesamt den Anschein, als würde OpenID immer mehr Freunde finde. JanRain veröffentlichte im Januar die Relaying-Party-Statistik, die einen deutlichen Anstieg im letzten Jahr an OpenID-Client-Implementierungen erkennen läßt.
Relaying Parties 2008
Wäre schön, wenn die Statistik für dieses Jahr genaus aussehen könnte…warten wirs ab.

So, ich denke, das ist ein schöner Abschluß (vorerst) von OpenID. Beim nächsten mal gehts dann um oAuth.

OpenID – Es ist (nicht) in den Köpfen drin!

Bei der Recherche für die letzten Posts über OpenID bin ich immer wieder auf Diskussionen über die Problematik gestossen, wie man dem User nun letztendlich beibringen soll, sich eine bestimmte URL zur Anmeldung zu merken, nachdem er sich nun seit Anbeginn des Internetz mit einem frei gewähltem Benutzernamen oder einer Email-Adresse eingeloggt hat. Die Meinungen der OpenID interessierten Internetgemeinde spalten sich dabei im Großen und Ganzen in zwei Lager.

Da hätten wir auf der einen Seite Jene, die finden, dass man mit ausreichenden Marketing- und Aufklärungsmaßnahmen den Begriff OpenID und was dahinter steckt an die Frau bringen sollte. Dabei würde der User quasi so umerzogen, dass er nicht mehr in Email-Adressen, sondern in (Profil-)Urls denkt. Die Argumentationskette baut dabei darauf auf, dass, sobald der User erst einmal Verstanden hat, was eine OpenID ist und man ihm diesen Begriff nur oft genug auf die Nase bindet, er es auch toll finden und benutzen wird. Zugegeben, im ersten Moment war auch ich dieser Ansicht: Man muss es nur lange genug propagieren und erklären, dann werden die Leute schon kommen. Als damals die Emails erfunden wurden, waren die Leute auch nicht direkt hell auf begeistert und warscheinlich eher skeptisch. Zeit, Aufklärungsarbeit und Durchhaltevermögen werdens schon richten.

Auf der anderen Seite gibt es diejenigen, die finden, dass der User von OpenID und der Technik die dazu gehört generell überhaupt nichts mitbekommen sollte. Er benutzt also die OpenID-Implementierungen und weiß eigentlich davon gar nichts. Zurecht wird sich jetzt so manch einer fragen, wie dies möglich sein soll. Nun, prinzipiell ist die Antwort darauf nicht besonders schwierig. Man nehme einfach etwas, was der User sowieso schon kennt und dem er vertraut. Dies könnte beispielsweise ein Account einer Internetplatform oder vielleicht sogar wieder die altbekannte Email-Adresse sein, was bedeuten würde, dass sich für den User im ersten Moment nicht viel ändert und niemand von ihm verlangt plötzlich Sachen zu verstehen, die ihn bisher auch nicht interessiert haben: Nämlich wie etwas funktioniert.
Nun haben wir in der letzten Zeit bereits gelernt, dass der OpenID-Standart ja eigentlich auf im Internet einzigartigen URLs basiert, wieso und weshalb denn jetzt auf einmal wieder Account-Daten und Email-Adressen? Mit der OpenID 2.0 Spezifikation geändert und trägt den Namen Directed Identity.

Das ganze funktioniert prinzipiell genauso, wie ein ganz normaler OpenID-Login und die Großen mit Namen Google und Yahoo machens uns mal wieder vor. So bekommt man bei Directed Identity unterstützenden OpenID-Clients wie z.B. Plaxo -neben dem gewöhnlichen OpenID-Login- Links angeboten, die da lauten: ‘Sign in with Yahoo! Id’ oder ‘Sign In with a Google Account’. Klickt man nun diese, so wird man ganz normal auf den Google- oder Yahoo!-Login umgeleitet, wo man, wie beim normalen OpenID-Login auch, nur noch die Webseite, in unserm Beispiel also Plaxo, bestätigen muss. Fertig.
Man konnte sich also bei einem Service anmelden, ohne zuvor mit OpenID oder der Technik, die dazu gehört, vertraut zu sein. Der User benutzt zum Login nur dass, was er sowieso schon kennt: Einen Account und meiner Ansicht nach wird der Nutzer dies wohl eher einmal ausprobieren, als einen klassischen OpenID-Login, wo er nichts mit anfangen kann ohne zuvor lange Erklärungstexte zu gelesen zu haben.

Directed Identity ist demnach also eine Möglichkeit, den User an OpenID heranzuführen, ohne ihn zu überfordern, denn das OpenID-Icon und die Möglichkeit eines normalen OpenID-Logins sollte und ist natürlich immer gegeben neben den Account-Logins mit Google oder Yahoo!. Deswegen ist es meines Erachtens unerlässlich, dass sowohl die Provider, als natürlich auch die Clients, schnellst möglich OpenID 2.0 mit Directed Identity (und natürlich noch weiteren Neuerungen, wie z.B. Attribute Exchange 1.0) implementieren sollten, denn auch ich bin inzwischen zu der Meinung übergelaufen, dass es recht unwarscheinlich ist, dass der User auf einmal beginnen wird, sich URLs zu merken. Durch Directed Identity wird er aber einen Zugang zu OpenID finden, was dann vielleicht und hoffentlich in Zukunft weiter ausbaubar ist und sich dann schlußendlich auch durchsetzen wird.

Allerdings gibt es auch einen Kritikpunkt am ‘Anmelden mit Account’, der nicht zu unterschätzen ist: Die Platzherrschaft der Großen. Denn es könnte sehr schwer werden für OpenId-Provider wie xlogon und Co. sich durchzusetzen, wenn bei jedem OpenID-Login Google und Yahoo! zur Auswahl stehen. Denn warum sollte sich der User für einen eher unbekannten OpenID-Provider entscheiden, wenn er einfach und schnell auch seinen Google-Account, den er sowieso schon hat, zum Login benutzen kann. Es bleibt die kleine Hoffnung, dass der moderne Internetnutzer intelligent mit seinen Möglichkeiten umgeht und sich für solche, z.T. auch sensiblen Vorgänge und Daten die dort behandelt werden, eher einer Plattform anvertraut, die nicht schon alles andere für ihn tut und über ihn weiß.

OpenID – Es ist im Internet drin

Da wir jetzt wissen, was der Unterschied zwischen einem OpenID-Provider und einem OpenID-Client (Relaying-Party) ist und was man mit einer OpenID so alles anstellen kann, wird es an der Zeit, ein paar Services vorzustellen und etwas genauer unter die Lupe zu nehmen.

OpenID-Provider: Hier bekommst du eine OpenID

xlogon (deutsch). OpenID: http://xlogon.net/BENUTZERNAME
xlogon wirkt sehr übersichtlich und aufgeräumt und scheint zu wissen, was es ist: ein OpenID-Provider. Nicht mehr und auf keinen Fall weniger. Ein leicht zu verstehendes und übersichtliches User-Interface navigiert den Nutzer durch die Thematik. Direkt nach dem Login bekommt man einen Überblick und eine kurze, gute Erklärung über den Funktionsumfang. Neben sReg für eine einfachere Registrierung und der Möglichkeit zum Anlegen dazugehöriger Personas bietet xlogon einen Phishing-Schutz, der vor einem Mißbrauch von OpenIDs schützen soll. Daumen hoch von mir für xlogon.

Communipedia (deutsch, englisch). OpenID: http://BENUTZERNAME.yiid.net
Communipedia bietet mit seiner OpenID, der sogenannten yiid (your internet identity) eine stabile und für den User einigermaßen übersichtliche Provider-Implementierung.
Unterstützungen von OpenID-Erweiterungen wie sReg fehlen zu diesem Zeitpunkt allerdings noch, wobei aber zu berücksichtigen ist, dass Communipedia sich noch in der Closed-Beta-Phase befindet. Nach Aussagen der Entwickler werden diese Funktionalitäten, ebenso wie die Möglichkeit zum Anlegen verschiedener Personas, in den nächsten Wochen/Monaten in Angriff genommen und damit so schnell wie möglich nachgereicht. Wer einen Invite-Code möchte, um die Fortschritte bei Communpedia zu verfolgen oder sich seine yiid sichern möchte, kann diesen bei mir anfragen.

meinguter.name (deutsch). OpenID: https://BENUTZERNAME.meinguter.name
Nicht ganz so übersichtlich und fokusiert wie xlogon präsentiert sich meinguter.name. Mit seiner ‘Ego-Surfing’-Funktionalität, die im Netz nach Informationen zur eigenen Person zu suchen scheint, bietet die Plattform zwar eine nettes Gimmick an, doch leider erfährt man innerhalb der Seite wenig über OpenID und wozu es gut ist, was mir derzeit aber noch unerläßlich scheint. meinguter.name hat zwar eine sReg-Erweiterung implementiert, leider kann man aber auch hier nur eine Persona angeben. Da auch bei meinguter.name noch ein Beta-Stempel zu sehen ist, ist allerdings zu erwarten, dass an weiteren Provider-Funktionen noch gearbeitet wird. Warten wirs also ab.

myopenid (englisch). OpenID: http://BENUTZERNAME.myopenid.com
Innovativ, stabil, gut. Eigentlich gibt es über myopenid nicht mehr zu sagen. myopenid ist ein OpenID-Provider, der wirklich alles bietet, was man sich von einem Provider wünscht. Zudem zeigt myopenid sehr viel Kreativität und Entwicklungsarbeit in Sachen Funktionsumfang für OpenID, was wohl allerdings auch daran liegt, dass hinter myopenid die JanRain Inc. steckt, die man wohl als Vorreiter in Sachen OpenID bezeichnen kann. Für den Otto-Normal-User ist myopenid fast schon etwas zu umfangreich und man könnte gegebenenfalls manchmal etwas überfordert werden in Usability und ‘Wofür ist jetzt eigentlich dieser Menupunkt’. Damit ist die Seite also wohl eher etwas für Fortgeschrittene. Hinzukommt, das die Unterseiten bisher nur teilweise ins Deutsche übersetzt sind, was das Verständnis mit eher rudimentäreren Englisch-Kenntnissen nicht unbedingt einfacher macht.

myvidoop (englisch). OpenID: http://BENUTZERNAME.myvidoop.com/
Sicherheit und Schutz vor Mißbrauch ist bei myvidoop anscheinend sehr groß geschrieben, was einen auf der einen Seite zwar freut, andererseits mit der Zeit aber auch anfängt zu nerven. Möchte man sich bei myvidoop oder mit der myvidoop-OpenID anmelden, so muss man zunächst über einen Freischaltungscode, den man per Email bekommt, den Browser/PC bestätigen. Damit aber nicht genug, nachdem man den Freischaltungscode eingegeben hat wird man gebeten, statt eines Passworts eine Bilderkombination wiederzuerkennen, die man bei der myvidoop-Registrierung ausgewählt hat. Dieser Prozess bietet natürlich einen größeren Schutz vor Mißbrauch, als bei herkömmlichen Providern, doch wie gesagt, mich nervt es ein wenig und damit wird myvidoop vermutlich nicht mein bevorzugter OpenID-Provider. Vom Funktionsumfang her bietet die Seite zwar sReg-Unterstützung an, leider aber nicht die Auswahl von Personas. Insgesamt finde ich die Plattform Usability-Technisch grenzwertig.

Ausgewählte OpenID-Clients: Einloggen/Registrieren mit OpenID

  • Sixgroups (deutsch): Community-Lösungen für jedermann, insbesondere eine Community-Applikation für jede Website.
  • Mixxt (deutsch): Online-Baukasten für Social Networks
  • Communipedia (deutsch, englisch): Community-Verzeichnis/-Suche. Portables Netzwerk. Noch Closed Beta.
  • Magnolia (englisch): Bookmark-Service
  • Plaxo (englisch): Portables Netzwerk

Artikel/Seiten über OpenID

  • t3n magazin (deutsch): Artikel über die Vor- und Nachteile von OpenID
  • spreadopenid (englisch): Webblog über OpenID von Carsten Pötter und Thomas Huhn
  • openwebpodcast (deutsch): Folge über OpenID-Eine Einführung
  • openid.net (englisch): Seite der offiziellen OpenID-Foundation.

Ich hoffe, hiermit konnte ich Euch eine kleine Übersicht über OpenID-Provider und OpenID-Clients geben. Natürlich sind die beiden Listen längst nicht vollständig, sollten aber ausreichen, OpenID einmal auszuprobieren.
Selbstverständlich seid ihr alle herzlich eingeladen, die Liste innerhalb der Kommentare zu erweitern. Je mehr wir sammeln, desto besser….

Beim nächten Mal werde ich ein Fazit und einen Ausblick in die Zukunft von OpenID geben.

OpenWatt? OpenID! (Teil 2)

OpenID bietet mir nun also einen Ausweg aus dem Passwort-WirrWarr und damit eine schicke Lösung, mich auch ohne Nutzername und Passwort bei Services einzuloggen.

Leute, die sich häufiger im Internet bewegen kennen aber noch ein weiteres, zum Teil sehr nerviges Problem: Bei jeder Plattform oder Community, bei der man sich neu anmeldet, muss man immer wieder die selben Daten neu eintippen, obwohl diese sich in den seltensten Fällen ändern und ein Import von einer zentralen Stelle eine Supersache wäre. Auch hier lautet die Lösung des Problems OpenID und eine damit verbundene Registrierung.

Dafür ist es nötig, dass der OpenID-Client eine Registrierung mit OpenID unterstützt. Der User trägt dann bei der Registrierung seine OpenID ein und klickt ‘verifizieren’. Wie beim Login wird der Nutzer auf den OpenID-Provider umgeleitet und muss mit seinem Passwort seine Identität bestätigen. Beim normalen OpenID-Login ist damit alles getan und man ist schon fertig. Bei einer OpenID-Registrierung werde ich als User aber noch um einen weiteren Schritt gebeten, nämlich die Auswahl der gewünschten Daten, die ich an den OpenID-Client weitergeben möchtet.

Um dies zu vereinfachen kann ich bei einigen OpenId-Providern, wie z.B. bei myopenid.com, gleich mehrere Identitäten angeben, die sogenannten Personas. So besitze ich z.B. gleich drei Personas dort: Eine Private, eine Geschäftliche und eine Fiktive, die alle unterschiedliche Emailadressen, Profilfotos oder auch Namen enthalten.

Möchte ich mich jetzt bei einem Service per OpenID-Registrierung neu anmelden, wähle ich bei der Verifizierung eine der drei Personas aus, und die dazugehörigen Daten werden bei der Umleitung zurück zum OpenID-Client und dem damit verbundenen Server-Gespräch (siehe OpenWatt? OpenID! (Teil 2)) gleich mitgesendet. Nun sind bereits alle (oder zumindest die meisten) Registrierungsfelder vorausgefüllt. Wenn ich Glück habe und der OpenID-Client ein guter Service ist, dann wurden sämtliche Daten, die mein Provider mitgeschickt hat nach Abschluss des Registrierungsprozesses bereits meinem Profil hinzugefügt und ich spare mir das Ausfüllen. Zudem kann ich mich ab sofort immer wie gewohnt mit meiner bei der Registrierung angegebenen OpenID einloggen.

Damit das ganze reibungslos und gut funktioniert, reicht es allerdings leider nicht aus, dass der OpenID-Client blos ein OpenID-Feld in seinem Registrierungsformular hinzufügt. Beide Seiten müssen hierfür ihre OpenId-Implementierung entweder um das sogenannte sReg (Simple Registration) oder um AX (Attribute Exchange) erweitern.

Bei diesen beiden OpenID-Erweiterungen handelt es sich um Standarts, die vorgeben, wie genau der Austausch der Daten stattzufinden hat und vor allem, wie genau die einzelnen Daten bezeichnet und abgelegt sein müssen, denn ein Datenaustausch kann nur stattfinden, wenn die am Austausch beteiligten Partner die gleiche Sprache sprechen. Das heißt in unserem Fall (dem Austausch von Profilinformationen), dass der Client zum Beispiel das Email-Adress-Feld nur vorausfüllen kann, wenn er auch weiss welches von den Daten, die der Provider geschickt hat die Emailadresse ist. Ein Austausch ist demnach nur erfolgreich, wenn beide Seiten die gleiche Sprache sprechen, der Client also Simple Registration versteht, wenn der Provider Simple Registration unterstützt. Analog dazu funktioniert das mit Attribute Exchange: Beide Partner müssen Attribute Exchange unterstützen, wenn sie Daten untereinander austauschen wollen.

Das Ganze funktioniert also prinzipiell wie ein normales ‘Tauschgeschäft’ in einem Laden: Möchte ich als Kunde (Client) die gewünschte Ware mit nach Hause nehmen, dann ist es sehr förderlich, wenn ich das Zahlungsmittel (Standart) dabei habe, was der Verkäufer (Provider) auch akzeptiert. Besonders gut klappt der Kauf dann noch, wenn der Verkäufer Euro möchte, ich ihm auch Euro geben kann, denn sonst wird er Probleme haben zu wissen, was das, was ich ihm gegeben habe wert ist (->Client und Provider haben entweder beide sReg oder AX implementiert und haben damit keine Probleme, zu wissen, was der andere geschickt hat).

Gott sei dank kann ich an dieser Stelle beruhigend sagen: Auch dies sind wieder alles Dinge die im Hintergrund passieren und von denen der normale User nichts mitbekommt, sondern lediglich davon profitiert, ohne irgendetwas davon verstanden haben zu müssen.

Allgemein kann man noch sagen, dass Simple Registration die eher abgespecktere Variante der beiden ist, es werden also nicht soviele Daten ausgetauscht. Deswegen hat man irgendwann Attribute Exchange entwickelt, welches den Austausch von weitaus mehr Informationen unterstützt. Möchte jemand wissen, welche Daten von welchem Standart unterstützt werden können, findet er hier einen Überblick.

Der Vollständigkeit halber möchte ich an dieser Stelle noch die dritte Möglichkeit erwähnen, in deren Format man bei einer OpenID-Registrierung Profildaten austauschen kann: OpenID mit hcard. Auf Microformate und hcard möchte ich allerdings an dieser Stelle nicht weiter eingehen, kommt bestimmt später noch. Aber wen es interessiert, der sollte unbedingt hier (deutsch) und hier (englisch) weiterlesen. Der Ablauf insgesamt ist zudem auch gleich wie oben beschrieben.

Beim nächsten mal werde ich ein paar OpenID-Provider vorstellen und eine kleine Liste mit Services zusammenstellen, bei denen man sich mit OpenID einloggen oder sogar registrieren kann.

PS: Leider habe ich es immernoch nicht geschafft, meinen eigenen OpenID-Login ans laufen zu bekommen. Schätzungsweise ist auch 1und1 Schuld und ich werde ihnen im neuen Jahr mal schreiben um nachzufragen, was da los ist. Deswegen verzeihen mir bitte die tausend und abertausend Leute, die hier kommentieren den Mißstand :)

OpenWatt? OpenID! (Teil 1)

Möchte man OpenID mit etwas aus dem realen Leben vergleichen fällt mir spontan das Geldabheben mit einer Kredit- oder EC-Karte ein, womit ich bei jedem erdenklichen Geldautomaten mit immer den gleichen Zugangsdaten auf mein Konto und damit auf mein Geld zugreifen kann.

Es wäre ziemlich dämlich, wenn ich für jeden Geldautomaten dieser Erde eine extra Kreditkarte mit einem Benutzernamen und einer PIN bekommen würde. Dies würde ziemlich schnell ziemlich unpraktikabel, denn spontan wäre hier gar nichts mit Geld abheben und ich müßte mir verdammt viele PINs merken, damit ich nicht an jedem Ort ausserhalb meines Zuhauses völlig mittellos dastehe. Um sowas zu umgehen, bekomme ich von meinem Bank- oder Kreditkarteninstitut eine Karte mit einer PIN, also quasi eine Identität, die es mir ermöglicht, mich an so gut wie jedem Geldautomaten als IchSelbst auszuweisen und an mein Geld zu kommen.

Während dies im realen Leben wunderbar funktioniert scheint dies im virtuellen Internetleben noch nicht ganz so gut zu gehn. Bei jedem erdenklichen Dienst wird von mir ein möglichst immer unterschiedliches Passwort mit einem Benutzername verlangt, um mich als IchSelbst auszuweisen. Da man Passwörter möglichst nicht notieren soll, bin ich eine potentielle Kanditatin dafür, ständig irgendwelche Passwort-vergessen-Funktionen zu klicken oder gar ganz fatal, immer das gleiche Passwort zu benutzen. Gott sei dank halte nicht nur ich dies für einen untragbaren Zustand und schlaue Leute haben sich einen Mechanismus ausgedacht, der das Passwort-Wirrwarr in Zukunft überflüssig macht: die OpenID.

Wie beim Kreditkarteninstitut erhält hierbei der User eine einzigartige URL als Internetidentität. Um diese zu bekommen muss er sich lediglich bei einem sogenannten OpenID-Provider, wie z.B. www.myopenid.com registrieren. Ratsam ist, für diesen Provider ein möglichst sicheres Passwort zu finden, was ich ok finde, denn ich muss mir in Zukunft ja nur noch dieses merken. Das Passwort wäre dann zu vergleichen mit meinem Karten-PIN. Nach meiner Registrierung also erhalte ich automatisch meine neue und schicke OpenID. Bei myopenID lautet diese immer: http://BENUTZERNAME.myopenid.com.

Möchte ich mich nun bei einem Service (der Geldautomat) einloggen, muss ich hierfür einfach meine OpenID in das dafür vorgesehene Login-Feld eingeben. Eine Plattform wo dies gut funktioniert ist z.B. Ma.gnolia.com. Die Services, die einen OpenID-Login ermöglichen nennt man OpenID-Client, OpenID-Consumer oder auch OpenID-Relaying-Party.

Nachdem ich nun also meine OpenID eingetragen habe und den absenden-Button geklickt habe beginnen im Beispielfall Ma.gnolia als OpenID-Client und MyOpenID als OpenID-Provider im Hintergrund eine Diskussion:
Magnolia: “Hallo myopenid, ich bins magnolia. Ich bin ein Openid-Client und hier möchte sich jemand mit einer myopenid-openid bei mir einloggen. Die ist zwar bei mir hinterlegt, aber kann ich dem User vertrauen?”
myopenid: “Hallo magnolia, ich sehe, du bist in der Tat ein OpenID-Client. Dann lass doch mal schauen, wer sich da bei dir einloggen möchte und ob es auch der ist, der die OpenID bei dir hinterlegt hat. Lass mal die OpenID sehn.”
Von dieser Konversation bekommt der User natürlich zunächst nichts mit, denn das ist das nötige Handshake der Server, um einen Reibungslosen Login zu gewährleisten. Nachdem also der myopenid-server dem magnolia-server sein ok gegeben hat, wird der User auf die myopenid-login-Seite umgeleitet. Hier gebe ich nun mein Myopenid-Passwort ein und bestätige damit, dass ich der zugehörige Nutzer zur von Magnolia gesendeten OpenID bin, magnolia vertraue und mich gerne dort einloggen will. Nun führen die Server ihre Unterhaltung fort:
myopenid: “He magnolia, die snirgel hat die OpenID mit ihrem Passwort bestätigt. Die hat gemeint, sie ist es wirklich und das sie sich gerne bei dir einloggen will. Kannst also reinlassen”
magnolia: “Super, weiß ich bescheid, ist eingeloggt.”
Nach diesem Gespräch, wovon ich natürlich wiederum nichts mitbekommen habe, werde ich wieder zurück zu magnolia geleitet, wo ich dann eingeloggt bin.

Kritiker könnten jetzt meinen, dass das ja nicht wirklich was gebracht hat, denn ich mußte mich ja trotzdem irgendwo einloggen und ein Passwort eintragen. Was ist denn daran jetzt so toll.
Richtig einloggen mußte ich mich tatsächlich, doch habe ich erstens bei Magnolia selbst nie ein Passwort angegeben, sondern lediglich einmal meine OpenID hinterlegt. Klar hier hinkt das Beispiel mit dem Geldautomaten und man muss tatsächlich beim OpenID-Client immer seine OpenID angeben, denn der Client muss beim Login der OpenId ja auch einem Nutzer zuordnen können. Zweitens läuft dieser Prozess mit jedem OpenID-Client gleich ab und ich muss mir also nur EIN Passwort merken, und zwar das meines OpenID-Providers.
Ich beweise also nicht mehr mit einer Nutzername/Passwort – Kombination, wer ich bin, sondern der OpenID-Provider übernimmt dies für mich, denn ich habe ihm ja bestätigt, dass ich es tatsächlich bin, die zur angefragen OpenID gehört und er dies auch dem Client bestätigen kann.

Insgesamt hört sich das alles noch sehr kompliziert an, allerdings gibt es zusammenfassend gibt es zu sagen, dass man als User nur genau 2 Schritte von einem schön einfachen OpenID-Login entfernt ist:
1. Einmaliges Anlegen eines OpenID-Account bei einem OpenID-Provider
2. OpenID beim gewünschten und natürlich auch teilnehmenden Service hinterlegen

Ob Ihr Euch bei einem Service mit einer OpenID einloggen könnt erkennt Ihr an diesem Icon: openid

In OpenWatt? OpenID! (Teil 2) werde ich etwas näher auf den Unterschied zwischen OpenID-Provider und OpenID-Client eingehen und ein paar Services dazu vorstellen.

P.S.: Ich bitte zu verzeihen, dass der OpenID-Login bei meinen Blogkommentaren gerade noch nicht geht. Ich arbeite dran und reiche das in den nächsten Tagen nach. Ich weiss, peinlich, peinlich.