open-web-podcast.png

Sebastian, Christian und ich wünschen euch natürlich frohe Weihnachten und einen guten Rutsch ins neue Jahr… Feiert schön! Damit euch während den Feiertagen nicht so langweilig wird, gibt’s diesmal eine etwas längere Weihnachtsfolge in der wir versuchen einen kleinen Open Web Jahresrückblick bzw. Ausblick zu geben.

Viel Spaß beim hören und bis nächstes Jahr 🙂

Weitere Links zur Sendung gibt’s wie immer im Wiki!

Den Podcast abonnieren:

open-web-podcast.png

In der 8. Episode des Open Web Podcasts dreht sich alles um die News der letzten Woche: Facebook Connect, Google Friend Connect, MySpaceID und mögliche Alternativen wie z.B. OpenID und der Open Stack.

Weitere Links zur Sendung gibt’s wie immer im Wiki!

Den Podcast abonnieren:

Seit dem Start von Facebook Connect wurde das proprietäre System immer wieder mit OpenID verglichen. Dass OpenID im direkten Vergleich den kürzeren zieht ist klar, immerhin handelt es sich bei dem offenen Standard "nur" um ein Single-Sign-On System und nicht, wie bei Facebook Connect, um ein umfassende Komplettlösung.

Wie Marc Canter schon vor einigen Tagen bemerkt hat sollte OpenID eher als ein kleines Teil des "Identity Puzzles" ansehen:

…that OpenID is NOT a full solution – it is an important piece of the identity puzzle … but OpenID can – actually solve all these issues – by embracing other complementary technologies (like oAuth, OpenSocial, Portable Contacts, microformats, FOAF and RSS/Atom) to create a wrapper solution oriented approach – focused on simplifying the the whole ID conundrum for end-users.  Barriers of entry, usability issues and confusing messages can all be solved by OpenID positioning itself as a single point-of-contact solution.

Warum aber so viele kleine Standards und nicht einfach OpenID zum Open Connect aufblasen?
OpenID in seiner jetzigen Form hält den Open Stack dezentral und macht die Komponenten austauschbar:

  • Jeder der oben genannten Standards ist sowohl alleine als auch in Kombination nutzbar, was den Entwicklungsaufwand für Spezialfälle vereinfacht. Braucht eine Community eine Single-Sign-On Lösung, ist auch nur ein OpenID in seiner jetzigen (unaufgeblasenen) Form nötig. Steigen nachträglich die Anforderungen, kann der Stack beliebig erweitert werden.
  • Bestehende Informationen können (wenn eine entsprechende Schnittstelle besteht) wiederverwendet werden und müssen nicht alle über ein System bereitgestellt werden, der OpenID Provider muss nur wissen wo diese Informationen zu finden sind. (Ein schönes Beispiel für ein solches dezentrales System ist die OpenID + PortableContacts Beispiel-Implementierung von JanRain)
  • Die Komponenten des Open Stack sind beliebig austauschbar. Es ist prinzipiell egal ob man den Sozialen Graphen über XFN, FoaF oder Portable Contacts importiert oder alle Varianten unterstützt.

Das vorgestern angekündigte MySpaceID (aka Data Availability) scheint ein erster Schritt in Richtung Open Stack zu sein und auch Googles Friend Connect ist auf einem guten Weg. Es gibt sicherlich noch einiges zu tun um die Bausteine etwas besser miteinander zu verbinden (z.B. OpenID und OAuth zu kombinieren) aber ich bin weiterhin optimistisch und glaube dass sich der offene und dezentrale Ansatz durchsetzen wird.

Jetzt wo MySpace sein Data Availability – Projekt in MySpaceID umbenannt hat ist der Name OpenID vielleicht doch gar nicht so doof… 🙂

Ob Connect oder ID (oder sonst wie), die Funktionsweise von OpenID wird durch eine Umbenennung sicherlich nicht einfacher oder besser!

…wer nicht weiß auf was ich hier anspiele sollte sich meinen Post über „Promote the utility, not the technology“ einmal durchlesen.

Christian Scholz macht sich in seinem Artikel „The OpenID Branding problem“ Gedanken darüber wie man dem normalen User OpenID näher bringen könnte (und ich Stimme ihm auch bei vielen Punkten zu (der ID-Selector ist wirklich sehr überladen)).

Aber ist es wirklich wichtig am Branding „OpenID“ zu arbeiten? Yahoo hat in seiner OpenID Usability Studie einen Satz, der das Problem (meiner Meinung nach) ziemlich gut trifft:

„Promote the utility, not the technology“

Als Google seine OpenID Implementierung veröffentlicht hat wurden viele Stimmen laut, Google würde OpenID nur für seine Zwecke „missbrauchen“… Aber ist das nicht genau der Schritt den OpenID gehen muss? Weg von der Technik und dem Branding, hin zur Funktionalität und dem Anbieter. Facebook Connect ist doch nur so erfolgreich (wobei wir das ja noch gar nicht wissen) weil ein normaler Internet-Nutzer den Login wieder erkennt (E-Mail Adresse und Passwort) und versteht… bei Yahoo!s oder Googles Directed Identity Implementierung ist es ähnlich, der Benutzer klickt einen Link wie z.B. „mit Google Account anmelden“ kommt zu Google und muss wieder nur das Formular ausfüllen welches er schon kennt. Er bekommt nichts von OpenID mit und hat sich ohne Hürden und (im besten Fall) mit einem Klick angemeldet… und für alle Geeks bleibt immer noch die normale OpenID Anmledung!

Diesen Schritt finde ich sogar noch Sinnvoller als die E-Mail – OpenID, da der Nutzer ohne große Workarounds (und nichts anderes ist EAUT) auf OpenID vorbereitet wird.

Ich würde mich sehr über einige weitere Meinungen und Ideen freuen, also ran an die Tastatur 😉

Dieser Post entstand übrigens als Kommentar bei hackr

Bei Vidoop hab ich gerade von dem neuen OpenID Plugin für Flock gelesen. Das Plugin ist eine Zusammenarbeit zwischen Vidoop, MySpace und Flock und basiert auf dem Know-How des IDIB (Identity in the Browser) Plugins für den Firefox.

Ähnlich wie bei IDIB für Firefox kann man auch bei der Flock Version mehrere OpenIDs voreinstellen. Neu beim Flock-Plugin ist die Automatische Erkennung von OpenID Providern und OpenID Relying Parties. Besuchte OpenID Profider wie z.B. Yahoo! oder MySpace merkt sich das Plugin und schlägt sie unter „Suggested OpenID’s“ vor.

Flock-openid-config.png

OpenID Consumer oder Relying Parties werden wohl nur noch am Login-Feld <input id="openid_identifier" /> und nicht mehr (wie bei IDIB) über XRDS-Simple erkannt. Ist ein OpenID Login möglich, werden einem die vorher angelegten OpenIDs angeboten und man kann sich bequem über das Plugin anmelden.

Flock-openid-login.png

Für die Audio-Visuellen unter euch gibt es auch noch eine kurze Einführung per ScreenCast.

Download OpenID Plugin: https://extensions.flock.com/extensions/

Bei meiner Recherche zu XRDS bzw. XRI (dem XML-Standard auf dem z.B. auch die OpenID und OAuth Discovery basieren) bin ich (dank Thomas Huhn) auf den XRI Busy Web Developer’s Guide gestoßen und jetzt frage ich mich, warum nicht alle Spezifikationen so erklärt werden können.

Das <XRDS /> Element wird z.B. so beschrieben:

Note: Busy web developers will almost never ask for this type of document.

Zu Deutsch: Es wird zwar der Vollständigkeit halber erwähnt, aber ignorier es doch einfach 🙂

Großartig!

Falls jemand ein „JanRain OpenID Lib for busy Web Developers“ oder „OpenSocial for busy Web Developers“ kennt… ich wäre interessiert 😉

’…it’s just proving hard to get people to understand that. Using horses is all they know and the user testing suggests that getting people to switch to something so foreign as an automobile will be near impossible. Maybe we could make some changes so that adoption is easier?’

own your identity mit einer Metapher zu der Diskussion die E-Mail – Adresse aus Usability-Gründen mit in den OpenID Standard aufzunehmen.

…immerhin haben unsere heutigen Autos ja auch keine Zügel 😉

(via hackr)

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: