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

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…