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!

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

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

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

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 🙂

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

Quelle: John McCrea

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

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

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 😉

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

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 🙂

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

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)

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

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!

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

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:

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

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

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

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" />

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.

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