Hat der erste Entwurf von OpenID Connect noch auf eine (übersichtliche) Seite gepasst, braucht der Draft der OpenID Foundation schon 7 unterschiedliche Spezifikationen.

Wieso müssen „Standard“-Organisationen wie das W3C (z.B. RDFa) oder der OpenID Foundation denn alles so unnötig kompliziert machen? Immerhin schafft es ja sogar Facebook seinen Authentifizierungsprozess auf einer Seite zu erklären. …und noch besser! Er lässt in drei Sätzen zusammenfassen:

1. Hol dir über folgende URL einen Access-Token:
   https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL
2. Häng ihn an folgende URL, auf den du den User weiterleitest:
   https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
scope=email,read_stream
3. Fertsch!

…dazu kommen eine weitere Discovery-Variante die Webfinger, host-meta, XRD, XRDS oder YADIS komplett ignoriert und eine Identity-API die SREG oder AX noch nicht einmal ähnelt!

Mike Jones, einer der Hauptentwickler der Spezifikation, schreibt zwar:

The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

Das ist aber nur die halbe Wahrheit. Webseitenbetreiber, die zukünftig einen OpenID Connect Login anbieten wollen, haben es in der Tat etwas einfacher, da sie sich auf die „Minimalanforderungen“ konzentrieren können. Seiten die einen OpenID Connect Provider stellen wollen haben aber folgendes Problem:

Authorization Requests can follow one of two paths; the Implicit Flow or the Authorization Code Flow. […]
The OpenID Connect Basic Client profile only documents Clients using the Implicit Flow. OpenID Providers MUST support both flows. […]

Damit begeht die OpenID Foundation wieder den gleichen Fehler wie bei OpenID 2.0. Am Schluss gibt es so viele unterschiedliche und halbfertige Implemenrierungen, dass man wieder auf SaaS-Dienste wie Janrain oder Gigaya zurückgreifen muss. Wozu braucht es dann noch einen „Standard“?

Warum denn immer 1000 Alternativen anbieten? Bei Facebook klappts ja auch ohne…

Congratulations on being an RSS reader! You are part of an elite group of people who know how to stay updated in style.

Mit dem Plugin für WordPress sind all diese Features jetzt auch für den privaten Blog nutzbar.

Das Plugin ist sicherlich ein genialer Marketing-Coup um RPX zu promoten, bietet für mich aber (außer dem breiten Spektrum an Login-Möglichkeiten) keine wirkliche Alternative zu dem klassischen OpenID-Plugin von Will Norris.

Was mich an RPX besonders stört:

• Für jeden der sich beim Kommentieren über RPX authentifiziert wird ein WordPress-Profil angelegt, auch wenn die Registrierung für WordPress deaktiviert wurde.
• Der ganze Login-Prozess wird über JanRain abgehandelt, was ja eigentlich auch nicht der Idee von OpenID entspricht. „Man in the middle“ mit Ansage!
• Man muss sich zuerst relativ umständlich bei RPX registrieren um einen API-Key zu bekommen

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

This is a step-by-step tutorial guide for implementing OpenID consumer-side support with a web site that already has users with accounts. It will explain how to easily let new users sign up for an account on your site using their OpenID URL and how to let existing users attach their OpenID(s) so they can sign in using them.

You are a master of efficiency! By using RSS, you save time and avoid distractions. 👏