Blogging & Offenes Web

WebFinger für eine persönliche Website — Eine Domain zum Profil führen lassen

Geschrieben von Adam Muiz Aktualisiert: 13 Nov 2026 7 Min. gelesen
WebFinger für eine persönliche Website — Eine Domain zum Profil führen lassen

WebFinger für eine persönliche Website — Eine Domain zum Profil führen lassen

Eine persönliche Website kann eine Profilseite, eine Autoren-URL, einen Feed und vielleicht ein Konto bei einem anderen Dienst haben. Menschen finden diese Verweise meist, indem sie die Seite lesen. Software hat diesen Luxus nicht. Wenn sie acct:[email protected] erhält, welche URL soll sie anfordern?

WebFinger ist eine Antwort auf dieses Discovery-Problem. Es bietet einem Client einen standardisierten Ort, um eine Domain nach Informationen über eine durch eine URI identifizierte Entität zu fragen. Das Protokoll ist klein genug für eine verständliche Einführung, wird aber leicht missverstanden: WebFinger ist ein Verzeichnis-ähnliches Discovery-Protokoll und kein Beweis dafür, dass eine Person eine Identität kontrolliert.

Das Problem ist Discovery, nicht Login

Menschen kommen mit Namen zurecht, die verständlich, aber unvollständig sind. „Alice bei example.com“ ist lesbar, verrät aber nicht, ob ihr Profil unter /alice, /users/alice oder auf einem anderen Host liegt. Ein Client, der URL-Pfade errät, wird an das interne Design einer Website gekoppelt.

RFC 7033 definiert WebFinger als Möglichkeit, Informationen über Personen oder andere Entitäten mit standardmäßigen HTTP-Methoden zu entdecken. Das angefragte Objekt wird als URI dargestellt. Die Antwort ist ein JSON Resource Descriptor, meist JRD genannt, mit Feldern wie subject, aliases, properties und links.

RFC 7033 weist außerdem darauf hin, dass das JRD-Format ursprünglich in RFC 6415 eingeführt wurde. Diese Vorgeschichte ist nützlich, aber das WebFinger-Protokoll definiert, wie dieser Descriptor für seine eigenen Anwendungen angefragt und interpretiert wird.

Diese Unterscheidung ist wichtig. Der Client fragt: „Welche Links und Metadaten veröffentlicht dieser Dienst für diesen Identifier?“ Er fragt nicht: „Kannst du kryptografisch beweisen, dass diese Person wirklich diese Identität besitzt?“ Authentication und Authorization benötigen getrennte Mechanismen.

So funktioniert eine WebFinger-Anfrage

WebFinger verwendet den Well-Known-Pfad /.well-known/webfinger. RFC 8615 beschreibt /.well-known/ als reserviertes Pfadpräfix für anwendungsspezifische Metadatenorte. RFC 7033 definiert darunter die WebFinger-Ressource.

Ein Client sendet eine GET-Anfrage mit dem Query-Parameter resource. Eine illustrative Anfrage sieht so aus:

GET /.well-known/webfinger?resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
Accept: application/jrd+json

Die Percent-Encoding-Schreibweise ist nicht dekorativ. Der Wert des Parameters ist die URI acct:[email protected]; Doppelpunkt und At-Zeichen werden innerhalb des Query-Strings codiert. In einem echten Client sollte dafür eine URI- oder Query-Bibliothek verwendet werden, statt den String von Hand zusammenzusetzen.

Der Host ist relevant. Normalerweise wird die Anfrage an den Host der Ziel-URI gesendet. Ein Dienst kann WebFinger über eine gehostete Infrastruktur anbieten, aber Weiterleitungen müssen bei HTTPS bleiben und der Client muss Zertifikate validieren. RFC 7033 verlangt ausdrücklich, eine fehlgeschlagene sichere Anfrage nicht über unverschlüsseltes HTTP zu wiederholen.

Die JRD-Antwort lesen

Eine minimale Antwort könnte so aussehen:

{
  "subject": "acct:[email protected]",
  "aliases": [
    "https://example.com/about/alice"
  ],
  "links": [
    {
      "rel": "profile-page",
      "type": "text/html",
      "href": "https://example.com/about/alice"
    },
    {
      "rel": "author",
      "type": "application/atom+xml",
      "href": "https://example.com/feed.xml"
    }
  ]
}

Das ist eine illustrative Antwort und keine Behauptung über einen aktiven Endpoint. Wichtig ist ihre Struktur:

  • subject identifiziert die vom JRD beschriebene Entität. Es kann eine kanonische Form verwenden, die vom angefragten Wert abweicht.
  • aliases listet weitere URI-Strings auf, die dieselbe Entität identifizieren, sofern die Anwendung diese Beziehung definiert.
  • links enthält Link-Relationsobjekte. rel beschreibt die Beziehung, während href auf ein Ziel zeigt und type dessen Medientyp angibt.

Die Bedeutung eines Links wird nicht von WebFinger selbst erfunden. Anwendungen müssen URI-Schema, Relationstypen und erwartete Properties definieren. Ein Client sollte einen Link daher anhand einer verstandenen Semantik auswählen und nicht einfach die erste URL des Arrays nehmen.

Warum ActivityPub WebFinger verwendet

ActivityPub gibt Actors weltweit erreichbare Identifier, meistens HTTPS-URLs. Das ist nützlich, sobald ein Client die Actor-URL kennt. Eine Erwähnung wie @[email protected] beginnt jedoch mit einem Handle und nicht unbedingt mit der Actor-URL.

ActivityPub definiert das soziale Protokoll und die Actor-Darstellung. WebFinger kann als Discovery-Schritt dienen, der ein Handle im Account-Format auf eine Actor-URL abbildet. Die Mastodon-Dokumentation zeigt eine konkrete Implementierung: Mastodon fragt den WebFinger-Endpoint der Domain nach einer acct:-URI ab und sucht anschließend einen Link mit der Relation self und einem ActivityPub-JSON-Typ.

Die beiden Ebenen sollten nicht verwechselt werden. RFC 7033 ist anwendungsneutral. Eine ActivityPub-Implementierung ergänzt eigene Regeln dafür, welcher JRD-Link als Actor gilt. Eine persönliche Website kann WebFinger implementieren, ohne ein ActivityPub-Server zu werden, ebenso wie sie einen RSS-Feed veröffentlichen kann, ohne jedes Protokoll zu implementieren, das RSS konsumiert.

Was eine persönliche Website veröffentlichen könnte

Eine kleine Publishing-Website könnte WebFinger nutzen, um bewusst eine begrenzte Zahl öffentlicher Beziehungen anzubieten:

  • Einen profile-page-Link zur kanonischen Autorenseite.
  • Einen author- oder feed-Link zu einem öffentlichen Feed, wenn dieser für Clients nützlich ist.
  • Einen anwendungsspezifischen Link nur dann, wenn seine Semantik und Datenschutzregeln klar definiert sind.

Das entscheidende Wort ist öffentlich. RFC 7033 warnt davor, dass WebFinger persönliche Informationen leichter auffindbar machen kann, und verlangt eine ausdrückliche Zustimmung für die Veröffentlichung persönlicher Daten. Eine Antwort muss keine E-Mail-Adresse, Telefonnummer, Position oder jedes soziale Profil enthalten, nur weil das Format Links aufnehmen kann.

Bei einer eigenen PHP-Website könnte die technische Grenze einfach aussehen: den Well-Known-Pfad routen, die resource-URI validieren, nur öffentliche Beziehungen abfragen, ein JRD mit dem richtigen Medientyp ausgeben und eine bewusste CORS-Regel setzen. Das ist ein Architekturentwurf und keine fertige Implementierung. Lookup-Regeln, Speichermodell, Cache-Header und Fehlerbehandlung müssen weiterhin geplant werden.

Sicherheits- und Betriebsgrenzen

WebFinger ist maschinenlesbare Metadaten und schafft damit eine stabile Discovery-Oberfläche. Die folgenden Grenzen sind wichtiger als ein besonders cleverer Endpoint:

  • HTTPS verwenden. Das Protokoll verlangt sichere Anfragen und gültige Zertifikate. Bei einem HTTPS-Fehler nicht still auf HTTP zurückfallen.
  • Den Well-Known-Pfad kontrollieren. RFC 8615 weist darauf hin, dass Well-Known-Orte den gesamten Origin repräsentieren. Eine nicht zugehörige Anwendung oder ein beschreibbares Verzeichnis darf die Antwort nicht übernehmen können.
  • Links sorgfältig begrenzen. Ein Link ist ein Verweis und keine universelle Sicherheitsaussage über jeden verwandten Hostnamen.
  • CORS bewusst konfigurieren. RFC 7033 behandelt Browserzugriffe und erlaubt für öffentliche Daten ein weites CORS, während sensible Deployments eine engere Origin-Regel benötigen können.
  • Gewöhnlichen Missbrauch einplanen. Öffentliche Discovery-Endpoints können übermäßig viele Anfragen erhalten. Caching und vernünftige Limits sind Betriebsentscheidungen, keine Protokollgarantien.
  • Discovery nicht Authentication nennen. Ein bösartiger oder kompromittierter Server kann irreführende Metadaten veröffentlichen. Für einen Besitznachweis braucht ein Client eine getrennte Verifikationsmethode.

Wann lohnt sich die Erweiterung?

WebFinger passt, wenn eine Website einen Account-Identifier besitzt, den externe Software auflösen muss, oder wenn ein Protokoll verwendet wird, das WebFinger erwartet. Es kann auch eine gute Grundlage für Experimente mit Open-Web-Identität sein, solange die veröffentlichten Daten bewusst knapp bleiben.

Wahrscheinlich unnötig ist WebFinger, wenn es keine Account-Identifier, keine externen Clients und kein konsumierendes Protokoll gibt. Ein Endpoint, den niemand abfragt, vergrößert die Oberfläche, ohne eine Website automatisch offener zu machen. Eine normale Autorenseite mit klaren HTML-Links kann die ehrlichere Lösung sein.

Es gibt außerdem eine Wartungsfrage. Eine WebFinger-Antwort sollte nicht auf veraltete Profil-URLs, alte Feeds oder eine Identität zeigen, die unbemerkt den Besitzer gewechselt hat. Wenn eine Website diese Beziehungen nicht aktuell halten kann, ist ein maschinenlesbarer Endpoint möglicherweise schlechter als keiner.

Fazit

WebFinger löst ein enges, aber reales Problem: Es übersetzt einen URI-förmigen Identifier in Metadaten und Links, die Software verstehen kann. Sein Endpoint ist vorhersehbar, sein Antwortformat strukturiert, und Anwendungen wie ActivityPub zeigen, warum die Trennung zwischen Handle und Profil-URL nützlich ist.

Das Protokoll erzeugt jedoch kein Vertrauen. Es bestätigt keine Identität, autorisiert keinen Client und macht aus einer persönlichen Website kein föderiertes Netzwerk. Für eine kleine Website ist es sinnvoll, mit der Frage „Wer muss was entdecken?“ zu beginnen und nur Beziehungen zu veröffentlichen, für die es eine klare Antwort gibt.

References