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:

haudio

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:

haudio

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.

Yahoo! hat den SearchMonkey jetzt auch in ihren Suchdienst BOSS (Build your Own Search Service) integriert.

Einfach die entsprechende SearchMonkey – Konstante als {query} übergeben (eine Liste von Konstanten findet ihr hier):

http://boss.yahooapis.com/ysearch/web/v1/{query}?appid={youBOSSappid}
http://boss.yahooapis.com/ysearch/web/v1/searchmonkeyid:com.yahoo.page.uf.hcard?appid={youBOSSappid}

oder mit normalen Suchbegriffen kombinieren (alle hCards von Mr. T):

http://boss.yahooapis.com/ysearch/web/v1/searchmonkeyid:com.yahoo.page.uf.hcard+mr.t?appid={youBOSSappid}

: (|)

Der SearchMonkey unterstützt ab sofort drei neue (Mikro)Formate: adr, geo und tag. Außerdem wurde für alle lowercase semantiken ein neuer Namespace eingeführt.
Aus searchmonkeyid:com.yahoo.uf.hcard wird searchmonkeyid:com.yahoo.page.uf.hcard.
Wahrscheinlich um sie von höherwertigen XML-Formaten wie z.B. Atom oder RDF abzugrenzen.

Die neue Liste aller unterstützten Formate:

Viel spaß beim suchen :(|)

(via)

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