OpenID Delegation ermöglicht es den OpenID Nutzern eine beliebige URL als OpenID zu verwenden. Für die „Delegation“ sind zwei <link /> Einträge im HTML-Header notwendig:

<link rel="openid.server" href="http://example.com" />
<link rel="openid.delegate me" href="http://id.example.com/" />

Der erste Eintrag (openid.server) gibt den Server an, der den eigentlichen OpenID Service anbietet, der zweite Eintrag (openid.delegate) gibt an, welches die eigentliche OpenID URL ist.

Bei den Arbeiten an hCard-Commenting kam mir die Idee, diese Art der „Delegation“ auch für Microformats, speziell hCards, zu verwenden.

<link rel="hcard.delegate me" href="http://example.com/hcard/" />

Der Vorteil dieser Variante wäre, dass man schon bestehende hCards wie z.B. die Profilseite von flickr (http://flickr.com/people/<username>) oder das Public-Profile von myOpenID (http://<username>.myopenid.com) wiederverwenden könnte, ohne sie nochmals im eigenen Blog veröffentlichen zu müssen.

<link rel="hcard.delegate me" href="http://www.flickr.com/people/pfefferle" />

Ein weiterer Vorteil der „Delegation“ ist, dass die Weblog URL meistens kürzer und viel einfacher zu merken ist, als ein Community Profil:

Weblog URL: https://notiz.blog
flickr URL: http://www.flickr.com/people/pfefferle

Einige WordPress Plugins wie z.B. das oben erwähnte hCard-Commenting oder hAvatar nutzen das Website Feld eines Blogs, um die URL einer hCard anzugeben und widersprechen dabei eigentlich ein wenig der Idee des „adapting to current behaviors“1 der Microformats Community. Wenn ich einen Weblog Eintrag kommentiere gebe ich eigentlich meine normale Blog-URL in das Website Feld ein, das heißt ich müsste eigentlich ein Verhalten ändern, was ich mit hCard-Delegation beibehalten könnte 😉

Aber der eigentliche Vorteil der „Delegation“ liegt in der zentralen Nutzung der hCard. Ich müsste im besten Fall also nur noch eine hCard anlegen und pflegen.

5 Kommentare zu “hCard Delegation

  1. Jo, gute Idee.

    Schonmal beim DiSo-Projekt vorgeschlagen? Ich glaube aber, da geht es eher in die Richtung, die OpenID als eindeutigen Identifier zu nehmen und hCard usw. irgendwie da dranzuklatschen.
    Es wäre wahrscheinlich einfacher, als für jede mögliche Info eine Weiterleitung zu erzeugen.

    Aber ich kann mich irren, vor allem, da ich mir den OpenID-Standard ja eh immer nochmal komplett durchlesen wollte 😉

    http://groups.google.com/group/diso-project

    DataPortability mag natürlich auch eine Möglichkeit sein, das zu diskutieren (denn ohne Support von anderen bringt das wahrscheinlich eher wenig).

  2. Ja, es gab gestern eine längere Diskussion im DiSo Forum (http://tinyurl.com/2tx7yc).

    Mit OpenID hast du natürlich recht, es macht Sinn so wenig wie möglich URLs als Identifier zu verwenden, deshalb finde ich die Idee von myOpenID gar nicht schlecht, den OpenID Endpoint (schöner Artikel von Carsten) mit einer hCard auszuzeichnen. So kann ich mit <link rel="openid.delegate me" href="http://pfefferle.myopenid.com/" /> zwei Fliegen mit einer Klappe schlagen.

    rel-openid.delegate für OpenID und
    rel-me für die hCard.

    Der Auslöser des Artikels war eh ein ganz anderer… Ich hatte mir eigentlich überlegt ob es nicht möglich sei, einen einheitlichen Standard gibt um diese Avatar/Icon-Vielfalt (Pavatar, Favicon, iPhone Bookmark Icon, usw.) in den Griff zu bekommen und meine erste Idee war eine hCard (hcard.logo oder hcard.photo).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert