audio

· · zu lesen
open-web-podcast.png

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:

Text

· · zu lesen

Nach der Demo von Brian Ellin auf dem Portable Contacts Summit…

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,

openid-porc.jpg

sich mit seiner OpenID an der Demoseite anmelden,

den Zugriff auf die eigenen Daten gewähren

Plaxo Pulse.jpg

und die Demo-Anwendung bekommt meine Kontakte übermittelt.

OpenID with Portable Contacts Demo.jpg

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 🙂

Text

· · zu lesen

David Recordon stellt auf O’Reilly – Radar zwei der spannendsten Ergebnisse des gestrigen PortableContacts Hackathon (bei Six Apart) vor:

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 😉

Text

· · zu lesen

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"],
    }]
}Code-Sprache: JSON / JSON mit Kommentaren (json)

Portable Contacts 1.0 Draft B

{
  "name" : "Max Mustermann",
  "emails":
    [{
      "value": "max@example.com",
      "type": "work",
    }]
}Code-Sprache: JSON / JSON mit Kommentaren (json)

Man erkennt zumindest eine Ähnlichkeit 🙂

Text

· · zu lesen
emailtoid.logo.png

EMAIL to ID ist ein Service, der eine E-Mail – Adresse zu OpenIDs macht.

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)

Text

· · zu lesen

Gestern bin ich auf das Portable Contacts Projekt gestoßen…

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!

Text

· · zu lesen

Angelehnt an die, für Profile-URIs geschaffene URI-Services wie z.B. PURL (oder XMLNS für XML-Namespaces), schafft XRDSType.net einen zentralen und „community-neutral URIspace“ für XRDS-Simple Types.

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">
...Code-Sprache: HTML, XML (xml)

XRDS-Simple Type:

<Service>
  <Type>http://gmpg.org/xfn/11</Type>
  <URI simple:httpMethod="POST">http://twitter.com/pfefferle</URI>
</Service>Code-Sprache: HTML, XML (xml)

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

  • 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)

Text

· · zu lesen

Da XRDS-Simple auch eine zentrale Rolle bei DataPortability spielen wird, hab ich mir das Format nochmal vorgenommen. (Im folgenden Text setze ich, der Einfachheit halber, XRDS mit XRDS-Simple gleich auch wenn es technisch nicht ganz korrekt ist)

XRDS-Simple-Large.png

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>Code-Sprache: HTML, XML (xml)

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
https://web.archive.org/web/20090825215938/http://www.mybloglog.com:80/buzz/members/pfefferle/foaf/
hCard
type
http://purl.org/uF/hCard/1.0/
url
https://web.archive.org/web/20100413121636/http://www.mybloglog.com:80/buzz/members/pfefferle/hcard
APML
type
https://github.com/apml/spec-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" />Code-Sprache: HTML, XML (xml)

statt jeder Meta-Tag einzeln:

<link rel="meta" type="text/xml" title="APML" href="..." />
<link rel="meta" type="text/xml" title="OPML" href="..." />Code-Sprache: HTML, XML (xml)

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.