Ich hatte in den letzten Monaten die Möglichkeit, mich ein bisschen intensiver mit ID4me zu beschäftigen. Nach anfänglicher Skepsis finde ich die Idee mittlerweile extrem charmant.

Im letzten Jahr haben sich einige deutsche Firmen zusammen geschlossen um mit netID bzw. VERIMI zwei konkurrierende Single-Sign-On Dienste zu entwickeln. Beide Systeme basieren zwar auf dem offenen Standard OpenID Connect, scheinen aber mindestens genauso restriktiv zu sein. netID wird nur von einer begrenzten Anzahl von Diensten angeboten und VERIMI setzt einen zentralen Account bei verimi.de voraus.

ID4me basiert zwar auch auf OpenID Connect, ist aber kein „Yet Another Login-Service“, wie ich anfangs fälschlicherweise vermutet hatte. ID4me erweitert die OpenID Spezifikation mit einer DNS-Discovery und funktioniert vollkommen dezentral.

The ID4meidentifier, consisting of a valid DNS hostname (or, potentially, of an email address), would allow users to log into any online service via a single account, similarly to the OTT-run services, but would also allow users to choose the manager of their identifier among any number of compatible providers.

[…]

To foster adoption and remove barriers to market entry, ID4me builds on public and open standards (OpenID Connect and DNSSEC) and releases all its specifications as open, royalty-free standards, submitting them to the appropriate Internet standardization bodies. Entities already running single sign-on systems based on OpenID Connect should be able to extend them to provide ID4meidentifiers quite easily.

ID4me – General overview

Wie funktioniert ID4me genau?

Der ID4me DNS Eintrag sieht wie folgt aus:

_openid.notiz.blog. 600 IN TXT "v=OID1;iss=id.test.denic.de;clp=identityagent.de"

Dabei steht v für die Protokoll-Version, iss für den Issuer (der Endpunkt der für die Autentifizierung verantwortlich ist) und clp für Claims Provider (der Endpunkt über den „Claims“ (beispielsweise Profildaten) abgefragt werden können).

Was macht ID4me so spannend?

Zum selbst hosten einer OpenID, braucht man eine Domain, Webspace und eine OpenID Connect – Library, außerdem muss man wissen wie man diese installiert und betreibt. Um diese Komplexität zu reduzieren hat man sich bei OpenID 1.1 schon 2006 mit dem Thema „Delegated Authentication“ beschäftigt.

If the End User’s host is not capable of running an Identity Provider, or the End User wishes to use one running on a different host, they will need to delegate their authentication. For example, if they want to use their website, http://www.example.com/, as their Identifier, but don’t have the means, or desire, to run an Identity Provider.

Klassisch braucht OpenID Connect für die „Delegation“ mindestens ein WebFinger – Dokument. Das heißt man braucht „nur“ noch eine Domain, Webspace und man muss wissen wie WebFinger funktioniert.

ID4me konzentriert sich ausschließlich auf das Prinzip der „Delegated Authentication“ und reduziert die Anforderungen auf eine Domain!

Die Domain ist dadurch an keinen festen OpenID-Provider (Issuer) gebunden und kann bei einem Umzug zu einem neuen Registrar, weiterhin auf den alten Issuer zeigen, bzw. den Issuer beliebig wechseln. Solange sich die Domain nicht ändert, sind Hoster, Domain-Registrar, OpenID-Provider oder E-Mail – Anbieter austauschbar.

Noch ein schöner Nebeneffekt: ID4me tritt nicht in Konkurrenz zu anderen OpenID Connect Providern wie beispielsweise die oben erwähnten netID oder VERIMI. Im Gegenteil, jeder dieser Anbieter sollte mit wenig Aufwand über ID4me „delegierbar“ sein.

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

Im Ernst, ich freue mich sehr, dass Marcel Interesse an dem Thema hat (und das schon seit einer ganzen Weile) und nach einem kurzen Vorgespräch haben wir auch gemerkt, dass uns der Stoff so bald nicht ausgehen wird!

Die erste Ausgabe ist eine Bestandsaufnahme der letzten 15 Jahre „Open Web“ und ein kleiner Ausblick auf zukünftige Themen.

In der ersten Ausgabe der neuen Podcastreihe zum Themenkomplex ‚Open Web‘ sprechen Matthias Pfefferle und Marcel Weiß über die Evolution von OpenID, die uns einen Hinweis auf allgemeine Herausforderungen für Protokolle in der heutigen Zeit gibt; Stichwort Extrawürste der großen Teilnehmer, welche zu Balkanisierung führen. Weitere Themen sind die DSGVO und Dataportability, Mastodon, Identi.ca und wie ActivityPub aktuell OStatus als zugrundeliegendes Protokoll für dezentrale Netzwerke ablöst. Wir ordnen die Irrungen von Diaspora ein und reden last not least über die Tragödie der Microformats.

Viel Spaß beim Hören!

‚Hier & Jetzt‘ kann man per RSS-Feed abonnieren und findet man natürlich auch bei Apple Podcasts und in jeder Podcast-App.

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Spezifikationen lesen, macht ja generell nicht viel Spaß, aber bei der OpenID Connect Federation 1.0 kam ich nicht mal bis zur Hälfte. Bevor man wirklich versteht was das Protokoll eigentlich macht (für mich hört es sich ähnlich an wie OpenID Connect Dynamic Client Registration), geht es um Metadaten, JSON Web Signature (JWS), JSON Web Tokens (JWT) und JSON Web Keys (JWK).

Eigentlich dachte ich, dass OpenID Connect durch OAuth 2 super simpel sein soll… Immerhin basiert ja OAuth 2 auf SSL/TLS und nicht wie OAuth 1 auf komplizierte Signaturen.

The majority of failed OAuth 1.0 implementation attempts are caused by the complexity of the cryptographic requirements of the specification. The fact that the original specification was poorly written didn’t help, but even with the newly published RFC 5849, OAuth 1.0 is still not trivial to use on the client side. The convenient and ease offered by simply using passwords is sorely missing in OAuth.

Eran Hammer

Die OpenID Foundation scheint ihre Meinung geändert zu haben… SSL scheint wohl doch nicht auszureichen.

Another problem that has been raised is the dependency on TLS as the sole protection against attacks on the transferred information. These last couple of years a number of problems with OpenSSL, which is probably the most widely used TLS library, have been discovered that put reasonable doubt into this dependency.

OpenID Connect Dynamic Client Registration

Schade, schade…

Wer eine wirkliche Alternative zu OpenID Connect sucht, der soll sich mal IndieAuth anschauen. IndieAuth kommt der ursprünglichen Idee von OpenID Connect sehr nahe und ist relativ einfach zu verstehen und auch zu implementieren!

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

Janrain just announced that MyOpenId.com will be shutting down by early 2014. If you currently delegate OpenID on your domain to myopenid.com, you’ll need to find a new OpenID provider.

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

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

RSS readers like you are the unsung heroes of the internet. Keep up the good work!

(Kleiner Nachtrag zu der „OAuth ist tot“ Kolumne in der SCREENGUIDE Ausgabe 15 um zu zeigen, warum gerade das W3C auch für Community Formate durchaus nützlich sein kann)

Vor ein paar Wochen kam eine E-Mail mit der Bitte, an einer Umfrage zu den W3C Community and Business Groups teilzunehmen und das hat mich daran erinnert, dass ich mich bisher noch gar nicht zu dem Thema geäußert habe… das hole ich hiermit kurz nach!

Ich beschäftige mich ja jetzt schon eine ganze Weile mit dem Web und seinen diversen Formaten, Standards, Techniken, Spezifikationen usw. usf. Leider ist das Web aber ziemlich vergänglich und eine Menge guter Ideen und Formate sind, aus Mangel an Interesse, mangelndem Durchhaltevermögen, nicht genug Ruhm oder einfach nur aus kurzfristigen „Publicity“ Interessen wieder spurlos verschwunden.

Hier ein paar Beispiele:

• MicroID – Ein simples Format um das leidige Thema „Webseite verifizieren“ zu vereinheitlichen. Domain nicht mehr erreichbar!
• POSHFormats – POSHFormats wollte alle Websemantiken sammeln die es leider nicht zu einem Microformat geschafft haben. Domain nicht mehr erreichbar!
• MicroJSON – Ein Projekt welches sich mit der JSON-Serialisierung von Microformats beschäftigt hat. Zum Glück hat die Diskussion einen Weg ins Microformats-Wiki gefunden. Domain nicht mehr erreichbar!
• Portability Policy – Das DataPortability Vorzeige-Projekt wollte eine vereinheitlichte Policy für die Portability von Daten schaffen. Domain nicht mehr erreichbar!
• Microsyntax – Eine Sammlung von Microblogging Syntaxen wie z.B. das „@username“ oder „RT“. Domain nicht mehr erreichbar!
• AXSchema.org – Die Seite wollte die Attribute für OpenIDs Attribute Exchange sammeln. Domain nicht mehr erreichbar!
• Monkeyformats.org – Eine etwas schräge Idee, Webseiten per Greasemonkey-Scripts mit Microformats zu versehen um sie dann mit Microformats-Plugins interpretieren zu können. Alleine wegen dem Namen aber schon großartig :(|)! Domain nicht mehr erreichbar!
• Bioformats – Mikroformate um biologische Daten abzubilden. Domain wurde verkauft!

…um nur einige zu nennen. Ob jetzt alle Projekte gut waren, darüber lässt sich streiten, aber es ist auf alle Fälle schade dass sie mittlerweile gar nicht mehr erreichbar sind. Viele Ideen waren vielleicht zu früh gedacht oder das Problem, das sie versuchten zu beheben, war einfach noch nicht groß genug. Oftmals braucht es vielleicht einfach nur ein wenig mehr Zeit! Lange Rede, kurzer Sinn: Die W3C Communities bieten genau für diese Community Formate die ideale Plattform:

A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C’s international community of Web experts. Community Groups may produce Specifications; these are not standards-track documents but may become input to the standards process. For instance, a Community Group might gather to work on a new technical specification, or convene to have discussions about a tutorial for an existing specification.
W3C FAQ

Auch wenn aus den Formaten kein „Standard“ werden sollte, so sind sie beim W3C doch besser aufgehoben und HOFFENTLICH auch für längere Zeit erreichbar! Gerade Junge Projekte wie „Unhosted Web“ oder „Federated Social Web“ scheinen die W3C Communities gut anzunehmen und auch Facebook forciert eine „Mobile Web“ Gruppe (die jetzt vielleicht nicht mehr so aktiv betrieben wird ;)).

Vielleicht macht sich jemand ja mal die Mühe und zieht zumindest die MicroID und die Portability Policy um!

Thanks for reading this post via RSS. RSS is great, and you’re great for using it. ♥️

(das Bild hab ich mir von hueniverse.com ausgeliehen)

Am Freitag (also morgen) gibt’s mal wieder ’ne neue SCREENGUIDE mit dem Fokus auf „Social Commerce“… In meiner Kolumne geht es diesmal um OAuth und das Dilemma dass offene Standards, wenn sie einmal vom W3C oder der IETF betreut werden, zu wahren Monstern mutieren.

Open Web Technologien können sich bald nur noch die Googles, Microsofts, Yahoos und Facebooks des Internets leisten! OpenID Connect mutiert von einem simplen Konzept zu einer 8 Dokumente schweren Spezifikation, RDFa ist so kompliziert, dass es einer “light” Version bedarf und Eran Hammer legt sein Amt als Editor von OAuth 2.0 nieder, da ihm der Standard zu „Enterprise“-lastig wird.

KAUFEN! LESEN! FEEDBACK GEBEN!

RSS readers like you are the unsung heroes of the internet. Keep up the good work!

So, jetzt muss ich mich auch mal zu der OAuth Geschichte äußern! Wer nicht weiß warauf ich anspiele, der sollte sich zuerst mal Eran Hammers Blogpost durchlesen: OAuth 2.0 and the Road to Hell.

Auf alle Kritikpunkte von Eran Hammer möchte ich gar nicht eingehen… Ich kann seine Kritik durchaus verstehen und teile sie auch weitestgehend. Auch ich bin generell der Freund von schlanken Spezifikationen und hasse Standards die versuchen alles abzudecken und jedes Format zu unterstützen.

Abgesehen von den ganzen Sicherheitsaspekten und dem Fokus auf „Enterprise“-Anwendungen welche Eran Hammer in seinem Artikel erwähnt, hat mich die Fehlende Interoperability von OAuth 2 zuerst am Meisten genervt:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Mein erster Gedanke: Na toll! Man macht sich hier Gedanken über dezentrale Netzwerke, für die man einfache und simple Spezifikationen braucht und Familie OAuth released ein „Framework“…

Aber eigentlich ist ja gerade das auch eine riesen Chance für das Web! Während OpenID Connect bestimmt, dass jeder Provider die komplette Spezifikation implementieren muss:

The OpenID Connect Basic Client profile only documents Clients using the Code Flow. OpenID Providers MUST support both flows. OpenID Providers should consult the OpenID Connect Standard 1.0 Specification.

bleibt es jedem frei gestellt welchen Teil von OAuth 2 er umsetzt… Also warten wir doch einfach ab, bis das „Framework“ fertig ist, suchen uns die für das Web eleganteste Variante raus, dokumentieren sie schön und fertig ist „OAuth 2 – The Web Edition„.

…nicht perfekt, aber es könnte auch schlimmer sein!

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

Das Problem: Für die meisten Bedürfnisse im Web gibt es eine Reihe an Services, die diese befriedigen… und das ist eigentlich auch gut so… Leider führt es aber dazu dass Seitenbetreiber, um es jedem Besucher recht zu machen, zu folgendem neigen:

In der OpenID-Community (welche mit dem gleichen Problem zu kämpfen hat), nennt man dieses Phänomen "NASCAR Problem" in Analogie zu den bunten Stickern der Rennwagen.

Das große Problem des dezentralen Webs!

Im Idealfall sollte aber nicht der Seitenbetreiber die Services auswählen sondern der Seitenbesucher …und genau das ist das Dilemma bei verteilten Diensten (wenn man mal nicht davon ausgeht dass eh alle Welt bei Facebook ist).

OpenID, Diaspora, StatusNET, Addthis, ShareThis und viele andere haben bisher relativ erfolglose Versuche gestartet die Icon-Flut einzudämmen. OpenID & Co. hat es mit diversen "Identifiern" (URL, XRI, E-Mail, Webfinger, …) versucht und die User dadurch nur noch mehr verwirrt und die Share-Services verschleiern das Problem in dem sie die Buttons einfach in einem Popup/Layer verstecken.

Wie können Web Intents helfen?

Web Intents funktionieren nach einem ganz ähnlichen Prinzip wie XAuth (hier erklärt). Beim Surfen merkt sich der Browser welche Dienste ein User benutzt und gibt diese, bei bedarf an besuchte Seiten weiter. Ein Beispiel:

1. Ein User besucht Google (oder Yahoo oder MyOpenID)
2. Der Browser fragt nach, ob er sich Google als Login-Dienst (in dem Fall OpenID) merken soll
3. Der User bestätigt und besucht weitere Seiten
4. Er entdeckt Plaxo und möchte sich anmelden
5. Beim Klick auf den Login-Button wird die Liste aller, beim Browser registierten Login-Dienste (in unserem Beispiel nur Google) an die Webseite übertragen (sofern der User einverstanden ist)
6. Statt wahrlose ausgewählte Diensten anzuzeigen, ist Plaxo jetzt in der Lage gleich den Authentifizierungs-Prozess mit Google zu starten

Dank Web Intents brauchen Service-Anbieter fortan nur noch ihre Dienste beim Browser registrieren und Seitenbetreiber können einen Platz auf ihrer Seite anbieten, an dem diese Aktionen ausgeführt werden sollen… so zu sagen eine Art "Universal Button". Der Webmonkey fasst das Thema Web Intents folgendermaßen zusammen:

In practice Web Intents work a bit like mailto: links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services.

Keine Identifier, keine langen Button-Leisten/Popups/Layer und den ganzen komplizierten Käse übernimmt der Browser! Vielleicht wird es so ja doch noch was mit dem synaptic, distributed bzw. federated social web 🙂

In den kommenden Artikeln werde ich etwas mehr auf die Technik und die Implementierung in Chrome/WebKit eingehen.

Hier noch ein paar Links:

• Web Intents – Gluing web functionality together
• Button Sluts and Web Actions
• WebKit Offers Early Preview of ‘Web Intents’
• Web Intents: Demos
• Web Intents: Examples

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

Ich durfte mal wieder einen Artikel für die t3n schreiben und das Thema ist (auch mal wieder) Single Sign On.

Seit Jahren spricht niemand mehr von Data Portability, und auch der Hype um OpenID flacht aus vielerlei guten Gründen immer weiter ab. Es ist an der Zeit, Bilanz zu ziehen, die Themen „Online Identity“ und „Single Sign-On“ neu anzugehen und aus den Fehlern der letzten Jahre zu lernen. Ein Ausblick.

Der Artikel beschreibt im Wesentlichen die aktuellen Projekte von OpenID (OpenID Connect und Account Chooser), Google (Google Identity Toolkit) und Mozilla (BrowserID) und deren Starken und Schwächen.

Seit Freitag ist Ausgabe 27 des t3n-Magazins im Handel erhältlich… also ab in den Laden, kaufen, meinen Artikel lesen und mir Feedback geben! Danke 🙂

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

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…

RSS readers like you are the unsung heroes of the internet. Keep up the good work!

Ich schreibe gerade einen Artikel für das t3n Magazin über aktuelle Sign-In-Mechanismen und hab mir in dem Zuge BrowserID mal etwas genauer angeschaut. Ich bin wirklich extrem überrascht mit wie wenig Arbeit es sich in z.B. WordPress einbauen lässt.

BrowserID besteht eigentlich nur aus einem JS-File,ein paar Zeilen JS-Code:

<script src="https://browserid.org/include.js" type="text/javascript"></script>
<script type="text/javascript">
navigator.id.get(function(assertion) {
    if (assertion) {
        // This code will be invoked once the user has successfully
        // selected an email address they control to sign in with.
    } else {
        // something went wrong!  the user isn't logged in.
    }
});
</script>

und dem anschließenden Verifizieren der assertion:

$ curl -d "assertion=&audience=https://mysite.com" "https://browserid.org/verify"
{
    "status": "okay",
    "email": "lloyd@example.com",
    "audience": "https://mysite.com",
    "expires": 1308859352261,
    "issuer": "browserid.org"
}

Den ausführlichen Ablauf der Authentifizierung findet ihr auf Github.

Um BrowserID in WordPress zu integrieren lädt man also zuerst den JS-Code in den Login Header:

// add the BrowserID javascript-code to the header
add_action('login_head', 'bi_add_js_header');
function bi_add_js_header() {
  echo '<script src="https://browserid.org/include.js" type="text/javascript"></script>';
  echo '<script type="text/javascript">'."\n";
  echo 'function browser_id_login() {
    navigator.id.get(function(assertion) {
      if (assertion) {
        window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion;
      } else {
        // do nothing!
      }
    })
  };'."\n";
  echo '</script>';
}

und platziert den BrowserID-Button auf der Login-Seite:

// add the login button
add_action('login_form', 'bi_add_button');
function bi_add_button() {
  echo '<p><a href="#" onclick="return browser_id_login();"><img src="https://browserid.org/i/sign_in_blue.png" style="border: 0;" /></a></p>';
}

Nach dem klick auf den Button öffnet sich das Autorisierungs-Fenster von BrowserID und nach dem erfolgreichen Sign-In wird die gerade implementierte Methode navigator.id.get(function(assertion) {} aufgerufen.

Im nächsten Schritt muß man die erhaltene assertion über BrowserID.org verifizieren. Da ich den notwendigen POST nicht über JavaScript absetzen will, leite ich einfach auf eine Seite weiter und übergebe die erhaltene assertion als GET-Paramater.

if (assertion) {
  window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion;
}

Jetzt kann der POST bequem über WordPress abgesetzt werden.

// the verification code
add_action('parse_request', 'bi_verify_id');
function bi_verify_id() {
  global $wp_query, $wp, $user;

  if( array_key_exists('browser_id_assertion', $wp->query_vars) ) {
    // some settings for the post request
    $args = array(
      'method' => 'POST',
      'timeout' => 30,
      'redirection' => 0,
      'httpversion' => '1.0',
      'blocking' => true,
      'headers' => array(),
      'body' => array(
        'assertion' => $wp->query_vars['browser_id_assertion'], // the assertion number we get from the js
        'audience' => "http://".$_SERVER['HTTP_HOST'] // the server host
      ),
      'cookies' => array(),
      'sslverify' => 0
    );

    // check the response
    $response = wp_remote_post("https://browserid.org/verify", $args);

    if (!is_wp_error($response)) {
      $bi_response = json_decode($response['body'], true);

      // if everything is ok, check if there is a user with this email address
      if ($bi_response['status'] == 'okay') {
        $userdata = get_user_by('email', $bi_response['email']);
        if ($userdata) {
          $user = new WP_User($userdata->ID);
          wp_set_current_user($userdata->ID, $userdata->user_login);
          wp_set_auth_cookie($userdata->ID, $rememberme);
          do_action('wp_login', $userdata->user_login);

          wp_redirect(home_url());
          exit;
        } else {
          // show error when there is no matching user
          echo "no user with email address '" . $bi_response['email'] . "'"; 
          exit;
        }
      }
    }
    
    // show error if something didn't work well
    echo "error logging in"; 
    exit;
  }
}

Gibt es einen User mit der entsprechenden E-Mail – Adresse wird er eingeloggt, falls nicht, wird ein Fehler ausgegeben.

Bei der Demo hab ich mir aus Zeitgründen ein wenig Code bei Marcel Bokhorst geliehen, dessen BrowserID-Plugin wesentlich ausgereifter und vollständiger ist als der kleine Demo-Code den ich hier zusammengestückelt habe.

Wenn euch das zu schnell ging und ich auf einige Details nicht genügend eingegangen bin, könnt ihr gerne fragen 🙂

Ich habe den kompletten Code übrigens auch auf Github hochgeladen… das ist einfacher als sich alles zusammen zu kopieren.

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

• OpenID Discovery basiert auf Meta-Tags, alternativ funktioniert aber auch XRDS(-Simple)/Yadis oder Webfinger.
• OpenID stellt über SREG Profilinformationen bereit, alternativ aber auch über Attribute Exchange.
• RDFa 1.1 ist folgendermaßen aufgebaut: <html prefix="foaf: http://xmlns.com/foaf/0.1/" > ... <span property="foaf:name">John Doe</span> ... </html> alternativ aber auch: <div vocab="http://xmlns.com/foaf/0.1/" about="#me"> <span property="name">John Doe</span> </div> …oder: <div profile="http://xmlns.com/foaf/0.1/" about="#me"> <span property="foaf:name">John Doe</span> </div>
• OpenSocial, oEmbed, ActivityStrea.ms und host-meta benutzen JSON, alternativ aber auch XML
• OAuth verschlüsselt mit HMAC-SHA1, alternativ aber auch mit RSA-SHA1 oder PLAINTEXT

To be continued…

Wie viel Komplexität man sich sparen könnte wenn man sich auf eine Variante beschränken würde.

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

Ich hab mir letzte Woche mal den aktuellen Draft von OpenID Connect angeschaut und mich riesig gefreut, dass die OpenID-Community ihrer Linie treu bleibt und dem User-Schema wieder komplett neue Bezeichnungen gibt. Aber das scheint ein genereller Spaß in OpenWeb-Kreisen zu sein. Ich hab mir mal einen Spaß d’raus gemacht einzelne Bezeichnungen verschiedener „Standards“ die mit Profil/User-Infos zu tun haben, zu vergleichen.

Claims für den kompletten „Namen“ eines Users:

• fn (vCard, hCard)
• name (foaf, OpenID Connect, Facebook Connect, schema.org)
• fullname (OpenID SREG)
• namePerson (OpenID AX)
• displayName (Portable Contacts, Open Social, Activity Streams)

Claims für den „Nachnamen“ eines Users:

• given name (vCard)
• given-name (hCard)
• lastName (foaf)
• family_name (OpenID Connect, Facebook Connect)
• namePerson/last (OpenID AX)
• givenName (Portable Contact, Open Social)

Gut dass wir das W3C, die WHATWG, die IETF und diverse ander Standard-Organisationen haben die in jahrelanger Arbeit, Standards wie RDF, XML, JSON, RDFa und Microdata spezifizieren und dann jeder, wie er gerade bock hat, ein Schema dafür baut 😀

… Schema.org und das Open Graph Protocol sind perfekte Beispiele dafür, wie man gekonnt bestehene Schemas ignoriert und einfach macht, wie man denkt!

P.S. Ich weiß dass man die Bezeichnung „Eskimo“ eigentlich nicht mehr benutzt und wehe mir nimmt jemand den Mythos mit den 90 Wörtern für Schnee 😉

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

MyProfile intends to provide a solution for managing the numerous accounts and profiles that users have on the Internet. Its main purpose is to provide a unified user account, or simply ‘user profile’, which as opposed to current ‘silo’ profiles, would really be under the user’s control, on a device controlled by the user.

Es gibt übrigens auch einen OpenWebPodcast zum Thema WebID…

Hey there, RSS reader! You’re cool. Keep being awesome! 😎

Die Meldung ist nicht nur erfreulich, sondern vielleicht auch die Rettung des etwas angeschlagenen offenen Standards. Trotz des eher hinkenden Vergleichs, wurde OpenID immer mit dem Erfolg von Facebook Connect gemessen. Die OIDF hat es durchweg versäumt den Standard als reines „Werkzeug“ sehen und die Produkte basierend auf OpenID zu promoten. Wie ich schon im Webstandards-Magazin (Ausgabe 9: Pfefferles OpenWeb) schrieb:

Facebook Connect ist nicht wegen seinem proprietären System so erfolgreich und der Misserfolg von MySpaceID hat nichts mit den benutzten offenen Standards zu tun. Promote the utility not the technologie. To reach the majority of users who aren’t familiar with OpenID as a technology, promote the ability to log in using an existing account, not „OpenID“ itself. Ich würde sagen das Problem liegt nicht am Protokoll sondern an den fehlenden sinnvollen Anwendungsfällen. OpenID funktioniert überall da, wo der User einen Nutzen hat ohne zu wissen was unter der Oberfläche passiert, beispielsweise „Sign in with Google“ oder „Sign in with Yahoo!“. Wo bleiben also die Killerapplikationen wie z.B. Paypals angekündigtes Express Checkout auf Basis von OpenID?

Reines Single-Sign-On ist ein Geek-Thema und scheint wohl kein generelles Bedürfnis zu befriedigen. Ein „Mit einem Klick-Bezahlen“ ist dagegen eine enorme Chance für Einkäufer und kleine Verkäufer. Wo man bisher, oft durch die langwierige Anmeldung und das hinterlegen der Kontodaten, trotz günstigerer Angebote doch wieder bei Amazon bestellt hat, bietet PayPal in Zukunft vielleicht die Lösung: Schnelles, unkompliziertes und sicheres Einkaufen mit einem „Klick“.

Hoch lebe OpenID 🙂

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

As the Web becomes increasingly a focal point for economic and social activity, there is an urgent need for trustworthy, widely-applicable digital identity management. This includes the need for authentication and authorization to work across multiple web-sites, enterprises, devices, and browsers in a uniform and easy-to-use manner.

Leider scheint Chris Messina nicht dabei zu sein… mir hat seine damalige Konzeptstudie sehr gut gefallen!

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

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

Negative Nachrichten dominierten in den vergangenen Wochen das Geschehen im OpenWeb: RSS ist tot und die Zukunft von delicious ist ungewiss. Ganz abgesehen von der Diskussion um die Zukunft von OpenID.

…und wie immer würde ich mich sehr über Feedback freuen 🙂

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