Zusammenfassung

  • RFC 3043 schlug urn:pin als dauerhaften Namensraum vor, mit dem sich Personen und Organisationen anwendungsübergreifend identifizieren ließen.
  • Außerhalb des internen Resolvers von Network Solutions blieb die Struktur der Kennungen opak; das Dokument erklärte die Resolver des Unternehmens für maßgeblich. Eine globale Syntax machte die Auflösungsbefugnis nicht ebenso übertragbar.

Es ging nicht bloß darum, einer Person ein dauerhaftes Etikett zu geben. Eine Referenz sollte auch dann brauchbar bleiben, wenn sich E-Mail-Adresse, Nachname, Arbeitgeber, Internetanbieter oder sogar das ursprünglich vergebende System änderten. Network Solutions beschrieb dieses Problem in RFC 3043 vom Januar 2001 anhand von Verzeichnisdiensten und elektronischem Handel: Zwei Einträge sollten selbst bei ähnlichen Beschreibungsdaten unterscheidbar sein, und derselbe Mensch oder dieselbe Organisation sollte über längere Zeit wiederauffindbar bleiben.

Als Lösung schlug das Unternehmen den Personal Internet Name (PIN) vor, dargestellt als Uniform Resource Name im Namensraum pin. Die Beispiele der RFC sind kompakte Kennungen wie urn:pin:bs4321234 und keine Zeichenfolgen, die Nachnamen oder Firmennamen offenlegen. Der namensspezifische Teil, die NSS, wurde als flacher alphanumerischer Raum beschrieben. Entscheidend war der Zusatz, dass seine interne Struktur außerhalb des internen Resolvers von Network Solutions nicht erkennbar sei und extern weder erschlossen noch als verlässlich angenommen werden dürfe. Die Opazität war eine Designgrenze, keine Einladung, die Zeichenfolge zu entschlüsseln.

Diese Trennung hatte einen praktischen Nutzen. Eine Anwendung konnte eine stabile Referenz weitergeben, ohne eine veränderliche E-Mail-Adresse einzubetten oder von einer lokalen Datensatznummer eines bestimmten Verzeichnisses abhängig zu sein. Laut RFC sollte eine Kennung nie neu vergeben werden; ihre Bindung an die benannte Person oder Organisation sollte trotz Namensänderung, Unternehmensumstrukturierung, Tod oder Auflösung dauerhaft sein. Die RFC verwies außerdem auf einen standardisierten URN-Auflösungsmechanismus, über den andere Anwendungen PINs offen und ohne proprietäre Bindung referenzieren und auflösen könnten.

Die Registrierungsvorlage zog jedoch eine zweite Grenze: Wer durfte festlegen, was ein PIN bedeutete? Network Solutions vergab Kennungen über ein proprietäres Registrierungssystem und erklärte, dieses garantiere die Eindeutigkeit. Der damalige Algorithmus setzte bei der zuletzt vergebenen Nummer an und erhöhte sie um eine positive ganze Zahl; eine spätere Änderung blieb ausdrücklich möglich. Als Auflösungsinstanz nannte das Dokument die URN-Resolver von Network Solutions. Eine Auflösung über einen anderen Anbieter sei fehleranfällig und nicht maßgeblich.

Darin liegt das Portabilitätsparadox. Das Token ließ sich in eine Anwendung außerhalb des ursprünglichen Verzeichnisses kopieren. Eine externe Anwendung konnte seine Struktur aber weder selbstständig ableiten noch allein durch Parsen eine maßgebliche Bindung behaupten. Portabilität der Referenz und Portabilität der Autorität sind verschiedene Eigenschaften. Das Format überschritt Organisationsgrenzen leichter als die Befugnis, die dahinterstehende Person oder Organisation zu bestätigen.

Das Problem ist nicht auf pin beschränkt. Ein Namensraum kann Referenzen weltweit unterscheidbar machen und zugleich Vergabe, Berichtigung, Auflösung und Streitfälle von einer zuständigen Stelle abhängig lassen. Das kann ein vertretbarer Kompromiss sein: Opazität erhält interne Flexibilität, eine Vergabestelle koordiniert Eindeutigkeit, und ein benannter Resolver gibt Anwendungen eine klare Instanz. Doch damit konzentriert sich auch das Kontinuitätsrisiko. Sollen Kennungen den Dienst oder die Organisation überdauern, die sie auflöst, braucht es Regeln für Nachfolge, Datenexport, strittige Identitäten und Prüfung bei Unerreichbarkeit des benannten Resolvers. RFC 3043 beschreibt Vergabe und Auflösung, belegt aber nicht, dass solche Kontinuitätsvorkehrungen existierten.

Auch der Dokumentstatus ist genau zu unterscheiden. Der IETF Datatracker führt RFC 3043 heute als informativen RFC im Legacy-Stream, ohne formalen Status im IETF-Standardisierungsprozess. Zugleich steht pin im aktuellen IANA-URN-Namensraumregister weiterhin in der Tabelle formaler Namensräume; als Referenz dient RFC 3043. Das sind Einträge zu unterschiedlichen Fragen: der Status eines RFC im Standardisierungsprozess ist nicht dasselbe wie ein Eintrag im IANA-Register. Keiner von beiden belegt für sich, dass heute ein Dienst betrieben wird oder die Kennung aktuell verwendet wird.

Die historische Lehre lautet nicht, dass zentrale Resolver grundsätzlich schlecht seien. Dauerhafte Kennungen beheben ein Problem: Referenzen brechen, wenn Beschreibung oder Speicherort wechseln. Sie beseitigen aber nicht automatisch die Abhängigkeit von der Institution, die den Namen vergibt oder seine maßgebliche Auflösung bestätigt. RFC 3043 machte diese Trennung in der eigenen Vorlage ungewöhnlich deutlich. Ein dauerhafter Name kann weiter reisen als sein Vertrauensanker.

Wer zugleich Dauerhaftigkeit und Offenheit verspricht, muss deshalb nicht nur das Namensformat festlegen, sondern auch sagen, wer die Bindung prüfen darf, wie Befugnisse übertragen werden und was bleibt, wenn der ursprüngliche Resolver ausfällt oder verschwindet.