The website at openidsamplestore.com was built to demonstrate how a website that already allows users to login can help those users (and new users) leverage OpenID to login.

OpenID-Provider gibt es genug, jetzt ist es an der Zeit auch mal ein paar Relying Parties zu bauen.

» Google’s Internet Identity Research – Overview of OpenIDSampleStore
» OpenID Sample Store
» OpenID Videos

Extensible Resource Descriptor
Am 1. November wurde die erste finale Version von XRD veröffentlicht. XRD ist eine Art API-Beschreibung in XML und eine vereinfachte Variante von XRDS/XRDS-Simple (wird z.B. von OpenSocial verwendet), außerdem basieren OStatus und Webfinger auf XRD.

» Extensible Resource Descriptor (XRD) Version 1.0
» XRDS-Simple 1.0 Draft 1

Simple Web Discovery
XRD ist, wie schon erwähnt, wesentlich simpler als XRDS oder XRDS -Simple, aber manchen ist es immer noch zu komplex.

Simple Web Discovery (SWD) defines a HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name.

» Simple Web Discovery (SWD)

Ach ja… Carsten Pötter bloggt übrigens wieder über OpenID. Lesen!

So, Folge 3 ist fertig! Diesmal leider nur mit Christian und mir da Sebastian bei Radio Fritz ein bisschen Werbung für unseren Podcast gemacht hat

Die aktuelle Folge behandelt das Thema OAuth von eher allgemeinen Dingen (Anwendungsgebiete, Beispiel-Applikationen, Abgrenzung zu OpenID) bis zur detaillierten Funktionsweise des offenen Standards.

Ich freue mich wie immer über Kommentare und Anregungen

Die Links zur Sendung findet ihr hier!

Den Podcast bekommen:

• Download MP3
• RSS Feed
• iTunes

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together.

und der Ankündigung, Portable Contacts in myOpenID zu integrieren…

Portable Contacts is an emerging standard for transferring profile data and social connections across websites. Look for upcoming support of this new standard in myOpenID!

…habe ich endlich auch eine funktionierende Demo im Web gefunden. Notwendig für die Testanwendung sind ein myOpenID Profil und ein Plaxo-Account.

Zuerst muss man über den myOpenID Einstellungen Plaxo als seinen Portable Contacts – Provider angeben,

sich mit seiner OpenID an der Demoseite anmelden,

den Zugriff auf die eigenen Daten gewähren

und die Demo-Anwendung bekommt meine Kontakte übermittelt.

Im besten Fall laufen diese Schritte völlig automatisch ab und der Anwender hat nicht mehr zu tun als seine Einverständniserklärung per Knopfdruck zu geben. Ein schöner Anwendungsfall für dieses Beispiel wäre z.B. eine OpenID-Neuanmeldung bei einer Community mit anschließendem Import aller Kontakte.

Was ich an diesem Beispiel außerdem sehr schätze ist, dass JanRain die Portable Contacts API in seinen OpenID-Provider integriert hat ohne sie wirklich integriert zu haben… Der Fokus von myOpenID bleibt weiterhin auf OpenID und die Portable Contacts Anfragen werden lediglich über XRDS-Simple an z.B. Plaxo weiterdelegiert.

So zentral kann dezentral sein

Quelle: John McCrea

Aus Joseph Smarrs Präsentation Implementing the Open Web, gehalten auf der Web 2.0 Expo in New York.

Joseph Smarr and Kevin Marks of Google hacked together a web transformer that integrates Microformats, vCard, and the Portable Contacts API. Given Kevin’s homepage which is full of Microformats, they’ve built an API that extracts his profile information from hCard, uses a public API from Technorati to transform it to vCard, and then exposes it as a Portable Contacts API endpoint. Not only does this work on Kevin’s own page, but his Twitter profile as well which contains basic profile information such as name, homepage, and a short bio.

Ein schönes Beispiel was man mit semantisch ausgezeichneten Informationen machen kann und dass Microformats eben auch (ohne viel Aufwand und mit ein bisschen Transformation) in höherwertige APIs integriert werden können… also keine hCard wurde umsonst geschrieben

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

Dazu brauche ich nicht mehr sagen, als: Implementieren! Sofort und überall

In der aktuellen Folge (Episode 5: The Portable Contacts Initiative) sprechen John McCrea, Joseph Smarr und Chris Messina über das Portable Contacts – Projekt über welches ich vor kurzem noch so gescholten habe… Und ich muss sagen, ich hatte unrecht! Ich glaube kleine Gruppen mit dem Fokus auf ein spezielles Problem können wesentlich effektiver arbeiten als eine so große und über die ganze Welt verstreute Organisation wie DataPortability (da wird wohl auch die Steering Group nichts ändern können… aber man wird sehen).

Die (Portable Contacts (1.0 Draft B) – Spezifikation basiert auf sehr vielen aus dem DataPortability – Umfeld bekannten Techniken wie z.B. XRDS-Simple als Discovery-Service und OAuth für die Authentifizierung.

Was mir besonders gefällt, ist das Contacts Schema welches hauptsächlich auf dem (wenn auch etwas abgeänderten) vCard-Standard basiert und fehlende Felder von anderen Standards wie z.B. OpenSocial übernommen wurden. Dass es auch anders geht, hat z.B. das AX-Schema bewiesen…

Die Verbindung zu Microformats

Schade dass die vCard nicht zu 100% übernommen wurde… sonst hätte man ohne größere Änderungen auch die JSON-Serialisierte hCard (jCard) in den Prozess integrieren können. Spannend wäre es vor allem für Services wie Twitter, die das Freundesnetzwerk sowieso mit hCards auszeichnen.

Vergleich:

jCard

{
  "fn" : "Max Mustermann",
  "email":
    [{
      "value": "max@example.com",
      "type": ["work"],
    }]
}

Portable Contacts 1.0 Draft B

{
  "name" : "Max Mustermann",
  "emails":
    [{
      "value": "max@example.com",
      "type": "work",
    }]
}

Man erkennt zumindest eine Ähnlichkeit

Emailtoid is a simple mapping service that enables the use of email addresses as OpenID identifiers.

EMAIL to ID will kein neuer Provider sein, sondern sieht sich selbst nur als Übergangslösung bis E-Mail Services (z.B. GMX oder GMail) selbst diesen Dienst anbieten.

Der Login-Prozess soll folgendermaßen ablaufen:

When a user enters in an email address, there is an xrds discovery made on the top level domain (eg, gmail.com). If the XRDS document contains an Emailtoid mapper or email transformation template, use that. If not, then you make the same request on emailtoid.net to get the mapper document and send the email to there. Emailtoid is a fallback.

Wie genau das Mapping oder das XRDS-Dokument aussehen soll ist noch nicht spezifiziert, wird aber demnächst hier zu finden sein.

Macht eine E-Mail – Adresse als OpenID Sinn?

In Zukunft steht sicherlich die URL im Zentrum des Authentifizierungsprozesses, da sich über sie einfach mehr Informationen transportieren lassen (seien es Meta-Information oder Semantisches HTML). Auch das Semantische Web basiert auf URIs, um verschiedene Informationen zu vernetzen. Aus diesen Gründen sollte man den User mal so langsam an diese neuen Umstände gewöhnen

Mit EMAIL to ID kann der Nutzer seine bestehenden Gewohnheiten (Anmelden per E-Mail – Adresse) beibehalten und trotzdem die Vorteile von OpenID nutzen (Simple Lösung für ein scheinbar schwieriges Problem… hat was vom Ei des Kolumbus).

Warum kein eigener Standard?

Ein neuer OpenID Standard auf Basis von E-Mail – Adressen (wie hier angedacht) würde zusätzlichen und unnötigen Implementierungsaufwand bedeuten (nimmt man an, die URLs sind die Zukunft), den man sich bei EMAIL to ID sparen kann. EMAIL to ID mappt eigentlich nur eine E-Mail – Adresse auf eine URL http://emailtoid.net/mapper?email=jane@example.com und entspricht somit einer vollwertigen OpenID (keine Anpassungen am bisherigen Standard nötig).

(via)

The momentum began building for ‘data portability’ last year, and we are now at a point where there is strong support for the principle that users should be in control of their data and have the freedom to access it from across the web.

[...]

The goal of Portable Contacts is to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web.

[...]

…we’re using existing standards wherever possible, including vCard, OpenSocial, XRDS-Simple, OAuth, etc.

…was für mich nichts anderes als eine Trotzreaktion auf Data Portability ist!

Da spricht man von einheitlichen Standards und Portabilität, schafft es aber nicht, gemeinsam an einem Projekt zu arbeiten… Ich sehe kaum Erleichterung darin, statt verschiedener proprietärer APIs (z.B. Google’s GData Contacts API oder Microsoft’s Live Contacts API) wahrscheinlich mind. genauso viele unterschiedliche standard APIs (Data Portability oder Portable Contacts) implementieren zu müssen!

…irgendwie ironisch!

Zum besseren Verständnis hier zwei Beispiele…

Profile-URI:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">

  <head profile="http://gmpg.org/xfn/11">
...

XRDS-Simple Type:

<Service>
  <Type>http://gmpg.org/xfn/11</Type>
  <URI simple:httpMethod="POST">

http://twitter.com/pfefferle

  </URI>
</Service>

Zwei wesentliche Aspekte für den Einsatz von XRDSTypes.net (via):

• Besteht schon eine Profile-URI bzw. XMLNS wird dieser verwendet.
• XRDSTypes soll ein community-unabhängiger Platz sein, um Type-URIs zu definieren.
• …

Für Microformats könnten also die im Microformats Wiki definierten Profile URIs genutzt werden.

(via Mr. Topf)

XRDS-Simple ist in erster Linie eine einfache Form der Service-Discovery, von der Idee her ähnlich wie z.B. die Web Services Description Language (WSDL).
XRDS beschränkt sich, im Gegensatz zu dem wesentlich komplexeren WSDL, auf die Beschreibung der Service URLs/URIs und wie man sie nutzt (POST oder GET).

Vom Aufbau her ist XRDS-Simple dem YADIS Format (OpenID-Autodetection) sehr ähnlich:

<XRDS xmlns="xri://$xrds">
  <XRD xmlns:simple="http://xrds-simple.net/core/1.0"
          xmlns="xri://$XRD*($v*2.0)" version="2.0">
    <Type>xri://$xrds*simple</Type>
    <Service>
      <Type>http://example.net/some_type</Type>
      <URI simple:httpMethod="POST">

http://example.com/resource

      </URI>
    </Service>
  </XRD>
</XRDS>

Der wichtigste Teil eines Services ist der Type welcher den Typ der URI beschreibt und die URI welche beschreibt unter welcher URI der Service zu erreichen ist.

Ein paar Beispiele für ein paar klassische Services:

FOAF

type

http://xmlns.com/foaf/0.1/

url

http://www.mybloglog.com/buzz/members/pfefferle/foaf

hCard

type

http://purl.org/uF/hCard/1.0/

url

http://www.mybloglog.com/buzz/members/pfefferle/hcard

APML

type

http://www.apml.org/apml-0.6

url

http://notizblog.org/apml/

OPML

type

http://www.opml.org/spec2

url

http://ma.gnolia.com/opml/default/people/pfefferle

Neben dem <Type> kann für die URI auch noch ein <MediaType> (nichts anderes als der MIME-Type (RFC2046)) gesetzt werden, der beschreibt um was es sich bei dem Verlinkten handelt.

Beispiel: <MediaType>text/html</MediaType>

Mit diesem einfachen Prinzip lassen sich auf einfache Weise nahezu alle Services beschreiben.

Vorteile von XRDS-Simple? Meiner Meinung nach gibt es zwei wesentliche Gründe XRDS einzusetzen.

Einheitliche Erkennung

XRDS vereinfacht die automatische Service-Erkennung, da nur noch ein Meta-Tag interpretiert werden muss:

<meta http-equiv="X-XRDS-Location" content="http://example.com/xrds" />

statt jeder Meta-Tag einzeln:

<link rel="meta" type="text/xml" title="APML" href="..." />
<link rel="meta" type="text/xml" title="OPML" href="..." />

One file to detect them all

Information Hiding

Ein weiterer wesentlicher Aspekt der Autodetection ist die Sicherheit… nicht jeder möchte seine Attention-Daten (APML) oder seine hCard frei zur Verfügung stellen. Über XRDS-Simple ist es möglich, diese Informationen zu bündeln und z.B. nur über OpenID AX oder OAuth zugänglich zu machen.

Ein Beispiel dazu: XRDS-Simple als zentraler ServiceCatalogue

OAuth discovery

Der Vollständigkeit halber sollte man erwähnen dass XRDS-Simple eigentlich ein “Nebenprodukt” von OAuth Discovery ist.

The first draft of OAuth Discovery published four months ago started a dialog and was the main driver behind the development of XRDS-Simple. #

Mehr zu diesem Thema bei hueniverse oder Chris Messina.