(das gibt dann wohl demnächst ein update mit easteregg)

es benötigt sicherlich etwas mehr Doku den Facebook-Authorisation-Provider zu erklären, aber sicherlich nicht viel mehr… das ist aber auch eigentlich nicht der Punkt. Das Wunderbare an der Facebook API ist der klare Fokus! Facebook hat eine einfache API gebaut die jeder versteht, die ohne Libs innerhalb von wenigen Stunden zu implementieren ist und trotzdem alles abdeckt was auch OpenID Connect leisten will.

Organisationen wie das W3C oder die OpenID Foundation neigen dazu Spezifikationen aufzublasen um alle Eventualitäten abzudecken. Das führt dazu dass Standards so komplex werden, dass sie von anderen Formaten abgelöst werden (beispielsweise RDFa und Microdata) oder von Dienstleistern vereinfacht werden. Es ist ja schon ironisch, dass man Dienste wie Janrain Engage braucht um einen standardisierten Zugriff auf die diversen OpenID-Provider zu bekommen. Ein proprietäres Produkt welches den Standard standardisiert…

Dem OpenWeb fehlt, finde ich, etwas die agile Herangehensweise. Auf ein Problem fokussieren und wenn das gelöst ist, das nächste angehen. Zuerst eine simple Single-Sign-On Lösung für das Web. Falls die Lösung nicht für digitale Bilderrahmen funktioniert, bekommt der Bilderrahmen seine eigene Single-Sign-On Lösung.

Wenn Flickr dann beide Parteien (Web und Bilderrahmen) bedienen will, dann müssen sie halt zwei Specs implementieren. Das ist aber OK, da sie einen echten Nutzen aus beisen Varianten ziehen.

So wie es gerade aussieht, bestraft man jeden, der die Bilderrahmen gar nicht bedienen will, da die OpenID Spec klar sagt: Ihr müsst alle Varianten abbilden.

…ich glaub’ das formuliere ich für einen Blogpost nochmal richtig aus

PS. Ich wünsch dir viel Glück bei der Board Member Election (meine Stimme hast du) und dein Firefox Plugin funktioniert leider nicht auf dem Mac…