Nach den Ankündigungen, dass myBlogLog MicroID für die eigenen Profilseiten einsetzt (bsp.: www.mybloglog.com/buzz/members/pfefferle/) habe ich mich gefragt, warum myBlogLog MicroIDs nur anbietet, nicht aber für die Verifizierung der Blogs verwendet.

Aber zuerst mal eine kurze Einführung. MicroID ist eine einfache Möglichkeit, den Besitz von Webseiten zu validieren.

MicroID enables anyone to claim verifiable ownership over content hosted anywhere on the web (social networking sites, discussion forums, blogs, etc.).

Das Prinzip ist einfach, es wird ein Hash-Wert aus zwei unterschiedlichen URLs (auch Pseudo-URLs wie z.B. „mailto:“ oder „xmpp://“ sind möglich) gebildet und als Metatag in die Webseite eingebunden.

hash = sha1(
    sha1( "mailto:mustermann@example.com" ) 
    + 
    sha1( "http://www.example.com/" ) 
  )Code-Sprache: JavaScript (javascript)

Alternativ zu sha1 kann z.B. auch MD5 verwendet werden. Der Aufbau des Metatags sieht folgendermassen aus uri+uri:algo:hash

<meta name="microid" 
  content="mailto+http:sha1:
    ba37d92454792b65838c9827a8d75171c7241924" />Code-Sprache: HTML, XML (xml)

Der Vorteil eines proprietären Formats im Gegensatz zu MicroID

Was die genauen Gründe dafür sind, dass myBlogLog ein eigenes Format verwendet weiß ich natürlich nicht, aber schaut man sich MicroID etwas genauer an, findet man doch einige kleine Problemchen.

Eigentlich ist es ja nur ein wirkliches Problem, und zwar die URL… Eine URL kann man auf zu viele verschieden Weisen schreiben, als dass sie eine valide ID abgeben könnte:

  • http://example.com
  • http://www.example.com
  • http://example.com/

Zusammen mit der E-Mail – Adresse mustermann@example.com bekommt man drei verschiedene Hash-Werte:

  • 19358536d8c443614bc7d861f4b050ee34a549b9
  • 05c732700bfa89cd234bb7fc08cb673f7c0d88b8
  • 9275b4dcd7cc2c997b2a5249420b422e937d36e0

Das heißt, es kommt immer darauf an wie der Benutzer seine URL bei einem entsprechenden Service angibt. Ist für den Metatag der Webseite http://example.com verwendet und beim Service http://www.example.com/ angegeben worden, kann die Webseite nicht verifiziert werden, da sich die Hash-Werte unterscheiden.

Lösungsvorschläge

Eine mögliche Lösung wäre alle denkbaren URLs auszuprobieren, was nicht sehr performant wäre und eine menge Zeit beanspruchen würde. Die (meiner Meinung nach) bessere Lösung wäre eine Art „service catalogue“ an, in dem festgelegt ist wie z.B. die von myBlogLog verwendete MicroID-URL aussieht.

Ein Beispiel: http://www.mybloglog.com/buzz/members/Username/

Das Problem bezieht sich natürlich nur auf Services/Communities, bei denen man keinen Einfluss auf die MicroID hat. Bei persönlichen Weblogs ist das natürlich was anderes, da die URL und der Matatag vom Benutzer selbst angelegt werden.

Falls jemand noch nen tollen Lösungsvorschlag hätte wäre ich sehr dankbar, weil ich MicroID trotz allem gerne einsetzen würde… Das Prinzip ist einfach so schön simpel 🙂

8 Kommentare zu “Das kleine Problem mit MicroIDs

  1. Ein Problem von MicroID gut erkannt. 🙂 Ich habe vor längerer Zeit mal vergeblich versucht, Last.fm bei ClaimID zu verifizieren. Das Problem war tatsächlich der Trailing Slash.

    In der OpenID Spezifikation wird das Thema „Normalisation“ von URLs behandelt. Könnte man natürlich auch bei MicroID machen. Aber ich denke mal, dass das niemand aufgrund der vorhandenen Einfachheit von MicroID wirklich implementieren möchte.

    Man sollte auch bedenken, dass MicroID nicht dazu gedacht ist, so etwas wie ein Trust System zu sein. Es ist nur ein Indikator, der darauf hinweist, dass jemand wirklich Inhaber dieser URL ist. Aber ich gebe ja zu, dass ich auch immer schreie, wenn jemand statt MicroID ein proprietäres System nutzt. 😉

  2. @Carsten: Trotz allen Nachteilen ist es halt immernoch ein offener und dokumentierter „Standard“, der (wegen der Wiederverwendbarkeit) in jedem Fall nützlicher ist als ein proprietäres Format.

    Ich hab übrigens auch grad mal das von dir erwähnte „MyOpenID for Domains“ ausprobrobiert und rate mal was für die verifizierung der Domain benutzt wurde… myOpenID ist leider genau wie myBlogLog, sie bieten zwar alle möglichen Offenen-Standards an, nutzen selbst aber leider nur wenige:

    You have chosen web page validation. Put the following text anywhere in a document at http://example.org/some-path.html

    Wo es sich doch gerade in diesem Fall anbieten würde eine MicroID zu verwenden. Statt mich aufzufordern eine HTML mit speziellem Inhalt hochzuladen wäre es doch viel eleganter (und einfacher), mir (wie bei ClaimID) eine MicroID zu generieren die ich in den Header meine Seite einbinden muss und eventuell sogar noch für andere Dienste nutzen könnte.

  3. Ach, hätte ich das doch mal bis zum Ende durchspielen sollen. Ich finde da momentan keine Verwendung für und habe bei der DNS Konfiguration abgebrochen. Mal mein Posting ergänzen. 😉

  4. Was ist an URL-Normalisierung so schwer? Das sind nur ein paar URLs, von denen man SHA-1- oder MD5-Werte berechnen muß…

    Übrigens gibts auch noch (zum Glück nur selten) das w.- und das m.-Prefix 😉

    Davon abgesehen würde ich vorschlagen, dem „Use my hCard“-Plugin einen anderen User-Agent als „Python-urllib/1.16“ zu verpassen, denn der ist bei mir geblockt.

  5. Weil ich grade darüber gestolpert bin: Ich habe mir mal eine solche MicroID per Shellscript generiert und bin da über eine Kleinigkeit gestolpert.
    ———————————————–
    #!/bin/bash
    u1=“mailto:mustermann@example.com“
    u2=“http://www.example.com“

    s1=`echo -n $u1 | sha1sum | cut -d‘ ‚ -f1`
    s2=`echo -n $u2 | sha1sum | cut -d‘ ‚ -f1`
    s=`echo -n „$s1$s2″ | sha1sum | cut -d‘ ‚ -f1`
    echo -n “
    ——————————————————–
    Das -n beim echo ist wichtig, sonst wird ein \n angehängt und von sha1sum mitverwurschtelt 🙂

Schreibe einen Kommentar

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